Pattern 34 (Task Precondition - Data Existence)

FLASH animation of Task Precondition - Data Existence pattern

Description

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.

Example

Only execute the Run Backup task when tape_loaded_flag exists.

Motivation

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

Overview

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:

Context

There are no specific context conditions associated with this pattern.

Implementation

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.

Issues

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.

Solutions

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.

Evaluation Criteria

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.

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.

Summary of Evaluation