| Author |
Message
|
| girish_tharwani |
 Posted: Mon Jan 19, 2009 12:03 am Post subject: HTTPInput and HTTPReply in separate flows ?? |
 |
|
Voyager
Joined: 01 Aug 2001
Posts: 88
Location: Pune, India
|
| I want to take a WS reqeust via HTTPInput node, do some transformation and pass it on a backend system for further processing. Backend system can read it from an MQ queue only. So I have to put the transformed request message on a queue. Backend system replies back in another queue. I need to pick it up, transform it and send it back to WS reqeustor via HTTPReply. Per documentation, HTTPInput and HTTPReply nodes need to be in same message flow. How do I achive it in this situation? Or did I misunderstand the documentation? |
|
| Back to top |
|
 |
| gregop |
| Posted: Mon Jan 19, 2009 12:46 am Post subject: |
|
|
Voyager
Joined: 24 Nov 2006
Posts: 81
|
You can use another flow for the HTTP Reply provided you can supply that flow with the original Request Id. Can you pass that to your backend system and have your backend system send it to your reply flow ?
http://publib.boulder.ibm.com/infocenter/wmbhelp/v6r0m0/index.jsp?topic=/com.ibm.etools.mft.doc/ak05100_.htm
Alternatively with a single flow you could receive the reply from the backend system via an MQGet, then make the HTTP reply. If you have lots of requests this could lead to a backlog while your flow waits for a response from the backend system. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jan 19, 2009 12:46 am Post subject: Re: HTTPInput and HTTPReply in separate flows ?? |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| girish_tharwani wrote: |
| How do I achive it in this situation? |
By reading the reply from the backend system out of the reply queue in the same flow?
I don't understand your question.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| gregop |
| Posted: Mon Jan 19, 2009 12:51 am Post subject: |
|
|
Voyager
Joined: 24 Nov 2006
Posts: 81
|
|
| Back to top |
|
|
| girish_tharwani |
| Posted: Mon Jan 19, 2009 1:24 am Post subject: |
|
|
Voyager
Joined: 01 Aug 2001
Posts: 88
Location: Pune, India
|
| Quote: |
| Alternatively with a single flow you could receive the reply from the backend system via an MQGet, then make the HTTP reply. If you have lots of requests this could lead to a backlog while your flow waits for a response from the backend system. |
While I was waiting to get some help from this forum, I read some docs on net and found this solution but did nto like it exactly for the reason you mentioned.
| Quote: |
| Can you pass that to your backend system and have your backend system send it to your reply flow ? |
Unfortunately, no. Stubborn legacy system, not ready to change  so I am thinking of setting up a state storage on the Qmgr with the help of MQMD message id and Correl ids. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Jan 19, 2009 5:06 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
The solution using an MQGet node is scalable, you just have to increase the number of additional instances of the flow.
Any other solution, possibly using a database or a shared row or etc. to store Request ID, that puts the HTTPReply in a second flow is going to require that there is some unique ID in the request to the backend that will be returned in it's reply, so you can retrieve the HTTPRequest.
And in any case, there is a fixed amount of time that a given request is going to take to process on the backend, and during that time the HTTP Request is going to be "stacked up" waiting for it's reply. There's nothing you can do to change that.
So the only load you are saving by splitting things across two flows is load on the broker itself, whether it has a half-finished copy of the Request flow open waiting for the reply or not.
And thank you for doing your own research while waiting for a response from this forum. |
|
| Back to top |
|
|
| broker_new |
| Posted: Mon Jan 19, 2009 5:38 am Post subject: |
|
|
Yatiri
Joined: 30 Nov 2006
Posts: 614
Location: Washington DC
|
think of using MQRFH2 header or correlationId(MQMD) and timernodes to timeout the message flow.
_________________
IBM ->Let's build a smarter planet |
|
| Back to top |
|
|
|
|
