| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Reply message |
« View previous topic :: View next topic » |
| Author |
Message
|
| Tom |
 Posted: Wed Apr 03, 2002 1:22 pm Post subject: |
 |
|
Newbie
Joined: 28 Mar 2002
Posts: 6
|
Hi,
My MQ Application gets the message from the queue, process it and put the reply message to another queue. If processing fails, Which is the best way to tell the success or failure to the application at the other end which gets the reply message?
1) by setting the failuire or success in the feedback of the message descriptor. If so, How do I define the Application specific feed back?
2) or it should be the part of the reply message eg.. The first word of the reply message should contain success or failuire
Thanks
|
|
| Back to top |
|
 |
| StefanSievert |
| Posted: Wed Apr 03, 2002 1:43 pm Post subject: |
|
|
Partisan
Joined: 28 Oct 2001
Posts: 333
Location: San Francisco
|
| Quote: |
On 2002-04-03 13:22, Tom wrote:
Hi,
My MQ Application gets the message from the queue, process it and put the reply message to another queue. If processing fails, Which is the best way to tell the success or failure to the application at the other end which gets the reply message?
1) by setting the failuire or success in the feedback of the message descriptor. If so, How do I define the Application specific feed back?
2) or it should be the part of the reply message eg.. The first word of the reply message should contain success or failuire
Thanks
|
Tom,
there's probably not a 'best way' to achieve what you want. Both your apporaches will work. Some thoughts, however:
1 Defining application specific feedback values requires that you have to keep both sides of the pipe in sync about what these values are. If you have multiple programs use a specific server process, this could get tricky.
2 How would you define those values? Well, you would just pick and choose any numeric value that is between MQFB_APPL_FIRST and MQFB_APPL_LAST. You could define them as symbols or just use something like MQFB_APPL_FIRST+1...n in your programs. Defining them as symbols in a header/copy-book/class would probably be a good way of keeping them in sync across platforms.
3 You could, instead of sending your reply as mqmd.MsgType = MQMT_REPLY, send your error report as MQMT_REPORT and set your feedback to MQFB_NAN, probably accompanied by a textual error text in the message payload. Your requesting application would than check if the received msg has MsgType = MQMT_REPLY and process the reply (no error), or, if MsgType = MQMT_REPORT assume an error and perform generic error processing. If you need to know exactly what the error was, defining distinct feedback values (or return codes in the payload) might be your only choice. The former could be handled by a generic function which logs the error message or something like that, the latter would most likely need application specific error handling logic.
I guess there is a cornucopia of other possible approaches to that, I'll leave it up to the rest of the folks to comment on how they did it. It basically depends on the granularity of your error handling routine requirements.
Hope that helps,
Stefan
_________________
Stefan Sievert
IBM Certified * WebSphere MQ |
|
| Back to top |
|
|
| Tom |
| Posted: Wed Apr 03, 2002 1:56 pm Post subject: |
|
|
Newbie
Joined: 28 Mar 2002
Posts: 6
|
So the request message has to set the report option for NAN or it does not need to set. I guess the queue manager does not take any action on this.
Please advice me if I am wrong...
thanks |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Apr 03, 2002 2:39 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7716
|
Setting NAN in the report options of the request is simply a means of letting the replying application know that you are requesting a NAN report should something fail. It is up to the replying application to look at the report field and honor its values.
Of course, if in you situation your replying app will always send back a NAN report should it fail, then there is no need (but no harm) in setting that option in the request message.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Tom |
| Posted: Wed Apr 03, 2002 2:40 pm Post subject: |
|
|
Newbie
Joined: 28 Mar 2002
Posts: 6
|
|
| 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
|
|
|
|
