Author |
Message
|
marcin.kasinski |
Posted: Fri Mar 16, 2007 2:35 am Post subject: MQReply node and correlID - theoretical question |
|
|
Sentinel
Joined: 21 Dec 2004 Posts: 850 Location: Poland / Warsaw
|
Hi,
I have theoretical question about processing reply message within broker.
To process reply message I use MQReply node.
This node reads msgID and place it into CorrelID
What I do inside my application which sends reply is placing msgid of request into msgid of reply.
In my opinion it is strange unnatural behavior.
With point to point communication I put request msgID into reply correlID.
Another thing is JMS.
With JMS I can not set msgID. Because of it in my JMS application I put request msgID into reply correlID (like in p2p communication) and inside my flow which reads these messages before HTTPReply I place Compute where I move correlID into msgID.
My questions are :
Why MQReply changes MQMD
How do you process reply message in applications and flows ?
Can you comment it ?
What do you think about it ?
I hope I have explained it clearly. _________________ Marcin |
|
Back to top |
|
 |
jefflowrey |
Posted: Fri Mar 16, 2007 3:54 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
There's a flag or an option on the MQMD that says what the replier should do with the msgId. I forget what it is.
The MQReplyNode will honor that, I believe. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
marcin.kasinski |
Posted: Fri Mar 16, 2007 4:09 am Post subject: |
|
|
Sentinel
Joined: 21 Dec 2004 Posts: 850 Location: Poland / Warsaw
|
jefflowrey wrote: |
There's a flag or an option on the MQMD that says what the replier should do with the msgId. I forget what it is.
The MQReplyNode will honor that, I believe. |
Really ?
I can not find it. _________________ Marcin |
|
Back to top |
|
 |
jefflowrey |
Posted: Fri Mar 16, 2007 4:14 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
|
Back to top |
|
 |
jsware |
Posted: Fri Mar 16, 2007 9:18 am Post subject: |
|
|
 Chevalier
Joined: 17 May 2001 Posts: 455
|
Applications generating reply messages are instructed to follow the directions indicated by the Report options field. The qmgr will do this when automatically generating its own report messages. The important statement under this section in the manual is (it says must):
IBM Manual wrote: |
Servers replying to requests or generating report messages must check whether the MQRO_PASS_MSG_ID or MQRO_PASS_CORREL_ID options were set in the original message. If they were, the servers must take the action described for those options. If neither is set, the servers must take the corresponding default action. |
_________________ Regards
John
The pain of low quaility far outlasts the joy of low price. |
|
Back to top |
|
 |
jefflowrey |
Posted: Fri Mar 16, 2007 5:16 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
On the other hand, most people do not follow these "must" guidelines when building their own server applications.
But I'd be ... *shocked*... if the WMB developers who wrote the MQReply Node failed to do so. So, it *should* follow these guidelines, and do what you tell it to do. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
marcin.kasinski |
Posted: Fri Mar 16, 2007 11:49 pm Post subject: |
|
|
Sentinel
Joined: 21 Dec 2004 Posts: 850 Location: Poland / Warsaw
|
jefflowrey wrote: |
On the other hand, most people do not follow these "must" guidelines when building their own server applications.
But I'd be ... *shocked*... if the WMB developers who wrote the MQReply Node failed to do so. So, it *should* follow these guidelines, and do what you tell it to do. |
I only know, that we don't set this raport parameters in our apps.
I wonder why MQReply in this situation place msgid into correlid.
Is it default behavior ? _________________ Marcin
Last edited by marcin.kasinski on Tue Mar 20, 2007 5:48 am; edited 1 time in total |
|
Back to top |
|
 |
jefflowrey |
Posted: Sat Mar 17, 2007 4:03 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
If you read that link, it says what the default behavior is, and the part that scottj2512 posted says that well-behaved apps must use the defaults if nothing is specified.
I guess I'm suggesting that you change this value inside your flow, if you know your sending apps are going to match on msgid. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
marcin.kasinski |
Posted: Tue Mar 20, 2007 6:24 am Post subject: |
|
|
Sentinel
Joined: 21 Dec 2004 Posts: 850 Location: Poland / Warsaw
|
Ok,
I red that MQRO_COPY_MSG_ID_TO_CORREL_ID is default.
In our sending apps we don’t specify these reports, so when request goes to server app it takes default action copy Msgid of question to CorrelID of answer.
My problem that when we use MQReply this node also copy Msgid to CorrelID (default action when there is no report options). Because of this we loose correlation information.
To solve this problem our server apps copy Msgid of question to Msgid of answer.
Then in flow MQReply copy Msgid to CorrelID and in client app I can correlate request and adwser. When this server application is written in JMS we copy Msgid to CorrelID because JMS can not set MSGid and then in flow before MQReply in Compute we copy CorrelID to Msgid.
I hope you understand me.
What do you think about it ?
I wonder how you design similar scenarios. _________________ Marcin |
|
Back to top |
|
 |
jefflowrey |
Posted: Tue Mar 20, 2007 6:47 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
I think that server apps should follow the "MUST" declarations...
And client apps need to specify the right report options for what they are expecting...
That said, if you need to modify the behavior of the MQReply node so that it doesn't use the *default* options, then set the report options in your flow before you call the MQReply node.
Otherwise, I probably wouldn't use the MQReply node in this scenario, or I would create a new MsgID or MQMD for the request to the server, and then restore the old one for the Reply - I think this later point is what the standard Proxy design pattern wants. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
|