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

Combine SimpleDocumentActionsWebService with WorkflowDocumentActionsService, review and approve the new contract for workflow services


    • Similar issues:
      KULRICE-5369Combine Group and GroupUpate services
      KULRICE-4551Expose new service methods in SimpleDocumentActionsWebService including Super User actions and Adhoc revocation
      KULRICE-4505Decide on and document guidelines for how service contracts, DTOs, and implementations should be versioned
      KULRICE-5230Add ability to fetch a service from the ServiceBus by a combination of service name and application id
      KULRICE-7523Deprecate KRMS DefinitionContracts, extend new Contracts
      KULRICE-2196Create new workflow user service which uses KIM APIs
      KULRICE-889New workflow API
      KULRICE-7573The standalone version of WorkflowDocumentActionsService should always be called when kew.mode is Thin or Remote
      KULRICE-8360Create a new basic authentication service
      KULRICE-1153add api methods to identify all the places a given user appears in workflow, to remove a user from workflow, and to replace a user in workflow
    • Rice Module:
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Review Completed


      There is no real reason to have two separate services for this purpose. Instead they should be combined into a single service (basically move the simple operations into WorkflowDocumentActionsService).

      However I think we can improve it beyond that. Currently the simple actions service provides for simple service calls to be invoked without passing all of the extra RouteHeaderDTO information which is passed into WorkflowDocumentActionsService. A better approach might be to have operations like the following:

      public RouteHeaderDTO approveAndUpdate(
      @WebParam(name = "docId") String docId,
      @WebParam(name = "principalId") String principalId,
      @WebParam(name = "annotation") String annotation,
      @WebParam(name = "routeHeaderUpdate") RouteHeaderUpdateDTO routeHeaderUpdate

      In this case, RouteHeaderUpdateDTO would be optional but would allow for the updating of things like XML document content, document title, etc.

      Then for simple cases where updates did not need to be based and the result didn't need to be read we could have an operation like the following:

      public void approve(
      @WebParam(name = "docId") String docId,
      @WebParam(name = "principalId") String principalId,
      @WebParam(name = "annotation") String annotation

      Then on the java client we can code WorkflowDocument so that it's smart enough to know which of these methods to call based on updates to the data stored in the WorkflowDocument by the client application.

      In general, I think that we will want to go through a joint effort to design the workflow document services so that they have all of the appropriate operations and provide the desired level of functionality. This should be done in conjunction with the KTI.

        Issue Links



            • Assignee:
              Eric Westfall
              Eric Westfall
            • Votes:
              0 Vote for this issue
              0 Start watching this issue


              • Created:

                Time Tracking

                Original Estimate - 4 days
                Remaining Estimate - 4 days
                Time Spent - Not Specified
                Not Specified

                  Structure Helper Panel