---
title: "10.7 Compensation"
chapter: "10 Process"
source: "OMG BPMN 2.0.2 — formal/2013-12-09"
pages: "301-304"
---
> 10 Process · páginas 301-304 · [índice](../README.md)
## 10.7 Compensation
*Compensation* is concerned with undoing steps that were already successfully completed, because their results and possibly side effects are no longer desired and need to be reversed. If an **Activity** is still active, it cannot be compensated, but rather needs to be canceled. Cancellation in turn can result in *compensation* of already successfully completed portions of an active **Activity**, in case of a **Sub-Process**. *Compensation* is performed by a *compensation handler*. A *compensation handler* performs the steps necessary to reverse the effects of an **Activity**. In case of a **Sub-Process**, the *compensation handler* has access to **Sub-Process** data at the time of its completion (“snapshot data”). *Compensation* is triggered by a *throw* **Compensation Event**, which typically will be raised by an *error handler*, as part of cancellation, or recursively by another *compensation handler*. That **Event** specifies the **Activity** for which *compensation* is to be performed, either explicitly or implicitly.
### 10.7.1 Compensation Handler
A *compensation handler* is a set of **Activities** that are not connected to other portions of the **BPMN** model. The *compensation handler* starts with a *catch* **Compensation Event**. That *catch* **Compensation Event** either is a boundary **Event**, or, in case of a **Compensation Event Sub-Process**, the *handler’s* **Start Event**. A *compensation handler* connected via a boundary **Event** can only perform “black-box” *compensation* of the original **Activity**. This *compensation* is modeled with a specialized **Compensation Activity**, which is connected to the boundary **Event** through an **Association** (see Figure 10.121). The **Compensation Activity**, which can be either a **Task** or a **Sub-Process**, has a marker to show that it is used for *compensation* only and is outside the *normal flow* of the
*Figure 10.121 – Compensation through a boundary Event* (p. 302)
A **Compensation Event Sub-Process** is contained within a **Process** or a **Sub-Process** (see Figure 10.122). Like the **Compensation Activity**, the **Compensation Event Sub-Process** is outside the *normal flow* of the **Process**. The **Event Sub-Process**, which is marked with a dotted line boundary, can access data that is part of its parent, a snapshot at the point in time when its parent completed. A **Compensation Event Sub-Process** can recursively trigger *compensation* for **Activities** contained in its parent.
*Figure 10.122 – Monitoring Class Diagram* (p. 303)
It is possible to specify that a **Sub-Process** can be compensated without having to define the *compensation handler*. The **Sub-Process** attribute compensable, when set, specifies that default *compensation* is implicitly defined, which recursively compensates all successfully completed **Activities** within that **Sub-Process**. The example in 10.122, above contains a custom **Compensation Event Sub-Process**, triggered by a **Compensation Start Event**. Note that this *compensation handler* deviates from default *compensation* in that it runs **Compensation Activities** in an order different from the order in the forward case; it also contains an additional **Activity** adding **Process** logic that cannot be derived from the body of the **Sub-Process** itself.
### 10.7.2 Compensation Triggering
**Compensation** is triggered using a *compensation throw* **Event**, which can either be an **Intermediate** or an **End Event**. The **Activity** that needs to be compensated is referenced. If the **Activity** is clear from the context, it doesn’t have to be specified and defaults to the current **Activity**. A typical scenario for that is an inline *error handler* of a **Sub- Process** that cannot recover the *error*, and as a result would trigger *compensation* for that **Sub-Process**. If no **Activity** is specified in a “global” context, all completed **Activities** in the **Process** are compensated. By default, *compensation* is triggered synchronously, that is, the *compensation throw* **Event** waits for the completion of the triggered *compensation handler*. Alternatively, *compensation* can just be triggered without waiting for its completion, by setting the *throw* **Compensation Event’s** waitForCompletion attribute to *false*. Multiple *instances* typically exist for **Loop** or **Multi-Instance Sub-Processes**. Each of these has its own *instance* of its **Compensation Event Sub-Process**, which has access to the specific snapshot data that was current at the time of completion of that particular *instance*. Triggering *compensation* for the **Multi-Instance Sub-Process** individually triggers *compensation* for all *instances* within the current *scope*. If *compensation* is specified via a boundary *compensation handler*, this boundary *compensation handler* also is invoked once for each *instance* of the **Multi-Instance Sub-Process** in the current *scope*.
### 10.7.3 Relationship between Error Handling and Compensation
The following items define the relationship between *error handling* and *compensation*:
- Compensation employs a “presumed abort principle,” with the following consequences: Compensation of a failed **Activity** results in a null operation.
- When an Activity fails, i.e., is left because an error has been thrown, it’s the error handlers responsibility to ensure that no further *compensation* will be necessary once the *error handler* has completed.
- If no error Event Sub-Process is specified for a particular Sub-Process and a particular error, the default behavior is to automatically call *compensation* for all contained **Activities** of that **Sub-Process** if that *error* is thrown, ensuring the behavior for *auditing* and *monitoring*.