Recovery Action

The final consideration in regard to exception handling is what action will be taken to remedy the effects of the situation that has been detected. There are three alternate courses of action:

  1. no action (NIL) - do nothing;
  2. rollback (RBK) - rollback the effects of the exception, by reversing the preceding process execution events recorded in the execution log; or
  3. compensate (COM) - compensate for the effects of the exception.

Rollback and compensation are analogous to their usual definitions (e.g. [MRKS92]). When specifying a rollback action, the point in the process (i.e. the task) to which the process should be undone can also be stated. By default this is just the current work item, although it can be any preceding point in the process. When a rollback action is initiated, the execution state of the process instance is reversed back to the point identified for the rollback by undoing the effects of any work items that have executed subsequent to the rollback point. It is important to note that this does not necessarily result in the execution state after rollback being identical to the execution state when the rollback point occured originally during execution state when the rollback point occurred originally during execution of the process instance, it merely undoes the effects of any subsequent work items as recorded in the execution log. The effectiveness of this recovery strategy is largely governed by the richness of the events captured in the execution log and some events (e.g. resource allocation, production of hard-copy reports) cannot be undone.

For compensation actions, a corresponding compensation process must also be identified. As with rollback, this process aims to undo the effects of preceding work items that resulted in or were affected by the exception. Because an entire process can be associated with the recovery action, it provdies a more flexible means of remedying the effects fo the exception and allows a wide variety of issues to be addressed, not just the observable actions as recorded in the execution log.

Previous - Exception Handling at Case Level
Next - Characterising Exception Handling Strategies