| Author |
Message
|
| vicks_mq |
 Posted: Mon Apr 15, 2019 6:30 am Post subject: Retaining the Publisher MessageID in Pub/Sub |
 |
|
Disciple
Joined: 03 Oct 2017
Posts: 162
|
|
| Back to top |
|
 |
| hughson |
| Posted: Mon Apr 15, 2019 2:41 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1967
Location: Bay of Plenty, New Zealand
|
There is no way to have the publisher's message ID go to the subscriber.
Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| vicks_mq |
| Posted: Mon Apr 15, 2019 4:16 pm Post subject: |
|
|
Disciple
Joined: 03 Oct 2017
Posts: 162
|
| hughson wrote: |
There is no way to have the publisher's message ID go to the subscriber.
Cheers,
Morag |
that is going to give me reason to worry about 
BTW, thank you for your reply Morag. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Mon Apr 15, 2019 4:50 pm Post subject: Re: Retaining the Publisher MessageID in Pub/Sub |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| vicks_mq wrote: |
| Hi, we have a requirement where we are setting up Publish Subscribe. And we have to retain the Message ID of the Publishing application to both the subscriber destinations. |
Can you provide any details of the requirement. There may be other design approaches that meet the requirement.
_________________
Glenn |
|
| Back to top |
|
|
| vicks_mq |
| Posted: Tue Apr 16, 2019 4:00 am Post subject: Re: Retaining the Publisher MessageID in Pub/Sub |
|
|
Disciple
Joined: 03 Oct 2017
Posts: 162
|
| gbaddeley wrote: |
| vicks_mq wrote: |
| Hi, we have a requirement where we are setting up Publish Subscribe. And we have to retain the Message ID of the Publishing application to both the subscriber destinations. |
Can you provide any details of the requirement. There may be other design approaches that meet the requirement. |
Hi Glenn, Thank you for looking to help us out.
Between our 2 MQ applications, we have a Java application which take the reply message, do some massaging on the data and then send that reply to the original requesting application. This java application is copying the Message ID to generate correlation ID of the Reply Message.
So, if we don't retain the message ID of the publishing app , we can't get correlation.
I think the best solution is just to change the java app to take the value from the correlation ID instead of Message ID. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Apr 16, 2019 4:59 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
Request / Reply and Pub / Sub are not simpatico.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Apr 16, 2019 5:05 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| PeterPotkay wrote: |
| Request / Reply and Pub / Sub are not simpatico. |
By definition, a publisher shouldn't be expecting a "reply" to it's publication. The point of the pub/sub model is that the publisher and subscriber are decoupled and unaware of each other.
If all you're trying to do is send the same request to a number of interested parties and get a reply, you're better off using a normal send with a distribution list.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| vicks_mq |
| Posted: Tue Apr 16, 2019 7:00 am Post subject: |
|
|
Disciple
Joined: 03 Oct 2017
Posts: 162
|
my apology for not being clear.
we have 2 applications - A and B, A is requesting application, B reply to A.
Scenario which is working for years - before the request from A reach to application B, there is a java program which picks the message from Request Q of A, massage the data, put the message again into a remote Queue and from there it goes to B QMGR and B application picks it. App B reply back and the same java program picks the reply and then massage the reply and put back into another Remote Q and the message goes to App A.
during this whole process, the Java program copy the message ID from both Request from A and Reply from B and always manually set the outgoing message MsgID and correlID to this message Id.
Now the new scenario, request will come from both A and C and because of budget constraint we r not supposed to change reply application B , so we are planning to use Pub Sub to send a copy of reply to both A and C application.
But as our Java application uses the Message ID parameter to generate both MsgID & CorrelID of the outgoing message so to retain the Correl ID between Request A and C and Reply B, we need to also retain the message ID from the Pub/sub which is not happening.
I will look into Destination list if this can be achieved. |
|
| Back to top |
|
|
| vicks_mq |
| Posted: Tue Apr 16, 2019 7:07 am Post subject: |
|
|
Disciple
Joined: 03 Oct 2017
Posts: 162
|
| vicks_mq wrote: |
my apology for not being clear.
we have 2 applications - A and B, A is requesting application, B reply to A.
Scenario which is working for years - before the request from A reach to application B, there is a java program which picks the message from Request Q of A, massage the data, put the message again into a remote Queue and from there it goes to B QMGR and B application picks it. App B reply back and the same java program picks the reply and then massage the reply and put back into another Remote Q and the message goes to App A.
during this whole process, the Java program copy the message ID from both Request from A and Reply from B and always manually set the outgoing message MsgID and correlID to this message Id.
Now the new scenario, request will come from both A and C and because of budget constraint we r not supposed to change reply application B , so we are planning to use Pub Sub to send a copy of reply to both A and C application.
But as our Java application uses the Message ID parameter to generate both MsgID & CorrelID of the outgoing message so to retain the Correl ID between Request A and C and Reply B, we need to also retain the message ID from the Pub/sub which is not happening.
I will look into Distribution list if this can be achieved. |
I looked into Distribution List and found it is not supported on IBM MQ on Z/OS.
Our Replying application B is running on Z/OS
https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.0.0/com.ibm.mq.dev.doc/q026190_.htm |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Tue Apr 16, 2019 11:44 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3265
Location: London, ON Canada
|
| vicks_mq wrote: |
Scenario which is working for years - before the request from A reach to application B, there is a java program which picks the message from Request Q of A, massage the data, put the message again into a remote Queue and from there it goes to B QMGR and B application picks it. App B reply back and the same java program picks the reply and then massage the reply and put back into another Remote Q and the message goes to App A.
during this whole process, the Java program copy the message ID from both Request from A and Reply from B and always manually set the outgoing message MsgID and correlID to this message Id.
Now the new scenario, request will come from both A and C and because of budget constraint we r not supposed to change reply application B , so we are planning to use Pub Sub to send a copy of reply to both A and C application.
But as our Java application uses the Message ID parameter to generate both MsgID & CorrelID of the outgoing message so to retain the Correl ID between Request A and C and Reply B, we need to also retain the message ID from the Pub/sub which is not happening. |
Pub/Sub is not designed nor is it capable of doing it.
<Vendor>
Why don't you have a look at MQ Message Replication?
You simply set it up on the Reply B queue and it will replicate messages that are going back to A and C. The cloned messages will have exactly the same MQMD which includes MsgId and CorrelId.
</Vendor>
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| vicks_mq |
| Posted: Tue Apr 16, 2019 12:39 pm Post subject: |
|
|
Disciple
Joined: 03 Oct 2017
Posts: 162
|
| RogerLacroix wrote: |
| vicks_mq wrote: |
Scenario which is working for years - before the request from A reach to application B, there is a java program which picks the message from Request Q of A, massage the data, put the message again into a remote Queue and from there it goes to B QMGR and B application picks it. App B reply back and the same java program picks the reply and then massage the reply and put back into another Remote Q and the message goes to App A.
during this whole process, the Java program copy the message ID from both Request from A and Reply from B and always manually set the outgoing message MsgID and correlID to this message Id.
Now the new scenario, request will come from both A and C and because of budget constraint we r not supposed to change reply application B , so we are planning to use Pub Sub to send a copy of reply to both A and C application.
But as our Java application uses the Message ID parameter to generate both MsgID & CorrelID of the outgoing message so to retain the Correl ID between Request A and C and Reply B, we need to also retain the message ID from the Pub/sub which is not happening. |
Pub/Sub is not designed nor is it capable of doing it.
<Vendor>
Why don't you have a look at MQ Message Replication?
You simply set it up on the Reply B queue and it will replicate messages that are going back to A and C. The cloned messages will have exactly the same MQMD which includes MsgId and CorrelId.
</Vendor>
Regards,
Roger Lacroix
Capitalware Inc. |
Roger, thank you for reply. I will be honest - We are Poor. Hope that answers why we can't go for "MQ message Replication" product. |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Tue Apr 16, 2019 1:35 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3265
Location: London, ON Canada
|
| vicks_mq wrote: |
| I will be honest - We are Poor. Hope that answers why we can't go for "MQ message Replication" product. |
If a group of people spend more than a few hours on your problem then you have already spent more money than the cost of MQ Message Replication (MQMR) because MQMR only costs $299.00 per queue manager. 
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Tue Apr 16, 2019 3:57 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| vicks_mq wrote: |
| ....so we are planning to use Pub Sub to send a copy of reply to both A and C application. |
This is not a valid use case of the Pub Sub feature.
Wouldn't it be better to send the reply back to the originating application (A or C) only? If the reply queue / reply queue manager combination for A and C are different, then your B app can just open the combination (as specified in the request MQMD) and MQ will route the mesage back to the correct orginating app.
_________________
Glenn |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Apr 16, 2019 7:38 pm Post subject: Re: Retaining the Publisher MessageID in Pub/Sub |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20767
Location: LI,NY
|
| vicks_mq wrote: |
I think the best solution is just to change the java app to take the value from the correlation ID instead of Message ID. |
The default JMS app coding would take the correlid if it exists. I understand your plight where the correlId was related to the subscription. Change the subscription to pass a correlid of (0) (thanks Morag) and you should retain the correlid of the publishing app. Just make sure the publishing app requests a new correlid on the put/publish.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| vicks_mq |
| Posted: Tue Apr 16, 2019 8:20 pm Post subject: |
|
|
Disciple
Joined: 03 Oct 2017
Posts: 162
|
| gbaddeley wrote: |
| vicks_mq wrote: |
| ....so we are planning to use Pub Sub to send a copy of reply to both A and C application. |
This is not a valid use case of the Pub Sub feature.
Wouldn't it be better to send the reply back to the originating application (A or C) only? If the reply queue / reply queue manager combination for A and C are different, then your B app can just open the combination (as specified in the request MQMD) and MQ will route the mesage back to the correct orginating app. |
B app is hard coded to send to only a particular reply Q. |
|
| Back to top |
|
|
|
|
