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 Index » General IBM MQ Support » MQ Dynamic reply: Reply without Remote Queue (server-server)

Post new topic  Reply to topic
 MQ Dynamic reply: Reply without Remote Queue (server-server) « View previous topic :: View next topic » 
Author Message
yasaboy
PostPosted: Tue Jun 25, 2019 11:40 pm    Post subject: MQ Dynamic reply: Reply without Remote Queue (server-server) Reply with quote

Voyager

Joined: 23 Jun 2014
Posts: 90

We currently have a server to server mq setup as following.

Application QM (APP)
-----------------------

Transmission queue -> X0001.LOCAL
Sender channel -> APP.C01.LOCAL , XMITQ('X0001.LOCAL')
Receiver Channel -> LOCAL.C01.APP
Local Queue -> XXXX.RPLY01
Remote Queue -> XXXX.RQST01

Our Local QM(LOCAL)
------------------------

Transmission queue -> X0001.APP
Sender channel -> LOCAL.C01.APP , XMITQ('X0001.APP')
Receiver Channel -> APP.C01.LOCAL
Local Queue -> XXXX.RQST01
Remote Queue -> XXXX.RPLY01

We are currently exploring a option to remote the burden of creating the remote queue(Remote Queue-> XXXX.RPLY01) at our side and any alternative option to put message to the reply queue in APP side directly(Local Queue ->XXXX.RPLY01)


Can anyone please suggest a alternative approach if its possible or not to take our remote queue out of the picture ?
Back to top
View user's profile Send private message
hughson
PostPosted: Wed Jun 26, 2019 2:00 am    Post subject: Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1914
Location: Bay of Plenty, New Zealand

In a request/reply model such as (I assume by the names) this is, it is normal for the requesting application to provide the name of the reply queue in the request message.

So an application running, connected to queue manager APP, puts a message to remote queue XXXX.RQST01 and fills in the MQMD.ReplyToQ field with the name of its reply queue, XXXX.RPLY01. Assuming that the application wants the reply to come back to the queue manager it is connected to (APP), then it does not need to fill in the MQMD.ReplyToQMgr field and the queue manager will fill this in on its behalf when the message is put.

The request message will then move across the channel, APP.C01.LOCAL to queue manager LOCAL, and will be placed on the queue XXXX.RQST01. The application reading queue XXXX.RQST01 will pick up the message, do whatever it needs to do, and will then create the reply message which it should put to the name of the queue and queue manager provided in the MQMD ReplyTo fields. To be clear it should do an MQOPEN/MQPUT (or commonly an MQPUT1) using MQOD.ObjectName set to MQMD.ReplyToQ, and MQOD.ObjectQMgrName set to MQMD.ReplyToQMgr. I can't stress enough how important it is that both fields are used, not just the queue name.

The job of the configuration at queue manager LOCAL is now to route this reply message safely back to queue manager APP.

You say:-
yasaboy wrote:
We are currently exploring a option to remove the burden of creating the remote queue(Remote Queue-> XXXX.RPLY01) at our side


This statement, and the XXXX.REPLY01 naming convention that you have lead me to believe (although you have not said specifically) that this is a burden because for every application you have, you need to make a new remote queue, and there are lots of them (4 X's suggests you could have up to 9999 of them!).

What you need is a single definition that will route all of them successfully, without the need to make a new definition for every new application added.

The simple way for routing to a queue manager without any remote queue definitions is to use the queue manager name as the name of the transmission queue. You have not done this, and that is not a problem - so long as you don't literally have one transmission queue per application - which you do not need. You didn't name them XXXX.APP so I'm hoping not!

The next simplest way is to have a single definition to say, whenever you see queue manager APP mentioned in the routing required for a message, please place it on this XmitQ. That definition looks as follows:-

Code:
DEFINE QREMOTE(APP) XMITQ(X0001.APP)


I will reiterate that this solution requires the following things to be successful, and only you know whether they are true or not.
  • Application sending request message fills in MQMD.ReplyToQ
  • Application sending reply message uses MQMD.ReplyToQ and ReplyToQMgr fields
  • Single transmission queue and channel, NOT one channel for each request/reply queue pair
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
Vitor
PostPosted: Wed Jun 26, 2019 5:01 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

Moved to more relevant section
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
Vitor
PostPosted: Wed Jun 26, 2019 5:02 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

And to add to the most excellent comments made by my most worthy associate, don't forget that the requesting application can dynamically create a reply queue (the name of which it must still supply as described above) rather than using a predefined one.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Wed Jun 26, 2019 5:51 am    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY

And keeping with a pre-defined reply queue the op might as well want to look into the different articles for request reply talking about the use of a reply alias queue and queue manager alias, that would allow for automatic routing of the reply to message from local without changing or creating any object on local....
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
gbaddeley
PostPosted: Wed Jun 26, 2019 3:31 pm    Post subject: Reply with quote

Jedi

Joined: 25 Mar 2003
Posts: 2492
Location: Melbourne, Australia

Agree with the above suggestions. Queue manager aliases also make it easier to do multi-hop routing and also hub-and-spoke MQ topologies. In our shop, we don't have any xmitq's that have the same name as qmgrs. They are named 'qmgr.XMITQ' and we have qmgr aliases that point to these queues.
I also suggest that you implement an improved naming standard for queue managers, channels, transmission queues and local queues. I understand what you have currently set up, but it took a little thinking, whereas it should be immediately obvious.
_________________
Glenn
Back to top
View user's profile Send private message
yasaboy
PostPosted: Thu Jun 27, 2019 12:15 am    Post subject: Reply with quote

Voyager

Joined: 23 Jun 2014
Posts: 90

Hi all,
Thanks all for prompt replies.

hughson wrote:
This statement, and the XXXX.REPLY01 naming convention that you have lead me to believe (although you have not said specifically) that this is a burden because for every application you have, you need to make a new remote queue, and there are lots of them (4 X's suggests you could have up to 9999 of them!).


This is exactly correct. Ours is a financial organization and have 1000s and thousands of reply queues and its highly sensitive and critical since data are actual financial txns. We need to retain low latency and should be no performance impact.
So If I understand correctly your suggestion is as follows
Application QM (APP)
----------------------------------------------
Transmission queue -> X0001.LOCAL
Sender channel -> APP.C01.LOCAL , XMITQ('X0001.LOCAL')
Receiver Channel -> LOCAL.C01.APP
Local Queue -> XXXX.RPLY01 / XXXX.RPLY02/ XXXX.RPLY03/ XXXX.RPLY04/ XXXX.RPLY05
Remote Queue -> XXXX.RQST01 / XXXX.RQST02/ XXXX.RQST03/ XXXX.RQST04/ XXXX.RQST05


Our Local QM(LOCAL)
-----------------------------------------------
Transmission queue -> X0001.APP (Only 1)
Sender channel -> LOCAL.C01.APP , XMITQ('X0001.APP')
Receiver Channel -> APP.C01.LOCAL
Local Queue -> XXXX.RQST01 / XXXX.RQST02/ XXXX.RQST03/ XXXX.RQST04/ XXXX.RQST05
Remote Queue -> APP (only 1 queue with name or remote Queue Manager)

I have a doubt now into how will the transmission Q know which exact reply Queue to put message to eg: (XXXX.RPLY01 / XXXX.RPLY02/ XXXX.RPLY03/ XXXX.RPLY04/ XXXX.RPLY05)
Is it based on the MQMD header ? MQMD.ReplyToQ ?
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Thu Jun 27, 2019 4:52 am    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY

On QM.LOCAL

Code:
DEF QR(APP) RQMNAME(APP) xmitq (X001.APP)

This will ensure that a message for any queue on APP gets moved to its destination. It is called a qmgr alias and it also creates a default routing to qmgr APP.

Enjoy
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
Vitor
PostPosted: Thu Jun 27, 2019 6:04 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

yasaboy wrote:
I have a doubt now into how will the transmission Q know which exact reply Queue to put message to eg: (XXXX.RPLY01 / XXXX.RPLY02/ XXXX.RPLY03/ XXXX.RPLY04/ XXXX.RPLY05)


To be clear (because it's important) -

The transmission queue doesn't do anything, it's a storage area for a specific sender channel MCA that points to a specific receiver channel MCA on a specific queue manager. The advice of my worthy associates determine which transmission queue a message is placed on and thus which queue manager it ends up on.

yasaboy wrote:
Is it based on the MQMD header ? MQMD.ReplyToQ ?


Yes. The reciever MCA will check the ReplyTo fields. If the reply to queue manager isn't the one it's running on, it will look for a matching transmission queue (as described above on name resolution and multi-hop). If it is the queue manager, it looks for the ReplyToQ. If it can find it, it puts it. If it can't, it puts it to the DLQ.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Thu Jun 27, 2019 11:02 am    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY

Vitor wrote:
yasaboy wrote:
Is it based on the MQMD header ? MQMD.ReplyToQ ?


Yes. The reciever MCA will check the ReplyTo fields. If the reply to queue manager isn't the one it's running on, it will look for a matching transmission queue (as described above on name resolution and multi-hop). If it is the queue manager, it looks for the ReplyToQ. If it can find it, it puts it. If it can't, it puts it to the DLQ.


Let's be a little more specific here. The request message gets to the server app. It reads the MQMD and TRANSFERS the replyto qmgr info int the destination qmgr and the reply to queue into the destination queue of the response message. The response message first looks for a transmission queue with the same name as the destination qmgr, then for a qmgr alias (remote queue) of the same name as the remote queue manager. Once found it will put the message on the corresponding transmission queue.
This will forward the message to the next hop.
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
Vitor
PostPosted: Thu Jun 27, 2019 11:28 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

fjb_saper wrote:
Let's be a little more specific here.


So you're not possessed by the spirit of my English master, you're his reincarnation???


_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
hughson
PostPosted: Thu Jun 27, 2019 7:44 pm    Post subject: Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1914
Location: Bay of Plenty, New Zealand

yasaboy wrote:
I have a doubt now into how will the transmission Q know which exact reply Queue to put message to eg: (XXXX.RPLY01 / XXXX.RPLY02/ XXXX.RPLY03/ XXXX.RPLY04/ XXXX.RPLY05)
Is it based on the MQMD header ? MQMD.ReplyToQ ?

Inside the message that is now sitting on the transmission queue, is a header called a Transmission Header (MQXQH). This is put onto the front of your message so that the channel when reading the message (most specifically the receiver channel) knows what to do with it when it comes to put the message at the target system.

So, here are the steps in the process again:-
  1. Requesting app sends request message containing MQMD.ReplyToQ
  2. APP queue manager fills in MQMD.ReplyToQMgr because app leaves it blank
  3. Replying app picks up message and MQPUT1s the reply message to the MQMD.ReplyToQ and MQMD.ReplyToQMgr fields.
  4. Message sits on XmitQ with MQXQH header containing the queue and queue manager the message was MQPUT1 to.
  5. Receiver channel receives message and strips off MQXQH header and uses those fields to put the message to the target queue.
If you have a test system, stop a channel and have a browse of the messages on the XmitQ to see exactly how this all works.

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
fjb_saper
PostPosted: Fri Jun 28, 2019 4:57 am    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY

Vitor wrote:
fjb_saper wrote:
Let's be a little more specific here.


So you're not possessed by the spirit of my English master, you're his reincarnation???


And here I thought that would possibly be Morag? God bless her she always states things so clearly...
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
Vitor
PostPosted: Fri Jun 28, 2019 6:36 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

fjb_saper wrote:
Vitor wrote:
fjb_saper wrote:
Let's be a little more specific here.


So you're not possessed by the spirit of my English master, you're his reincarnation???


And here I thought that would possibly be Morag? God bless her she always states things so clearly...


Nope, her answers show understanding and contain information. He'd never manage that.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » General IBM MQ Support » MQ Dynamic reply: Reply without Remote Queue (server-server)
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.