MQ services can fail to successfully process an MQ message for various reasons.  For example, information in the message itself is missing or is not valid, an external system fails while the service is in the process of retrieving a message, and so on. 

When a message fails, the result can be incorrect or partially committed database transactions and a lost message.

To avoid incorrect transactions and/or losing messages after they were processed unsuccessfully, configure the MQ listener to support transacted messaging.

Suggested Approach

When you enable transacted messaging, there are two options for handling failed messages:

• Place the message back on the queue to be processed again. The MQ queue manager keeps a count of the number of times the message has been put back on the queue.  This number is called the backout count.
• Send the message to a different queue, called a backout queue, so that another process can examine the message to determine the problem

Typical configurations use a combination of both options.  That is, you specify how many times the service is to put a failed message back on the queue and attempt to process it again.  If the message is still not successfully processed after that many attempts, it gets sent to a backout queue for further processing.

There are two main steps when enabling transacted messaging:

1. Set up a queue on the MQ server to serve as the backout queue.

2. In Process Commander, configure the MQ listener instance (instance of Data-Admin-Connect-MQListener) to support transacted messaging.  Select the Properties tab, scroll down to the Transaction section, and enter values in the following fields:

• Select Transacted Messaging.
• In the Threshold field, enter the number of times the service should attempt to process the same message.
• In the Backout Requeue field, enter the name of the backout queue. Note that if you specify the name of a nonexistent queue, messages will be lost after they exceed the threshold limit.

After you enable transacted messaging support, the MQ service behaves like this:

1. When the MQ listener notices a message on the queue, it checks the backout count on the message.

• If the backout count is less than the threshold value, the listener routes the message to the appropriate MQ service for processing.
• If the backout count equals the threshold value, the listener puts the message on the backout queue rather than routing it to the service. Another process can now retrieve the message and either repair it or discard it.

2. When the MQ service receives a message from the listener, it attempts to process the message.

• If the processing succeeds, the message is permanently removed from the queue and any database transactions are committed.
• If the processing fails (the service activity returns an error in the status), database transactions are rolled back and the MQ message is put back on the original queue. The process starts over again at step 1.

If another process repairs a message, it can generate a new message from the repaired message.  That way, when the new message arrives on the queue, its backout count is set to zero.