| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| queue name resolution |
« View previous topic :: View next topic » |
| Author |
Message
|
| sebastia |
 Posted: Sat Nov 29, 2008 11:34 am Post subject: queue name resolution |
 |
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
Good evening all of you.
I want to run a "demo" on "Queue name resolution".
This is, an application sends a message to a queue
that does not exist on the local queue manager,
so the destination queue manager name is used
to find a transmission queue of the same name,
where the message shall be placed.
Do we agree until this point ? I hope so.
I read "Chapter 7, MQ v 7 Intercommunication, page 499 out of 525".
+++
The sequence of events is as follows:
1. The putting application issues MQOPEN and MQPUT calls to put messages to the target queue.
2. During the MQOPEN call, the name resolution function detects that the target queue is not local, and decides which transmission queue is appropriate. Thereafter, on the MQPUT calls associated with the MQOPEN call, all messages are placed on this transmission queue.
3. The sending MCA gets the messages from the transmission queue and passes them to the receiving MCA at the remote computer.
4. The receiving MCA puts the messages on the target queue, or queues.
5. The getting application issues MQOPEN and MQGET calls to get the messages from the target queue.
+++
I have a local queue manager QM1 on the machine where my prog runs.
I issue a MQ_Connect(QM1) and I get a handle. Cool.
Now I have to issue a MQ_Open(queue_name),
where I want to place a message
whose destination queue manager is "QM2"
and destination queue name is "QL2".
(a) So, I must issue a MQ_Open (queuename = dummy) ?
(b) And then a MQ_Put() of the message there ??
And the message auto-magically appears move to
transmission queue names "QM2" ?
Help me a bit, please. I dont understand it.
At moment "a" I shall get "queue does not exist" return code ...
At moment "b", I shall have no handle to "put()" the msg ...
OK, lets supose I do have local queue QL1.
I can do "MQ_Open(QL1)".
Shall I do MQ_Put() of my message into QL1 ?
What I do not understand is the text from the book,
where it says "During the MQOPEN call, the name resolution function detects that the target queue is not local, and decides which transmission queue is appropriate."
SO, which queue shall I do "MQ_Open()" ? QL2 seems appropiate ...
But, as it does not exist on local qmgr,
shall I get a handle to be able a mq_put() ???
There is something I am missing,
and I need you my coleagues to help me.
Thanks.
I just need a short and precise sequence of mq api verbs
to run a demo of "queue name resolution".
Seb. |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Sat Nov 29, 2008 12:04 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| What I do not understand is the text from the book, where it says "During the MQOPEN call, the name resolution function detects that the target queue is not local, and decides which transmission queue is appropriate." |
Name resolution requires a local object definition on the local qmgr your application executes on. So, on the local qmgr, you will need to create a QRemote(name) definition. The QR definition has some important attributes: RQname (remote queue name) and RQMname (remote qmgr name), and possibly an xmit queue name.
At MQOPEN, your application specifies the QR(name). The qmgr uses the QR definition to build the xmit queue header, and determine the xmit queue. If your QR definition explicitly specifies the name of an xmit queue, the object handle is that of the xmit queue. If your QR definition does not specifiy explicitly an xmit queue, the RQMname will be used as the xmit queue name. RQMname could be a qmgr-alias; in which case, that name will (should) resolve to an xmit queue.
Thus, a message ends up in an xmit queue. The sending MCA sends the message (MQMD, XQH, application data) down the network.
Down the network, the receiving MCA checks to see if the RQMname in the XQH is the same one it is MQCONNected to. If the message arrives on the qmgr whose name is RQMname (or there's a qmgr-alias to resolve it), the MCA tries to open the queue name specified in the xmit-queue-header RName. If either of these fails, the msg goes to the dead-letter-queue.
_________________
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 |
|
|
| sebastia |
| Posted: Sat Nov 29, 2008 12:18 pm Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
Hi, Bruce. Thanks for your answer.
I understand what you say : create a QR with an emptry XmitQname.
MQ_open(QR) and the RemoteQueueManager name in the msg
shall be used as Xmit Queue.
OK.
Just let me push the situation one step ahead :
CAN WE PRODUCE THE SAME RESULT without that QR ?
Because I have seen it work, without that QR ...
My environment is this one :
I receive an XML message thru MQ into ICS.
I save "ReplyToQueue" and "ReplyToQueueManager"
and send the XML message to SAP,
including those 2 fields.
The message from SAP comes back,
and all the info ICS has are those 2 fields,
no QR name at all !!!
*** what queue does ICS "Open()" ??? ***
Thanks. Seb. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Nov 29, 2008 12:51 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| Because I have seen it work, without that QR ... |
As with everyting else, there are a few exceptions. But first, back to the basics:
An application must be MQOPEN or MQPUT1 to open a queue. The MCA is just another application; it MQCONNects to a local qmgr, MQOPENs queues, etc.).
Name resolution is driven by an MQOPEN (or MQPUT1s implied MQOPEN). Name resolution looks first for a local object (QL, QM, QA, QR); and if none is found, then looks in a repository (partial, then full).
In the case of a replying application, name resolution of the reply-to-queue and reply-to-queue-manager names take place on the sending qmgr. (Imagine the replying qmgr trying to validate a dynamically named queuename like amq.a1b2c3d4e5...).
It is assumed by the replying qmgr that the reply-to-queue and reply-to-queue-manager names have been resolved on the sending side. The replying application MQPUT1s the reply message to the names taken from the inbound request message. In the case of a remote application, the reply-to-qmgr field is presumed to be an xmit queue.
| Quote: |
| CAN WE PRODUCE THE SAME RESULT without that QR ? |
In violation of best-practice thingies, you could write an application that explicitly opens an xmit queue, builds an xqh, and puts a message.
_________________
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 |
|
|
| atheek |
| Posted: Sat Nov 29, 2008 1:06 pm Post subject: |
|
|
Partisan
Joined: 01 Jun 2006
Posts: 327
Location: Sydney
|
You can specify both the Queue name as well as the QUeue Manager Name in the MQOpen call.
In your example, the receiving application issues the following:
1. MQCONNECT ( ICF Queue Manager) - Gets a handle to the ICF Qmgr
2. MQOPEN(SAP QMGR, SAP Q) - Name Resolution is done at the ICF Queue Manager. It resolves that the application is opening a queue belonging to a remote queue manager. Hence it will serach for a XMITQ with the same name as remote QMGR ( SAP) and when you issue MQPUT subsequently, it is put to the XMITQ.
In this way it could work without QR. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Nov 29, 2008 1:06 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
The message from SAP comes back,
and all the info ICS has are those 2 fields,
no QR name at all !!! |
I continue:
If the replying application is local to the requesting application, then there is no xmit queue, no QRemote definition. The replying application does an MQPUT1 to the reply-to-queue named in the reply-to-queue field in the request message MQMD.
In your configuration, are the requesting and replying applications local? Or is there message flow across a network?
_________________
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 |
|
|
| bruce2359 |
| Posted: Sat Nov 29, 2008 1:14 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| You can specify both the Queue name as well as the QUeue Manager Name in the MQOpen call. |
Yes, you can. But hard-coding the name of the queue and qmgr runs afoul (afowl?) of the best-practice thingie about object name abstraction, namely: the program(mer) doesn't need to know the real names of the queue or qmgr. Hard-coding makes it difficult to move the requesting or replying application.
If your app specifies both qname and qmgrname, queue name resolution does not occur. You must have an xmit queue with the exact name your app specified, or a qmgr alias that resolves to an xmitq, or a default xmitq.
_________________
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 |
|
|
| atheek |
| Posted: Sat Nov 29, 2008 1:49 pm Post subject: |
|
|
Partisan
Joined: 01 Jun 2006
Posts: 327
Location: Sydney
|
Page 100 of the Application programming guide has a table which lists how the name resolution happens for the different combinations of QMGR names and Q names passed in MQOpen Call.
One entry in that is if the name of the queue manager passed in MQOpen is a local xmitq, then the transmission queue is derived to be that XMITQ.
In the example, I gave this will work if there is a XMITQ under ICF QMGR with the name of SAP QMGR.
I think this is how a server application which is supposed to service multiple clients should be coded to work. They need to specify the ReplyToQmgr and ReplyToQ names in the request as the qmgrName and qName in the MQOPEN call for the reply. So each time when you add a new client, the only change at the server side is to add a XMITQ with same name as client QMGR and the associated channel definition. |
|
| Back to top |
|
|
| sebastia |
| Posted: Sat Nov 29, 2008 3:16 pm Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
Thanks, mr Atheek - I have page 93 of App Prog Guide MQ version 6
in front of me. I shall have a good look at this table ...
Yes, I see you got my point of view :
we have a "server" application,
that receives messages that carry "ReplyToQueue"
and "ReplyToQueueManager" fields.
New clients ONLY requirement is their (remote) queue manager name
to be known (reflected in a Xmit Queue).
We have no Remote Queue definition at all, and dont need it.
yes, mr Bruce - I shall try MQ_PUT1() using the MQMD of received msg,
good idea (and easy to code !)
No, the "ReplyToQueue" is not local (it is a diferent company in fact)
and the "ReplyToQueueManager" is the one of the "client" application,
remote also.
We have NOTHING hardcoded, except one Xmit Queue
for every remote client we accept.
VERY FLEXIBLE, I'd say !
Thanks for your ideas ! |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Nov 29, 2008 3:44 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| New clients ONLY requirement is their (remote) queue manager name to be known (reflected in a Xmit Queue). |
For clarity: At the remote (requester) qmgr, there must be an xmit queue and sender channel that connects to your qmgr. At your (server) end, you need a replying application, an xmit queue and sender channel back to the requesting qmgr.
When you refer to client, you aren't refering to an MQ client bindings application, are you? Your clients are people, organizations); and their applications use qmgr bindings; meaning that their applications MQCONNect to a local qmgr, and messages traverse the usual MQ channels (sender-receiver, server-requester, for example)
| Quote: |
| We have no Remote Queue definition at all, and dont need it. |
True. You need no QR definitions if your qmgr is only behaving as a server respoding (replying) to inbound requests.
| Quote: |
| We have NOTHING hardcoded, except one Xmit Queue for every remote client we accept. |
Hard-coded, in this case, means coding inside an application program with specific, static names of objects - like the program specifying qname and qmgrname in the MQOD. What you have is a locally defined object - an xmit queue back to the requester qmgr. Your replying application will use the inbound reply-to-queue and reply-to-qmgr to seed the MQOD.
_________________
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 |
|
|
| sebastia |
| Posted: Sat Nov 29, 2008 3:53 pm Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
Yes, Bruce - you are 100% right.
a) when I said "clients" I was meaning applications, not "mq client" code.
b) no QR - we are pure "responders", answerers", yes.
c) we have on item hardcoded : the name of the remote qmgr
as a Xmit Queue, you are righ again.
*** But we can send replies to ANY remote queue ! ***
All they have to do is specify it in the ReplyToQueue
and we need no DEFINITION at all.
It is quite an "old-style" of routing
( being "modern" the cluster-style or the "remote queue" style )
but very very flexible.
Let's see if I can make the following code to run :
a) MQ_Connect(QM1)
b) MQ_Open(Q1)
c) MQ_GET(MSG_1)
c1) display MSG_1.ReplyToQueueManager
c2) display MSG_1.ReplyToQueue
c3) MQ_PUT1(MSG_1.ReplyToQueue, MSG_1.ReplyToQueueManager)
d) MQ_Close()
e) MQ_Disc()
Thanks again. Seb. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Nov 29, 2008 3:59 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| All they have to do is specify it in the ReplyToQueue and we need no DEFINITION at all. |
For clarity: for msgtype of request, the requesting application must specify a reply-to-queue or the put will fail. If the application does not specify a reply-to-qmgr, the local qmgr will place its name in the reply-to-qmgr field. So, the inbound request message will already have these two fields in the MQMD when your replying application MQGETs it from the queue. Your replying application only needs to move these two fields to the MQOD prior to MQPUT.
| Quote: |
| c) we have on item hardcoded : the name of the remote qmgr |
Why?
_________________
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 |
|
|
| sebastia |
| Posted: Sun Nov 30, 2008 12:13 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
1) Clarity : perfect.
Requestor Application fills both fields, ReplyToQueueMqnager
and ReplyToQueue.
We move those fields from MQMD (received) into MQOD (prior to PUT).
Cool.
2) We have hardcoded the "accepted" queue managers names ...
... as XMIT queue names.
I think we aree on this item also ..
( ) |
|
| Back to top |
|
|
| sebastia |
| Posted: Sun Nov 30, 2008 12:18 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
Sorry, Bruce - I missed a line.
If in your opinion
| Quote: |
"Hard-coded, in this case, means coding inside an application program with specific, static names of objects - like the program specifying qname and qmgrname in the MQOD. "
|
And what we have is ...
| Quote: |
"What you have is a locally defined object - an xmit queue back to the requester qmgr."
|
... then we have nothing hardcoded, of course ! |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
