I am trying to PUT (i.e. send) a message to a queue using a PUT MSMQ Adapter Service.
Fine. It works.
But I cannot figure out how to specify the ResponseQueue property for the message. It does not show up as an Property in the Input Message Property tab (which is where I would expect to see it).
I am very worried that for some reason web methods have not supported this very essential and basic feature of MSMQ. Without it we are rather… screwed! It’s kind of a fundamental feature of messaging… the request/response pattern? Need to tell it where to send the responses?
Oh well. Fingers crossed there is a way to do this.
In request/response queue pattern, the response would come in a different queue. Your receiving application would return any response to a different queue for your WM application to pick-up. We use IBM MQ and that is how we have it set up. All output msgs from WM application puts to queue A for receiving application. Receiving application picks up from queue A and returns any response msg to WM application in queue B. WM application picks the response msg from queue B. If you don’t have different queues for this purposes, your sending/receiving applications will not know if it is receiving or sending the msg (source or target).
We have different queues for the purpose of send/receive -that is basic.
BUT, the point is that there is no way to set up the “address” of where to send the response message on the request message. Not via the MSMQ Adapter anyway.
We cannot implement the request/response pattern unless we can set the return address (i.e. the path to the response queue that wm will listen on) on the outbound request message.
The capability is there in MSMQ to set the response queue on the message - the field is called ResponseQueue.
The problem is it is not exposed by the wm adapter, so I cannot set this property.
THEREFORE my service which is listening for requests, can process the request happily, but it cannot know where to send the response.
Are you saying your “receiving application” is hardcoded to return all responses to the same queue “B”?
That is no good for us - we need a generic solution, whereby the “receiving application” (i.e. the service which uses MSMQ to receive requests) does not know where to send the responses until it looks at the request message which itself contains the return path.
A bit like putting a sender address on a postal letter.
You may see a null response if your adapter service times out. Check the timeout parameter of your adapter service. If the target application is taking longer than that amount of time to place the response on the reply queue, then that could explain why you’re seeing a null response.
I’m not familiar with the details of your process so I can’t tell you whether that is an appropriate timeout value or not. When you run it, does it take 60 seconds before you see the null response? If so, then you probably want to get together with the developers/admins of the target application to understand why the response is not coming back in a timely fashion.