| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Best way to handle backed out messages |
« View previous topic :: View next topic » |
| Author |
Message
|
| Nitgeek |
 Posted: Sat Dec 22, 2012 10:28 am Post subject: Best way to handle backed out messages |
 |
|
Novice
Joined: 21 Feb 2012
Posts: 21
|
I have a backout queue for my queue manager.
I want to build a message flow which will read this queue and if any message comes to the queue it should take the message and wrap it in a specially formatted XML message and put it in the normal exception queue which gets the handled exceptions.
But, the messages coming to the backout queue can be in any format and I have to make an xml where that message is going be a field.
So, what could be the best settings for my flow(Regarding MQMD properties like CCSID, format etc) and which parser should I use (DFDL or BLOB or MRM)?
Kindly advice. |
|
| Back to top |
|
 |
| goffinf |
| Posted: Sat Dec 22, 2012 11:31 am Post subject: Re: Best way to handle backed out messages |
|
|
Chevalier
Joined: 05 Nov 2005
Posts: 401
|
| Nitgeek wrote: |
But, the messages coming to the backout queue can be in any format and I have to make an xml where that message is going be a field.
|
Only if you are using a single BO queue for all of your message flows, otherwise you will know the format of the messages. Is that really the way you want to deal with messages that fail processing first time around ?
If you still want to have generic processing for any message on any BO queue well that rather depends what you want to do with that message. If its just part of exception processing and you just want to include it as part of the exception message you could acheive that using a CDATA field possibly with B64 encoding if you are worried that your messages may contain illegal XML characters. If you want to resubmit messages that have been backed out, then you would need metadata that helps you route them to the correct entry point (but that again depends on the reason for the original message being backed out, i.e you may want a retry policy that isn't indefinite). |
|
| Back to top |
|
|
| Nitgeek |
| Posted: Sat Dec 22, 2012 11:42 am Post subject: Re: Best way to handle backed out messages |
|
|
Novice
Joined: 21 Feb 2012
Posts: 21
|
| goffinf wrote: |
Only if you are using a single BO queue for all of your message flows, otherwise you will know the format of the messages. Is that really the way you want to deal with messages that fail processing first time around ?
If you still want to have generic processing for any message on any BO queue well that rather depends what you want to do with that message. If its just part of exception processing and you just want to include it as part of the exception message you could acheive that using a CDATA field possibly with B64 encoding if you are worried that your messages may contain illegal XML characters. If you want to resubmit messages that have been backed out, then you would need metadata that helps you route them to the correct entry point (but that again depends on the reason for the original message being backed out, i.e you may want a retry policy that isn't indefinite). |
The messages going to my exception queue are actually being saved in a database.
But I was missing the backed out messages. So, the requirement is just to store that message in the database(same) as well.
But still not clear how to handle the messages where format is not known. |
|
| Back to top |
|
|
| Vitor |
| Posted: Sat Dec 22, 2012 1:23 pm Post subject: Re: Best way to handle backed out messages |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Nitgeek wrote: |
| The messages going to my exception queue are actually being saved in a database. |
This has no impact on the actual question at hand. You're trying to generically store failed messages; where you store them is irrelevant.
| Nitgeek wrote: |
| But still not clear how to handle the messages where format is not known. |
You use the method indicated by my associate and store them as a Base64 encoded string.
The key issue, again as my associate indicated, is what you plan to do with them after you've stored them. If you're using a central backout queue as you describe, not only do you not know the format of the message but potentially you've also lost where it failed in your topology (given that a message of a given format could be used in multiple locations)
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| 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
|
|
|
|
