When an inner Activity with outgoing Sequence Flows completes, a number of tokens are produced on its outgoing Sequence Flows. This number is specified through its attribute completionQuantity. The resulting state MAY contain also other tokens on incoming Sequence Flows of either Activities, converging Parallel or Complex Gateways, or an Intermediate Event. Then all tokens are propagated as far as possible, i.e., all activated Gateways are executed until no Gateway and Intermediate Event is activated anymore. Consequently, a state is obtained where each token is on an incoming Sequence Flow of either an inner Activity, a converging Parallel or Complex Gateway or an Intermediate Event. An inner Activity is now enabled if it has either no incoming Sequence Flows or there are sufficiently many tokens on its incoming Sequence Flows (as specified through startQuantity).

Workflow patterns: WCP-17 Interleaved parallel routing.

13.3.6 Loop Activity

The Loop Activity is a type of Activity that acts as a wrapper for an inner Activity that can be executed multiple times in sequence.

Operational semantics: Attributes can be set to determine the behavior. The Loop Activity executes the inner Activity as long as the loopCondition evaluates to true. A testBefore attribute is set to decide when the loopCondition should be evaluated: either before the Activity is executed or after, corresponding to a preand post-tested loop respectively. A loopMaximum attribute can be set to specify a maximal number of iterations. If it is not set, the number is unbounded.

Workflow Patterns Support: WCP-21 Structured Loop.

13.3.7 Multiple Instances Activity

The multi-instance (MI) Activity is a type of Activity that acts as a wrapper for an Activity which has multiple instances spawned in parallel or sequentially.

Operational semantics: The MI specific attributes are used to configure specific behavior. The attribute isSequential determines whether instances are generated sequentially (true) or in parallel (false). The number of instances to be generated is either specified by the integer-valued Expression loopCardinality or as the cardinality of a specific collection-valued data item of the data input of the MI Activity. The latter is described in detail below.

The number of instances to be generated is evaluated once. Subsequently the number of instances are generated. If the instances are generated sequentially, a new instance is generated only after the previous has been completed. Otherwise, multiple instances to be executed in parallel are generated.

Attributes are available to support the different possibilities of behavior. The completionCondition Expression is a boolean predicate that is evaluated every time an instance completes. When evaluated to true, the remaining instances are canceled, a token is produced for the outgoing Sequence Flows, and the MI Activity completes.

The attribute behavior defines if and when an Event is thrown from an Activity instance that is about to complete. It has values of none, one, all, and complex, assuming the following behavior:

none: an EventDefinition is thrown for all instances completing. one: an EventDefinition is thrown upon the first instance completing. all: no Event is ever thrown.

complex: the complexBehaviorDefinitions are consulted to determine if and which Events to throw.

For the behaviors of none and one, an EventDefinition (which is referenced from

MultipleInstanceLoopCharacteristics through the noneEvent and oneEvent associations, respectively) is thrown which automatically carries the current runtime attributes of the MI Activity. That is, the ItemDefinition of these SignalEventDefinitions is implicitly given by the specific runtime attributes of the MI Activity.

The complexBehaviorDefinition association references multiple ComplexBehaviorDefinition entities which each point to a boolean condition being a FormalExpression and an Event which is an ImplicitThrowEvent. Whenever an Activity instance completes, the conditions of all

ComplexBehaviorDefinitions are evaluated. For each ComplexBehaviorDefinition whose condition is evaluated to true, the associated Event is automatically thrown. That is, a single Activity completion can lead to multiple different Events that are thrown. The Events can then be caught on the boundary of the MI Activity. Multiple ComplexBehaviorDefinitions offer an easy way of implicitly spawning different flow at the MI Activity boundary for different situations indicating different states of progress in the course of executing the MI Activity.

The completionCondition, the condition in the ComplexBehaviorDefinition, and the DataInputAssociation of the Event in the ComplexBehaviorDefinition can refer to the MI Activity instance attributes and the loopDataInput, loopDataOutput, inputDataItem, and outputDataItem that are referenced from the MultiInstanceLoopCharacteristics.

In practice, an MI Activity is executed over a data collection, processing as input the data values in the collection and producing as output data values in a collection. The input data collection is passed to the MI outer Activity’s loopDataInput from a Data Object in the Process scope of the MI Activity. Under BPMN data flow constraints, the Data Object is linked to MI activity’s loopDataInput through a DataInputAssociation. To indicate that the Data Object is a collection, its respective symbol is marked with the MI indicator (three-bar). The items of the loopDataInput collection are used to determine the number of instances REQUIRED to be executed (whether sequentially or in parallel). Accordingly, the inner instances are created and data values from the loopDataInput are extracted and assigned to the respective instances. Specifically, the values from the loopDataInput items are passed to an inputDataItem, created in the scope of the outer Activity. The value in the inputDataItem can be passed to the loopDataInput of each inner instance, where a DataInputAssociation links both. The process of extraction is left under-specified. In practice, it would entail a special-purpose mediator that not only provides the extraction and data assignment, but also any necessary data transformation.

Each instance processes the data value of its DataInput. It produces a value in its DataOutput if it completes successfully. The DataOutPut value of the instance is passed to a corresponding outputDataItem in the outer Activity, where a DataOutputAssociation links both. Each outputDataItem value is updated in the loopDataOutput collection, in the corresponding item. The mechanism of this update is left underspecified, and again would be implemented through a special purpose mediator. The loopDataOutput is passed to the MI Activity’s Process scope through a Data Object that has a DataOutputAssociation linking both.

It should be noted that the collection in the Process scope should not be accessible until all its items have been written to. This is because, it could be accessed by an Activity running concurrently, and therefore control flow through token passing cannot guarantee that the collection is fully written before it is accessed.

The MI Activity is compensated only if all its instances have completed successfully.

Workflow Patterns Support: WCP-21 Structured Loop, Multiple Instance Patterns WCP 13, 14, 34, 36