| Author |
Message
|
| kwelch |
 Posted: Thu Oct 04, 2001 1:49 pm Post subject: |
 |
|
Master
Joined: 16 May 2001
Posts: 255
|
Hi,
I am developing an MQSI messageflow that receives reply messages from a single backend queue manager that must then go to a variety of front end queue managers. I am attempting to use the replyToQueue option for Destination Mode on my Output Node(advanced tab).
That part is working correctly. The message is going to the right place. However, what is happening is the Correl Id is being replaced with the Message Id and a new Message Id is being generated. So now the application can't find it's reply. It seems that this replyToQueue option is causing this to happen because it does not happen when I use QueueName and Hard Code the Qmgr and Queue names.
The front end and back end apps. are following the request/reply model where the replier takes the message id of the request and puts it to the Correl Id of the Reply. The front ends then do a Get on Correl Id. I am specifying in the Compute Node to copy headers and in the MQOutput Node I am not checking the boxes that say New Correl Id and New Message Id. However if a front end application sets the report option of mqro-pass-correl-id then this node does not overlay the Correl Id but still creates a new Message Id. There are still two things wrong even if the front end does this. 1. We are still getting a new Message Id and 2. We can't have the front ends specifying this option because then the back end will treat the Message Id and Correl Id fields incorrectly.
Is there any way to keep the MQOutput Node using the replyToQueue option from taking this default action of Message Id to Correl Id/New Message Id? All we want to do is pass the entire MQMD unchanged.
Any help is appreciated.
Karen
The Hartford Ins. Co.
|
|
| Back to top |
|
 |
| EddieA |
| Posted: Thu Oct 04, 2001 2:36 pm Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
Karen,
If you can't find a way to get the actions you want with a ReplyTo node (I can't offer anything), then you might consider taking the ReplyToQueue and ReplyToQueueManager from the MQMD and building a DestinationList. You can then use a MQOutput node with that List.
Cheers.
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| NickB |
| Posted: Fri Oct 05, 2001 12:30 am Post subject: |
|
|
Centurion
Joined: 20 May 2001
Posts: 107
Location: Zurich Financial Services
|
Karen
See the first ever thread in this MQSI section posted by me with the same problem. A couple of solutions were posted as a result. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Oct 05, 2001 5:03 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Nick,
I don't think that first post of yours and Karen's are talking about the same thing. You were referring to the ReplyNode, whereas she is refering to the Replyto Option on a regular Output node.
I can see an argument made for the REPLYNODE acting this way for "1way" transactions. I am an app on QMGR1, needing some MQSI work done on a message, and want the output to come back to me. Fine, the REPLYNODE should use the report options.
Our case (Karen and I are teammates at work) is the QMGR1 sends a request up to QMGR2, the replier. It then sends a reply back to the Reply2Q and Reply2QMGR. We added a message flow on the way up to QMGR2 and a message flow on the way back to QMGR2. Because QMGR1 can really be any 1 of a dozen different front QMGRS, we need that message flow coming back to look at the Reply2Q and Reply2QMGR fields to determine where to send this message. We don't want it mucking with any fields in the MD. We thought the reply option on a regular output node was the way to go, but apparantly it still acts on the report options that were put in place for QMGR2 by the frontends.
Is the solution for QMGR2 to realize that its message is going thru a MQSI flow on the way back, and thus it needs to set the MD a certain way. I hope this is not the case! I thought MQSI was supposed to be transparent to an app.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Oct 05, 2001 5:04 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
oops, typo!
We added a message flow on the way up to QMGR2 and a message flow on the way back to QMGR2.
Should read
We added a message flow on the way up to QMGR2 and a message flow on the way back to QMGR1.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| MNSUR1 |
| Posted: Fri Oct 05, 2001 8:15 am Post subject: |
|
|
Newbie
Joined: 20 Jun 2001
Posts: 3
Location: Dearborn, Michigan
|
Hi Peter and Karen,
Nick is right because the ReplytoNode is a specialized version of MQoutput node, which in turn is exactly same as specifying ReplyToQueue option for Destination Mode on MQOutput Node. Since both work the same way,they both change the MQMD header fields. Eddie is right by saying that you should use the destinationlist option for Destination Mode on MQOutput node. Do you use the IMS Bridge to go to the backend because the IMS Bridge generates a new MessageId, unless you specify in the report option MQRO_PASS_MSG_ID. I hope this will help you, but you can always contact me by email.
Madhavi |
|
| Back to top |
|
|
| REBONTO |
| Posted: Thu Dec 22, 2005 10:06 pm Post subject: Details required for COA and COD |
|
|
Newbie
Joined: 21 Dec 2005
Posts: 1
|
I WANT TO SENT MESSAGE TO REMOTE QUEUE, SO WHAT ARE THE STEPS REQUIRED, TO GET REPORT OF ARRIVAL AND DELIVERY.
Thanks |
|
| Back to top |
|
|
| JT |
| Posted: Fri Dec 23, 2005 9:52 am Post subject: |
|
|
Padawan
Joined: 27 Mar 2003
Posts: 1564
Location: Hartford, CT.
|
| To best help you, start by opening a new thread, and clearly articulate your requirements (provide more details than a single line of content), the products employed (as well as their versions/fixpacks), and the OS platforms that are involved. |
|
| Back to top |
|
|
| EddieA |
| Posted: Fri Dec 23, 2005 1:20 pm Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
And don't SHOUT. It's rude.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
|
|
