| Author |
Message
|
| Y75 |
 Posted: Fri Feb 07, 2014 3:58 pm Post subject: MQOutput node and queue manager name |
 |
|
Apprentice
Joined: 29 Jul 2013
Posts: 32
|
In MQ Output node, queue manager name can be defined along with the name of queue. Documentation says if you specify a queue name defined on remote queue manager, queue manager name must be equal name of transmission queue.
Why would you want to send a message by naming a queue on remote queue manager; why not just define a remote queue on your local queue manager?
What is the reason for this option to exist? |
|
| Back to top |
|
 |
| smdavies99 |
| Posted: Fri Feb 07, 2014 10:15 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
It allows you to do I outside the Queue Manager Definition if that is your bent
PLUS (and here is the big advantage IMHO)
You can then use the MQOutput Node in DistributionList mode and setup the destination Queue and/or Queue Manager programmatically.
I have to say, I have never used the Queue Manager setting in the node but I have set it dynamically.
_________________
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 |
|
|
| Vitor |
| Posted: Mon Feb 10, 2014 5:40 am Post subject: Re: MQOutput node and queue manager name |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Y75 wrote: |
| Why would you want to send a message by naming a queue on remote queue manager; why not just define a remote queue on your local queue manager? |
A lot of sites don't set up remote queues but use the automatic name resolution of having a xmitq named for the target queue manager. Often this is team with a queue manager alias so that an application (and in this context WMB is just an application) can use a queue manager called "ORDERS".
The pros and cons of doing this as opposed to setting up remote queues is an entirely separate discussion. Suffice it to say that this topology is possible, is supported by IBM and this option exists on the node to support it.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Y75 |
| Posted: Fri Feb 14, 2014 9:22 am Post subject: |
|
|
Apprentice
Joined: 29 Jul 2013
Posts: 32
|
| Thanks Vitor ! I was trying to know pros and cons of one over the other to make a decision whether I should support it in my message flow or not. What is used more often? |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Feb 14, 2014 9:34 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Y75 wrote: |
| What is used more often? |
The one which best fits your requirements. 
As I said, the pros & cons are a lengthy conversation. Typically security & control are the principle drivers.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Feb 14, 2014 11:26 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
If a requesting application creates a dynamic queue for its reply queue, it wants the replier to send the reply to that dynamic queue, so the requestor puts the name of the dynamic queue into the Reply To Q field of the request.
You can't predict the name of a dynamic queue, therefore you can't build a remote queue that aims at it ahead of time.
Another use case:
If you have 20 queue managers all with a local queue called MY.REPLY.QUEUE, how is the replying app supposed to use a remote queue definition if for one reply it wants to send to MY.REPLY.QUEUE on QM1, but the next messages it wants to go to MY.REPLY.QUEUE on QM2?
If you are an application that provides a service, you typically are coded to respect the reply to q and reply to qm names in the request message, and when you put the reply you rely just on name resolution and not a predefined remote queue for the reply. If you rely on a predefined remote queue for the relies, you have locked your service to only be able to service requests from that one consumer. That is poor design.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
