Service Virtualization Messaging FAQ

Does a virtual service with a messaging runner expose a port?

If the virtual service includes only a single enabled messaging runner, that does not have an Embedded Broker, it does not expose any port. The messaging runner with External Broker functions solely as a client for the broker.

Users can enable or disable both types of runners during runtime. The limitation is that the HTTP Runner always exposes a port.

Therefore, when you run a virtual service with a Messaging Runner and activate the HTTP Runner, restart the virtual service for the port to become available. Simply updating the virtual service is insufficient.

Similarly, to disable the HTTP Runner and fully unexpose the port, a complete restart of the virtual service is necessary. While disabling the HTTP Runner will render the runner URL inaccessible, the port itself will remain exposed.

Why am I experiencing issues with endpoint visibility when switching from an External Broker to an Embedded Broker?

This behavior is expected. Fully restart the virtual service to expose the endpoint of an embedded broker.

The same applies when switching back: Fully restart the virtual service to stop exposing the port.

Do HTTP Runners and Messaging Runners share the same dataset snapshot?

Yes, both runners operate on the same dataset snapshot. Any state update actions performed in one runner's transaction will be visible in the other runner's transaction.

How to enable two-way SSL for a single Runner without affecting the other?

To enable two-way SSL exclusively for the HTTP Runner:

  1. Select a keystore and truststore file in the shared SSL configuration.

  2. In the Messaging Runner's basic settings, disable the SSL authentication checkbox.

Conversely, to enable two-way SSL solely for the Messaging Runner:

  1. Select a keystore and truststore file in the shared SSL configuration.

  2. In the HTTP Runner's keystore settings, disable both the "Override Server Keystore" and "Override Server Truststore" checkboxes.

How to restart the recording replay?

The recording replay automatically restarts when there is an update to the virtual service. Any ongoing recording replays will be temporarily suspended during this process.

Can a virtual service with a Messaging Runner be deployed to a public location or a Kubernetes (k8s) environment?

No, a virtual service with the Messaging Runner enabled can only be deployed to a private Docker location. Additionally, the user's account must have the feature enableMockServicesMessaging activated.

Does the transaction count metric include transactions from the Messaging Runner?

The transaction count metric displayed on the main Service Virtualization page includes transactions from the Messaging Runner. Additionally, it includes each replayed message from a recording, contributing to the overall total.

Why did the recording converter ignore my recorded messages?

When you convert recordings into transactions, certain recorded messages are ignored. The recording converter is designed to convert only those messages that have correlation IDs assigned. Please ensure that your recorded message includes a specified correlation ID. You can set or update this ID manually as needed.

What happens if I assign a numeric value to a Boolean property?

Numeric values of Boolean properties are disregarded, and a warning will appear in the container log.

What happens if I use an unknown header?

If you employ an unknown or IBM-specific header in the message or transaction response of the IBM_MQ9_JMS protocol runner, this header is ignored.

How many requests per second can the Messaging Runner handle?

To assess the performance metrics of the Messaging Runner, it's essential to understand how many requests per second it can handle.

The performance of runners varies based on the protocol used. When using the IBM_MQ9_JMS protocol, the runners processed approximately 400 requests per second, while those using the IBM_MQ9_NATIVE protocol achieved around 760 requests per second.

To evaluate the performance, the following setup was implemented: Two virtual services were deployed in the same private location. A broker was configured to operate from an IBM developer docker image on the same network, utilizing two queues: Queue1 and Queue2. Each runner was assigned one transaction, matching a regex message body of any value: .*

The first runner read messages from Queue1 and forwarded the same messages to Queue2. Meanwhile, the second runner read messages from Queue2 and sent them back to Queue1. This configuration established a continuous communication loop between the two runners.

It's important to note that the performance metrics of the runners are heavily influenced by broker latency. For instance, when operating with a remote broker in the cloud and a Private Location on a local developer network, both protocols exhibited notably low performance, processing only about 6 requests per second.

What causes the discrepancy between the actual delay of replayed recorded message and the specified delay value?

Broker latency and specific client characteristics make it challenging to deliver messages with the exact specified delay. The Messaging Runner guarantees that messages are delivered in the proper sequence while using the designated delay value for scheduling the dispatch.

Which of the two messaging protocols IBM_MQ9_JMS and IBM_MQ9_NATIVE should I choose?

When deciding between the two protocols, IBM_MQ9_JMS and IBM_MQ9_NATIVE, consider that each protocol has its unique advantages and may be better suited for different scenarios:

The IBM_MQ9_JMS protocol is recommended in the following scenarios:

  • When a virtualized application uses standard JMS interfaces for communication

  • When the virtualized application uses JMS message types such as STREAM_MESSAGE, OBJECT_MESSAGE, and MAP_MESSAGE, which are not supported by the native implementation of MQ9

The IBM_MQ9_NATIVE protocol is highly recommended for the following scenarios:

  • When a virtualized application relies on MQ9 native interfaces for communication

  • When there is a need to match specific MQMD headers

  • When it is necessary to respond using specific MQMD headers