xweld-workflow is an API which can be used to support workflow processing common in capital markets applications. Writing to the API provides your application with a pluggable workflow provider that may be swapped into or out of your application via configuration. A default implementaiton is uspported out of the box, and it's straightfoward to add new support for toher vendors like JBPM, Activity and Pega. Using xweld-workflow in your application results in reduced overhead in wiring up the workflow engine to the application, greatly reduces the lines of code you need to write, and as a result accelerates application development.
Primary Features and Benefits¶Features that make xweld-workflow an attractive mechanism for implementing workflow in your application include:
- A number of common workflow patterns are used in many financial applications. The xweld-workflow API makes it much easier to implement these patterns, and to implement them consistently.
- The workflow design process follows industry standards, using an established process of defining workflow into your application.
- Workflow history and logging can feed MIS reporting on workflow metrics.
- Workflow captures history and allows for attachments to workflow items, providing the capability of adding artifacts to workflow items out of the box.
A workflow item is the unit of work that moves through various states under the management of a workflow engine. At any given point, the item exists in exactly one state, and there is a configurable set of actions available that can move the item to a new state. For example, in Figure 1 below, a workflow item in state A may move to either state B or state C, depending on whether Action A to B or Action A to C is applied to the workflow item in State A.
To summarize: a workflow item moves through the various states by the application of actions.
Each workflow item includes:
- Details – the actual data content of the item (for example, for an accounting adjustment workflow item, the adjustment details)
- History – a history of the states it has passed through, based on auditing and versioning of the item throughout the process
- Attachments – any related files, URLs or any other binary data that has been associated with the item
- Methods to perform actions available to a particular user/role to move an item from its current state to a subsequent one
The screen shot below shows a sample application that models a 'task' under workflow as a workflow item.
A workflow item is shown as an Accounting Adjustment Task. The task inherits the history, description, attachments and actions from the <xweld/> abstract class WorkflowItem. On the left is shown a navigation pane that displays the list of items available to the current user.
A workflow engine is used to implement the configured actions available for a given user, role, and workflow item. It is the mechanism that transitions an item from one state to another when an action is applied. Based on a user’s role and the available actions for the current state, the engine supplies a list of actions that may be applied to an item.
Workflow Item Association and Assignment¶
A workflow item in a particular state is associated in the workflow design with one or more preconfigured roles that are responsible for handling the item in that state and executing an action to move it to the next state. All users with one of those roles are candidates to handle the item, but only one may do so. One user takes ownership of the item either by having it assigned to them or by self-assigning it. Once the item is assigned to the user, only that user may apply the next action to that item. Once an action is applied, the item then moves to the next state and appears as a candidate for ownership by a user in the next set of configured roles.For example:
- A user in a Sender role applies the Send action to a workflow item.
- The workflow item is displayed in the available items list for all users in a Receiver role.
- A user in the Receiver role takes ownership of the item (either it is assigned to them by another or is self-assigned).
- The owning user applies the Done action to close the item.
Packages and Classes¶
xweld-workflow includes the following packages:
- com.xweld.workflow.workflow – the public workflow API
The Attachment abstract class extends workflow capabilities to allow attachments to be uploaded and mapped to workflow items in the workflow engine. The types of attachments supported include XML/DOM document attachments and binary and file attachments. Once an attachment is attached to a workflow item, attachment details such as ID, Attachment Name, Properties, Source, Workflow Item, Description, and Attached By can be set and mapped as accessible entries for the workflow item.
The history class records for each workflow item the various state changes a workflow item transistions through in its lifetime, providing an audit trail of transactions on the workflow item.
The IWorkflowAction interface defines a unique workflow action in the xweld-workflow module by name.
The IWorkflowEngine interface defines the API to an implementation. The implementation of the engine is returned from the IWorkflowEngineFactory, which is driven by configuration.
IWorkflowItem represents a unit of work that transitions through various states by applying actions. IWorkflowItems are assigned to users, have a current state, a history, and optionally a set of attachments.
For more information, please contact us at firstname.lastname@example.org
Copyright © 1999-2014 Free North Alliance Inc. All Rights Reserved.
The contents of this web site, including all images, text, graphics and software, are the sole property of Free North Alliance Inc. and its agents. Unauthorized use or transmission is strictly forbidden by international copyright law.