The message flow reads the request from the 'Input queue 1', uses a MQOutput to forward it to 'Receiver queue', waits for the Service which responds to 'Input queue 2' and forwards the message back to the Consumer's ReplyToQueue.
As far as I know it's recommended (performance reasons) to use 2 message flows. One to move the request from the consumer to the service and one to move the reply from the service to the consumer. I'm having problems with these because the ReplyToQueue can vary and therefore the second message flow doesn't know the right queue.
However, since performance is not really an issue, I would like to know if it wouldn't be possible and probably easier to combine both message flows to one.
Joined: 10 Feb 2003 Posts: 6076 Location: Somewhere over the Rainbow this side of Never-never land.
Remember that the flow will essentially be blocked from handling other messages while it is waiting for the reply unless you configure the flow to have extra instances.
This is a common problem and can be solved in many ways including saving the ReplyToQueue in a db table, shared variables etc.
Using a MQGet node to wait for the reply may require some tricky setup so that you give the MQGet node long enough before it times out but not too long so that other traffic is blocked for long periods.
If I were writting this flow, I wouldn't use the MQGet node in this way unless I was sure that the message rate was sufficiently low that I could guarantee that other requests would not get blocked. _________________ WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions.
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