Kuali Rice Development
  1. Kuali Rice Development
  2. KULRICE-2729

The "Future Action Requests" tab on the Route Log does not work properly with a client application using "embedded" mode

    Details

    • Type: Bug Fix Bug Fix
    • Status: Closed Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.0
    • Component/s: Development
    • Labels:
      None
    • Similar issues:
      KULRICE-7451Future Action Requests tab does not work when using standalone Rice server
      KULRICE-9146SuperUserAction tab does not load when using custom DocumentTypeAuthorizer implementation in embedded mode
      KULRICE-3603After a document is saved but before it is routed, the "Future Action Requests" tab on the doc's route log does not display any of the ad hoc requests
      KULRICE-8687Immediate Action Emails don't work on client applications using KEW in embedded mode
      KULRICE-12117Problems with "Future Action Requests" involving initiator routing
      KULRICE-3978time/date is irrelevant for future action requests
      KULRICE-3784KEW Thin Client integration does not work properly
      KULRICE-370Route Log panel shrinks when viewing future requests
      KULRICE-6516Document client applications requirements on what they need to do in order to ensure they remain compatible with future versions of Kuali Rice
      KULRICE-2641Future Action Requests section of route log shows all requests
    • Rice Module:
      KEW

      Description

      Currently, when the "Future Requests" show button is clicked, it initiates the workflow simulation engine to figure out where the document will route in the future.

      The issue with this is that this simulation executes on the standalone server. If the document against which we are running the simulation has a document type that has a "service namespace" that represents one of the embedded client applications (i.e. KFS, etc.) then we really want the simulation to execute within the embedded engine on that embedded client application. To that end, we should use the service bus to call back into the appropriate client application for the execution of this simulation.

      If you look at SuperUserAction you can see an example of how we are doing this with the WorkflowDocumentActions service. We want to do the same thing in the RouteLogAction but for the WorkflowUtilityService.

      One issue here though, we are using the SimulationEngine directly inside of the RouteLogAction. Instead what we will want to do is use the WorkflowUtilityService.routingReport method. Unfortunately, this method is a little bit wierd as it takes the simulated action requests and appends them onto the DocumentRouteHeaderValue object's action requests prior to generating the DocumentDetailDTO to return. The result of this is that the action requests which are generated end up getting interleaved on the DocumentDetailDTO with the non-generated ones. You can figure out which ones are generated by checking if the action request ID is a negative number.

      Also, DocumentDetailDTO has a collection of ActionRequestDTO objects where the Route Log is expecting to display ActionRequestValue objects. So some conversion needs to come into play here. To make it further complicated, Action Requests in KEW are arranged in a hierarchical fashion which is used to model roles and delegations. So the conversion from ActionRequestDTO to ActionRequestValue will need to take that into consideration.

      Also, it would be great if we could write some unit tests to test this aspect of WorkflowUtility.routingReport and also the conversion of ActionRequestDTOs into a proper hierarchical ActionRequest graph.

        Issue Links

          Activity

          Hide
          Aaron Hamid (Inactive) added a comment -

          Hi guys, we just ran into this with 0.9.2.1 at CU so it is good to find this will be getting enhanced/fixed. To go one step further we needed to support thin clients (where we can't call them over the bus to perform the route). I worked around this with an enhancement to the BSFRuleExpression (and HttpInvokerConnector) which runs the code in the context of the various server-side plugins so the server can use application-supplied plugin classes. I expect we will bring that back as an enhancement at some point.

          Show
          Aaron Hamid (Inactive) added a comment - Hi guys, we just ran into this with 0.9.2.1 at CU so it is good to find this will be getting enhanced/fixed. To go one step further we needed to support thin clients (where we can't call them over the bus to perform the route). I worked around this with an enhancement to the BSFRuleExpression (and HttpInvokerConnector) which runs the code in the context of the various server-side plugins so the server can use application-supplied plugin classes. I expect we will bring that back as an enhancement at some point.
          Hide
          Eric Westfall added a comment -

          Yes, we ran into it here at IU as well but haven't addressed it locally yet.

          I'm surprised you would need this for the thin client considering that all workflow engine processing happens on the server. Can you elaborate?

          Show
          Eric Westfall added a comment - Yes, we ran into it here at IU as well but haven't addressed it locally yet. I'm surprised you would need this for the thin client considering that all workflow engine processing happens on the server. Can you elaborate?
          Hide
          Aaron Hamid (Inactive) added a comment -

          Sure. Specifically this comes up when we have application document types that call arbitrary application-provided bus services (or just in general use application-provided classes). There are well defined plugin hooks in KEW for a few specific extension points, but not (as far as I could tell) for arbitrary code. We use named rule expressions with Groovy quite a bit, and these expressions use application-provided classes. From what you describe of your enhancement above, that would fix our problem for the case of invoking the simulation of KNS-based embedded apps from the server UI.

          But we also have (or intend to have) non-embedded-Rice applications, e.g. PHP and ColdFusion. I'm using the term "thin client" loosely - basically any application that doesn't embed Rice (and where I assume the approach above would not work), but instead goes through some web service layer. DocumentTypes for these applications have no choice but to run in the core standalone server [1]. What I did was create a composite classloader that contained the classloaders of all plugins (I'm not 100% comfortable with that but I don't know of a better solution), and set it on the BSFManager so the BSF script gets compiled and executed with that classloader, and has access to all plugin classes. I also had to hack HttpInvokerConnector because the underlying Spring HttpInvokerRequestExecutor switches the classloader back to the WebappClassLoader immediately prior to service invocation which yields ClassNotFoundErrors.

          Of course I may have missed the boat on this - maybe there is a better or existing way to solve this. [1] Now that I think of it, I suppose it would be possible to stand up "dummy" engines with message entities whose sole purpose is to process the thin clients' document types but that seems to be more work than solving it in the core.

          Show
          Aaron Hamid (Inactive) added a comment - Sure. Specifically this comes up when we have application document types that call arbitrary application-provided bus services (or just in general use application-provided classes). There are well defined plugin hooks in KEW for a few specific extension points, but not (as far as I could tell) for arbitrary code. We use named rule expressions with Groovy quite a bit, and these expressions use application-provided classes. From what you describe of your enhancement above, that would fix our problem for the case of invoking the simulation of KNS-based embedded apps from the server UI. But we also have (or intend to have) non-embedded-Rice applications, e.g. PHP and ColdFusion. I'm using the term "thin client" loosely - basically any application that doesn't embed Rice (and where I assume the approach above would not work), but instead goes through some web service layer. DocumentTypes for these applications have no choice but to run in the core standalone server [1] . What I did was create a composite classloader that contained the classloaders of all plugins (I'm not 100% comfortable with that but I don't know of a better solution), and set it on the BSFManager so the BSF script gets compiled and executed with that classloader, and has access to all plugin classes. I also had to hack HttpInvokerConnector because the underlying Spring HttpInvokerRequestExecutor switches the classloader back to the WebappClassLoader immediately prior to service invocation which yields ClassNotFoundErrors. Of course I may have missed the boat on this - maybe there is a better or existing way to solve this. [1] Now that I think of it, I suppose it would be possible to stand up "dummy" engines with message entities whose sole purpose is to process the thin clients' document types but that seems to be more work than solving it in the core.
          Hide
          Peter Giles (Inactive) added a comment -

          Committed the following:

          DTOConverter:

          • Added child interface RouteNodeInstanceLoader to allow adding
            RouteNodeInstances during convertActionRequestDTO(...).
          • Overloaded convertActionRequestDTO(...) to provide a method signature
            including a RouteNodeInstanceLoader parameter.
          • Modified populateActionRequest(...)
            + Now accepts a RouteNodeInstanceLoader parameter, and populates
            RouteNodeInstanceS with it if it's non-null.
            + Removed a check for a principalId or groupId that threw a RuntimeException,
            pushing this check out to RouteModuleRemoteAdapter.

          RouteModuleRemoteAdapter:

          • Added check in findActionRequests(DocumentRouteHeaderValue) that at least one
            of principalId or groupId is set, throwing a RuntimeException otherwise.
            + This was pushed out from DTOConverter.populateActionRequest(...)

          RouteLogAction:

          • Modified popluateRouteLogFutureRequests(...)
            + Now use WorkflowUtility to run the simulation instead of directly using
            SimulationEngine.
            + Reconstitutes the resulting DTOs into objects usable for rendering in the
            Route Log.
          • Added RouteNodeInstanceFabricator inner class.
            + Imports RouteNodeInstanceS from RouteNodeInstanceDTOs.
            + Implements DTOConverter.RouteNodeInstanceLoader

          Still need to add a unit test.

          Show
          Peter Giles (Inactive) added a comment - Committed the following: DTOConverter: Added child interface RouteNodeInstanceLoader to allow adding RouteNodeInstances during convertActionRequestDTO(...). Overloaded convertActionRequestDTO(...) to provide a method signature including a RouteNodeInstanceLoader parameter. Modified populateActionRequest(...) + Now accepts a RouteNodeInstanceLoader parameter, and populates RouteNodeInstanceS with it if it's non-null. + Removed a check for a principalId or groupId that threw a RuntimeException, pushing this check out to RouteModuleRemoteAdapter. RouteModuleRemoteAdapter: Added check in findActionRequests(DocumentRouteHeaderValue) that at least one of principalId or groupId is set, throwing a RuntimeException otherwise. + This was pushed out from DTOConverter.populateActionRequest(...) RouteLogAction: Modified popluateRouteLogFutureRequests(...) + Now use WorkflowUtility to run the simulation instead of directly using SimulationEngine. + Reconstitutes the resulting DTOs into objects usable for rendering in the Route Log. Added RouteNodeInstanceFabricator inner class. + Imports RouteNodeInstanceS from RouteNodeInstanceDTOs. + Implements DTOConverter.RouteNodeInstanceLoader Still need to add a unit test.
          Hide
          Peter Giles (Inactive) added a comment -

          RouteLogAction.java:

          • Fixed issue where existing action request IDs were not being correctly
            gathered (was causing non-future ActionRequestValues to be included)

          RouteLogActionTest:

          • initial commit of unit tests for RouteLogAction
            + currently only tests populateRouteLogFutureRequests

          ActionsConfig:

          • added test data for RouteLogActionTest
          Show
          Peter Giles (Inactive) added a comment - RouteLogAction.java: Fixed issue where existing action request IDs were not being correctly gathered (was causing non-future ActionRequestValues to be included) RouteLogActionTest: initial commit of unit tests for RouteLogAction + currently only tests populateRouteLogFutureRequests ActionsConfig: added test data for RouteLogActionTest
          Hide
          Eric Westfall added a comment -

          Bulk change of all Rice 1.0 issues to closed after public release.

          Show
          Eric Westfall added a comment - Bulk change of all Rice 1.0 issues to closed after public release.

            People

            • Assignee:
              Peter Giles (Inactive)
              Reporter:
              Eric Westfall
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - 4 days
                4d
                Remaining:
                Remaining Estimate - 4 days
                4d
                Logged:
                Time Spent - Not Specified
                Not Specified

                  Structure Helper Panel