Compensation - mrietveld/jbpm GitHub Wiki

Wiki ▸ Compensation
2013-03-01

Further pages

Work Plans
Stackless refactoring

Table of Contents

This is a compilation of notes concerning Compensation from the following sources:

Everything below can be found in either one or both of the above sources.

Because the BPMN2 specification is not particularly clear on some points, including Compensation, I created these notes in order to figure out the exact (implementation) definition of Compensation and associated elements and functionalities.

Basic Definitions

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).

BPMN2 spec, pp. 428

Compensation Elements

Compensation Visibility

In short, compensation is neither inner- nor outer-recursive. It only applies to the compensation handlers on activites at it's own level.

Compensation of a successfully completed Activity triggers its compensation handler. The
compensation handler is either user defined or implicit. The implicit compensation handler of a
Sub Process calls all compensation handlers of its enclosed Activities in the reverse
order of Sequence Flow dependencies. If compensation is invoked for an Activity that has not yet
completed, or has not completed successfully, nothing happens (in particular, no error is
raised).

BPMN2 spec, p. 235

However, with regards to a activities compensated by a Compensation Intermediate Event, the following is written:

The Activity MUST be visible from the Compensation Intermeidate Event, i.e., one of the
following MUST be true: 

- The Compensation Intermediate Event is contained in normal flow at the same level of
  Sub-Process. 

- The Compensation Intermediate Event is contained in a Compensation Event Sub-Process which is
  contained in the Sub-Process containing the Activity. 

If no activity is identified, all successfully completed Activities visible from the
compensation Intermediate Event are compensated, in reverse order of their Sequence Flows.
Visible means one of the following: 

- The Compensation Intermediate Event is contained in normal flow and at the same level of
  Sub-Process as the Activities. 

- The Compensation Intermediate Event is contained in a Compensation Event Sub-Process which is
  contained in the Sub-Process containing the Activities. 

To be compensated, an Activity MUST have a boundary Compensation Event, or contain a Compensation
Event Sub-Process.

BPMN2 spec, p. 252

This means the following:

  • Compensation Boundary Events are visible from all other elements at the same level.
    • For example, a CBE in on a task in a sub-process is visible only to every other element in the same sub-process (at the same level of sub-process, e.g. not nested or outside that sub-process)
  • Compensation Event Sub-Processes are visible from all other elements at the same level as the (sub-)process which contains the Compensation Event Sub-Process.
    • For example, a CESP in a sub-process in a process, is visible only to all other elements at the (root) process level. Once you consider that CESPs in a sub-process can only be signalled once that sub-process completes, you can then see that this make sense.
  • This means that it's possible for a sub-process to have 2 compensation handlers: one Compensation Boundary Event (attached to the boundary of the sub-process) and one Compensation Event Sub-Process, within the sub-process itself. Both have the same level of visibility. However, we (jBPM) will not support this because it's an unclear situation with multiple possible outcomes.

Compensation Handlers

Meaning

  • A Compensation Handler is made up of the following:
    • A catch Compensation Event
      • This is either a Compensation Intermediate Boundary Event
      • or the Compensation Start Event of a Compensation Event Sub-Process
    • A set of Activities triggered by the Compensation Event

Function

  • Compensation can occur in Loop or Multi-Instance Sub-Processes
    • each (Loop or Multi-Instance) instance has it's own Compensation Handler instance
    • Triggering compensation for one individual Multi-Instance Sub-Process instance triggers compensation for all instances ("within the current scope").
      • This applies regardless of whether the Compensation Handler is a Boundary Event Compensation Handler or a Event Sub-Process Compensation Handler.

Structure

  • The set of activities in a Compensation Handler complies with the following:
    • The set is not connected to other portions of the BPMN Model
    • When the catch Event is a Boundary Event:
      • This must then be either a Task or a (non-Event) Sub-Process.
      • This will be a set of only one activity.
    • When the catch Event is the Start Event (of a Compensation Event Sub-Process):
      • This is the Compensation Event Sub-Process itself
    • The Compensation activity should have the isForCompensation attribute set to true
      • This is implied by 10.6.1 and Figure 10.121, but not explicitly stated.

Compensation Intermediate (Boundary) (catch) Event

Meaning

  • Trigger/Entry point for an associated compensating activity
    • An association is used to link it to a single compensating activity

Function

  • Triggered through one of the following:
    • the failure of a transaction
    • a thrown Compensation Event that targets the activity it's attached to
    • a thrown non-specific (broadcast) Compensation Event
    • a thrown error inside a Sub-Process which contains no error Event Sub-Process
  • Can only be triggered after the attached-to activity completes successfullly.
  • If one of the following is true for the attached-to activity:
    • has not started
    • is still running when the transaction fails (e.g. when the event is triggered)
    • completes unsuccessfully
  • Then
    • the compensating activity must not run

Structure

  • It has no outgoing sequence flow.
  • It MUST only be attached to the boundary of an Activity. (BPMN2 spec, p. 263)

Compensation Start (catch) Event

  • May ONLY be used for an event subprocess

Function

Compensation End/Intermediate (throw) Event

Meaning

  • Aborts the associated Transaction of the Sub-Process.
  • Indicates that compensation is necessary.

Function

  • If there is an identified activity:
    • the successfully completed Activity will be compensated.
  • If no Activity is identified, all successfully completed Activities visible from the Compensation End Event are compensated, in reverse order of their Sequence Flows.

Structure

  • Compensated activity/ies must be visible from the Compensation Throw Event (CTE), which means one of the following:
    1. The CTE is contained in normal flow at the same level of Sub-Process.
    2. The CTE is contained in a Compensation Event Sub-Process that is contained in the Sub-Process containing the Activity/ies.
    3. To be compensated, an Activity must
      • have a boundary Compensation Event
      • or contain a Compensation Event Sub-Process.

Compensation Event Sub-Process

A Compensation Event Sub-Process is contained within a Process or Sub-Processes. It can access
data that is part of its parent, including the snapshot of the point in time when its parent 
has completed. A Compensation Event Sub-Process can in particular recursively trigger 
compensation for Activities contained in its parent.

BPMN2 spec, P. 441

Function

  • Executed outside the normal flow
  • Can access data that is part of its parent
    • Specifically, the snapshot of data from when its parent completed
  • Can recursively trigger compensation for activities contained in its parent

Structure

  • Contained within a process or sub-process

Compensation association

Function

  • Links an activity with its associated compensating activity

Structure

  • Compensation association occurs outside the normal flow of the Process and is based upon a Compensation Intermediate Event.
  • The target of the Association must be marked as a Compensation Activity.

Cancel Intermediate (catch) Event

  • all other types of interrupting boundary events on a transactional subprocess abort the transaction without compensation.

Meaning

  • Identical to Error except that before beginning the error handling, cancel implictly commands compensation.
    • All successfully completed activities wthin the transaction (that have defined compensating activities) are undone by those compensating activities.

Function

  • Used(/activated) when the source of the (transaction) failure is within the transaction subprocess, not after the completion
  • Interrupting, like an error
    • Always interrupts the activity to which it is attached
  • Triggered if:
    • A Cancel End Event is reached in the transactional subprocess
    • A transaction-protocol "Cancel" message is received while the transaction is being executed.

Structure

  • Must be attached to the boundary of the transactional subprocess
  • May only be used with transactional subprocesses
  • Once compensation is complete, error handling commences by executing the exception flow or event subprocess associated with the Cancel event.

Cancel End (throw) Event

Meaning

  • Indicates that the Transaction should be cancelled

Function

  • Will trigger a Cancel Intermediate Event attached to the Sub-Process boundary.
  • Indicates that a TransactionProtocol Cancel Message should be sent to any Entities involved in the Transaction.

Structure

  • This type of End is used within a Transaction Sub-Process.

Business Transactions / Transactional Sub-Processes

Meaning

  • A transaction is a Sub-Process that
    • is supported by a special protocol
      • that insures that all parties involved have complete agreement that the activity should be completed or cancelled
  • Possible results:
    • Success
    • Fail (unsuccessful/Cancel)
    • Hazard

Function

  • Component activities must either
    • all complete successfuly
    • or the subprocess must be restored to its original consistent state.
  • Each activity in the transaction executes normally in its turn, but if the transaction as a whole fails to complete successfully,
    • the defined compensating activity is executed for each of the activities that has already successfully completedly.
  • 3 possible outcomes:
    • Sucessful completion:
      • a normal sequenceFlow that leaves the transactional subprocess
    • Failed completion (cancel):
      • a (Boundary) Cancel Intermediate Event will direct the flow
        • after the transaction has been rolled back
        • and after all compensation has been completed
      • two mechanisms to signal cancellation:
        • a Cancel End Event is reached
        • a Cancel Message can be received "via the transaciton protocol that is supporting the execution of the transactional subprocess
    • Hazard: something went terribly wrong and success or cancel is not possible
      • Error Intermediate Events are used to show Hazards
      • When a hazard happens, the activity is interrupted without compensation and the flow will continue from the Error Intermediate Event

Structure

  • Transactional Sub-Process attributes:

  • When each path of a transactional subprocess reaches a non-cancel end event, the following happens:

    1. First, the transaction protocol needs to verify that all of the participants have successfuly completed their end of the transaction.
    2. Then the flow will move up to the higher-level process.
      • If
        • one of the participants "ends up with a problem that causes a Cancel or a Hazard",
      • then
        • the flow will move to the appropriate intermediate event,
        • even though it apparently finished successufly.