Requests can be processed in synchronous mode or in asynchronous
mode, regardless of the deployment pattern associated with the Adapter
service.
The fundamental difference between adapter request processing in asynchronous
mode versus adapter request processing in synchronous mode is:
- The BTS process implementing an instance of the CICS® Service
Flow Runtime for
inquiry requests, is run in the same unit of work with the same commit
scope as the WebSphere® MQ-CICS
bridge link task. The DPL stub program and the BTS process initiated by the
stub program are run synchronously as part of this single unit of work
- The BTS process implementing an instance of the CICS Service
Flow Runtime for
update requests, is run asynchronously from the initiating unit of work.
All BTS activities within that BTS process are run asynchronously from their
parent activities. This has the effect of running the BTS process and all
activities as separate units of work, each with a distinct commit scope.
Running asynchronously means that data can only be added to the
output message after the execution of the last server adapter. If your modeled
flows require data to be moved to the output message between the invocation
of server adapters, i.e. in mid-flow, use the synchronous processing mode.
This restriction is removed when you apply APAR PK32131.
Under normal circumstances, if you are invoking the runtime environment
using a CICS-supplied interface, you cannot run in asynchronous mode.