message requeue and placing into backout issues

Question

I'm stuck with the following issue with message Broker 7.0.0.5 Here is my flow:

what I want it to do: 1. accept an XML, parse, using XMLNSC 2. then I want some business logic to be performed, but let's skip it and focus on the following - I want to throw two user exceptions - one in module GoodReport, another one - in module BadReport, therefore, after being processed in both Out and Catch flows, I assume my message to land to Backout Queue (I have created one for my queue, and set Threshold to 10) and be sent back to MQInput in order to be processed again. So I expect 10 messages in the Backout queue, but instead - I get NOTHING

I can see both errors being thrown in my flow, but what wonders me most is the last lines in the trace - from where have that "XMLNS" domain appeared? I use only XMLNSC domain.

And why the message does not appear in the Backout queue?

Thank you in advance!

Tatiana.

here is the trace:

2012-12-17 19:25:54.692283 5756 RecoverableException BIP2488E: ('.Esql6_1Flow_Report.Main', '19.4') Error detected whilst executing the SQL statement ''THROW EXCEPTION MESSAGE 3 VALUES( 'NO_SUCH_SOURCE');''. The message broker detected an error whilst executing the given statement. An exception has been thrown to cut short the SQL program. See the following messages for details of the error.

2012-12-17 19:25:54.692302 5756 UserException ?????????? 3 ?????????? BIPmsgs.properties 2012-12-17 19:26:52.830982 5756 Error BIP2628E: Exception condition detected on input node 'Esql6_1Flow.MQInput'. The input node 'Esql6_1Flow.MQInput' detected an error whilst processing a message. The message flow has been rolled-back and, if the message was being processed in a unit of work, it will remain on the input queue to be processed again. Following messages will indicate the cause of this exception. Check the error messages which follow to determine why the exception was generated, and take action as described by those messages.

2012-12-17 19:26:52.831005 5756 RecoverableException BIP2230E: Error detected whilst processing a message in node 'Esql6_1Flow.BadReport'. The message broker detected an error whilst processing a message in node 'Esql6_1Flow.BadReport'. An exception has been thrown to cut short the processing of the message. See the following messages for details of the error.

2012-12-17 19:26:52.831012 5756 RecoverableException BIP2488E: ('.Esql6_1Flow_Compute.Main', '13.4') Error detected whilst executing the SQL statement ''THROW EXCEPTION MESSAGE 3 VALUES( 'NO_SUCH_SOURCE');''. The message broker detected an error whilst executing the given statement. An exception has been thrown to cut short the SQL program. See the following messages for details of the error.

2012-12-17 19:26:52.831020 5756 UserException ?????????? 3 ?????????? BIPmsgs.properties

2012-12-17 19:26:53.831737 5756 Error BIP2648E: Message backed out to a queue; node 'Esql6_1Flow.MQInput'. Node 'Esql6_1Flow.MQInput' has received a message which has previously been backed out one or more times because of a processing error in the main path of the message flow. The failure terminal is not attached, so the message broker is putting the message directly to the requeue or dead letter backout queue associated with this node. The MQMD 'backoutCount' of the message now equals the 'backoutThreshold' defined for the WebSphere MQ input queue. Examine previous messages and the message flow to determine why the message is being backed out. Correct this situation if possible. Perform any local error recovery processing required.

2012-12-17 19:26:53.832435 5756 UserTrace BIP2638I: The MQ output node 'Esql6_1Flow.MQInput' attempted to write a message to queue ''SYSTEM.DEAD.LETTER.QUEUE'' connected to queue manager ''testQueueManagerName''. The MQCC was '0' and the MQRC was '0'.

2012-12-17 19:26:53.832466 5756 UserTrace BIP2615I: The WebSphere MQ input node 'Esql6_1Flow.MQInput' has backed out the message to the backout requeue or the dead letter queue. Message backout processing has been invoked, and the message has either been backed out by being written to the backout requeue or dead letter queue, as determined by the WebSphere MQ queue manager and queue configuration. No user action required.

2012-12-17 19:27:31.087949 4380 UserTrace BIP2632I: Message received and propagated to 'out' terminal of MQ input node '.InputNode'.

2012-12-17 19:27:31.088045 4380 UserTrace BIP6060I: Parser type ''Properties'' created on behalf of node '.InputNode' to handle portion of incoming message of length 0 bytes beginning at offset '0'.

2012-12-17 19:27:31.088066 4380 UserTrace BIP6061I: Parser type ''MQMD'' created on behalf of node '.InputNode' to handle portion of incoming message of length '364' bytes beginning at offset '0'. Parser type selected based on value ''MQHMD'' from previous parser.

2012-12-17 19:27:31.088092 4380 UserTrace BIP6069W: The broker is not capable of handling a message of data type ''''. The message broker received a message that requires the handling of data of type '''', but the broker does not have the capability to handle data of this type. Check both the message being sent to the message broker and the configuration data for the node. References to the unsupported data type must be removed if the message is to be processed by the broker.

2012-12-17 19:27:31.088113 4380 UserTrace BIP6061I: Parser type ''XMLS'' created on behalf of node '.InputNode' to handle portion of incoming message of length '236' bytes beginning at offset '364'. Parser type selected based on value ''XMLS'' from previous parser.

Answer 1

BACKOUT count determines the number of times the flow should retry processing the message. Here the threshold is set as 10, that means the flow tries the processing 10 times and if it still failed, MQInput node will put the message to backout queue or DLQ if backout queue is not configured. Flow will put only one message to the backout queue, not 10 messages as exepected by you

If the messages are processed in non-transactional mode, then the flow will not put the message to backout queue. Check whether you have configured Transactional property as 'NO' in the MQInput node. If the configured value is 'Automatic' then the message should be a persistent one to get it processed under a transaction. But the trace snippet shows the message is put to SYSTEM.DEAD.LETTER.QUEUE. You may need to check whether the message is in DLQ and also confirm backout queue property is correctly configured in the input node.

Have a read on http://publib.boulder.ibm.com/infocenter/wmbhelp/v7r0m0/topic/com.ibm.etools.mft.doc/ac00414_.htm this will address all your queries.