> My assumption is all 3 services should pick the request and send the response (2 invalid and 1 valid) and it is upto the client application to pick the right response using the correlation ID which is not happening.
>
> Not sure whether DevTest supports running multiple services on same req and response queues.
You can run multiple services listening on the same request queue. However, they do not share the same *listener*. Each one has its own connection to the queue. Unless you are using message selectors to control which service receives which request, then the particular listener that receives each request message is up to the JMS provider, and only that listener will receive it. The only way around this without using message selectors is to use a Topic instead of a Queue. Depending on the version of MQ you're using some level of support for Topics may be present, but I've never actually gotten it to work.
> based on the transaction name
Is this transaction name stored in the message body, or is it in a message header or custom property that you can access with a message selector? If it's in a property then we can support that now. You will have to build a JMS Consumer asset with an appropriate message selector for each of your services and make sure it's selected in the 'JMS Consumer' field in each of your VSM's Listen steps.
If your transaction name is in the body then we don't currently support doing filtering based on that from the VSE Listen step. We support that kind of thing in a client context as a correlation scheme; when a request is sent from the Send Receive step you can filter on some part of the response body when receiving the response. However, there's currently no way to take just the filtering part of that and use it from the VSE Listen step.
> What I even further tried is, in the listen step, I have captured the "lisa.jms.Recv.HeaderMap.JMSMessageID" and stored it in a property and in the java step, where I'm setting the transient response, I have added this message ID to "lisa.jms.Send.HeaderMap.JMSCorrelationID" in the meta data.
> Not sure where I'm doing wrong. Can anyone throw some light incase if you have worked on similar requirement earlier.
I think the meta-data property you have to set is called 'msg.correlationid', not 'lisa.jms.Send.HeaderMap.JMSCorrelationID'. However, there's a better way that doesn't bypass the correlation scheme on the Respond step.
It's tough to tell from just your screenshot, but I'm pretty sure the Send Receive step in between your Listen and Respond steps is overwriting a testExec property that the Respond step needs in order to successfully operate its correlation scheme. That property is 'LASTRESPONSEPAYLOAD'. Try this:
1. Add a filter to your 'Listen' step that copies 'LASTRESPONSEPAYLOAD' to some other property, like 'LASTRESPONSEPAYLOAD_COPY'.
2. Add a filter to your 'Send Receive' step that copies 'LASTRESPONSEPAYLOAD_COPY' back to 'LASTRESPONSEPAYLOAD'.