Pattern 35 (Task Precondition - Data Value)

FLASH animation of Task Precondition - Data Value pattern

Description

Data-based preconditions can be specified for tasks based on the value of specific parameters 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

Execute the Rocket Initiation task when countdown is 2.

Motivation

The ability to specify value-based preconditions on parameters to tasks provides the ability to delay execution of the task (possibly indefinitely) where a precondition is not satisfied.

Overview

The operation of this pattern is similar to that in Figure 21 except that the precondition is value-based rather than a test for data existence. There are three possible alternatives where a value-based precondition is not met:

  • The task can be skipped and the subsequent task(s) initiated.
  • Commencement of the task can be delayed until the required precondition is achieved.
  • This thread of execution in the case can be terminated.

Context

There are no specific context conditions associated with this pattern.

Implementation

This pattern is directly implemented by FLOWer through the milestone construct which enables the triggering of a task to be delayed until a parameter has a specified value. Similarly COSA provides the ability to delay execution of a task where a precondition is not met through the specification of transition conditions based on the required data values on the incoming arc to the task. By specifying alternate data conditions (which correspond to the negation of the required data values) on the outgoing arc from the state preceding the contingent task to the subsequent state, it is also possible to support the skipping of tasks where data preconditions are not met. Both approaches assume the transition conditions are specified in conjunction with the CONDITION.TOKEN tool agent. iPlanet supports this form of precondition using Trigger methods which are evaluated when a task receives the thread of control to determinewhether it can commence. UML 2.0 ADs allow preconditions to be specified for actions and activities using OCL expressions.

In a more limited way, Staffware provides the ability to delay task execution through the specification of scripts which test for the required data values at task commencement. However, this approach is only possible for tasks which have forms associated with them. A better solution is to use condition actions to test for required parameters and skip the task invocation where they are not available. XPDL provides support for a task to be skipped when a nominated data value is not achieved through the specification of an additional edge in the workflow schema which bypasses the task in question (i.e. it links the preceding and subsequent tasks) and has a transition condition which is the negation of the required data value.

A similar effect can be achieved in BPEL through the use of link conditions. By specifying a link condition to the task, call it A, which corresponds to the required data values and creating a parallel empty task in the business process that has a link condition that is the negation of this, task A will be skipped if the required data values are not detected.

Issues

None identified.

Solutions

N/A.

Evaluation Criteria

An offering achieves full support if it has a construct that satisfies the description of the pattern.

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 + Initial scripts can be used to delay invocation depending on parameter values where tasks have forms. Conditional actions can be used to skip tasks where parameter values are not equal to specified values
Websphere MQ Workflow 3.4 - Not supported
FLOWer 3.0 + Milestones can also have a condition delaying invocation of subsequent task until condition is met
COSA 4.2 + By specifying transition conditions for tasks based on the required data values and CONDITION.TOKEN tool agent, subsequent task invocation can be delayed until required data values are met
XPDL 1.0 + Inclusion of additional edge around task with transition condition that is the negation of required data values allows task to be skipped when values not met
BPEL4WS 1.1 + Inclusion of additional link around task with transition condition that is the negation the required data values allows task to be skipped when data values not met.
BPMN 1.0 - Not supported
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 + Directly supported via joinCondition evaluation the status of links
jBPM 3.1.4 - jBPM does not support this pattern. See the motivation for RP34.
OpenWFE 1.7.3 + OpenWFE supports the task precondition on data value pattern, as such preconditions can be defined through <if>-then statements testing the value of a field or a variable.
Enhydra Shark 2 - Enhydra Shark does not support task preconditions. As tsk preconditions can be specified for tasks with multiple incoming arcs, transition conditions on the incoming transitions alone would not be enough for capturing the full semantics of the precondition.

Summary of Evaluation

+ Rating

+/- Rating
  1. Direct precondition support at task instance level
  2. Support for a broad range of preconditions
  1. Limited range of preconditions supported
  2. Programmatic extensions required