10.3.8 Loop Characteristics
Activities MAY be repeated sequentially, essentially behaving like a loop. The presence of LoopCharacteristics signifies that the Activity has looping behavior. LoopCharacteristics is an abstract class. Concrete subclasses define specific kinds of looping behavior.
The LoopCharacteristics inherits the attributes and model associations of BaseElement (see Table 8.5). There are no further attributes or model associations of the LoopCharacteristics.
However, each Loop Activity instance has attributes whose values MAY be referenced by Expressions. These values are only available when the Loop Activity is being executed.
Figure 10.45 displays the class diagram for an Activity’s loop characteristics, including the details of both the standard loop and a multi-instance.
Figure 10.45 – LoopCharacteristics class diagram
The LoopCharacteristics element inherits the attributes and model associations of BaseElement (see Table 8.5), but does not have any further attributes or model associations. However, a Loop Activity does have additional instance attributes as shown in Table 10.27.
188 |
Business Process Model and Notation (BPMN), v2.0.2 |
Table 10.27 – Loop Activity instance attributes
Attribute Name |
Description/Usage |
|
|
loopCounter: integer |
The LoopCounter attribute is used at runtime to count the number of loops |
|
and is automatically updated by the process engine. |
|
|
Standard Loop Characteristics
The StandardLoopCharacteristics class defines looping behavior based on a boolean condition. The Activity will loop as long as the boolean condition is true. The condition is evaluated for every loop iteration, and MAY be evaluated at the beginning or at the end of the iteration. In addition, a numeric cap can be optionally specified. The number of iterations MAY NOT exceed this cap.
The marker for a Task or a Sub-Process that is a standard loop MUST be a small line with an arrowhead that curls back upon itself (see Figure 10.46 and Figure 10.47).
The loop Marker MAY be used in combination with the Compensation Marker.
Figure 10.46 – A Task object with a Standard Loop Marker
Figure 10.47 – A Sub-Process object with a Standard Loop Marker
The StandardLoopCharacteristics element inherits the attributes and model associations of BaseElement (see Figure 8.5), through its relationship to LoopCharacteristics. Table 10.28 presents the additional attributes and model associations for the StandardLoopCharacteristics element.
Business Process Model and Notation (BPMN), v2.0.2 |
189 |
Table 10.28 – StandardLoopCharacteristics attributes and model associations
Attribute Name |
Description/Usage |
|
|
testBefore: boolean = false |
Flag that controls whether the loop condition is evaluated at the beginning |
|
(testBefore = true) or at the end (testBefore = false) of the loop |
|
iteration. |
loopMaximum: integer [0..1] |
Serves as a cap on the number of iterations. |
|
|
loopCondition: Expression [0..1] |
A boolean Expression that controls the loop. The Activity will only loop |
|
as long as this condition is true. The looping behavior MAY be |
|
underspecified, meaning that the modeler can simply document the |
|
condition, in which case the loop cannot be formally executed. |
|
|
Multi-Instance Characteristics
The MultiInstanceLoopCharacteristics class allows for creation of a desired number of Activity instances. The instances MAY execute in parallel or MAY be sequential. Either an Expression is used to specify or calculate the desired number of instances or a data driven setup can be used. In that case a data input can be specified, which is able to handle a collection of data. The number of items in the collection determines the number of Activity instances. This data input can be produced by an input Data Association. The modeler can also configure this loop to control the tokens produced.
The marker for a Task or Sub-Process that is a multi-instance MUST be a set of three vertical lines.
If the multi-instance instances are set to be performed in parallel rather than sequential (the isSequential attribute set to false), then the lines of the marker will be vertical (see Figure 10.48).
If the multi-instance instances are set to be performed in sequence rather than parallel (the isSequential attribute set to true), then the marker will be horizontal (see Figure 10.49).
The Multi-Instance marker MAY be used in combination with the Compensation marker.
Figure 10.48 – Activity Multi-Instance marker for parallel instances
Figure 10.49 – Activity Multi-Instance marker for sequential instances
190 |
Business Process Model and Notation (BPMN), v2.0.2 |
The MultiInstanceLoopCharacteristics element inherits the attributes and model associations of BaseElement (see Table 8.5), through its relationship to LoopCharacteristics. Table 10.29 presents the additional attributes and model associations for the MultiInstanceLoopCharacteristics element.
Table 10.29 – MultiInstanceLoopCharacteristics attributes and model associations
Attribute Name |
Description/Usage |
|
|
|
|
isSequential: boolean = false |
This attribute is a flag that controls whether the Activity instances will |
|
|
execute sequentially or in parallel. |
|
|
|
|
loopCardinality: Expression [0..1] |
A numeric Expression that controls the number of Activity instances |
|
|
that will be created. This Expression MUST evaluate to an integer. |
|
|
This MAY be underspecified, meaning that the modeler MAY simply |
|
|
document the condition. In such a case the loop cannot be formally |
|
|
executed. |
|
|
In order to initialize a valid multi-instance, either the loopCardinality |
|
|
Expression or the loopDataInput MUST be specified. |
|
loopDataInputRef: |
This ItemAwareElement is used to determine the number of Activity |
|
ItemAwareElement [0..1] |
||
instances, one Activity instance per item in the collection of data stored |
||
|
||
|
in that ItemAwareElement element. |
|
|
For Tasks it is a reference to a Data Input which is part of the Activity’s |
|
|
InputOutputSpecification. |
|
|
For Sub-Processes it is a reference to a collection-valued Data Object |
|
|
in the context that is visible to the Sub-Processes. |
|
|
In order to initialize a valid multi-instance, either the loopCardinality |
|
|
Expression or the loopDataInput MUST be specified. |
|
loopDataOutputRef: |
This ItemAwareElement specifies the collection of data, which will be |
|
ItemAwareElement [0..1] |
||
produced by the multi-instance. |
||
|
||
|
For Tasks it is a reference to a Data Output which is part of the |
|
|
Activity’s InputOutputSpecification. |
|
|
For Sub-Processes it is a reference to a collection-valued Data Object |
|
|
in the context that is visible to the Sub-Processes. |
|
|
|
|
inputDataItem: DataInput [0..1] |
A Data Input, representing for every Activity instance the single item of |
|
|
the collection stored in the loopDataInput. This Data Input can be |
|
|
the source of DataInputAssociation to a data input of the Activity’s |
|
|
InputOutputSpecification. The type of this Data Input MUST the |
|
|
scalar of the type defined for the loopDataInput. |
|
outputDataItem: DataOutput [0..1] |
A Data Output, representing for every Activity instance the single item |
|
|
of the collection stored in the loopDataOutput. This Data Output can |
|
|
be the target of DataOutputAssociation to a data output of the |
|
|
Activity’s InputOutputSpecification. The type of this Data |
|
|
Output MUST the scalar of the type defined for the loopDataOutput. |
Business Process Model and Notation (BPMN), v2.0.2 |
191 |
Table 10.29 – MultiInstanceLoopCharacteristics attributes and model associations
behavior: MultiInstanceBehavior = all { |
The attribute behavior acts as a shortcut for specifying when events |
|
None | One | All | Complex } |
SHALL be thrown from an Activity instance that is about to complete. It |
|
|
||
|
can assume values of None, One, All, and Complex, resulting in the |
|
|
following behavior: |
|
|
• None: the EventDefinition which is associated through the |
|
|
noneEvent association will be thrown for each instance completing. |
|
|
• One: the EventDefinition referenced through the oneEvent |
|
|
association will be thrown upon the first instance completing. |
|
|
• All: no Event is ever thrown; a token is produced after completion of all |
|
|
instances. |
|
|
• Complex: the complexBehaviorDefinitions are consulted to |
|
|
determine if and which Events to throw. |
|
|
For the behaviors of none and one, a default SignalEventDefini- |
|
|
tion will be thrown which automatically carries the current runtime |
|
|
attributes of the MI Activity. |
|
|
Any thrown Events can be caught by boundary Events on the Multi- |
|
|
Instance Activity. |
|
|
|
|
complexBehaviorDefinition: |
Controls when and which Events are thrown in case behavior is set to |
|
ComplexBehaviorDefinition [0..*] |
||
complex. |
||
|
||
completionCondition: Expression |
This attribute defines a boolean Expression that when evaluated to |
|
[0..1] |
||
true, cancels the remaining Activity instances and produces a token. |
||
|
||
|
|
|
oneBehaviorEventRef: |
The EventDefinition which is thrown when behavior is set to one |
|
EventDefinition [0..1] |
||
and the first internal Activity instance has completed. |
||
|
||
|
|
|
noneBehaviorEventRef: |
The EventDefinition which is thrown when the behavior is set to |
|
EventDefinition [0..1] |
||
none and an internal Activity instance has completed. |
||
|
Table 10.30 lists all instance attributes available at runtime. For each instance of the Multi-Instance Activity (outer instance), there exists a number of generated (inner) instances of the Activity at runtime.
192 |
Business Process Model and Notation (BPMN), v2.0.2 |