How compensation processing works

At run time, CICS® Service Flow Runtime provides compensation control and coordination of adapter request processing. It contains a journaling facility using CICS/BTS container services to support compensation.

Overall responsibility for compensation lies with the service requestor. The run time processing associated with compensation is not initiated automatically when errors occur. Instead, the run time issues a reply (DFHMAH) and it is the responsibility of the service requestor to invoke compensation processing. If the service requestor decides not to invoke compensation processing, the process will remain in CICS SFR until it is cancelled.

Service Flow Modeler does not allow you to explicitly associate a compensating service flow to a modeled service flow. However, a person using the tool can model a service flow for the purpose of being used in compensation, if the service requestor:

When adapter request processing runs in asynchronous mode, syncpoints are taken while the Navigation Manager, Navigator and server adapters complete their processing. These synchronization points provide the necessary state, status and journaling information in the event of subsequent failure. This information can in turn be used in a flow that has been modeled to perform compensation.

The following list provides an overview of how compensation works:
  1. The person modeling the sequence flow to be used for compensation needs to set specific parameters and use logic in the service requestor to associate this flow to the one that requires compensation.
  2. A service flow that will be used for compensation, must be designated at the highest level (i.e., the Adapter) in the model.
  3. If a server adapter fails at run time, state and status information and journal data context are retained. This means that the failed BTS process is left in an incomplete state, therefore allowing other tasks to ACQUIRE the failed process and access the necessary container information. The state and status information is in a process container that is owned by the failed process. The journal context is in a data-container owned by the DFHROOT activity of the failed process (i.e., the Navigation Manager (DFHMAMGR).
  4. The failed BTS process name and process type are returned to the service requestor.
  5. The service requestor determines whether or not to send a request to invoke compensation. The message structure used by the service requestor adheres to the same structure that a normal request message adheres to. See Request message headers for a description of structure.
  6. The failed BTS process name and process type must be returned in the message structure on compensation. In addition, a new BTS process name and process type must be provided to run the compensating flow. Optionally, compensating application data may be supplied.
  7. The DPL Stub program DFHMADPL initiates compensation at run time. DFHMADPL performs the following tasks:
    • ACQUIRE the failed process using the failed process name and process type.
    • Retrieve (issue GET CONTAINER) the state and status and journal information.
    • CANCEL the failed process. At this point the failed process data is unavailable.
    • DEFINE the compensating flow process.
    • Write three process containers that contain the state and status information, journal context and compensating input message, respectively. These containers have read-only access to Navigators and server adapters.
    • RUN the compensating flow process.
  8. As is the case with normal processing, the state and status information is available (in read-only access) to the compensating Navigators. The information resides in the ADAPTER.PROCESS process data-container.
  9. The journal context is available to compensating Navigators in the ADAPTER.JOURNAL process container (again read-only access). It is the modelers responsibility to map from the journal process data-container to the compensating Navigators data context areas or other storage areas if necessary when defining and modeling the service flow to be used in compensation processing. The layout is in DFHMAMAC. The flow must have knowledge of the journal context structure.
  10. Any compensating application data is available to compensating Navigators as in normal processing in the ADAPTER.INPUT process container, again read-only access.