• Type: Improvement Improvement
    • Status: Closed Closed
    • Priority: Minor Minor
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: Not version specific
    • Component/s: Development
    • Labels:
    • Similar issues:
      KULRICE-2196Create new workflow user service which uses KIM APIs
      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
      KULRICE-8696Some KEW API classes/services are not accessible via any service locator
      KULRICE-1155expose doc search capabilities via workflow api
      KULRICE-5158Update Group service to use new Criteria API
      KULRICE-1063Split out BOs and KIMService into a new kim-api maven module
      KULRICE-7642RoleResponsibilityAction APIs are insufficient
      KULRICE-967Add ability to query workflow for document status via the API
      KULRICE-12286New KIM API to bulk fetch display name information
      KULRICE-5326Get rid of KualiWorkflowInfo, replace with usage of standard KEW apis
    • Rice Module:


      We need a new, non-document-centric, workflow API that deals with things like processes, work lists (action lists), and work items (a.k.a., tasks, action requests, etc.).

      While the document-centric API works for document-centric workflows, it does not support the following things elegantly:

      • workflows involving distinct forms/documents
      • workflows requiring distinct security on a per-form, or per-action-request basis (either the security changes at the field level on a per-action-request basis, or the security is manifested by requiring a different input form altogether, which itself intrinsically embodies different security based on what fields are defined on the form)
      • non-Java/non-OO clients; this is possible but a little bit clumsy as the current API involves construction and additions of multiple objects (e.g. addition of attribute objects vs. map-like put(string, string))
      • composing a coherent "business process" from multiple documents; currently business processes that involve multiple forms/documents are implemented by separate DocTypes which the application is responsible for integrating into a seamless user interaction.
      • migration path from workflow products that support the above

      I believe the existing WorkflowDocument API is essentially a degenerate case of the above (i.e., there is only ever a single set of form data, namely that described globally for the DocType), so we should be able to wrap the existing API, and then implement something like BEPL behind the scenes under the same API.

      I believe we will want something that takes cues from the OKI workflow OSID and OpenWFE and WebMethods Workflow APIs. All of these are essentially equivalent at the conceptual level (combination of processes, work list, and submittable work item with key/value fields).


        Aaron Hamid (Inactive) added a comment -

        euthanizing this issue

        Aaron Hamid (Inactive) added a comment - euthanizing this issue


          • Assignee:
            Aaron Hamid (Inactive)
            Aaron Hamid (Inactive)
          • Votes:
            0 Vote for this issue
            0 Start watching this issue


            • Created:

              Structure Helper Panel