Pattern 7 (Workflow Data)
FLASH animation of Workflow Data pattern
Description
Data elements are supported which are accessible to all components in each and every case of the process and are within the context of the process itself.
Example
Motivation
Some data elements have sufficiently broad applicability that it is desirable to make them accessible to every component in all cases of process execution. Data that falls into this category includes startup parameters to the operating environment, global application data that is frequently used and production information that governs the potential course of execution that each case may take.
Overview
Figure 8 illustrates the extent of global data visibility. Note that in contrast to case level data elements which are typically only visible to tasks in the case in which they are declared, global data elements are visible throughout all cases.
Figure 8: Workflow data visibility
Context
There are no specific context conditions associated with this pattern.
Implementation
In order to make data elements broadly accessible to all cases, most offerings address this requirement by utilising persistent storage, typically in the form of a database. This may be provided directly as an internal facility (e.g tables, persistent lists, DEFINITION tool agents, packages and data objects (ObjectNodes) in the case of Staffware, Websphere MQ , COSA, XPDL and BPMN respectively) or by linking in/accessing facilities in a suitable third-party product.
Issues
The main issue associated with global data is in managing concurrent access to it by multiple processes.
Solutions
As discussed for the Folder Data and Case Data patterns.
Evaluation Criteria
An offering achieves full support if it has a construct that satisfies the description for the pattern. It achieves a partial support rating if the value of these data elements cannot be modified during process execution.
Product Evaluation
To achieve a + rating (direct support) or a +/- rating (partial support) the product should satisfy the corresponding evaluation criterion of the pattern. Otherwise a - rating (no support) is assigned.
Product/Language |
Version |
Score |
Motivation |
---|---|---|---|
Staffware | 9 | + | Supported through tables and lists |
Websphere MQ Workflow | 3.4 | + | Supported through persistent lists |
FLOWer | 3.0 | - | Not supported |
COSA | 4.2 | +/- | COSA allows for attributes of the form DEFINITION.name however these are fixed at design time |
XPDL | 1.0 | +/- | It appears that the "data fields" of a package can be used for this. Its not clear how the values can be modified |
BPEL4WS | 1.1 | - | Not supported |
BPMN | 1.0 | - | Not supported |
UML | 2.0 | + | Directly supported through Object-Nodes which are potentially accessible to all of the components in a UML 2.0 AD |
Oracle BPEL | 10.1.2 | + | Supported via deployment descriptor properties |
jBPM | 3.1.4 | - | jBPM does not support global data. |
OpenWFE | 1.7.3 | + | OpenWFE supports globl data through the notion of engine variables (defined in the form //varname) that can be accessed at any point in any process. |
Enhydra Shark | 2 | - | Enhydra Shark does not support global data. Workflow variables are indeed available on a pack level (a package contains one or several workflows). However, these variables contain Case Data, i.e. their data values are not shared between several cases. Hence the purpose of Workflow variables is mainly to reduce the amount of variable definitions within a package. |
Summary of Evaluation
+ Rating |
+/- Rating |
---|---|
|
|