OTMA transaction orchestration using asynchronous callout

After an IMS Connect client submits a CM0 send-receive transaction request to IMS with the transaction orchestration function activated, it then waits for a response from IMS. IMS transaction A processes the request and performs an asynchronous callout via ALTPCB to an external processing system for a response. When the external processing system sends a response back to IMS via an OTMA client, such as MQSeries® or IMS Connect, with a transaction code specified, IMS OTMA can correlate the response to the waiting IMS Connect client and route the response back to the waiting client.

To activate the transaction orchestration function, IMS Connect customers can choose to use a message level activation or a datastore level activation.

  • For message level activation, the IMS Connect client needs to turn on the new client flag OMCTLORC via IMS Connect message exit, such as HWSSMPL1, for the input CM0 send-receive request.

  • For datastore level activation, the IMS Connect system, IMS Connect datastore, or OTMA client descriptor can activate the transaction orchestration function by using TRANORCH parameter so that all of the IMS Connect CM0 send-receive calls from the datastore or member can have the function activated.

The order of precedence of activating transaction orchestration is as follows:

  1. Message level activation via IMS Connect message exit

  2. Datastore or HWS level activation in IMS Connect

  3. IMS activation via OTMA client descriptor

Once a response is sent back to IMS by an external processing system via an OTMA client, there are three methods you can choose from to route the response back to the waiting IMS Connect client.

  • Method 1 is to use the OTMA destination descriptor with ORCHRSP=YES via ISRT ALTPCB so that IMS can know the waiting IMS Connect client by the specified TMEMBER and TPIPE names in the destination descriptor.

  • Method 2 is to use the OTMA DRU0 exit to specify the TMEMBER/TPIPE names for the waiting IMS Connect client. Make sure that the new output flag X’04’ is set at the offset +16 of the output parameter list.

  • Method 3 is to use an IMS Connect client, such as IMS TM Resource Adapter, that supports the IMS callout correlator token to send a response back to IMS. This type of IMS Connect client issues a Resume TPIPE request to retrieve the asynchronous callout message with the callout correlator token from IMS, and then sends a response back to IMS with the same callout correlator token. The callout correlator token includes the following information:
    • The name of the waiting IMS Connect datastore name
    • The waiting TPIPE name or clientID name
    • IMS id of the IMS which performs the asynchronous callout Unique token id
    • Optionally, the userid of the original transaction orchestration input message, if the length of the waiting datastore name is equal to or less than 8 bytes.
    Make sure that an IMS transaction code is specified in the beginning of the response data from the external system so that IMS can process the response via ISRT I/O PCB or ISRT ALTPCB.
    • If the ISRT ALTPCB is used to send a response back to the waiting IMS Connect client, specify CORRTKN=YES in the OTMA destination descriptor with TYPE=IMSCON. No other parameters are needed for this destination descriptor.
    • If the ISRT ALTPCB is used to send a response back to the waiting IMS Connect client using DFSYDRU0 user exit instead of OTMA destination descriptor, make sure to turn on X'04' output flag in the output parameter list of the exit.

    Make sure to apply PTF UO04689 for APAR PH65775 to support the multiple callout scenario when you want IMS to send multiple asynchronous callout messages. Each asynchronous callout message carries its own callout correlator token so that IMS can properly handle multiple callouts and its response messages.

Because the OTMA transaction orchestration function introduces new parameters for both the OTMA client descriptor and the OTMA destination descriptor, a COLD start of IMS is required if you change these parameters via the DFSYDTx Proclib member.

IMS OTMA has a default 10-second timeout for the response message when the transaction orchestration function is activated. This timeout value can be updated by using RESPTO parameter in the OTMA client descriptor or destination descriptor. If specified, the RESPTO value in the OTMA destination descriptor takes precedence.

The following are the restrictions of using the new function:

  • IMS Connect is the only OTMA client which can activate the transaction orchestration function via a message level activation or datastore level activation.

  • After an external processing system receives an asynchronous callout message from an IMS, it needs to send back a reply to the same IMS which delivers the asynchronous callout message. The response can then be processed by a different shared queues back-end IMS.

  • When multiple response messages via IOPCB ISRT and/or ALTPCB ISRT are sent back to the waiting IMS Connect client, only the first response message will be accepted by IMS Connect. The subsequent response messages, by default, will be queued to a hold queue of OTMA TPIPE.

  • When a super member is used for transaction orchestration, the IMS super member can only support one client member. Additional client members to use the same super member will be rejected at OTMA connection time.

  • When an IMS Connect client submits an CM0 send-receive message to IMS with the new function activated, the size of the user data prefix cannot go over 512 bytes.