Uploaded image for project: '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
    • Status: Closed
    • Priority: Blocker
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.0
    • Component/s: Development
    • Labels:
      None
    • 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.

        Attachments

          Issue Links

            Activity

            Hide
            ahamid 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
            ahamid 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
            ewestfal 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
            ewestfal 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
            ahamid 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
            ahamid 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
            gilesp 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
            gilesp 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
            gilesp 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
            gilesp 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
            ewestfal Eric Westfall added a comment -

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

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

              People

              • Assignee:
                gilesp Peter Giles (Inactive)
                Reporter:
                ewestfal 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