| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Collector Node error handling |
« View previous topic :: View next topic » |
| Author |
Message
|
| hallmark |
 Posted: Fri Jul 16, 2010 6:23 am Post subject: Collector Node error handling |
 |
|
Voyager
Joined: 10 Mar 2005
Posts: 76
|
Hi,
I have a collector node with three inputs which is configured to process onwards once a message arrives on each of the inputs (say). Down stream of the collector node I have some logic that creates a message with items from DB and other enrichment before writing out a message to one or more queues.
If I should fail in this downstream part of the flow I would like to roll back any PUTs done to queues. However rethrowing in the catch terminal of the collector is not permitted as per my understanding.
1. Is there any way to rollback any queue PUTS even though the transaction is being completed down the catch terminal?
2. Is there any way to throw back to the original input nodes - i.e. have I misunderstood?
Or should I just simply let the collector generate it's event and immediately write to a queue to end that transaction and have all logic described above in a separate flow.
Thanks in advance
Rob
_________________
Rob |
|
| Back to top |
|
 |
| hallmark |
| Posted: Mon Jul 19, 2010 12:52 am Post subject: |
|
|
Voyager
Joined: 10 Mar 2005
Posts: 76
|
Have I asked
1) a really stupid question
2) a question that no-one cares about/has thought about before.
3) a question so specific to my own requirments that I should answer myself.
I hope it's not 1, am working on 3 in anycase and maybe (and you can't know this with the info I have posted) I am misusing the collector node by using it to trigger a new event when 3 other events have completed which could explain 2.
Rob
_________________
Rob |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Jul 19, 2010 1:56 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
You've asked a complicated question.
There's no way to roll back any transactions that occur BEFORE the out of the collector, once the message flow has reached the relevant In terminal.
That is, all of the inputs to Collector are separate and individual transactions from each other and from the output terminal of the Collector that must be handled separately.
There should be a way to deal with the exceptions down stream of the out terminal in the manner that you want to. But I've not reviewed the docs recently on this particular subject, so I can't say what it is. |
|
| Back to top |
|
|
| hallmark |
| Posted: Mon Jul 19, 2010 2:43 am Post subject: |
|
|
Voyager
Joined: 10 Mar 2005
Posts: 76
|
Thanks mqeff, I didnt mean option 2 to sounds as harsh as it did and wanted it to encompass the complexity. I am still reviewing the docs but am none the wiser.
Since the collector can't have a throw in its own catch terminal I suspect the implication is that this is a completely new event we have created which is why I am favouring the simple output queue which then drives the more complex logic down stream. This still smacks of a cludge to me, but the event of the 3 messages being collected did happen and didn't error (hence output from the collector) so why should they be troubled by other issues (e.g. DBs and so on)...
Thanks for your time
Rob
_________________
Rob |
|
| 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
|
|
|
|
