MQeInput error handling

The MQeInput node takes unique actions when it handles errors with persistent and transactional messages. (Errors encountered with non-transactional messages are handled as described in Managing errors in the input node).

This action is summarized in the table below:

Error event Failure terminal connected Failure terminal not connected Catch terminal connected Catch terminal not connected
Node detects internal error Fail flow handles the error Node retries Not applicable Not applicable
Node propagates message to out terminal, exception occurs in out flow Not applicable Not applicable Node retries then propagates to catch terminal Node retries
Node propagates message to catch terminal, exception occurs in catch flow Fail flow handles the error Node retries Not applicable Not applicable
Node propagates message to failure terminal, exception occurs in fail flow Not applicable Not applicable Node puts message to alternative queue Node puts message to alternative queue

Retry processing

The node attempts retry processing when a message is rolled back to the input queue. It checks whether the message has been backed out before, and if it has, whether the backout count has reached (equalled) the backout threshold. The backout count for each message is maintained by WebSphere MQ in the MQMD.

You specify (or allow to default to 0) the backout threshold attribute BOTHRESH when you create the queue. If you accept the default value of 0, the node increases this to 1. The node also sets the value to 1 if it cannot detect the current value. This means that if a message has not been backed out before, it is backed out and retried at least once.

  1. If the backout threshold has not been reached, the node gets the message from the queue again. If this fails, this is handled as an internal error (described above). If it succeeds, the node propagates the message to the out flow.
  2. If the backout threshold has been reached:
    • If appropriate, the node propagates the message to the catch or failure terminal, according to the situation in which the error occurs (described above).
    • If not appropriate, the node puts the message on an available queue, in order of preference:
      1. The message is put on the input queue's backout requeue name (queue attribute BOQNAME), if one is defined.
      2. If the backout queue is not defined, or it cannot be identified by the node, the message is put on the dead letter queue (DLQ), if one is defined. (If the broker's queue manager has been defined by the mqsicreatebroker command, a DLQ with a default name of SYSTEM.DEAD.LETTER.QUEUE has been defined and is enabled for this queue manager.)
      3. If the message cannot be put on either of these queues because there is an MQPUT error (including queue does not exist), or because they cannot be identified by the node, it cannot be handled safely without risk of loss.

        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 incrementing of the BackoutCount of the message in the input bridge queue.

        If this situation has occurred because neither queue exists, you can define one of the backout queues mentioned above. If the condition preventing the message from being processed has cleared, you can temporarily increase the value of the BOTHRESH attribute. This forces the message through normal processing.

Related concepts
Message flows

Related tasks
Handling errors in message flows
Managing errors in the input node
Catching exceptions in a TryCatch node
Using subflows
Creating a message flow
Defining message flow content

Related reference
Built-in nodes
WebSphere MQ Mobile Transport