| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| COA correlation issue |
« View previous topic :: View next topic » |
| Author |
Message
|
| rekarm01 |
 Posted: Thu Sep 27, 2018 6:01 pm Post subject: Re: COA correlation issue |
 |
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| hughson wrote: |
I will add a further clarification after trying it (instead of relying upon my memory!)
If your MQPUT uses MQPMO_NEW_MSG_ID then a message ID will be generated and returned on output to the caller of the MQPUT. As noted above, this is not the message ID of any of the copies sent to subscribers.
If your MQPUT does not use that option, then the message ID will be all zeroes. |
Without actually trying it myself, the documentation says something slightly different.
For MQPUT/MQPUT1 calls, if the application:- sets MsgDesc.MsgId to MQMI_NONE,
- or sets PutMsgOpts.Options to include MQPMO_NEW_MSG_ID,
- or puts to a topic,
- or puts to a distribution list,
then the queue manager generates unique message identifiers for each message put/published. Otherwise, it just propagates MsgDesc.MsgId instead.
That's assuming the application uses default values for PutMsgOpts Version, Action, OriginalMsgHandle, and NewMsgHandle, and that Options does not include MQPMO_MD_FOR_OUTPUT_ONLY. Otherwise, things get more complicated.
| ziliboba wrote: |
| Any hint or advise is very much appreciated. |
Instead of using pub/sub, try inserting a new App D, which gets messages from App A, and forwards them to App B and App C:
App A -> QM.A[Q1] -channel-> QM.D[QL->App D->{Q2,Q3}] -> {App B, QM.C[Q4] -> App C}
where QL is a local queue on QM.D (which could be the same qmgr as QM.B)
In this case, QM.D would be sending COA reports when messages arrive on the App D input queue, so App D would need to at least clear the MQMD.Report field, when forwarding messages to App B and App C. |
|
| Back to top |
|
 |
| hughson |
| Posted: Thu Sep 27, 2018 10:05 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1967
Location: Bay of Plenty, New Zealand
|
| exerk wrote: |
| hughson wrote: |
| exerk wrote: |
| And still the RFE for all pub/sub messages to carry the MsgId of the 'original' is still outstanding. |
Do you have the number to hand? I could add it to the blog post I have just written, maybe get some more votes on it. |
Morag, it's still 'Under Consideration', so not a definite NO at the moment... |
Thanks. I have added a link to it in my latest MQuirks blog post.
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| hughson |
| Posted: Thu Sep 27, 2018 10:09 pm Post subject: Re: COA correlation issue |
|
|
Padawan
Joined: 09 May 2013
Posts: 1967
Location: Bay of Plenty, New Zealand
|
| rekarm01 wrote: |
Without actually trying it myself, the documentation says something slightly different.
For MQPUT/MQPUT1 calls, if the application:- sets MsgDesc.MsgId to MQMI_NONE,
- or sets PutMsgOpts.Options to include MQPMO_NEW_MSG_ID,
- or puts to a topic,
- or puts to a distribution list,
then the queue manager generates unique message identifiers for each message put/published. Otherwise, it just propagates MsgDesc.MsgId instead |
What the documentation says there is true. It doesn't mention what is returned on the MQPUT call though which is the issue at hand.
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| rekarm01 |
| Posted: Fri Sep 28, 2018 8:00 pm Post subject: Re: COA correlation issue |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| hughson wrote: |
| What the documentation says there is true. It doesn't mention what is returned on the MQPUT call though, which is the issue at hand. |
The documentation does mention what MQPUT returns to the caller when putting to a topic, (mostly), but while generally useful to know, it wasn't relevant to the OP's problem:
- If the application sets PutMsgOpts.Options to include MQPMO_NEW_MSG_ID, then the queue manager returns a unique (non-matching) message id,
- otherwise, if the application sets MsgDesc.MsgId to MQMI_NONE, then the queue manager returns MQMI_NONE,
- otherwise the documentation does not specify what the queue manager returns.
The OP's problem is what MQPUT sends to App B and App C, not what it returns to App A:App A -> QM.A[Q1] -channel-> QM.B[QA->T->...] -> {App B, QM.C[Q4] -> App C}
App A puts a message to a remote queue, (not a topic), so MQPUT returns the same message id to App A that it sent in the message, as expected.
The MCA for QM.B puts the message to a topic, so MQPUT generates unique message ids for the messages it sends to App B, and App C; what it returns to the MCA doesn't matter.
Regardless, the workaround is the same; don't use pub/sub here. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Sep 29, 2018 2:47 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20767
Location: LI,NY
|
Or rather if you do use pub sub you need to use properties to store a user msgid / correl id so that it gets propagated in the pub sub model... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
