The requirement here is to pick messages only intended for the virtual service in a shared MQ queue. How can we implement it without disrupting the other application messages.
The first question you should be asking the customer is: How do the *other* services listening on this "shared queue" separate which requests are meant for which service?
With IBM MQ Native mode, when you start a listener on a queue you can specify a filter. However, you can only use a small subset of the IBM MQ message headers in your filtering, and you can only filter on their exact values. The filterable headers are:
- Correlation ID (used for matching requests to responses)
- Message ID (usually generated and unique for each message)
- Group ID (used for grouping messages)
- Sequence Number (used for grouping messages)
- Offset (used for segmenting messages)
- Accounting Token (purely internal identifier generated for each message)
Note that none of these are intended for functionally separating different applications. Unless they are hijacking one of these fields for the purposes of separating their various services, my guess is that they are actually only running a single listener on that queue and it's doing some internal routing after receiving each message. If that's the case then that's not actually "shared" in a way that LISA can participate. If they *are*, however, hijacking one of the above fields then the new IBM MQ Native protocol in 8.5 will let you do the same kind of filtering. However, your options with the old IBM MQ protocol in 7.5 are much more limited.
With IBM MQ JMS mode it's a different story, if you're using a new enough version of IBM MQ. With JMS mode your listener can filter on custom message properties that mean whatever you want. Again, however, your options for doing that filtering in the old JMS/MQ VSE protocols are much more limited, but 7.5.1 should contain the new JMS protocol which greatly expands the ability to specify filters in the VSE recorder and at playback time.
If there is messageId/correlationId properties associated with the messages in the queue then you can use that to read the specific messages that matches the messageId/CorrelationId.
As rightly directed by Kevin & Udhaya, we can take advantage of the message mapping. Say for Eg : If it is Message ID to Correlation ID - which is for most of the scenarios, Generate/Put an ID in MQ PUBLISH Step Message Properties option in the message id field and Subscribe using the same ID in correlation ID field in MQ SUBSCRIBE step.
Any Identifier can be used in Message Properties in MQ Steps and the same can be obtained from the queue. These are just passed along with the message as Header info.
Hope this Helps man !
So correlation schemes are useful for a separating *responses* on shared response queue. However, the way the original poster words it implies that there is a shared *request* queue, which is a very different problem.
JMS provides a message selector (Oracle docs at JMS Message Selectors (The Java EE 6 Tutorial) ).
The old Sonic connection had a 'Selector Query' tab. I haven't checked to see if the standard JMS connection step provides this.
JMS has message selectors, and both the old and new JMS steps expose it (in different ways), and the new JMS VSE protocol exposes it in a way that can be used from the VSE recorder.
However, two questions still need to be answered by the original poster:
1. Does the IBM MQ service being virtualized use JMS Mode or Native mode? The answer to this determines what kind of filtering a message consumer can do. Native Mode does not have message selectors.
2. Is the "shared queue" the request queue or the response queue? A shared response queue can be solved by a correlation scheme, but a shared request queue is a very different problem.
Retrieving data ...