| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Full transaction and error logging |
« View previous topic :: View next topic » |
| Author |
Message
|
| Galichet |
 Posted: Wed Jan 09, 2002 2:56 pm Post subject: |
 |
|
Acolyte
Joined: 26 Jun 2001
Posts: 69
Location: Paris - France
|
Hi all,
I have the following problem :
need:
I have a flow that splits a message into two queues (A & B)
I want to log all errors messages (using the exception list) and send a error message in a specific Queue (C), this Queue is used in the Catch path (from the MQInput Node)
Problem
I want to be sure that the message is put in both Queues or none (if the put message in the Queue A fails, the message mustn't be sent to the Queue B).
Using the Catch path, when an error occurs for Queue A or B, the errors is trapped by the Catch and a message is generated in Queue C.
So, if for example I cannot put the message in Queue B, I have a message in Queue A and a message in Queue C.
In that case, I don't want to have the message in the Queue A, I would like to have a rollback for all the transaction but not for the Queue C (I want to have my error message).
When an error occurs, if the catch process doesn't work (Queue C full for example), I want to stop the processing of the flow. To do this, the Queue failure is not defined : The message remains on the Input queue. And a manual operation is done to reactivate the flow.
How could I do to do a rollback without sending the message in the failure Queue ?(the Queue C contains the necessary data to requeue the message after).
I've tried to do something using the Throw node, but without success (The best I can have is a rollback but with a message sent to the failure Queue).
anyone has an idea ?
_________________
Eric Galichet
SMABTP
France |
|
| Back to top |
|
 |
| kirani |
| Posted: Wed Jan 09, 2002 5:09 pm Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001
Posts: 3779
Location: Torrance, CA, USA
|
Eric,
I think you can achieve this by doing following,
1. Set 'Transaction Mode' of Queue A and Queue B to 'Yes' in MQOutput node .
2. Set 'Transaction Mode' of Queue C to 'No' in MQOutput node.
3. Enable Message flow for 'Coordinated Transaction'.
Let me know how it goes.
Kiran |
|
| Back to top |
|
|
| mpuetz |
| Posted: Thu Jan 10, 2002 11:18 am Post subject: |
|
|
Centurion
Joined: 05 Jul 2001
Posts: 149
Location: IBM/Central WebSphere Services
|
Hi,
the previous mail is pretty much the correct answer, but the 3. step is optional if you only manipulate MQ Series queues in your flow. Setting the global transaction coordination in the assignment panel to 'yes' switches on 2-Phase-Commit protokoll which is only needed if your flow also manipulates external database. Even then it's not mandatory since you can change the transaction mode of datasources as well in your compute or database nodes. But transaction coordination is then only 1 Phase-Commit under broker control (which offers less security).
To dig a littler deeper, you have to understand that as long as the catch tree ends without an exception, the *whole* flow is assumed to be succesful, hence A and B and C will be commited !! To roll back the messages to A and/or B you have to execute a throw node at the end of your catch tree !
If A and B have transaction mode 'yes' they will be rolled back then, but if C has transaction mode 'no' it will be explicitly
commited. Now, when catch tree throws an uncaught exception the message will be rolled back to the input queue and backout counter of the message will be incremented.
The message is read again at the next sweep. MQSI detects the backout count of > 0 and immedeately forwards it to the failure terminal of the input node. Now if that is *not* connected, the message is rolled back again and you have a nice infinite loop,
essentially stopping your message flow !
If you want to simply discard the message (since you already have it in your error queue C) you must connect the failure terminal of the input node to node which does nothing (e.g. a trace node with default options). Now you got rid of the infinite loop.
What happens when your C queue is full (or some other MQ error queues) ? Well the error message is not written, the message gets rolled back and its discarded in the failure flow. Bummer !
To avoid this have to explicitly catch the MQ exception with a extra try/catch node in front of C Output Node and handle it in some other fashion. An elegant solution would be
generate a PCF message and send it to the QMgrs command server control queue to get inhibit the input queue, thus stopping your flow in a safe manner. A simpler failover strategy would be to write to a backup error queue and raise an alert (maybe using the email plugin).
I hope this helps.
_________________
Mathias Puetz
IBM/Central WebSphere Services
WebSphere Business Integration Specialist |
|
| Back to top |
|
|
| Sandman |
| Posted: Thu Jan 10, 2002 12:29 pm Post subject: |
|
|
Centurion
Joined: 16 Oct 2001
Posts: 134
Location: Lincoln, RI
|
Just to add to Mathias' excellent response:
The infinite loop caused by not wiring the MQInput node's Failure terminal can be avoided if you configure the input queue to specify a "Backout Requeue Name". This has the added benefit (WE see it as a benefit anyway) of leaving a copy of the original input message around - which we might choose to requeue as is later - as well as an "error" message about why the input message didn't get processed. FWIW, we stamp the error message w/ the correlId of the input message for tracking purposes.
|
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
