| Author |
Message
|
| hammer76 |
 Posted: Fri Oct 24, 2014 8:02 am Post subject: Manipulating “ReplyTo” settings |
 |
|
Newbie
Joined: 24 Oct 2014
Posts: 6
|
MQSeries.net newbie, long time reader first time writer! Difficult scenario to explain but I'll try and keep it simple. This is in regards to replyToQmgr and replyToQ attributes on messages.
We have a scenario where a "QM1" queue manager is receiving messages from another internal queue manager (we'll call it QM2). These messages are picked up by an application from QM1 and are consumed successfully. However, the messages themselves have the attributes "replyToQmgr " and "replyToQ" set which are for the original sending queue manager (QM2), as I want the responses going back to QM1 I have created a "queue manager alias" with the name of QM2 on QM1. To do this I created a Remote Queue Definition with;
RMQ Name: QM2
Remote Q Name: Name of the Q I want the responses going to
R MQ Manager name: QM2
Transmission Q: Xmit queue which sends to QM2
I'm expecting this to allow the application to send back the responses to QM2, but it appears the consuming application has been written in a way that is trying to send the response back on QM2 qmgr only and falls over with a "2087. Unknown remote queue manager" instead.
It would appear that there isn't much I can do in changing the application both sending or consuming the messages so I was wondering what I can do to manipulate the "replyToQmgr " and "replyToQ" attributes? I've seen examples from IBM involving other queue managers but that’s not really an option here, I need to be able to do it on QM1 only.
Any suggestions as I've hit a road block it would appear. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Fri Oct 24, 2014 8:40 am Post subject: Re: Manipulating “ReplyTo” settings |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| hammer76 wrote: |
| Difficult scenario to explain |
You got that right.
| hammer76 wrote: |
| want the responses going back to QM1 I have created a "queue manager alias" with the name of QM2 on QM1. |
| hammer76 wrote: |
| I'm expecting this to allow the application to send back the responses to QM2 |
Can you explain the apparent contrdiction in these 2 statements? Especially as:
| hammer76 wrote: |
RMQ Name: QM2
Remote Q Name: Name of the Q I want the responses going to
R MQ Manager name: QM2
Transmission Q: Xmit queue which sends to QM2 |
This appears to be a queue manager alias that alises QM2 to itself, i.e. does with the XMITQ would do if you'd not defined the queue manager alias and doesn't point to QM1.
| hammer76 wrote: |
| I was wondering what I can do to manipulate the "replyToQmgr " and "replyToQ" attributes? |
Nothing at the queue manager level.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| hammer76 |
| Posted: Fri Oct 24, 2014 8:49 am Post subject: |
|
|
Newbie
Joined: 24 Oct 2014
Posts: 6
|
Yeah I figured explaining the scenario will cause some confusion!
To refine my orignal statement a little I want the responses going back to QM2 via QM1, although the application is falling over with the 2007 error before it even attempts to write (can't see an evidence in the QM1 logs).
Yeah I was thinking that creating a Remote Queue Defintion with the same name as the queue manager I am connecting to might not be proper MQ stanza.Are are you suggesting just creating an xmitq with QM2 as the name is enough? Slightly confused by that.
Well your end statement stops me in my tracks I guess, if there is nothing I can do to mainipulate the replyTo attributes, if the application consuming doens't play ball I'm stuck anyway. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Oct 24, 2014 8:56 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| hammer76 wrote: |
| To refine my orignal statement a little I want the responses going back to QM2 via QM1, although the application is falling over with the 2007 error before it even attempts to write (can't see an evidence in the QM1 logs). |
This has not helped me. So an application connected to QM2 sends a request which ends up on QM1, where it's consumed by an application connected to QM1, a reply is constructed and you want this reply to end up back on QM2 via QM1. Yes?
If the application sending the response is connected to QM1, how else is the response going to get back to QM2 except via QM1???
(I think in 7 years posting here that's the first time I've ever bolded an entire sentence......)
Now etither your scenario makes no sense, your explaination is fatally flawed, my reading & understanding of your explaination is woefully inadequate or I need to start the weekend earlier than I thought.
I see any of these explainations as plausible and look to you for clarifiaction.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Oct 24, 2014 8:58 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| hammer76 wrote: |
| Well your end statement stops me in my tracks I guess, if there is nothing I can do to mainipulate the replyTo attributes, if the application consuming doens't play ball I'm stuck anyway. |
If the replyToqmgr in the message is QM2, and your desired target is QM2, the fact that you can't change the headers is irrelevent - they're already correct.
It's how you want the messages to get to QM2 which seems to be at issue, and that is controlled at a queue manager level.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| hammer76 |
| Posted: Fri Oct 24, 2014 9:01 am Post subject: |
|
|
Newbie
Joined: 24 Oct 2014
Posts: 6
|
Apologies for my mumbled explanations but yes you hit the nail on the head with your first sentence  ;
"an application connected to QM2 sends a request which ends up on QM1, where it's consumed by an application connected to QM1, a reply is constructed <<by the consuming application off QM1) and you want this reply to end up back on QM2 via QM1"
So, the message that got sent to QM1 for consumption by the applications connected has a replyToQmgr of QM2 and a replyToQ <<a queue on QM2>>. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Oct 24, 2014 9:08 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Ok, so I need to start the weekend early.
| hammer76 wrote: |
| So, the message that got sent to QM1 for consumption by the applications connected has a replyToQmgr of QM2 and a replyToQ <<a queue on QM2>>. |
So we have established this. We have established that the application sending the response (addressed using the attributes above) is connected to QM1. The transmission of this message from QM1 to QM2 is achieved (as you indicate) by an XMITQ called QM2.
So I don't even understand why you're posting a question if that the case & you're a long time reader (which infers long time WMQ user) so you are clearly asking a different and more complex question which I'm completely missing.
Hence Saturday starts here.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Oct 24, 2014 9:10 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Or (he says in desparation) is your problem that the responding application isn't using the replyTo fields in the request to address the response but is simply putting it to QM1?
In which case you wouldn't get a 2087 you'd get a 2085.
Back to Plan A and the early weekend.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| hammer76 |
| Posted: Fri Oct 24, 2014 9:19 am Post subject: |
|
|
Newbie
Joined: 24 Oct 2014
Posts: 6
|
Believe it or not (I'm sure that you will) I haven't had to used a QM alias' before.
Ok, so the chances are my qm alias isn't set up correctly. So, is that all I need an xmitq names QM2? No remote Q defintion?
Everything I've read thus far makes me think that I need a remote q defintion with the same name as the QM I'm trying to mimic (in this case QM2)? |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Oct 24, 2014 9:33 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| hammer76 wrote: |
| So, is that all I need an xmitq names QM2? No remote Q defintion? |
Yes. A message put on QM1 addressed to QM2 will resolve to an XMITQ named QM2. This is (or should be) how the requests are getting from QM2 to QM1....... 
| hammer76 wrote: |
| Everything I've read thus far makes me think that I need a remote q defintion with the same name as the QM I'm trying to mimic (in this case QM2)? |
This is the definition of a queue manager alias. Given that the queue manager the messages are trying to find (QM2) is the real name of the target queue manager (QM2) then why do you think you need an alias?
If (for example) you needed to get to QM3 from QM1 and the only way (because of network restrictions) is via QM2 then you'd need a queue manager alias of QM3 on QM1 that resolved to QM2's xmitq. This is probably why:
| hammer76 wrote: |
| I've seen examples from IBM involving other queue managers |
You really need other queue managers to make a queue manager alias necessary. For a straight point to point they're pointless.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| hammer76 |
| Posted: Fri Oct 24, 2014 9:48 am Post subject: |
|
|
Newbie
Joined: 24 Oct 2014
Posts: 6
|
Ok cool got it, thank you for your patience. Enjoy your weekend!  |
|
| Back to top |
|
|
|
|
