| Author |
Message
|
| vicks_mq |
 Posted: Wed Jan 16, 2019 9:58 am Post subject: creating duplicate of messages |
 |
|
Disciple
Joined: 03 Oct 2017
Posts: 162
|
We have a requirement where for few hours during a critical maintenance window, we need to take backup of all the messages coming to a particular local Q,
I tried pub sub, but somehow that scenario will not work.
Suppose Application A is putting message in local TESTQ and application B is picking message from this queue and if I change this TESTQ to point to TOPIC and make 2 subscribers and 2 destinations - DESTQ1 & DESTQ2, then application B configuration need to change to pick message from DESTQ1.
We don't want to change any application configuration and doesn't want to do deployment.
Also, I was wondering just how an application can put message into ALIAS Q which point to a TOpic, can another application also point to same ALIASQ which point to Topic and pick the messages ? |
|
| Back to top |
|
 |
| exerk |
| Posted: Wed Jan 16, 2019 11:28 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
To quote an old post from PeterPotkay (props to the man!):
| 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. |
In your case substitute the appropriate queue names, as you may have to redefine your current QLOCAL as a QALIAS - which is a a good example of why application should never PUT/GET from anything but a QALIAS.
_________________
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 |
|
|
| RogerLacroix |
| Posted: Wed Jan 16, 2019 11:45 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
The biggest downside to copying messages via Pub/Sub is that certain fields of the message's MQMD are not duplicated. i.e. Date, Time, MsgId, etc.
If you need an exact copy of the messages including MQMD then you should have a look at MQ Message Replication.
Also, with MQMR, you do not need to add extra topics, subscriptions or even queue aliases because MQMR is an API Exit and runs within the queue manager.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| vicks_mq |
| Posted: Wed Jan 16, 2019 12:47 pm Post subject: |
|
|
Disciple
Joined: 03 Oct 2017
Posts: 162
|
| exerk wrote: |
To quote an old post from PeterPotkay (props to the man!):
| 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. |
In your case substitute the appropriate queue names, as you may have to redefine your current QLOCAL as a QALIAS - which is a a good example of why application should never PUT/GET from anything but a QALIAS. |
we have issue with this approach that both App A and App B is picking the queue name from same database parameter, so if I changename Queue A Alias Q(which point to Topic), the App B will also automatically to this Alias Q (because it is same DB parameter) and because Alias Q is pointing to Topic, the App B will not be able to pick from this AliasQ |
|
| Back to top |
|
|
| PaulClarke |
| Posted: Wed Jan 16, 2019 1:52 pm Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
Can't you just use a simple message splitter ? Something like my SupportPac MA01 (Q Program) would do it. Something like:
| Code: |
| q -I SOURCEQ -o TARGET1 -o TARGET2 -p 10 -w 6000 |
QLOAD will also do the same thing. I am sure there are a number of MQ programs which will take a source message and send the message to multiple locations.
Regards,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| vicks_mq |
| Posted: Thu Jan 17, 2019 7:28 am Post subject: |
|
|
Disciple
Joined: 03 Oct 2017
Posts: 162
|
| PaulClarke wrote: |
Can't you just use a simple message splitter ? Something like my SupportPac MA01 (Q Program) would do it. Something like:
| Code: |
| q -I SOURCEQ -o TARGET1 -o TARGET2 -p 10 -w 6000 |
QLOAD will also do the same thing. I am sure there are a number of MQ programs which will take a source message and send the message to multiple locations.
Regards,
Paul. |
Hi Paul, thank you for reply, the challenge is all these programs need to run manually , we were looking for a dynamic solution which as soon as message arrives in the queue, the message gets duplicated before even the "consuming" application "GET" the message. |
|
| Back to top |
|
|
| exerk |
| Posted: Thu Jan 17, 2019 7:43 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| vicks_mq wrote: |
| ...the message gets duplicated before even the "consuming" application "GET" the message. |
And just how were you going to stop the race condition between the application and the duplicator?
_________________
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 |
|
|
| vicks_mq |
| Posted: Thu Jan 17, 2019 10:40 am Post subject: |
|
|
Disciple
Joined: 03 Oct 2017
Posts: 162
|
| exerk wrote: |
| vicks_mq wrote: |
| ...the message gets duplicated before even the "consuming" application "GET" the message. |
And just how were you going to stop the race condition between the application and the duplicator? |
Hi Exerk, Pub Sub does the job where it duplicates the messages , I know the challenge here is the receiving application is listening to same Q as the Putting application, and that is why I was wondering if there is any solution. |
|
| Back to top |
|
|
| exerk |
| Posted: Thu Jan 17, 2019 11:59 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| vicks_mq wrote: |
| exerk wrote: |
| vicks_mq wrote: |
| ...the message gets duplicated before even the "consuming" application "GET" the message. |
And just how were you going to stop the race condition between the application and the duplicator? |
Hi Exerk, Pub Sub does the job where it duplicates the messages , I know the challenge here is the receiving application is listening to same Q as the Putting application, and that is why I was wondering if there is any solution. |
The solution is to not let applications directly access a QLOCAL - take the pains now to change your standard, it will be a lot easier to change things in the future and make those changes transparent to the applications.
_________________
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 |
|
|
| RogerLacroix |
| Posted: Thu Jan 17, 2019 3:45 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
| vicks_mq wrote: |
| the challenge is all these programs need to run manually , we were looking for a dynamic solution which as soon as message arrives in the queue, the message gets duplicated before even the "consuming" application "GET" the message. |
You really should have a look at MQ Message Replication (MQMR). MQMR is not a manually started process nor does it require extra queues or topics.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
|
|
