Pattern 34 (Task Precondition - Data Existence)
Data-based preconditions can be specified for tasks based on the presence of data elements at the time of execution. The preconditions can utilize any data elements available to the task with which they are associated. A task can only proceed if the associated precondition evaluates positively.
Only execute the Run Backup task when tape_loaded_flag exists.
The ability to deal with missing data elements at the time of task invocation is desirable. This allows corrective action to be taken during process execution rather than necessitating the raising of an error condition and halting any further action.
Figure 21: Task precondition - data existence
The operation of this pattern is illustrated in Figure 21. Typically data existence preconditions are specified on task input parameters (footnote12) in the process model as illustrated in Figure 21 . In this context, data existence refers to the ability to determine whether a required parameter has been defined and provided to the task at the time of task invocation and whether it has been assigned a value. One of five actions are possible where missing parameters are identified:
- Defer task commencement until they are available.
- Specify default values for parameters to take when they are not available.
- Request values for them interactively from PAIS users.
- Skip this task and trigger the following task(s).
- Kill this thread of execution in the workflow case.
There are no specific context conditions associated with this pattern.
This pattern is implemented in a variety of different ways amongst the offerings examined. Staffware provides the ability to set default values for fields which do not have a value recorded for them via the initial form command facility but only for those tasks that have forms associated with them. Conditional actions can also be specified which route control-flow around (i.e. skip) a task where required data elements are not available. FLOWer provides the milestone construct which, amongst other capabilities, provides data synchronization support allowing the commencement of a subsequent task to be deferred until nominated data elements have a value specified. COSA also provides transition conditions on incoming arcs and in conjunction with the CONDITION.TOKEN and STD tool agents, it enables the passing of control to a task to be delayed until the transition condition (which could be data element existence) is achieved. iPlanet supports this form of precondition using Trigger methods which are evaluated when a task receives the thread of control to determine whether it can commence. BPMN supports the specification of data existence preconditions using the RequiredForStart attribute for Data Objects. UML 2.0 ADs allow preconditions to be specified for actions and activities using OCL expressions. BPEL provides exception handling facilities where an attempt to utilize an uninitialized variable is detected. These can be indirectly used to provide data existence precondition support at task level but require each task to be defined as having its own scope with a dedicated fault handler to manage the uninitialized parameters accordingly.
A significant consideration in managing preconditions that relate to data existence is being able to differentiate between data elements that have an undefined value and those that are merely empty or null.
Staffware addresses this issue by using a special value (SW NA) for data elements that are undefined. Uninitialized fields have this value by default and it can be tested for in workflow expressions and conditions. FLOWer also provides facilities to test whether data elements have been assigned a value. BPEL provides internal capabilities to recognize uninitialized data elements although these facilities are not directly accessible to process developers. Other workflow engines examined do not differentiate between undefined and empty (or null) values.
An offering achieves full support if it has a construct that satisfies the description of the pattern. It rates as partial support if the precondition cannot be satisfied declaratively as part of the task declaration.
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.
|Staffware||9||+||Uninitialised fields can be detected via the SW_NA value. Initial scripts can be used to set default values for missing parameters where tasks have forms. Conditional actions can be used to skip tasks where required parameters are missing|
|Websphere MQ Workflow||3.4||-||Not supported|
|FLOWer||3.0||+||Supported in various ways e.g. milestone defined for a mandatory data element can defer subsequent task initiation until required data element is available|
|COSA||4.2||+||By specifying transition conditions for tasks based on the CONDITION.TOKEN and STD.exists tool agents, subsequent task invocation can be delayed until required data element is available|
|BPEL4WS||1.1||+/-||Can be indirectly facilitated via exception handlers dealing with attempts to use uninitialised parameters but requires dedicated scope for each activity|
|BPMN||1.0||+||In the cases data transfer is captured through Data Objects, the Boolean attribute RequiredForStart can capture a precondition for data existence|
|UML||2.0||+||Directly supported. Both action and activity constructs include local preconditions and postconditions based on logical expressions framed in OCL.|
|Oracle BPEL||10.1.2||-||Not supported|
|jBPM||3.1.4||-||jBPM does not support this pattern. By default a task-node is enabled when one of its incoming transitions propagate a token. Consequently, defining preconditions on a tak-node can be considered as a form of restricting the tokens passing through its incoming transitions. Actions associated with transitions can not be used in this way as actions cannot influence the control-flow of a process. Furthermore, any "guards" controlling the tokens passing through a transition (similar to those supported in UML activity diagrams) are deliberately not included in jPDL (according to "Why does jPDL lack a notion of a guard condition on every transition? on wiki.jboss.org/wiki/Wiki.jsp\?page=Jbpm3FAQ).|
|OpenWFE||1.7.3||+||OpenWFE supports this pattern as task precondition on data existence can be specified through <if>-then statements which contain an expression <defined variable-value="variable-name"> testing whether the variable variable-name has been defined or not.|
|Enhydra Shark||2||-||Enhydra Shark does not support this pattern. There is not any way to specify task preconditions. Only Transition Restrictions of type AND or XOR Join can be specified.|
Summary of Evaluation