| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Synchronous Request/Reply |
« View previous topic :: View next topic » |
| Author |
Message
|
| goffinf |
 Posted: Sun May 11, 2008 3:57 am Post subject: Synchronous Request/Reply |
 |
|
Chevalier
Joined: 05 Nov 2005
Posts: 401
|
MB: v6
I receive a inbound message via HTTP and the originating application needs to have a SYNCHRONOUS reply (I *could* change the protocol to MQ here since the message is sent via an ESB which supports either and will block and wait in either case).
Message Broker does a bunch of work connecting to a number of other applications, some of which are responsible for providing data for the reply message to the original caller. The arrangement of these apps is important. The critical part is this :-
Message Broker calls an application (it currently does so using HTTP, but again it could use MQ) that CANNOT send its response back synchronously (its a mainframe batch job). The batch job does its work and sends back a reply which it puts onto an MQ queue.
How do I connect up the synchronous request part of this processing to the asynchronous response part, that is, the flow is waiting (as is the original caller) for the data to be returned from the batch job, which takes [say] 10 seconds to complete its work.
Thanks
Fraser. |
|
| Back to top |
|
 |
| mgk |
| Posted: Sun May 11, 2008 5:52 am Post subject: |
|
|
Padawan
Joined: 31 Jul 2003
Posts: 1642
|
Look at the HTTP Nodes (WebServices) Sample that comes with the product in the samples gallery. It does exactly this...
_________________
MGK
The postings I make on this site are my own and don't necessarily represent IBM's positions, strategies or opinions. |
|
| Back to top |
|
|
| goffinf |
| Posted: Sun May 11, 2008 10:24 am Post subject: |
|
|
Chevalier
Joined: 05 Nov 2005
Posts: 401
|
| mgk wrote: |
| Look at the HTTP Nodes (WebServices) Sample that comes with the product in the samples gallery. It does exactly this... |
Thanks, indeed it does.
I would prefer to use an MQ Input (which provides a ReplyTo). Given the call to the back-end will be async and therefore needs to be handled in 2 separate flows, I assume I am going to have to store some state, such as the ReplyTo QMgr and QName ? (on MQ using a correlId ?) and then when the response arrives, retrieve it using MQGet (same correlId), and that I need to pass the correlId through to the back-end and ensure that it passes it back in the message ??
Does that sound about right ??
Fraser. |
|
| Back to top |
|
|
| elvis_gn |
| Posted: Sun May 11, 2008 6:29 pm Post subject: |
|
|
Padawan
Joined: 08 Oct 2004
Posts: 1905
Location: Dubai
|
Hi goffinf,
| goffinf wrote: |
| I would prefer to use an MQ Input (which provides a ReplyTo). Given the call to the back-end will be async and therefore needs to be handled in 2 separate flows, I assume I am going to have to store some state, such as the ReplyTo QMgr and QName ? (on MQ using a correlId ?) and then when the response arrives, retrieve it using MQGet (same correlId), and that I need to pass the correlId through to the back-end and ensure that it passes it back in the message ?? |
You don't even need to use MQGet, if you do, your flow is still stuck on that one message and cannot process anymore requests.
Rather, send the state to the backend, let the backend reply on your expected queue and you deliver the same (using your state) to the original requester.
Regards. |
|
| Back to top |
|
|
| goffinf |
| Posted: Mon May 12, 2008 3:41 am Post subject: |
|
|
Chevalier
Joined: 05 Nov 2005
Posts: 401
|
| elvis_gn wrote: |
| You don't even need to use MQGet, if you do, your flow is still stuck on that one message and cannot process anymore requests. |
How so ??. I was only proposing using an MQGet (in a separate message flow) when the message from the back end arrives and just to retrieve any data that I need to create the response to the original caller (including the ReplyTo QMgr/QName). I PUT the data into this [state] queue in the request flow (using a correlId that I pass to the back-end and expect it to pass me back later). Am I mis-understanding something ??
| elvis_gn wrote: |
| Rather, send the state to the backend, let the backend reply on your expected queue and you deliver the same (using your state) to the original requester. |
I assumed I had to send the correlation ID I used to store MY state in the request flow, to the back-end and have it return it to me (we already have a standard mechanism for passing message IDs around). Otherwise I wouldn't be able to correlate the original request to the [async] response right ?
Cheers
Fraser. |
|
| Back to top |
|
|
| elvis_gn |
| Posted: Mon May 12, 2008 10:58 am Post subject: |
|
|
Padawan
Joined: 08 Oct 2004
Posts: 1905
Location: Dubai
|
Hi goffinf,
Send the state to the backend in the rfh2 header, then you don't need to store a state in a temporary queue, and don't have to bother clearing and reading from that queue.
Let the backend return the rfh2 header to you, use that to get the requestor's message id and copy that back to the correlId for the final response.
Afcourse everything here depends on whether ur backend system can handle rfh2 headers.
Regards. |
|
| 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
|
|
|
|
