ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum IndexGeneral IBM MQ SupportCopying a Message once arrived from a QL to another QL

Post new topicReply to topic
Copying a Message once arrived from a QL to another QL View previous topic :: View next topic
Author Message
Heba_MQ
PostPosted: Mon Apr 27, 2020 1:14 pm Post subject: Copying a Message once arrived from a QL to another QL Reply with quote

Novice

Joined: 19 Apr 2020
Posts: 23

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
View user's profile Send private message
RogerLacroix
PostPosted: Mon Apr 27, 2020 1:26 pm Post subject: Reply with quote

Jedi Knight

Joined: 15 May 2001
Posts: 3170
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
View user's profile Send private message Visit poster's website
hughson
PostPosted: Mon Apr 27, 2020 9:50 pm Post subject: Reply with quote

Grand Master

Joined: 09 May 2013
Posts: 1462
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
View user's profile Send private message Visit poster's website
PaulClarke
PostPosted: Mon Apr 27, 2020 11:18 pm Post subject: Reply with quote

Guardian

Joined: 17 Nov 2005
Posts: 968
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
View user's profile Send private message Visit poster's website
crashdog
PostPosted: Tue Apr 28, 2020 12:41 am Post subject: Reply with quote

Apprentice

Joined: 02 Apr 2017
Posts: 44

What is the reason that you want the message IDs to be the same ?
If that's not really required you could simply use pub/sub as in below example:
https://www.ibm.com/support/pages/mq-you-want-put-message-queue-and-you-want-generate-duplicate-messages-other-queues

Cheers
Gerhard
_________________
You win again gravity !
Back to top
View user's profile Send private message
exerk
PostPosted: Tue Apr 28, 2020 12:43 am Post subject: Reply with quote

Jedi Council

Joined: 02 Nov 2006
Posts: 6177

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
View user's profile Send private message
Heba_MQ
PostPosted: Tue Apr 28, 2020 1:30 am Post subject: Reply with quote

Novice

Joined: 19 Apr 2020
Posts: 23

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
View user's profile Send private message
exerk
PostPosted: Tue Apr 28, 2020 1:41 am Post subject: Reply with quote

Jedi Council

Joined: 02 Nov 2006
Posts: 6177

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
View user's profile Send private message
tczielke
PostPosted: Tue Apr 28, 2020 10:22 am Post subject: Reply with quote

Sentinel

Joined: 08 Jul 2010
Posts: 881
Location: Illinois, USA

For this document https://www.ibm.com/support/pages/mq-you-want-put-message-queue-and-you-want-generate-duplicate-messages-other-queues, you probably want to define the topic as follows:

Code:

define topic(T1) topicstr('TOPIC1') usedlq(NO)


If you don't, the standard queue manager set up on modern queue managers will start putting messages on the DLQ if Q1 or Q2 were ever to become full. This is probably something you don't want to have happen.
_________________
Working with MQ since 2010.
Back to top
View user's profile Send private message
Heba_MQ
PostPosted: Tue Apr 28, 2020 11:54 am Post subject: Reply with quote

Novice

Joined: 19 Apr 2020
Posts: 23

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
View user's profile Send private message
bruce2359
PostPosted: Tue Apr 28, 2020 12:03 pm Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 8736
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.
_________________
My life flows on in endless song;
How can I keep from singing?
Back to top
View user's profile Send private message
Vitor
PostPosted: Tue Apr 28, 2020 12:19 pm Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26016
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
View user's profile Send private message
zpat
PostPosted: Thu May 21, 2020 12:14 pm Post subject: Reply with quote

Jedi Council

Joined: 19 May 2001
Posts: 5703
Location: UK

crashdog wrote:
What is the reason that you want the message IDs to be the same ?
If that's not really required you could simply use pub/sub as in below example:
https://www.ibm.com/support/pages/mq-you-want-put-message-queue-and-you-want-generate-duplicate-messages-other-queues


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
View user's profile Send private message
GheorgheDragos
PostPosted: Thu Jun 04, 2020 1:36 am Post subject: Reply with quote

Apprentice

Joined: 28 Jun 2018
Posts: 37

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
View user's profile Send private message
Display posts from previous:
Post new topicReply to topic Page 1 of 1

MQSeries.net Forum IndexGeneral IBM MQ SupportCopying a Message once arrived from a QL to another QL
Jump to:



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
Protected by Anti-Spam ACP


Theme by Dustin Baccetti
Powered by phpBB 2001, 2002 phpBB Group

Copyright MQSeries.net. All rights reserved.