---
title: "13.3 Activities"
chapter: "13 BPMN Execution Semantics"
source: "OMG BPMN 2.0.2 — formal/2013-12-09"
pages: "426-433"
---
> 13 BPMN Execution Semantics · páginas 426-433 · [índice](../README.md)
## 13.3 Activities
This sub clause specifies the semantics of **Activities**. First the semantics that is common to all **Activities** is described. Subsequently the semantics of special types of **Activities** is described.
### 13.3.1 Sequence Flow Considerations
The nature and behavior of **Sequence Flows** is described in “Sequence Flow” on page 95. But there are special considerations relative to **Sequence Flows** when applied to **Activities**. An **Activity** that is the target of multiple **Sequence Flows** participates in “uncontrolled flow.” To facilitate the definition of **Sequence Flow** (and other **Process** elements) behavior, we employ the concept of a *token* that will traverse the **Sequence Flows** and pass through the elements in the **Process**. A *token* is a theoretical concept that is used as an aid to define the behavior of a **Process** that is being performed. The behavior of **Process** elements can be defined by describing how they interact with a *token* as it “traverses” the structure of the **Process**. However, modeling and execution tools that implement **BPMN** are NOT REQUIRED to implement any form of *token*. Uncontrolled flow means that, for each *token* arriving on any *incoming* **Sequence Flows** into the **Activity**, the **Task** will be enabled independently of the arrival of *tokens* on other *incoming* **Sequence Flows**. The presence of multiple *incoming* **Sequence Flows** behaves as an **exclusive gateway**. If the flow of *tokens* into the **Task** needs to be ‘controlled,’ then **Gateways** (other than **Exclusive**) should be explicitly included in the **Process** flow prior to the **Task** to fully eliminate semantic ambiguities. If an **Activity** has no *incoming* **Sequence Flows**, the **Activity** will be instantiated when the containing **Process** or **Sub-Process** is instantiated. Exceptions to this are **Compensation Activities**, as they have specialized instantiation behavior. **Activities** can also be source of **Sequence Flows**. If an **Activity** has multiple *outgoing* **Sequence Flows**, all of them will receive a *token* when the **Activity** transitions to the *Completed* state. Semantics for *token* propagation for other termination states is defined below. Thus, multiple *outgoing* **Sequence Flows** behaves as a parallel split. Multiple *outgoing* **Sequence Flows** with conditions behaves as an inclusive split. A mix of multiple *outgoing* **Sequence Flows** with and without conditions is considered as a combination of a parallel and an inclusive split as shown in the Figure 13.1.
*Figure 13.1 – Behavior of multiple outgoing Sequence Flows of an Activity* (p. 427)
If the **Activity** has no *outgoing* **Sequence Flows**, the **Activity** will terminate without producing any *tokens* and termination semantics for the container is then applied. *Token* movement across a **Sequence Flow** does not have any timing constraints. A *token* might take a long or short time to move across the **Sequence Flow**. If the isImmediate attribute of a **Sequence Flow** has a value of *false*, or has no value and is taken to mean *false*, then **Activities** not in the model MAY be executed while the *token* is moving along the **Sequence Flow**. If the isImmediate attribute of a **Sequence Flow** has a value of *true*, or has no value and is taken to mean *true*, then **Activities** not in the model MAY NOT be executed while the *token* is moving along the
### 13.3.2 Activity
An **Activity** is a **Process** step that can be atomic (**Tasks**) or decomposable (**Sub-Processes**) and is executed by either a system (automated) or humans (manual). All **Activities** share common attributes and behavior such as states and state transitions. An **Activity**, regardless of type, has lifecycle generally characterizing its operational semantics. The lifecycle, described as a UML state diagram in Figure 13.2, entails states and transitions between the states.
*Figure 13.2 – The Lifecycle of a BPMN Activity* (p. 428)
The lifecycle of an **Activity** is described as follows:
- An **Activity** is *Ready* for execution if the REQUIRED number of *tokens* is available to activate the **Activity**. The REQUIRED number of *tokens* (one or more) is indicated by the attribute **StartQuantity**. If the **Activity** has more than one *Incoming* **Sequence Flows**, there is an implied **Exclusive Gateway** that defines the behavior.
- When some data InputSet becomes available, the **Activity** changes from *Ready* to the *Active* state. The availability of a data InputSet is evaluated as follows. The data InputSets are evaluated in order. For each InputSet, the data inputs are filled with data coming from the elements of the context such as **Data Objects** or Properties by triggering the input **Data Associations**. An InputSet is *available* if each of its REQUIRED **Data Inputs** is available. A data input is REQUIRED by a data InputSet if it is not optional in that InputSet. If an InputSet is available, it is used to start the **Activity**. Further InputSets are not evaluated. If an InputSet is not available, the next InputSet is evaluated. The **Activity** waits until one InputSet becomes available. Please refer to 10.4.2 on page 224 for a description of the execution semantics for **Data**
- An **Activity**, if *Ready or Active*, can be *Withdrawn* from being able to complete in the context of a race condition. This situation occurs for **Tasks** that are attached after an **Event-Based Exclusive Gateway**. The first element (**Task** or **Event**) that completes causes all other **Tasks** to be withdrawn.
- If an **Activity** fails during execution, it changes from the state *Active* to *Failed*.
- If an **Activity**’s execution ends without anomalies, the **Activity**’s state changes to *Completing*. This intermediate state caters for processing steps prior to completion of the **Activity**. An example of where this is useful is when non-interrupting *Event Handlers* (proposed for **BPMN 2.0**) are attached to an **Activity**. They need to complete before the **Activity** to which it is attached can complete. The state *Completing* of the main **Activity** indicates that the execution of the main **Activity** has been completed, however, the main **Activity** is not allowed to be in the state *Completed*, as it still has to wait for all non-interrupting *Event Handlers* to complete. The state Completing does not allow further processing steps, otherwise allowed during the execution of the **Activity**. For example, new attached non-interrupting *Event Handlers* MAY be created as long as the main **Activity** is in state *Active*. However, once in the state *Completing*, running handlers should be completed with no possibility to create new ones.
- An **Activity**’s execution is interrupted if an interrupting **Event** is raised (such as an *error*) or if an interrupting **Event Sub-Process** is initiated, In this case, the **Activity**’s state changes to *Failing* (in case of an *error*) or *Terminating* (in case any other interrupting **Event**). All nested **Activities** that are not in *Ready*, *Active* or a final state (*Completed*, *Compensated*, *Failed*, etc.) and non-interrupting **Event Sub-Processes** are terminated. The data context of the **Activity** is preserved in case an interrupting **Event Sub-Process** is invoked. The data context is released after the **Event Sub-Process** reaches a final state.
- After all completion dependencies have been fulfilled, the state of the **Activity** changes to *Completed*. The *outgoing* **Sequence Flows** becomes active and a number of *tokens*, indicated by the attribute **CompletionQuantity**, is placed on it. If there is more than one outbound **Sequence Flows** for an **Activity**, it behaves like an implicit **Parallel Gateway**. Upon completion, also a data OutputSet of the **Activity** is selected as follows. All OutputSets are checked for availability in order. An OutputSet is available if all its REQUIRED **Data Outputs** are available. A data output is REQUIRED by an OutputSet if it is not optional in that OutputSet. If the data OutputSet is available, data is pushed into the context of the **Activity** by triggering the output **Data Associations** of all its data outputs. Further OutputSets are not evaluated. If the data OutputSet is not available, the next data OutputSet is checked. If no OutputSet is available, a runtime exception is thrown. If the **Activity** has an associated IORule, the chosen OutputSet is checked against that IORule, i.e., it is checked whether the InputSet that was used in starting the **Activity** *instance* is together with the chosen OutputSet compliant with the IORule. If not, a runtime exception is thrown.
- Only completed **Activities** could, in principle, be compensated, however, the **Activity** can end in state *Completed*, as *compensation* might not be triggered or there might be no *compensation handler* specified. If the *compensation handler* is invoked, the **Activity** changes to state *Compensating* until either *compensation* finishes successfully (state *Compensated*), an exception occurs (state *Failed*), or controlled or uncontrolled termination is triggered (state *Terminated*).
### 13.3.3 Task
**Task** execution and completion for the different **Task** types are as follows:
- **Service Task**: Upon activation, the data in the inMessage of the Operation is assigned from the data in the **Data Input** of the **Service Task** the Operation is invoked. On completion of the service, the data in the **Data Output** of the **Service Task** is assigned from the data in the outMessage of the Operation, and the **Service Task** completes. If the invoked service returns a *fault*, that *fault* is treated as interrupting *error*, and the **Activity** fails.
- **Send Task**: Upon activation, the data in the associated **Message** is assigned from the data in the **Data Input** of the **Send Task**. The **Message** is sent and the **Send Task** completes.
- **Receive Task**: Upon activation, the **Receive Task** begins waiting for the associated **Message**. When the **Message** arrives, the data in the **Data Output** of the **Receive Task** is assigned from the data in the **Message**, and **Receive Task** completes. For key-based *correlation*, only a single receive for a given CorrelationKey can be active, and thus the **Message** matches at most one **Process** *instance*. For predicate-based *correlation*, the **Message** can be passed to multiple **Receive Tasks**. If the **Receive Task**’s instantiate attribute is set to *true*, the **Receive Task** itself can start a new **Process** *instance*.
- **User Task**: Upon activation, the **User Task** is distributed to the assigned person or group of people. When the work has been done, the **User Task** completes.
- **Manual Task**: Upon activation, the manual task is distributed to the assigned person or group of people. When the work has been done, the **Manual Task** completes. This is a conceptual model only; a **Manual Task** is never actually executed by an IT system.
- **Business Rule Task**: Upon activation, the associated business rule is called. On completion of the business rule,
- **Script Task**: Upon activation, the associated script is invoked. On completion of the script, the **Script Task** completes.
- **Abstract Task**: Upon activation, the **Abstract Task** completes. This is a conceptual model only; an **Abstract Task** is never actually executed by an IT system.
### 13.3.4 Sub-Process/Call Activity
A **Sub-Process** is an **Activity** that encapsulates a **Process** that is in turn modeled by **Activities**, **Gateways**, **Events**, and **Sequence Flows**. Once a **Sub-Process** is instantiated, its elements behave as in a normal **Process**. The instantiation and completion of a **Sub-Process** is defined as follows:
- A **Sub-Process** is instantiated when it is reached by a **Sequence Flow** *token*. The **Sub-Process** has either a unique empty **Start Event**, which gets a *token* upon instantiation, or it has no **Start Event** but **Activities** and **Gateways** without *incoming* **Sequence Flows**. In the latter case all such **Activities** and **Gateways** get a *token*. A **Sub-Process** MUST not have any non-empty **Start Events**.
- If the **Sub-Process** does not have incoming **Sequence Flows** but **Start Event**s that are target of **Sequence Flows** from outside the **Sub-Process**, the **Sub-Process** is instantiated when one of these **Start Events** is reached by a *token*. Multiple such **Start Events** are alternative, i.e., each such **Start Event** that is reached by a *token* generates a new *instance*.
- A **Sub-Process** *instance* completes when there are no more *tokens* in the **Sub-Process** and none of its **Activities** is still active.
- If a “terminate” **End Event** is reached, the **Sub-Process** is abnormally terminated. For a “cancel” **End Event**, the **Sub-Process** is abnormally terminated and the associated *Transaction* is aborted. Control leaves the **Sub- Process** through a cancel intermediate boundary **Event**. For all other **End Events**, the behavior associated with the **Event** type is performed, e.g., the associated **Message** is sent for a **Message End Event**, the associated signal is sent for a signal **End Event**, and so on.
- If a global **Process** is called through a **Call Activity**, then the **Call Activity** has the same instantiation and termination semantics as a **Sub-Process**. However, in contrast to a **Sub-Process**, the global **Process** that is called MAY also have non-empty **Start Events**. These non-empty **Start Events** are alternative to the empty **Start Event** and hence they are ignored when the **Process** is called from another **Process**.
### 13.3.5 Ad-Hoc Sub-Process
An **Ad-Hoc Sub-Process** or **Process** contains a number of embedded inner **Activities** and is intended to be executed with a more flexible ordering compared to the typical routing of **Processes**. Unlike regular **Processes**, it does not contain a complete, structured **BPMN** diagram description—i.e., from **Start Event** to **End Event**. Instead the **Ad-Hoc Sub-Process** contains only **Activities**, **Sequence Flows**, **Gateways**, and **Intermediate Events**. An **Ad-Hoc Sub-Process** MAY also contain **Data Objects** and **Data Associations**. The **Activities** within the **Ad-Hoc Sub- Process** are not REQUIRED to have *incoming* and *outgoing* **Sequence Flows**. However, it is possible to specify **Sequence Flows** between some of the contained **Activities**. When used, **Sequence Flows** will provide the same ordering constraints as in a regular **Process**. To have any meaning, **Intermediate Events** will have *outgoing* **Sequence Flows** and they can be triggered multiple times while the **Ad-Hoc Sub-Process** is active. The contained **Activities** are executed sequentially or in parallel, they can be executed multiple times in an order that is only constrained through the specified **Sequence Flows**, **Gateways**, and data connections.
#### Operational semantics
At any point in time, a subset of the embedded **Activities** is *enabled*. Initially, all **Activities** without *incoming* **Sequence Flows** are enabled. One of the enabled **Activities** is selected for execution. This is not done by the implementation but usually by a *Human Performer*. If the ordering attribute is set to sequential, another enabled **Activity** can be selected for execution only if the previous one has terminated. If the ordering attribute is set to parallel, another enabled **Activity** can be selected for execution at any time. This implies the possibility of the multiple parallel *instances* of the same inner **Activity**. After each completion of an inner **Activity**, a condition specified through the completionCondition attribute is evaluated:
- 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 pre- and 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 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**.
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 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**.
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