Requests in the CICS® Service Flow Runtime can be processed in synchronous mode or in asynchronous mode. You can use any of the supported interfaces to run an adapter service synchronously. However, to process requests asynchronously, you must use WMQ and the Websphere MQ-CICS bridge to invoke an adapter service.
When the service requester invokes an adapter service synchronously, the DFHMADPL stub program defines the BTS process for the navigation manager and runs it synchronously. The navigation manager then waits for the server adapter request processing to complete before returning to DFHMADPL. When the BTS process completes, the unit of work is committed, even if there are system errors. If you do not want this to happen, you can use the synchronous rollback mode
Synchronous rollback is indicated by the request record of the adapter service that is defined in the properties file. A value of 2 for the PARM01 parameter in the Request type indicates that the request should be processed in synchronous rollback mode.
If you use synchronous rollback for your adapter service, if a failure occurs in any activity within the BTS process, an abend occurs. This has the effect of returning the state of any and all recoverable resources updated during server adapter request processing to the state it was in prior to the start of the failed request. For example, if your adapter service comprises a series of DPL requests that need to run as a single unit of work and be committed, if any one of the DPL requests is unsuccessful the unit of work is not committed.
If the navigation manager detects an error, it issues the following command:
EXEC CICS ABEND ABCODE('CIA')
CANCEL
NODUMP
END-EXEC
This command ends the process with abend code CIA, and causes no dump to be taken in the CICS region.
The service requester must be a WebSphere MQ enabled application in order to invoke an adapter service asynchronously. The following scenario explains how the request message is processed asynchronously.