| Author |
Message
|
| mq_population |
 Posted: Wed Oct 03, 2018 6:28 am Post subject: MQ message duplication without using pub/sub |
 |
|
Apprentice
Joined: 14 Jul 2009
Posts: 26
|
Hi All
I have come across a situation where messages from a certain source is required across 3 (or 4) queue managers / environments .
Naturally - I have suggested to use Pub/Sub to achieve the same - But the requester informed that they are not able to change the code to publish message into a topic - instead of writing to a queue , which is what they are doing currently .
Is this possible to configure in MQ without making any code change from Sender APP ? possibly using a wildcard as topic string and altering the target to a topic ? any suggestions ?
Just to clarify - the flow goes like this -
1. Sender APP writes messages to QALIAS on SDR QM(Java Code using JMS)
2. QALIAS Points to a Cluster Q on the receiver QM
3. Receiver APP consumes the message from LQ on Receiver QM
But this Step 3 needs to change to replicate the message across 3 different QMGRs instead of only one , which is what it's doing currently .
And there will be no code change allowed in Sender APP (Step 1) to publish into a Topic.
Can anyone suggest if this is possible by using MQ only , No scripting or external coding to copy / move messages please .
FYI - we are using MQ Version 8.0.0.7 ;
Thanks |
|
| Back to top |
|
 |
| Vitor |
| Posted: Wed Oct 03, 2018 6:33 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
You could use an exit (mirrorq or something similar that's production strength).
I repeat what I've said many times in here - if the answer is an exit you're asking the wrong question.
It's going to be much safer / cheaper / easier to maintain to simply change the receiver app (not the unchangeable sender app) to read the message of the existing queue and then publish it as needed.
<plug>You might be able to mitigate some of the exit problems by buying a commerical exit with this capability</plug>
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mq_population |
| Posted: Wed Oct 03, 2018 6:52 am Post subject: |
|
|
Apprentice
Joined: 14 Jul 2009
Posts: 26
|
Thanks for the response !!
But we are not planning to use any exit , because we don't have budget to have one . Also - it will take considerable time to get the exit up and running in customer environment , probably not possible in a week or so .
The receiver application code change maybe possible - need to check that option .
But , are there any options to achieve this purely within MQ configuration , without changing any code in Sender and Receiver side ?
Thanks |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Oct 03, 2018 7:05 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mq_population wrote: |
| probably not possible in a week or so . |
Oh hell no! You need to test the contact admin out of an exit. 
(unless you bought it - no offense intended to any vendors reading this, who will have already tested the contact admin out of their product)
| mq_population wrote: |
| But , are there any options to achieve this purely within MQ configuration , without changing any code in Sender and Receiver side ? |
Nothing springs to mind. Someone smarter than me may be along in a minute.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Oct 03, 2018 7:24 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
With props to Mr. Potkay, whom posted this many years ago...
| Quote: |
App A is putting to a local q called Q1. App B is pulling from Q1. You have MQ 7 and want to duplicate the messages but do not want to change the sending or receiving app code.
Define a topic called Q1T, with a topic string of Q1
Define a sub to topic object Q1T, with a destination of Q1
Define a Q Alias called Q1Alias, target type topic with a target of Q1T
A put to Q1Alias will now produce a message to the Q1 local queue
Define another sub to topic object Q1T, this time with a destination of Q2
A put to Q1Alias will now produce 2 messages, one to Q1 and one to Q2.
The only change in the original setup is that App A puts to Q1Alias instead of Q1. App A and App B don't know they are using Pub Sub. The subscriptions are created by the MQ Admin using admin commands. |
Define as many subs as you need...
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| tczielke |
| Posted: Wed Oct 03, 2018 12:59 pm Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Oct 03, 2018 1:30 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Paraphrased from the abov URL, it's important to note that the data payload will be duplicated, BUT each message will have its own unique message-id. Thus, the usual request-reply app design model will not work.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Wed Oct 03, 2018 1:53 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
<Vendor>
Capitalware created and sells a product called MQ Message Replication. Its sole purpose is to clone messages written to a source queue (local, alias, remote and/or cluster) then write the exact same message to 'n' target queues.
</Vendor>
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
|
|
