The MQInput node has its own error handling for message flows. Consider how you want your solution to handle errors when your message flow contains an MQInput node.
The MQInput node attempts to connect to the queue manager when the flow is deployed and started. The MQOutput, MQGet, and MQReply nodes attempt to connect when the first message is sent or received. If any connection problems occur, see the WebSphere MQ product documentation for information about any mqrc return code values that are reported in the IBM® Integration Bus BIP messages.
When a message is rolled back to the input queue, the MQInput node attempts to process the message again. The MQInput node checks whether the backout threshold value has been reached. The BackoutCount for each message is maintained by WebSphere MQ in the MQMD.
When you create the queue, you can specify the value of the backout threshold attribute BOTHRESH, or use the default, 0. If you accept the default value of 0, the MQInput node increases this value to 1. The MQInput node also sets the value to 1 if it cannot detect the current value. If the backout threshold is set to 1, the message is processed once, and does not try again through the Out terminal of the MQInput node. For the message to try again at least once, set the backout threshold to 2.
The retry behavior for the MQInput node is as follows:
Typically, the backed out message is read again by the same MQInput node. However, depending on your WebSphere MQ queue manager configuration, it is possible for an MQInput node in a different message flow, or another WebSphere MQ application, to read the same input queue and get the backed-out message.
If you want to control or prevent roll back, you can use the Catch terminal, as described in Handling errors in message flows.
When a message is propagated through the Failure terminal, the exception list does not contain the exceptions that occurred in the flows that are connected to the Out or Catch terminals. The exception list contains new exceptions only, which describe the reason that the message went through the Failure terminal (for example, that the backout threshold was reached).
The MQInput node re-reads the message from the input queue before it is propagated through the Failure terminal. Therefore, the exception list does not contain the exceptions that occurred in the flows that are connected to the Out or Catch terminals. The exception list contains new exceptions only, which describe the reason that the message went through the Failure terminal (for example, that the backout threshold was reached).
The message cannot be discarded, therefore the message flow continues to attempt to backout the message. It records the error situation by writing errors to the local error log. A second indication of this error is the continual increase of the BackoutCount value of the message in the input queue.
If this situation occurs because neither queue exists, you can define one of the queues to resolve the problem. If the condition that prevented the message from being processed is resolved, you can temporarily increase the value of the BOTHRESH attribute, which forces the message through normal processing.
When a backed out message is read, the MQInput node can put the message to the backout queue or the DLQ. The BackoutCount value is checked when the message is received from the input queue. If the backout threshold is exceeded, the message is backed out immediately with no further processing performed on the message. The backout operation occurs in a separate transaction from previous processing failures, and the message is not parsed or validated during the backout transaction. The backout transaction generates its own set of monitoring events. Therefore, information that is obtained through message parsing, such as the exceptionList, might not be available.
WebSphere MQ supports message groups. You can specify that a message belongs to a group and its processing is then completed with the other messages in the group (that is, either all messages are committed or all messages are rolled back). When you send grouped messages to an integration node, this condition is upheld if the message flow is configured correctly, and errors do not occur during group message processing.
To configure the message flow to handle grouped messages correctly, review Receiving messages in a WebSphere MQ message group. However, if an error occurs while one of the messages is being processed, the message group might not be processed correctly.
If the MQInput node is configured as described, all messages in the group are processed in a single unit of work, which is committed when the last message in the group is successfully processed. However, if an error occurs before the last message in the group is processed, the unit of work that includes the messages, up to and including the message that generates the error, is subject to the error handling defined by the rules that are documented here, which might result in the unit of work being backed out.
Any of the remaining messages in the group might be successfully read and processed by the message flow, and therefore are handled and committed in a new unit of work. The unit of work is committed when the last message is processed. Therefore, if an error occurs in a group, but not on the first or last message, it is possible that part of the group is backed out and another part is committed.
Depending on the type of message processing that you require, you might need to provide extra error handling for message groups. For example, you might record the failure of the message group in a database, and include a check on the database when you retrieve each message. This check would force a rollback if the current group already encountered an error. This error handling configuration would ensure that the whole group of messages is backed out and not processed unless all are successful.