Pattern 36 (Task Postcondition - Data Existence)

FLASH animation of Task Postcondition - Data Existence pattern


Data-based postconditions can be specified for tasks based on the existence of specific parameters at the time of task completion. The postconditions can utilize any data elements available to the task with which they are associated. A task can only proceed if the associated postcondition evaluates positively.


Do not complete the Rocket Initiation task until ignition data is available.


Implementation of this pattern ensures that a task cannot complete until specified output parameters exist and have been allocated a value.


Figure 22 illustrates this pattern. The specification of a data-based postcondition on a task e®ectively creates an implicit decision at the end of the task. If the postcondition is met, then the thread of control is passed to one or more of the outgoing branches from the task (e.g. task B is enabled if the postcondition exists(R) is met). There is an alternate path if the postcondition is not met back to the task. There are two possible scenarios where the postcondition is not met: either (1) the thread of control can be routed back to the beginning of the task (which may or may not result in the task being executed again) or (2) it can be routed to the end of the task (which is analogous to suspending the task). The implication of both scenarios however, is that the task does not pass on control-flow until the required parameters exist and have defined values.

Figure 22: Task postcondition - data existence

Figure 22: Task postcondition - data existence


There are no specific context conditions associated with this pattern.


Two alternatives exist for the implementation of this pattern. Where tasks that have effectively finished all of their processing but have a nominated data existence postcondition that has not been satisfied, either the task could be suspended until the required postcondition is met or the task could be implicitly repeated until the specified postcondition is met.

FLOWer provides direct support for this pattern by allowing data element fields in task constructs, called plan elements, to be specified as mandatory, thus ensuring they have a value specified before the plan element can complete execution. WebSphere MQ implements this pattern through the specification of exit conditions on tasks. If the required exit condition is not met at the time task processing is completed, then the task is restarted. A specific IS NULL function is available to test if a parameter has been assigned a value. iPlanet provides the OnComplete method which can be used to defer task completion until a required data elements exists.

Staffware provides indirect support through the inclusion of release scriptswith tasks which evaluate whether the required data elements have been specified. Completion of the task is deferred until the required condition is satisfied although this approach is limited to tasks that have forms associated with them. Similarly COSA indirectly supports this pattern through the use of condition-based triggers which only pass control to a subsequent task once a required data existence condition is set.

BPMN supports the specification of data existence postconditions using the ProducedAtCompletion attribute for Data Objects. UML 2.0 ADs allow postconditions to be specified for actions and activities using OCL expressions.


As for Task Precondition - Data Existence pattern (WDP34).


As for Task Precondition - Data Existence pattern (WDP34).

Evaluation Criteria

An offering achieves full support if it has a construct that satisfies the description for the pattern. It rates as partial support if there are limitations on the range of data elements that can be included in postconditions.

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 +/- Indirectly achievable via validation functions linked to release form commands
Websphere MQ Workflow 3.4 + Directly supported via exit conditions and the IS NULL function which allow parameter value assignment to be tested. Where exit condition is not met, task automatically repeats
FLOWer 3.0 + Achieved by making a data element mandatory. Task will not complete until the data element had a defined value
COSA 4.2 - Not supported
XPDL 1.0 - Not supported
BPEL4WS 1.1 - Not supported
BPMN 1.0 + In the cases data transfer is captured through Data Objects, the Boolean attribute ProducedAtCompletion can capture a postcondition 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. (This pattern is intended to be supported through the Required attribute for variables in jPDL. However, whilst it is possible to define a variable as required, it was found that not providing a value for that variable did not prevent the user from registering the task as completed)
OpenWFE 1.7.3 - OpenWFE does not support this pattern.
Enhydra Shark 2 -

Enhydra Shark does not support task post-condition on data existence. Test for null values behaves as follows:
varName != null works as expected
varName == null evaluates to false, because if a value is not entered, Enhydra puts an empty string in the variable. If the variable is an integer, an error message stating "Incorrect type!" is displayed.

Summary of Evaluation

+ Rating

+/- Rating

  1. Direct postcondition support for evaluating data element existance at task level
  2. Must support internal task repetition
  1. Limited range of postconditions
  2. Programmatic extensions required