Compensation Handling

As indicated earlier, compensation for a successfully completed scope occurs under the guidance of a compensation handler, which reverses the scope's effect in response to a business development such as a cancelled purchase.

Imagine that scope in a BPEL process invokes a data-access service to record a customer's purchase. The service commits the changes because a multi-user database should not (and perhaps cannot) stay in an uncommitted state for days. The parent scope, however, runs an event handler for days more, waiting for a cancellation message for as long as the customer is allowed to cancel. If the message comes, the event handler issues a fault, and the fault handler invokes a compensation handler that in turn invokes a service to revise the database.

Invocation of a compensation handler always comes from a parent scope - specifically, from a fault, compensation, or termination handler that issues either of two activities: compensateScope or compensate.

The compensateScope activity invokes the compensation handler of a specific nested scope. Here, a failure in scope A causes invocation of the compensation handler in scope B:

 <scope name="A">    <compensationHandler>      <compensateScope target="B">    </compensationHandler>    <scope name="B">       <compensationHandler>          <!- a basic or structured activity is here ->       </compensationHandler>    </scope> </scope> 

The compensate activity invokes the compensation handler in each nested scope, in most cases in an order that is opposite to the order of scope completion. That behavior is guaranteed, however, only when the initiation of one scope depends on the completion of another, as is true when nested scopes run in sequence. Otherwise, the order is specific to a BPEL engine.

The compensate activity does not handle descendant scopes other than the immediately nested scopes. The assumption is that an invoked compensation handler will itself invoke the compensation handlers at the next descendant level.

The name of a scope embedded in a loop refers to all the scope instances that run in that loop, and the compensate or compensateScope activity from the parent scope invokes a group of compensation handlers, as appropriate.

A compensation handler has access to all values that were in effect when the scope completed, including the values of variables, correlation sets, and partner links. A problem can arise, however, if scopes are running at the same time as the one being compensated. You can ensure that changes to shared variables in one scope do not affect the values of variables in another. For details on isolating one scope from another, see the description of the scope activity in Appendix C.

If you do not specify a compensation handler for a given scope, the BPEL engine uses the following default.

 <compensationHandler>    <compensate/> </compensationHandler> 

A compensation handler (for example, a handler named inProcess) can be internally complex, and you can use embedded compensation handlers to ensure (as much as possible) that the activities in handler inProcess succeed or fail as a unit, rather than leaving some changes compensated and some uncompensated.

Two rules apply to the internals of a compensation handler. First, the top level cannot include a fault, compensation, or termination handler; and no default handlers are available at that level. Second, a scope nested directly in the compensation handler cannot include a compensation handler.

A business process might need to undo a compensation that completed successfully, but the question arises, "How many reversals are supported?" A compensation that compensates for a previous compensation might need.… You see the issue.

A BPEL process offers no routine way to undo the effects of a compensation handler that completed successfully. A business process ultimately relies on personal intervention.