It is often desirable or even necessary to execute things in parallel. For this purpose, BPEL offers the flow activity.

(Note that besides the flow activity, the parallel variant of forEach activity and event handlers allow multiple instances of its child activity to run in parallel.)

A link can have a transition condition associated with it which influences its status. If no transitionCondition is specified, the status of the link is true. If a transitionCondition is specified, it will set the status of the link.

Transition conditions offer a mechanism to split the control flow based on certain conditions. Therefore, a mechanism to merge it again must be offered, too. BPEL does that with join conditions. Join conditions are associated with activities, usually if the activities have any incoming links. A joinCondition specifies for an activity something like a “start condition”, e.g. all incoming links must have the status of true in order for the activity to execute, or at least one incoming link must have the status true.

WS-BPEL provides two mechanisms for dealing with false join conditions. By default, a joinFailure fault is thrown that may be caught by an appropriate fault handler. Alternatively, when the attribute suppressJoinFailure on the process or an enclosing activity is set to yes, the activity associated with the false join condition is skipped and the false link status is propagated along links leaving that activity. In other words, a false link status will be propagated transitively along entire paths formed by successive links until a join condition is reached that evaluates to true. This approach is called Dead-Path Elimination (DPE).

See also:

- WS-BPEL 2.0 Primer: Parallel processing