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