| Author |
Message
|
| Mohan215305 |
 Posted: Tue Feb 21, 2006 5:22 am Post subject: Error in Input Node in MQSI 2.1 |
 |
|
Newbie
Joined: 15 Feb 2006
Posts: 6
|
hi,
I have couple of questions regarding the Design of Message Flow in MQSI 2.1.
1. Under what conditions do we connect the Failure Terminal of the Input Node to a Compute Node (where the message is consumed)?
2. Please explain, under what circumstances the input message fails in the Input Node?
Please revert back at the earliest possible.
Thanks in advance,
Mohan |
|
| Back to top |
|
 |
| vk |
| Posted: Tue Feb 21, 2006 6:43 am Post subject: |
|
|
Partisan
Joined: 20 Sep 2005
Posts: 302
Location: Houston
|
|
| Back to top |
|
|
| Mohan215305 |
| Posted: Tue Feb 21, 2006 10:38 pm Post subject: |
|
|
Newbie
Joined: 15 Feb 2006
Posts: 6
|
Hi VK,
Thanks for your Inputs...
Before posting the question, I referred the manuals for Exception Handling (esp in the Input Node)........My question was from the design perspective.........may be I didnt put my question correctly......hence let me explain the scenario.
The scenario is, we have a message flow (already created) in which the Failure terminal of the Input Node is connected to a Compute Node (where the message is consumed) AND ExceptionSubflow is connected to the Catch Terminal
In case of any exception in the Input Node, there is all the likelihood that Message is lost.
My question is: Is this a good Design (to lose message) ?
How frequently the exception might occur in the Input Node........?
Thanks,
Mohan |
|
| Back to top |
|
|
| vk |
| Posted: Tue Feb 21, 2006 10:44 pm Post subject: |
|
|
Partisan
Joined: 20 Sep 2005
Posts: 302
Location: Houston
|
In the Input node, set Exception timing to Deferred. Then leave the failure and catch terminals of the input node unconnected.
Connect the failure terminals of all other nodes in the flow to your exception subflow.
Validation errors will be deferred to the node where the field is used and the message will be rolled back to the backout queue. You will not lose any messages.
Regards,
VK. |
|
| Back to top |
|
|
| elvis_gn |
| Posted: Tue Feb 21, 2006 10:46 pm Post subject: |
|
|
Padawan
Joined: 08 Oct 2004
Posts: 1905
Location: Dubai
|
Hi Mohan215305,
| Quote: |
| My question is: Is this a good Design (to lose message) ? |
No it is not a good design to lose messages...
I dont even think there would be a scenario of losing messages, your messages would either backout into the input queue or into the Dead letter queue...But even that should be taken care of...
You should have some exception queue or file writing where all failed messages are accounted for.
| Quote: |
| How frequently the exception might occur in the Input Node........? |
My question to this would be: How frequently will the user send wrong data or unparsable messages ?
Regards. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Feb 22, 2006 3:55 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
If you connect something to the failure terminal, then the MQInput node assumes you are going to handle the message entirely and roll-back or commit or discard as you choose. In addition, by the time you get to the failure node you have usually lost the original exception information.
It is a very bad idea to throw another error from a flow connected to the failure terminal - it will then loop back on itself forever.
The typical way I code error handling is to connect the Catch terminal only, take appropriate steps to log and decide how to handle the error. Then I end with a throw node. This causes the exception to propagate back to the MQInput node. Then normal retries can occur and the message can get put to the backout queue if defined.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
