Details

    • Type: Task
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 2.2
    • Fix Version/s: 2.3
    • Component/s: Development, Roadmap
    • Security Level: Public (Public: Anyone can view)
    • Labels:
      None
    • Rice Module:
      KRAD, KEW
    • KRAD Feature Area:
      KEW Integration
    • Application Requirement:
      KS
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required
    • Include in Release Notes?:
      Yes

      Description

      "fire and forget"" + audit log

      synchronous call to workflow that immediately calls the...

      Larry will talk to Dan E. about getting a Rice jira filed. Getting close to having a high level design of fundamental changes needed to the maint framework to hand off to rice.

        Attachments

          Issue Links

            Activity

            Hide
            wwashington William Washington (Inactive) added a comment -

            [2/1/13 12:00:29 PM] Larry Symms: We need a process for recording (think audit trail) of actions taken on a Data Dicionary based Object.  These actions would be performd on a KRAD form with a button that performs an immediate action without workflow.  The problem we've had implementing this with KEW (which does the logging we need) is that KEW is entirely asynchronous.  We need the action to be taken immediately, even if the auditing is done asynchronously.  Although, I think synchronous on the logging is necessary too.

            Show
            wwashington William Washington (Inactive) added a comment - [2/1/13 12:00:29 PM] Larry Symms: We need a process for recording (think audit trail) of actions taken on a Data Dicionary based Object.  These actions would be performd on a KRAD form with a button that performs an immediate action without workflow.  The problem we've had implementing this with KEW (which does the logging we need) is that KEW is entirely asynchronous.  We need the action to be taken immediately, even if the auditing is done asynchronously.  Although, I think synchronous on the logging is necessary too.
            Hide
            ewestfal Eric Westfall added a comment -

            If you don't define any routing/approval for a document, it's possible for KEW to process the document synchronously. The KNS didn't really handle that properly (since it assumed document handling was async) but it probably could be coded properly in the KRAD framework.

            Essentially, in this case when you use the KEW api to submit/route a document, the document will immediately transition to the "FINAL" status.

            Regardless, there's probably a question of whether or not for your specific case if this is really a desirable use of the workflow engine or not.

            Show
            ewestfal Eric Westfall added a comment - If you don't define any routing/approval for a document, it's possible for KEW to process the document synchronously. The KNS didn't really handle that properly (since it assumed document handling was async) but it probably could be coded properly in the KRAD framework. Essentially, in this case when you use the KEW api to submit/route a document, the document will immediately transition to the "FINAL" status. Regardless, there's probably a question of whether or not for your specific case if this is really a desirable use of the workflow engine or not.
            Hide
            wwashington William Washington (Inactive) added a comment -

            Additional comments (I'll also route Larry to this jira so that he can comment himself):

            [2/1/13 12:05:48 PM] Larry Symms: [if we] do this ourselves but that would mean providing screens for lookups of transactions which KEW already handles quite nicely

            Show
            wwashington William Washington (Inactive) added a comment - Additional comments (I'll also route Larry to this jira so that he can comment himself): [2/1/13 12:05:48 PM] Larry Symms: [if we] do this ourselves but that would mean providing screens for lookups of transactions which KEW already handles quite nicely
            Hide
            wwashington William Washington (Inactive) added a comment -

            I need to confirm: (1) that all current page flow issues will be fixed by KULRICE-8894, and (2) how this relates to recent KRAD transactional doc support.

            Show
            wwashington William Washington (Inactive) added a comment - I need to confirm: (1) that all current page flow issues will be fixed by KULRICE-8894 , and (2) how this relates to recent KRAD transactional doc support.
            Hide
            masargen Matt Sargent added a comment -

            We need a couple of scenarios or examples of how this would/is desired to work work.

            -Matt

            Show
            masargen Matt Sargent added a comment - We need a couple of scenarios or examples of how this would/is desired to work work. -Matt
            Hide
            gilesp Peter Giles (Inactive) added a comment -

            Also useful would be specifics on the unwanted behaviors that this would address.

            Show
            gilesp Peter Giles (Inactive) added a comment - Also useful would be specifics on the unwanted behaviors that this would address.
            Hide
            lsymms Larry Symms added a comment -

            unwanted behaviors: asynchronous write via post processor in external system causes us to either notify the user that their request is enroute or to do timed polling of KEW to get document status until status is final. This could be managed entirely from our application but we don't get document search or a trail of activity. We'd basically have to duplicate a large chunk of KEW to do that.

            Show
            lsymms Larry Symms added a comment - unwanted behaviors: asynchronous write via post processor in external system causes us to either notify the user that their request is enroute or to do timed polling of KEW to get document status until status is final. This could be managed entirely from our application but we don't get document search or a trail of activity. We'd basically have to duplicate a large chunk of KEW to do that.
            Hide
            masargen Matt Sargent added a comment - - edited

            From the meeting today Larry and Co. should try the below for an empty route path...
            http://svn.kuali.org/repos/rice/trunk/it/kew/src/test/resources/org/kuali/rice/kew/engine/EngineConfig.xml
            search that file for "EmptyProcessDocType"
            essentially, just define route paths section as: <routePaths/>
            and
            http://site.kuali.org/rice/2.2.0/apidocs/org/kuali/rice/kew/api/WorkflowDocument.html#logAnnotation%28java.lang.String%29
            for the logging as annotations.

            Show
            masargen Matt Sargent added a comment - - edited From the meeting today Larry and Co. should try the below for an empty route path... http://svn.kuali.org/repos/rice/trunk/it/kew/src/test/resources/org/kuali/rice/kew/engine/EngineConfig.xml search that file for "EmptyProcessDocType" essentially, just define route paths section as: <routePaths/> and http://site.kuali.org/rice/2.2.0/apidocs/org/kuali/rice/kew/api/WorkflowDocument.html#logAnnotation%28java.lang.String%29 for the logging as annotations.
            Hide
            masargen Matt Sargent added a comment -

            Eric Westfall: Larry/Dan, here's a code sample showing the workflow api interaction for these documents:

            http://svn.kuali.org/repos/rice/trunk/it/kew/src/test/java/org/kuali/rice/kew/engine/EmptyProcessTest.java

            You can see from the test there that it calls document.route and then can immediately ascertain the document has gone final

            i also verified that it is infact calling the post processor so you'll get three status transitions: (I)nitiated -> En(R)oute -> (P)rocessed -> (F)inal

            Show
            masargen Matt Sargent added a comment - Eric Westfall: Larry/Dan, here's a code sample showing the workflow api interaction for these documents: http://svn.kuali.org/repos/rice/trunk/it/kew/src/test/java/org/kuali/rice/kew/engine/EmptyProcessTest.java You can see from the test there that it calls document.route and then can immediately ascertain the document has gone final i also verified that it is infact calling the post processor so you'll get three status transitions: (I)nitiated -> En(R)oute -> (P)rocessed -> (F)inal
            Hide
            lsymms Larry Symms added a comment -

            Fixed. Will test when KS upgrades to 2.3.0 M1 in April

            Show
            lsymms Larry Symms added a comment - Fixed. Will test when KS upgrades to 2.3.0 M1 in April

              People

              • Assignee:
                Unassigned
                Reporter:
                wwashington William Washington (Inactive)
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: