| Author |
Message
|
| Heba_MQ |
 Posted: Mon Apr 27, 2020 1:14 pm Post subject: Copying a Message once arrived from a QL to another QL |
 |
|
Apprentice
Joined: 19 Apr 2020
Posts: 39
|
Dears,
We have an application that will use MQI to connect to our MQ server and put message to a certain local queue MonitoringQ - We need to copy the message once being put the MonitoringQ to another local queue MonitoringQ1 (with same message id -if possible) - no application will get from MonitoringQ - There will be only one applications the will get messages but from MonitoringQ1
We are on MQ 9.1 on windows...What are the possible ways to achieve this ?
Thanks for your help
PS: we can not change the application to put messages in the MonitoringQ and MonitoringQ1 - we need to do this via MQ config.
thanks
Heba |
|
| Back to top |
|
 |
| RogerLacroix |
| Posted: Mon Apr 27, 2020 1:26 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Hi,
<Vendor_Plug>
You should have a look at MQ Message Replication. Its purpose is to replicate the messages (MQMD and payload) in a queue to 1 or more other queues.
</Vendor_Plug>
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| hughson |
| Posted: Mon Apr 27, 2020 9:50 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
Do you need to copy it or can you just cause the message to redirect to MonitoringQ1?
For example:
| Code: |
DELETE QLOCAL('MonitoringQ1')
DEFINE QALIAS('MonitoringQ1') TARGET('MonitoringQ') |
Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| PaulClarke |
| Posted: Mon Apr 27, 2020 11:18 pm Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
Hi,
<Vendor_Plug>
If you have messages arriving on queue 'MonitoringQ' and you want to store a copy of each message for safe keeping and have another copy for processing then I would suggest you use 3 queues. The source queue MonitoringQ, the saved copy MonitoringQSave and the one you process MonitoringQ1. You would then have a program which processes the incoming message and puts it to the other queues.
You can do this kind of thing with our Q and QLOAD products.
For example commands:
| Code: |
| q -I MonitoringQ -o MonitoringQSave -o MonitoringQ1 -w 999999 |
or
| Code: |
| qload -I MonitoringQ -o MonitoringQSave -o MonitoringQ1 -w 999999 |
You can have additional targets just by adding more -o parameters. You can choose whether to also write the message to stdout, change the priority, transactional characteristics etc.
</Vendor_Plug>
Cheers,
Paul
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| crashdog |
| Posted: Tue Apr 28, 2020 12:41 am Post subject: |
|
|
Voyager
Joined: 02 Apr 2017
Posts: 77
|
|
| Back to top |
|
|
| exerk |
| Posted: Tue Apr 28, 2020 12:43 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| hughson wrote: |
Do you need to copy it or can you just cause the message to redirect to MonitoringQ1?
For example:
| Code: |
DELETE QLOCAL('MonitoringQ1')
DEFINE QALIAS('MonitoringQ1') TARGET('MonitoringQ') |
Cheers,
Morag |
If nothing else, this is a prime example of why an application should only PUT/GET via 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 |
|
|
| Heba_MQ |
| Posted: Tue Apr 28, 2020 1:30 am Post subject: |
|
|
Apprentice
Joined: 19 Apr 2020
Posts: 39
|
Dear Morag
Yes I want to copy each message comes to the MonitoringQ to MonitoringQ1
Message ID can be different (no issues for this)
Another application will process the messages from MonitoringQ1 - where as messages in MonitoringQ will be kept until there is a manual intervention from an administrator...
Many Thanks for your help,
Heba |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Apr 28, 2020 1:41 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| Heba_MQ wrote: |
Dear Morag
Yes I want to copy each message comes to the MonitoringQ to MonitoringQ1
Message ID can be different (no issues for this)
Another application will process the messages from MonitoringQ1 - where as messages in MonitoringQ will be kept until there is a manual intervention from an administrator...
Many Thanks for your help,
Heba |
In which case crashdog's solution would work for you.
_________________
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: Tue Apr 28, 2020 10:22 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
|
| Back to top |
|
|
| Heba_MQ |
| Posted: Tue Apr 28, 2020 11:54 am Post subject: |
|
|
Apprentice
Joined: 19 Apr 2020
Posts: 39
|
Thanks tczielke...
I followed up the method in the link :
https://www.ibm.com/support/pages/mq-you-want-put-message-queue-and-you-want-generate-duplicate-messages-other-queues
But unfortunately it does not fit the situation that I have...
The solution in the doc is writing in alias queue and once message is put there ...it will disappear from the alias queue and go to the 2 queues that are subscribed in the topic...
the problem with this solution is that, the application that will put message is taking the input queue name from config form... and its logic flow mandates that messages should stay there for sometime until it being checked against some business conditions...but in the same time another application will need to start processing the message immediately...that is why we want to copy messages to another queue from which the second application will GET messages...and keep the message copy in the first input queue, till decision is made...I know it is not a good design... but they asked me to see possible ways to do
I think it would be possible via channel exit or via application triggers...
if any one can give me just examples to start with...it will be great...
Thanks
Heba |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Apr 28, 2020 12:03 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
| Heba_MQ wrote: |
The solution in the doc is writing in alias queue and once message is put there ...it will disappear from the alias queue and go to the 2 queues that are subscribed in the topic...
Thanks
Heba |
A qalias is NOT a queue. The only type of queue that can hold messages is a qlocal. A alias definition is an abstraction that allows for another name (or multiple names) for a local queue (QLocal). At mqopen, an alias definition must resolve to a QLocal. All gets/puts are to the QLocal.
_________________
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 |
|
|
| Vitor |
| Posted: Tue Apr 28, 2020 12:19 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Heba_MQ wrote: |
| The problem with this solution is that, the application that will put message is taking the input queue name from config form... and its logic flow mandates that messages should stay there for sometime until it being checked against some business conditions...but in the same time another application will need to start processing the message immediately...that is why we want to copy messages to another queue from which the second application will GET messages...and keep the message copy in the first input queue, till decision is made |
So what's the problem? The message goes (via the alias, which as my worthy associate says is not a queue) to two queues. It can sit on one until the business decision is made, the other gets processed. What's wrong with that?
| Heba_MQ wrote: |
| ...I know it is not a good design... but they asked me to see possible ways to do |
Why not read it from a single queue, put a copy in a database for later examination and pass the message to the application that needs it immediately?
| Heba_MQ wrote: |
| I think it would be possible via channel exit |
And a couple of vendors have mentioned such solutions in this thread.
| Heba_MQ wrote: |
| or via application triggers... |
Triggers????? 
| Heba_MQ wrote: |
| if any one can give me just examples to start with...it will be great... |
I've quoted one above.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| zpat |
| Posted: Thu May 21, 2020 12:14 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
DESTCORL on the define sub may be of some use.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| GheorgheDragos |
| Posted: Thu Jun 04, 2020 1:36 am Post subject: |
|
|
Acolyte
Joined: 28 Jun 2018
Posts: 51
|
Hello,
On z/OS this could be achieved with dumping messages from the original queue to a flat file then reloading to target one. Triggering could be used to automate this.
Dragos |
|
| Back to top |
|
|
|
|
