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:
- Is programmed with the necessary logic to coordinate the service flow
and the compensating service flow.
- Provides the necessary information in the message header (DFHMAH).
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:
- 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.
- A service flow that will be used for compensation, must be designated
at the highest level (i.e., the Adapter) in the model.
- 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).
- The failed BTS process name and process type are returned to the service
requestor.
- 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.
- 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.
- 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.
- 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.
- 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.
- Any compensating application data is available to compensating Navigators
as in normal processing in the ADAPTER.INPUT process container, again read-only
access.