Setting multiple Virtual Services to listen on the same queue and consume specific messages
search cancel

Setting multiple Virtual Services to listen on the same queue and consume specific messages

book

Article ID: 117035

calendar_today

Updated On:

Products

Service Virtualization

Issue/Introduction

A messaging VSM usually listen to one queue and consume the messages available in that queue.

The JMS consumer can be used to define a message selector and specify which messages one specific VSM will consume.

However, the JMS message selector only works against message headers, so in case the uniqueness in the message is embedded inside the message payload the JMS Consumer will not help.

How to set multiple Virtual Services to listen on the same queue and consume specific messages, not all available messages?

Environment

All supported DevTest releases.

Cause

N/A

Resolution

Since the piece of uniqueness is in the message and not in the header, its possible to have a virtual service that will consume all the messages and based on the payload request, add a header to the message and publish this modified message to a second queue.

In this second queue, a different VSM using Message Selector would be able to consume the correct message.


Here are the steps:


1. Create a JMS VSM - let's call it the Proxy VSM.

The Proxy VSM will be listening in one queue, ProxyQ, and will consume any messages available in the ProxyQ.

In this virtual service you will need to be able to identify what is the incoming request to add the proper header to the message.

In this example, we used the Data Protocol Filters (DPH) to consider just the argument that contains the value we are interested.

The VSI response, in this case, will be the incoming request body, you can modify the SI response body to use a property that contains the incoming request.

Example, you can use the Request Data Copier to save the lisa.vse.request to a property - requestBody:



and use the {{requestBody}} property in the SI response:




In the VSI response header add the key 'msg.props.id' and the value needs to be the something that identifies this payload.




The response queue needs to be a different queue, let's call it LiveQ.

All the responses from the Proxy VSM will be published to the LiveQ, but this time the messages will contain a header id that identifies each message.


You can verify the message headers in the LiveQ by using a JMS Send Receive step.

After the Proxy VSM publishes the message to the LiveQ, configure the JMS step to consume the message from LiveQ.

Enable the JMS Receive and select the Receive Destination as the LiveQ.

Execute the step by selecting the green arrow icon at the top of the step.

When you receive the response, select the Open Viewer under Custom Properties.

A list of Custom Properties will open and you will be able to see the "id" key with the value specified, "myValue" in this case.




2. Now we can create multiple VSMs with different Message Selector to consume the messages available in the LiveQ.

While creating the VSM, in the 'Proxy Request' side select the gear icon - Edit advanced parameters.

In the new window, under JMS Consumer select the plus icon and JMS Consumer.




Under Message Selector specify id='your header value'. The value is between quotes because it is a string.




Select OK and continue with the recording process.

When the VSM is created, you will be able to see the JMS Consumer under the Listen step.




With these two virtual services, you should be able to consume all the messages from ProxyQ, add headers to the messages to identify each one of them and publish them to the LiveQ.

In the LiveQ, you can have multiple virtual services, with Message Selector configured, listening and consuming the messages that match each message selector.