Author |
Message
|
kbtraj |
Posted: Mon Apr 28, 2014 5:43 am Post subject: Need to have a copy of all the messages land in MQInput node |
|
|
Novice
Joined: 28 Apr 2014 Posts: 10
|
Hi All,
We have a requirement that we need to copy each message that comes to a MQInput node to different queue in all message flows
We have more than 100 message flows running (5 different execution groups) in our environment and basically we need to capture the input data of all these message flows.
It is like taking a backup copy of the input messages and we have to do it at Broker only because we dont have access to source applications.
One important that thing is we should be having an option to turn off this backup facility at any point and go back to normal if needed
One way we thought is changing existing message flow to add
MQOutput node connection for copying the message. This will involve changing all the message flows. And we have to keep two sets of execution groups (one new & one old) in case we have to turn off this backup.
It would be great if you guys can help me in doing this in a more efficient way with minimal changes to existing setup.
Thanks |
|
Back to top |
|
 |
mqjeff |
Posted: Mon Apr 28, 2014 5:44 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
|
Back to top |
|
 |
kbtraj |
Posted: Mon Apr 28, 2014 5:49 am Post subject: |
|
|
Novice
Joined: 28 Apr 2014 Posts: 10
|
mqjeff wrote: |
Record and Replay. |
Hi mqjeff
Can you please explain more?
We are using Message Broker V6. Is it possible to use what you are saying in it? |
|
Back to top |
|
 |
Esa |
Posted: Mon Apr 28, 2014 7:01 am Post subject: |
|
|
 Grand Master
Joined: 22 May 2008 Posts: 1387 Location: Finland
|
kbtraj wrote: |
We are using Message Broker V6. Is it possible to use what you are saying in it? |
V6 is out of support.
If you are using MQ 7.x and not some out-of support version of MQ, too, you could make the input queue a topic. Then create a new input queue to act as the input queue to the flow and another queue for collecting the message copies. And define subscriptions to both of the queues. Or something like that. There are ways to do this even so that you don't need to modify the flow at all. |
|
Back to top |
|
 |
mqjeff |
Posted: Mon Apr 28, 2014 7:17 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
And using this particular requirement as a specific justfication to upgrade to a supported version is the *best* way to meet this requirement.
Dump v6.
Skip v7. Go to v9. |
|
Back to top |
|
 |
smdavies99 |
Posted: Mon Apr 28, 2014 7:35 am Post subject: |
|
|
 Jedi Council
Joined: 10 Feb 2003 Posts: 6076 Location: Somewhere over the Rainbow this side of Never-never land.
|
mqjeff wrote: |
And using this particular requirement as a specific justfication to upgrade to a supported version is the *best* way to meet this requirement.
Dump v6.
Skip v7. Go to v9. |
Provided the customer is still paying for support! _________________ WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
Back to top |
|
 |
kbtraj |
Posted: Tue Apr 29, 2014 1:02 am Post subject: |
|
|
Novice
Joined: 28 Apr 2014 Posts: 10
|
Thanks for your replies.
The customer is now moving from V6 to V7. So to be sure all our existing flows going to work fine in the new version, we need to collect some test input messages before upgrading. So that is the reason we now have to save the incoming messages in all the flows |
|
Back to top |
|
 |
kbtraj |
Posted: Tue Apr 29, 2014 1:05 am Post subject: |
|
|
Novice
Joined: 28 Apr 2014 Posts: 10
|
Esa wrote: |
If you are using MQ 7.x and not some out-of support version of MQ, too, you could make the input queue a topic. Then create a new input queue to act as the input queue to the flow and another queue for collecting the message copies. And define subscriptions to both of the queues. Or something like that. There are ways to do this even so that you don't need to modify the flow at all. |
HI Esa,
Well, we are using MQ 7 only. So, I am thinking its better to try your solution. Are you sure we no need to change existing flows in this way? and can we unsubscribe/turn off this backup at any time? |
|
Back to top |
|
 |
smdavies99 |
Posted: Tue Apr 29, 2014 2:25 am Post subject: |
|
|
 Jedi Council
Joined: 10 Feb 2003 Posts: 6076 Location: Somewhere over the Rainbow this side of Never-never land.
|
kbtraj wrote: |
Esa wrote: |
If you are using MQ 7.x and not some out-of support version of MQ, too, you could make the input queue a topic. Then create a new input queue to act as the input queue to the flow and another queue for collecting the message copies. And define subscriptions to both of the queues. Or something like that. There are ways to do this even so that you don't need to modify the flow at all. |
HI Esa,
Well, we are using MQ 7 only. So, I am thinking its better to try your solution. Are you sure we no need to change existing flows in this way? and can we unsubscribe/turn off this backup at any time? |
Yes but don't take my word for it, give it a try yourself. _________________ WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
Back to top |
|
 |
Esa |
Posted: Tue Apr 29, 2014 2:27 am Post subject: |
|
|
 Grand Master
Joined: 22 May 2008 Posts: 1387 Location: Finland
|
Depending if you are usign MQ clustering or not, you can recreate the target queue (or remote queue target queue) as an alias queue. Make it point to a topic and create subscriptions to the input queue of the flow and the collection queue.
Later, when you don't need to collect messages any more, you can change the target alias queue to refer to the flow input queue directly.
The only thing you need to change or override is the name of the flow input queue. If you don't want to change that, you will have to change the remote queue target queue, or the cluster alias queue name. |
|
Back to top |
|
 |
zpat |
Posted: Tue Apr 29, 2014 2:50 am Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
Several ways to approach this
1. Change the original input queue (for the flow) into a topic alias queue to automatically publish the messages - create two durable subscriptions one to a queue (now) used by the flow, and one to a queue for the copies. You can add/remove the second subscription at any time.
2. Create copies in the flow - but set the MQMD.expiry value in a MQheader node to make the copies auto-expiring (e.g. in 7 days) - that way you can leave the flow unchanged all the time and the copies will self-manage.
3. Change the flow itself, to publish the messages in the flow (and create a durable subscription for that topic only when you want a copy). Or send the second copy to a topic alias queue, which achieves the same effect.
4. Event messages, or record-replay - all fairly complex to set up.
Personally I like option 1 - just remember to housekeep the second queue or it can fill up and also to set PSPROP(NONE) on the subs. _________________ 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 |
|
 |
fjb_saper |
Posted: Tue Apr 29, 2014 4:47 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
kbtraj wrote: |
Thanks for your replies.
The customer is now moving from V6 to V7. So to be sure all our existing flows going to work fine in the new version, we need to collect some test input messages before upgrading. So that is the reason we now have to save the incoming messages in all the flows |
Why go from V6 to V7 which will be obsolete pretty soon. Graduate directly to V9... There are rumors of V10 coming out @impact...  _________________ MQ & Broker admin |
|
Back to top |
|
 |
PeterPotkay |
Posted: Tue Apr 29, 2014 4:54 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
|
Back to top |
|
 |
Michael Dag |
Posted: Tue Apr 29, 2014 6:03 am Post subject: |
|
|
 Jedi Knight
Joined: 13 Jun 2002 Posts: 2607 Location: The Netherlands (Amsterdam)
|
fjb_saper wrote: |
kbtraj wrote: |
Thanks for your replies.
The customer is now moving from V6 to V7. So to be sure all our existing flows going to work fine in the new version, we need to collect some test input messages before upgrading. So that is the reason we now have to save the incoming messages in all the flows |
Why go from V6 to V7 which will be obsolete pretty soon. Graduate directly to V9... There are rumors of V10 coming out @impact...  |
it's not a rumour anymore... (that was quick!)
V10... I remember getting my hands on MQIntegrator 1.0 from New Era of Networks (NEON) ... Getting old... or  _________________ Michael
MQSystems Facebook page |
|
Back to top |
|
 |
|