Compensation block

Scope: Scopes are used for three reasons:

1. to configure transaction (long running or atomic)
2. to handle exceptions
3. to trigger compensating logic

A scope shape can have one or more Exception handling blocks and one Compensation Block. The Transaction type you've chosen for your scope will define which of these blocks can be added. An atomic scope can only have a compensation block, and a scope configured with the transaction type none can only have an Exception block. While a long running scope can have both blocks.

For an overview of the possibilities, check the below screenshot.



There could be more than one Exception block, but only one Compensation block added to a Scope.


Compensation block
Compensation is a way to correct or undo logical piece of work that have previously committed. 
       An exception can occur in the orchestration after successfully executing all logic in the scope. In this case, the process might be in a state where it is logically incorrect. So the action already performed in a transnational scope need to be compensated... this can be achieved using a compensation block
If no compensation block is added, the default compensation will be performed. this means calling all compensation blocks of the nested scopes, starting with the most recently completed ones, just as with the default exception handler.

Compensations blocks may be created for both atomic and long running transactions.  Compensation blocks must be explicitly invoked. To invoke the Compensations block, finally drop the "Compensate" shape into the exception handler block (Compensate shape can be placed only in exception or compensation block) and set the "Compensation" property to the corresponding transaction name in the properties window.

A particular scope can be compensated only once.The compiler will prevent more than one path leading to the compensation of a particular scope.

Compensate
      The compensate shape can only be used inside of an exception handler. The explicit use of this compensate shape, allows us to specify the order of compensation execution ourselfs. So this can be used in cases the default order (starting from te most recently completed ones and working its way back) doesn't fit.
1 compensate shape can only trigger 1 compensation block of a transaction. So the order must be defined using multiple compensate shapes, calling the compensation blocks in the desired order.




When an Atomic transaction throws an exception, this will generally be caught at an outer non-atomic scope. Atomic scopes cannot have exception handlers of their own. Compensation can only be invoked if the exception is caught by an outer LongRunning transaction.

For Ex:

Consider the above scenario for basic compensation model

We have 1 LongRunning transaction and 3 nested atomic transactions which insert data in DB with their compensation blocks associated with them,now the 3rd atomic transaction fails to commit then it invoke the compensation block in backward direction .

Execution order:

Insert into Table1(scope Shape)
Insert into Table2(scope Shape)
Insert into Table3(scope Shape) —  not commited
Catch exception
Compensation block 2
Compensation block 1