Synchronous and asynchronous processing

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.

Synchronous mode

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.

Asynchronous mode

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.

  1. A message is sent to a queue monitored by the WebSphere® MQ-CICS bridge monitor task (CKBR). The ReplyToQ and ReplyToQMgr are not loaded in MQMD Message Descriptor, but instead are included in the DFHMAH message header.
  2. The bridge monitor task CKBR starts the bridge link task CKBP.
  3. The bridge link task pulls the message from the queue and links to the DPL stub program DFHMADPL with the request message.
  4. DFHMADPL initiates the BTS process to start the navigation manager asynchronously, using the command BTS RUN ACQPROCESS ASYNCHRONOUS, and returns to the bridge task. The bridge task also returns, committing the GET of the request message.
  5. The navigation manager initiates the generated navigator asynchronously, using the BTS RUN ACTIVITY ASYNCHRONOUS command, and returns and waits for the navigator to complete its processing.
  6. The navigator initiates the server adapters that comprise the adapter service asynchronously.
  7. The navigator handles the completion events of the server adapters until all of the request processing is complete.
  8. When the processing is complete, the navigation manager is invoked with the completion event of the navigator.
  9. The navigation manager reads any reply message from the navigator's output data-container, and puts the reply message on the queue defined by the ReplyToQ and ReplyToQMgr fields in the DFHMAH message header.
  10. The navigation manager ends the process.