If operations occur that are not part of a transaction, then reversing operations must be applied to undo the changes. The reversing operations are performed to reverse the effects of the unwanted operations. This recipe shows how to do that.
Open the BPEL process that performs operations that cannot be rolled back as part of a transaction, and instead requires reversing operations to be applied in the case of a processing failure.
- For each operation (usually an
invokeactivity) that has a corresponding reversing operation, wrap it in ascopeactivity by dragging a scope from the Component Palette and dropping it just after the operation that requires reversing:
- Move the activity or activities that require reversing into the scope by dragging-and-dropping them into the scope:
-
Click on the Add Compensation Handler icon
in the scope to add a compensation handler:
- Drag appropriate activities (usually an
assignand aninvoke) into the compensation handler to reverse the operations in the corresponding scope:
- If a failure in an operation does not throw a fault, then create a Throw activity by dragging it into the scope that contains the failed operation (see step 2 of the recipe Aborting a transaction in this chapter).
- Choose an appropriate fault type (see step 4 of the recipe Aborting a transaction).
- Drag appropriate activities (usually an
assignand aninvoke) into the compensation handler to reverse the operations in the corresponding scope. - Add a catch block to the outermost scope (see step 3 of the recipe Catching rollback faults).
- Drag a Compensate activity from the Component Palette onto the catch that was just created:
When a fault is caught by catch, compensate it will cause all the operations that require reversing to be reversed.
Compensate can only be called from within a catch block. When it is called, it starts with the most recently completed scope and calls the compensation handler for that scope if it has one. It then looks for the previously completed scope and calls the compensation handler for that scope. In this way, the reversing operations are applied in the reverse order to the original operations. If a scope was not completed, its compensation handler will not be invoked.
If an operation throws a fault, we can catch it and call the Compensate activity. Operations may indicate failure by returning a failure status rather than throwing a fault. In this case, by placing a Throw activity inside the scope for which the operation failed, we can avoid the reversing operation being invoked for that scope.
Compensation occurs outside of transaction boundaries. So a BPEL process may be spread across several transactions, but compensation ignores this and continues to invoke compensation handlers for completed scopes regardless of the transaction context in which they were completed.