Asynchronous delivery

To implement asynchronous delivery, one DataPower® service processes the request and another service processes the reply.

For each service, use the following properties.
  • The Units-of-work property of the local queue manager that is used by the handler is set to 1, which enables units-of-work.
  • The Process back-end errors property for the service is disabled. When disabled, the service can automatically roll back the front-end GET when connection errors are detected.
  • No reply-to queue is specified in the destination URL. The service can automatically send an MQCMIT to the front-end request queue when the MQPUT on the other side succeeds to complete the unit-of-work. The header of the message must contain no ReplyToQ specification.

The back-end MQPUT is not on the same connection as the front-end MQGET, especially when message-routing is involved. However, with no response rule processing, a failure between the back-end MQPUT and the front-end MQCMIT is small. If a failure happens, the request message is restored automatically by the queue manager and processed again, which results in duplicate delivery.

For guaranteed asynchronous delivery with no duplicates, each service can be configured to use loopback processing. Instead, the service uses the handler to place (MQPUT) the message on the handler PUT queue after request-processing completes. Set the var://service/mpgw/skip-backside variable to 1 in the processing policy. The configured PUT queue in the handler must be used as it is opened on the same connection as the GET queue in the handler GET queue. The MQCMIT then commits both the MQGET and MQPUT messages atomically.

This delivery pattern requires that the same queue manager manages the following combinations. The two queue managers, one for each direction, can be different.
  • The queue that contains request messages and the queue that is monitored by the target server.
  • The queue that contains back-end response messages and the reply queue that is monitored by the requesting application.

All the policy contexts and variables for each direction are separate and not available to each other. It is not, for example, possible to correlate a request to the target server with the response by using the message ID and the correlation ID.