Here is a proposal for the completion condition - it addresses some issues not tackled so far (at
least not in case of <completeCondition>). It is a version of the
proposal for completion condition for the bundle element. This proposal
includes comments from many people including Frank Leymann, Dieter Koenig, Dieter Roller
and Satish Thatte. It does not mean that they completely support the
proposal - they may have issues with any part of the
The current semantics of the flow activity is that it waits for all
concurrent activities to complete. The completion also means that an enclosed
activity/scope may end abnormally or be skipped (e.g. the join condition of
the activity evaluated to false). If a fault is thrown within an enclosed
activity/scope and one of the local fault handlers catch the fault (and does
not rethrow the fault), the enclosed activity/scope will be deemed to be
completed (although ended abnormally). If a fault is not caught by any local
fault handler (or is rethrown) the flow activity will terminate all active
concurrent activities and corresponding fault handler may be
A completion condition for the flow activity is needed for scenarios
where not all concurrent activities of a flow activity must complete in order
the flow activity to complete. Note: We are not talking about "successful
completion" of enclosed concurrent activities because that would not be
consistent with the semantics of the current flow activity.
The completion condition may have different flavors, such
(1) N out of M
(2) The two most important requests
(3) A Boolean condition operating upon process
Not all activities must complete in order the enclosing flow activity
to complete. The way to identify that an enclosed activity did not complete is
to propagate faults. We may distinguish between severe faults and those that
can be ignored. Severe faults cause the enclosing flow activity (or more
precisely, enclosing scope) to terminate the flow activity, including all
active concurrent activities, and corresponding fault handler may be
initiated. Other faults may be ignored - the flow activity is "informed" that
a concurrent activity did not complete but still allows other active
concurrent activities to continue with execution.
Faults thrown within enclosed concurrent activities/scopes and not
handled by local fault handlers are rethrown. Enclosing <flow> element
decides which of these rethrown faults can be ignored. This new "ignore"
semantics should be part of the completion condition and should apply to all
enclosed activities. This new semantics does not introduce a new fault
handling mechanism. It is needed for identifying how many of the enclosed
<fault name="qname"? value="ncname"?/>*
Attribute branch is used to specify a condition of flavor
"wait for N out of M activities to complete", or more
precisely value N. Attribute expression is used to specify a Boolean
condition operating upon process variables or a
condition of flavor "the two most important requests completed".
and expression) may be
specified at the same time. They will be checked when one instance of the
scope activity reaches the end. If at least one condition evaluates to true
all active instances will be terminated.
Element <ignoreFaults> specifies faults that may be ignored. Element fault is used to specify a fault which
may be ignored (fault name and fault data may be specified).
Element <ignoreAll> would mean that all faults thrown/rethrown by any concurrent
activity/scope may be ignored. If this element is
specified <fault> element must be
Completion condition failure
A new standard fault, e.g. completionConditionFailure, should be
introduced to notify that the completion condition of a flow activity
evaluated to false (note: all concurrent activities have been completed). The
fault is thrown in the scope enclosing the flow element.
Completion condition and links
There should be no difference between a flow activity with a completion
condition and a flow activity without completion condition. For example, if
the completion condition fails all links leaving the flow activity should have
value "false" (or be reverted to a negative status).
There are just a few additional rules:
(1) Let's assume enclosed activity A is the source of a link. If the
completion condition evaluates to true and activity A is not completed it will
be terminated and the value of the link will be set to
(2) Let's assume enclosed activity A is the source of a link and the
activity failed but the fault is "ignored" by the enclosing flow activity. The
value of the link will be set to "false".
New function for completion condition of flavor "the two most important
For completion conditions of flavor "the two most important requests
completed" standard attribute "name" must be specified for all enclosing
activities in order to be able to distinguish them. In addition a new
function, e.g. isCompleted('activityName') must be introduced. The semantics
of the function is: if activity completed successfully the function returns
"isCompleted('A') AND isCompleted('B')"