| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Dynamic reply mechanism |
« View previous topic :: View next topic » |
| Author |
Message
|
| bruce2359 |
 Posted: Sat Apr 18, 2015 4:09 pm Post subject: |
 |
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| kordi wrote: |
Guys,
I know how it suppose to work, the theory is simple as you all explained to me. Let me explain my doubt in details:
APP1 puts message on QR1. QR1 is defined on QM1, so APP1 can open this queue for input because it exists on QM1. Message is being transmitted to QL2 on QM2, as defined in QR1. |
The request message creator (APP1) opens the QRemote def for OUTPUT, not INPUT.
| kordi wrote: |
| APP2 gets message fom QL2 on QM2. It process it somehow and now wants to send it back to QM1. We assume that it replies it to QL1 on QM1 as it is defined in ReplyToQ and ReplyToQmgr of message send by APP1. APP2 opens for input queue ReplyToQ and fails, because " 2085 0x00000825 MQRC_UNKNOWN_OBJECT_NAME" on QM2. |
No, the replying app (APP2) opens QL2 for input to MQGET the request message. To send the reply message, APP2 must build the MQOD with Replytoqueue and Replytoqmgr name from the MQMD of the request message. Then do an MQPUT1 (which does an implied MQOPEN) of the reply message to the xmitq. There will need to be an xmitq on QM2 with the same name as the Replytoqmgr (QL1).
APP2 on QM2 does NOT MQOPEN the Replytoqueue name. The Replytoqueue name does NOT get resolved on QM2. Qmgr QM2 assumes that the replytoqueue name was validated (resolved) on QM1 before the request message was MQPUT to the xmitq on QM1.
_________________
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 |
|
 |
| kordi |
| Posted: Wed Apr 22, 2015 1:30 pm Post subject: |
|
|
Centurion
Joined: 28 May 2012
Posts: 146
Location: PL
|
| bruce2359 wrote: |
The request message creator (APP1) opens the QRemote def for OUTPUT, not INPUT. |
You are correct, I made a mistake here, my fault.
| kordi wrote: |
| APP2 gets message fom QL2 on QM2. It process it somehow and now wants to send it back to QM1. We assume that it replies it to QL1 on QM1 as it is defined in ReplyToQ and ReplyToQmgr of message send by APP1. APP2 opens for input queue ReplyToQ and fails, because " 2085 0x00000825 MQRC_UNKNOWN_OBJECT_NAME" on QM2. |
Well, lack of knowledge resulted in wrong assumption.
There are two ways of using accessQueue:
accessQueue(java.lang.String queueName,int openOptionsArg)
and
accessQueue(java.lang.String queueName,int openOptionsArg,java.lang.String queueManagerName,java.lang.String dynamicQueueName,java.lang.String alternateUserIdArg)
In my code I used only first one and thats why I was confused about these replies. Now, my code looks like this:
| Code: |
// message was retrieved from queue
String ReplyToQ = rcvMessage.replyToQueueName;
String ReplyToQmqr = rcvMessage.replyToQueueManagerName;
// Define a simple WebSphere MQ Message ...
MQMessage rmsg = new MQMessage();
rmsg.writeUTF("Reply message!!!!");
// Specify the default put message options
MQPutMessageOptions rpmo = new MQPutMessageOptions();
openOptions = MQConstants.MQOO_OUTPUT | MQConstants.MQOO_FAIL_IF_QUIESCING;
MQQueue rqueue = qMgr.accessQueue(ReplyToQ, openOptions, ReplyToQmqr, null, null);
|
And reply message is delivered to ReplyToQ and ReplyToQmgr.
Thank you everyone involved in helping me, especially to fjb_saper for a good hint which finally helped me resolving my problem. |
|
| Back to top |
|
|
| PaulClarke |
| Posted: Wed Apr 22, 2015 2:36 pm Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
So basically what I told you to do on April 13th then 
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| kordi |
| Posted: Thu Apr 23, 2015 3:20 am Post subject: |
|
|
Centurion
Joined: 28 May 2012
Posts: 146
Location: PL
|
Well... I think there had to be small misunderstanding from my side. 
Anyway, thankfully I managed to resolve my issue and now I can sleep well finally 
Once again thank you a lot for your effort put in helping me.
Cheers!
Kordian |
|
| Back to top |
|
|
| boos |
| Posted: Fri May 22, 2015 6:00 am Post subject: |
|
|
Apprentice
Joined: 27 Jan 2004
Posts: 37
Location: Netherlands
|
| Isn't the problem that you try to put the message on the reply-2-q name with your local queuemanager (which doesn't know that queue). That means you filled the wrong queuemanager name within the OPEN/PUT api. You do the connect on your local queuemanager. But on the OPEN/PUT api you should use the Reply-2-qmgr name in the queuemanager field on that api. If you configured an alias queuemanager for your reply-2-qmgr your message will end up on the right queue. |
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
