| Author |
Message
|
| Santosh_Ghalsasi |
 Posted: Mon Aug 20, 2012 5:43 am Post subject: Asynchronous web service call (with Websphere MQ) |
 |
|
Novice
Joined: 01 Feb 2011
Posts: 19
|
Hi,
I am facing an issue while executing below scenario.
The flows structure is as below
Flow 1 - SOAPInput Node--> MQOutput Node
Flow 2 - MQInput Node--> SOAPReply Node
Below are the points for more clear idea -
1. These flows are deployed on two brokers say MB1 and MB2
2. The brokers use queue managers say MQ1 and MQ2 respectively.
3. There is a Gateway queue manager say GQ which is interacting with all external applications that connect to MB layer.
4. MQ1, MQ2 and GQ are in a cluster and GQ being a full repository and rest are partial.
5. The request message comes in SOAPInput Node(web service). That message is transformed and sent to an external application for further processing using MQOutput node in Flow 1. MQOutput node puts request on the queue residing on GQ.
6. External application processes that request and puts the response on a queue which is residing on both MQ1 and MQ2 and its a cluster queue(Cluster does the load balancing to send the responses to either queue in round robin fashion).
7. The response message is taken by MQInput Node of Flow 2 and the reply is sent via SOAPReply Node.
Now the issue is
Once the application hitting the web service sends a request, it waits for the response on the same thread, say either on broker-1 or broker-2. But it may happen that the broker on which the request is landed may not receive the processed response (cluster might route that response to the queue on other broker) and might keep waiting forever.
If message lands on the broker which has not sent the request, it goes into the DLQ.
Please let me know if anything can be done so that the reply should land back on the broker from which the request has been sent.
Thanks, |
|
| Back to top |
|
 |
| lancelotlinc |
| Posted: Mon Aug 20, 2012 5:44 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
Combine the two flows, swap the MQInput node for an MQGet node with wait on CorrelId, turn off transactionality, and use a reply-to-queue.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| wbi_telecom |
| Posted: Mon Aug 20, 2012 6:37 am Post subject: |
|
|
Disciple
Joined: 15 Feb 2006
Posts: 188
Location: Harrisburg, PA
|
The external appication should use ReplytoQmgr of the request message to send the response back rather than using the MQ Cluster. If you share your response queue in the cluster, you will have no control over where the response message will end up. If you send the response back to the QMgr in the ReplytoQmgr field in MQMD of the request, it will always go to the same queue manager from where the request originated.
Cheers, |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Aug 20, 2012 6:51 am Post subject: Re: Asynchronous web service call (with Websphere MQ) |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Santosh_Ghalsasi wrote: |
| Please let me know if anything can be done so that the reply should land back on the broker from which the request has been sent. |
Yes. Fix the external application described in step 6 so that it routes the reply correctly rather than just dumping the reply into the cluster & crossing it's fingers.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Santosh_Ghalsasi |
| Posted: Wed Aug 22, 2012 1:33 am Post subject: |
|
|
Novice
Joined: 01 Feb 2011
Posts: 19
|
Hi,
External Application cannot put the message on specific queue manager queue. This part should not be touched(as per the requirement).
lancelotlinc - could you please explain how MQGet would make sure that message lands on the desired broker's queue manager from which the request was sent. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Aug 22, 2012 1:41 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Santosh_Ghalsasi wrote: |
Hi,
External Application cannot put the message on specific queue manager queue. This part should not be touched(as per the requirement). |
This part is defective, it is doing the wrong thing.
You can not solve this problem without changing how the reply message is sent.
| Santosh_Ghalsasi wrote: |
| lancelotlinc - could you please explain how MQGet would make sure that message lands on the desired broker's queue manager from which the request was sent. |
The only thing that can be done to make sure that the message lands on the desired broker's queue manager is to fix the defective component that is sending the message incorrectly. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Aug 22, 2012 2:49 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
| Santosh_Ghalsasi wrote: |
Hi,
External Application cannot put the message on specific queue manager queue. This part should not be touched(as per the requirement). |
This part is defective, it is doing the wrong thing. |
The requirement to put messages across the cluster rather than replying to the requestor is flawed, i.e. it doesn't work. Is this actually a requirement, or is it simply that the application is external and changing it's behaviour will cost money?
| Santosh_Ghalsasi wrote: |
| lancelotlinc - could you please explain how MQGet would make sure that message lands on the desired broker's queue manager from which the request was sent. |
I'll be interested in that answer.... 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Wed Aug 22, 2012 5:06 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
MQGet with wait by CorrelId and using reply-to-queue / reply-to-queue-manager. When the replying application sends the reply, it will address the reply to the correct queue manager and the correct reply-to-queue. I'm surprised Vitor didn't know this.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Aug 22, 2012 5:10 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lancelotlinc wrote: |
| MQGet with wait by CorrelId and using reply-to-queue / reply-to-queue-manager. When the replying application sends the reply, it will address the reply to the correct queue manager and the correct reply-to-queue. I'm surprised Vitor didn't know this. |
I did know that. The point of the OP's post is that in point 6 it's clearly stated that the replying application doesn't address the reply to the correct queue manager but puts it to the cluster. The solution @mqjeff & myself was proposing was to fix that & make it work as you suggest above.
Your original response, which the OP wanted explained, was that you could use an MQGet node to intercept the responses as they moved across the cluster. I was interested in how you thought this could be achieved.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Wed Aug 22, 2012 12:44 pm Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
Another creative solution would be combination of QALIAS and QREMOTE in which the application would not have to change. You create a QALIAS pointing to a QREMOTE that always sends the replies back to the same QMGR. The downside to this would be limiting the originating traffic to just one broker.
So this suggestion is not the optimized solution, but it lets you implement the needed functionality without code changes to the replying application's source code.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Aug 22, 2012 12:50 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lancelotlinc wrote: |
| The downside to this would be limiting the originating traffic to just one broker. |
That's some downside...
| lancelotlinc wrote: |
| So this suggestion is not the optimized solution, but it lets you implement the needed functionality without code changes to the replying application's source code. |
You could achieve the same effect without any QALIAS or QREMOTE. Just use one broker to originate traffic, remove the other broker's "reply" queue from the cluster and all the responses will flow back to it.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
