Introduction to Service Virtualization Messaging

Service virtualization for IBM MQ involves simulating the behavior of IBM MQ components (e.g., queue managers, queues, channels) to mimic real-world scenarios for testing, development, or integration purposes. This is particularly useful when the actual IBM MQ infrastructure is unavailable, too costly, or impractical to use during development or testing phases.

BlazeMeter can mock different protocols within the same Service Virtualization environment; this article shows how to virtualize message queue (MQ) transactions. If your application under test does not rely on a MQ, use the standard HTTP Runner instead of the Messaging Runner described in this article.

With BlazeMeter Service Virtualization, your application under test does not need to communicate through the live message broker during the test. A Messaging Runner virtual service gives you deterministic control over requests and responses and their timings. You attach message recordings to virtual services just as you attach transactions.

This feature is currently accessible to a subset of enterprise customers. If you are an enterprise customer and are interested in accessing this feature before GA, contact support-blazemeter@perforce.com.

On this page:

Supported Features
Terminology
Filter virtual services by type
Prerequisites

Supported features

To run automated tests against applications that rely on MQs, you can choose to virtualize the messaging. BlazeMeter Service Virtualization supports recording IBM WebSphere MQ version 9.x. For more information on configuring the Messaging Runner in BlazeMeter, see Virtualizing Message Queues.

BlazeMeter supports the following messaging architectures:

Point-to-Point
Publish-Subscribe
Request-Reply

Point-to-Point

Description: App A, the producer, sends a message to a Queue with the destination App B, the Consumer. App B receives the message from the Queue. If App B is offline, the Queue holds the message until App B comes online. No other App can receive this message.

How Virtualization works: You virtualize App A, the producer, which injects messages into the Queue with messages intended for App B, the consumer. You virtualize App A in this case through Message Recordings.

Real world example: Hotel room reservation. A customer requests a room by filling in all his requirements via a web page or mobile app. The customer submits the request to a Booking Queue which sends it to the Reservation app which does the reservation processing and the next steps, like email confirmation, etc. Once done, the message is removed from the Booking Queue.

Publish-Subscribe

Description: App A, the publisher, sends a message to a Topic. The Subscriber apps, App B and App C, have subscribed to the Topic. Both the App B and App C receive a copy of the message from the Topic.

How Virtualization works: You virtualize App A, the publisher, which injects messages into the Topic that are intended for any apps that have subscribed (App B and App C in this case). You virtualize App A in this case through Message Recordings.

Real world example: The NASDAQ data feed service acts as a publisher and generates live trading data and publishes the data to a Topic. Subscribers like Investment Banks, Retail trading platforms, etc. subscribe to this Topic and receive the messages.

Request-Reply

Description: App A, the Requester, sends a message to a specific Request Queue. The Responder, App B, receives the message and acknowledges it on a specific Reply Queue. The response is then received by App A.

How Virtualization works: You virtualize, App A, the Requester, which sends a message into the Request Queue for App B. You can also virtualize App B, the Responder, which sends back the reply on the Reply Queue for App A. You can virtualize both Apps in this case by using Message Transactions.

Real world example: A customer puts in a request for loan approval. The customer-facing app gathers customer details and sends that message to a request Queue which sends the message to the loan approval app. The loan approval app puts that response (whether the loan is approved or denied) on the response queue. The customer-facing app listens and receives the response, processes it, and displays it to the customer via the UI, email, SMS, etc.

Terminology

In BlazeMeter, a messaging transaction consists of requests and responses:

A messaging request is a collection of matchers for the inbound message.
A messaging response is a Reply JMS message defined by its type, content, headers, properties, and think time.

In BlazeMeter, Flow configurations store one-to-many mappings that connect your inbound destinations with a list of one or multiple outbound destinations. Each transaction associated with the Messaging Runner must have an assigned flow configuration.

Message Recordings

In BlazeMeter, recordings are stored in the Asset Catalog. Each recording consists of an ordered list of recorded messages. Just as for transactions, the parent for the recording is a Service. Just like transactions, recordings can be tagged.

You can create and edit messages manually, or record them using the Messaging Recorder integrated into the Messaging virtual service runner. A message represents a single JMS message and includes content, headers, properties, a recorded-at timestamp, correlation ID, index, destination, and destination type (queue or topic). When needed, you can convert a recording into a transaction.

For more information on Message Recordings, see Virtualizing Message Recordings.

Filter virtual services by type

To find your existing Messaging-enabled services, you can filter all your virtual services by type.
In the top of the Service Virtualization > page, select one of the following filters:

HTTP - to see only HTTP Runner virtual services
Messaging - to see only Messaging Runner services

Prerequisites

This procedure requires you to set up the following services:

your message broker and MQ
a BlazeMeter Private Location for Service Virtualization on Docker configured with the IBM driver

In BlazeMeter, you will create the following:

Message Recordings in the Asset Catalog
A virtual service containing a Messaging Runner that replays the recordings

Setting Up the BlazeMeter Agent for the IBM MQ9 Virtual Service

Visit the Maven Central Repository at https://mvnrepository.com/artifact/com.ibm.mq/com.ibm.mq.allclient/9.4.2.0.
Download the com.ibm.mq.allclient.jar library.
Copy the com.ibm.mq.allclient.jar file to a directory on your virtual machine, for example:
```
/tmp/ibm-driver
```
Next, follow the steps 1-7 outlined in Installing a BlazeMeter Agent for Docker.

BlazeMeter generates a Docker installation command.
Copy the command and modify it.
1. Add a new environment variable to the command:
```
-env VIRTUAL_SERVICE_ADDITIONAL_JARS=/usr/blazemeter/virtual-service/additional-jars
```
2. Include a new volume definition:
```
-v /tmp/ibm-driver:/usr/blazemeter/virtual-service/additional-jars
```
  In this definition, the first part should be the directory containing the driver JAR, while the second part should match the value of your environment variable.

This will result in the following Docker installation command:

docker run -d --env HARBOR_ID=<HARBOR_ID> --env SHIP_ID=<SHIP_ID>
--env AUTH_TOKEN=<TOKEN> --env DOCKER_PORT_RANGE=6000-7000
--env A_ENVIRONMENT=https://dev-bzm.blazemeter.net
--env AUTO_UPDATE=false
--env VIRTUAL_SERVICE_ADDITIONAL_JARS=/usr/blazemeter/virtual-service/additional-jars
-u 0 --name=bzm-crane-67c99dd60f0f94da1c0b67a5
--restart=on-failure
-v /var/run/docker.sock:/var/run/docker.sock
-v /tmp/ibm-driver:/usr/blazemeter/virtual-service/additional-jars
-w /usr/src/app/
--net=host blazemeter/crane:latest python agent/agent.py