JMS Virtual Services

Applies to ReadyAPI 3.10, last modified on November 23, 2021

In ReadyAPI, you can create virtual services that emulate behavior of real JMS clients that act like both subscribers and publishers. For detailed information on how to perform this or that action, see topics of the APIs (Virtual) section. This section highlights specifics of creating and using JMS virtual clients in ReadyAPI.

Create JMS virtual services

In ReadyAPI, you create an empty JMS virtual service and then add JMS routes to it manually. A JMS route specifies:

  • the JMS server,

  • the JMS topic or queue.

Recording of JMS virtual services is not supported.

Configure Connection

To add JMS routes to an existing virtual service, right-click the virtual service in the Navigator panel and select JMS Route.

JMS service virtualization and API testing: Adding a new JMS route to a JMS virtual service manually

Click the image to enlarge it.

Option Description
JMS Server Select one of the JMS servers specified in the JMS dialog or select Create New to create a new JMS server.
Receive Destination JNDI Name The name of the topic or queue that ReadyAPI emulates.
Requests to it will be redirected to the virtual service.
Send Destination JNDI Name The name of the topic or queue ReadyAPI sends the response to. It can also be configured in the response editor.
  • Do not use the same topic (queue) for the request and its response. This may cause an infinite loop: after sending the outgoing message to the topic (or queue), the virtual service will recognize it as an incoming request and will process a reply, and the loop can repeat again and again.

  • Also, remember that in JMS, multiple consumers can subscribe to the same destination. In this case, the destination type – topic or queue – comes into play and specifies how messages are processed:

    • A message that comes to a destination of the topic type can be read by all consumers subscribed to this destination.

    • A message that comes to a queue destination will be read only by one consumer, the other subscribers will not receive it.

    When virtualizing JMS services, it is quite easy to create two or more consumers of the same queue destination. This might cause issues during testing, because your test will not receive answers to some messages. The JMS Request test step can run in an infinite waiting loop and you might think that your test has hung (see the example below). Be aware!

    Example

  • You can configure each response individually to use the ReplyTo value from the incoming request or the destination configured manually. ReadyAPI can send responses to a different queue or a different JMS server. For more information about connection options, see the JMS Response Properties topic.

  • If necessary, you can use the Start script to dynamically configure JMS connection properties. To do this, you call the ConnectionFactoryProducer() method and provide the required closures. This method should create, configure and return an instance of the ActiveMQConnectionFactory class.The scripts can use the following closures:

    Callback Name Required Parameters The Callback Returns
    contextProducer JmsConnectionConfiguration, Properties An InitialContext that you use to create the JMS connection.
    connectionFactoryProducer InitialContext A ConnectionFactory object that you use in your script.
    connectionProducer ConnectionFactory A JMS Connection object that you use to create the session.
    sessionProducer javax.jms.Connection A JMS Session object that you use in your script.
    destinationProducer javax.jms.Session, String A Destination object that specifies the JMS endpoint you send requests to.

    Here is a sample script that creates a connection to Apache ActiveMQ Artemis by using the above closures:

    Show Example

Send requests

To send requests, you can use a JMS publisher application, or you can use the JMS Request test step.

1. Configure the test step

Let’s see how you can do this with the JMS Request test step:

  1. Create a test suite and a test case (or open an existing test case for editing) and click JMS Request on the toolbar. ReadyAPI will ask you to enter the test step name and then will ask what interface type to use for the JMS request being created. This information is needed for selecting the request editor UI. Select any value you want:

    JMS service virtualization and API testing: Create a JMS request in SoapUI

    Click the image to enlarge it.

  2. Go through the subsequent dialogs that ReadyAPI uses for adding REST or SOAP requests. You can leave default settings in them. For instance, if you selected the REST interface, ReadyAPI will ask you about selecting the REST request. You can choose any value in that dialog.

  3. On the next step, ReadyAPI asks you to specify the endpoint for the request. For JMS virtual services, the endpoint means the JMS server (or JMS session) and topic or queue that the request will use for communication:

    JMS service virtualization and API testing: Add JMS Endpoint dialog

    Click the image to enlarge it.

    Parameter Description
    JMS Server

    Specifies the JMS server the test step will use. You can select the JMS server specified in the JMS dialog or create a new one.

    Send Destination JNDI Name

    The JMS topic or queue, where the JMS Request test step will post a message.

    Receive Destination JNDI Name

    The JMS topic or queue, where the JMS Request test step will wait for a response to the posted message.

    Note: We recommend using a different queue or topic than that you specified in the “Send Destination JNDI Name” field.

    Click OK to create the endpoint.

    You will see it in the JMS Request editor:

    JMS service virtualization and API testing: JMS Request editor

    Click the image to enlarge it.

    Note that only the endpoint matters. Other values like the resource path or method type are ignored.

    If needed, you can keep the “Send...” or “Receive...” edit box empty to create “send-only” or “receive-only” endpoints. See Setting Endpoints.

  4. Tip: After the test step sends a request, it will wait for a response message to appear in the JMS topic or queue set by the “Receive Destination JNDI Name” parameter. We recommend setting the maximum waiting time in the Timeout property of the JMS Request. This is needed to prevent endless request execution in case when the virtual service does not post a response. The timeout is set in milliseconds.

2. Start the JMS broker

Before sending requests to a JMS virtual service, you need to start the JMS broker on your computer. In this example, we are using ActiveMQ. You can start it from the command line:

<ActiveMQ folder>/bin/activemq.bat start

You can also configure and run ActiveMQ as a service every time the operating system starts. See Running ActiveMQ as a Service or ActiveMQ documentation.

3. Send a JMS request and check the results

  1. Start the virtual service. You can do this for example, by clicking Run on the service editor toolbar. Also, see Running Virtual Services.

    Service virtualization and API testing: Run a JMS virtual service

    If the service found the broker running, and if it detected the needed JMS sessions, topics and queue, the “connection” icons are black, otherwise, they are red:

    Service virtualization and API testing: Connection icons
  2. Run the JMS Request test step or the test case. After the virtual service responds, you will see the response contents in the editor:

    Service virtualization and API testing: Response contents

    Click the image to enlarge it.

Request and response dispatching

When a JMS virtual service receives a request, it starts searching for the matching virtual operation by comparing the JMS session and message destination with the session and destination set in the virtual operation properties. If the operation is found, the service uses dispatch settings to select a response for the reply. If the service has two operations that match the JMS session and destination, it will use the first found operation.

If the service fails to find an operation, it does not return anything. That is why we recommend setting a timeout for the JMS request (see above).

Tip: To simulate absence of responses from your JMS virtual service, select either the Query Match, XPath or the Script dispatch strategy, configure the strategy properties so that they do not return any response name, and select <None> in the Default Response box:

JMS virtual service: Simulating absence of responses

Click the image to enlarge it.

Run JMS virtual services

You can run JMS virtual services both on local and remote machines:

  • On local computers, you can run them from within ReadyAPI and from the command-line runner.

  • To run virtual services on remote machines, you need VirtServer there.

For complete information, see Running Virtual Services.

Important: To run a JMS virtual service on some computer, you need to install and configure a JMS provider (like ActiveMQ). For example, if you are going to run a JMS virtual service on VirtServer, you need to install ActiveMQ on the VirtServer computer.

View bytes messages

In the Transaction Log, you can view the contents of JMS bytes messages.

The HEX viewer

Click the image to enlarge it.

To open the editor, click Show hex viewer.

You can configure the editor, using the following options:

Option Description
View mode Specifies the view mode of the editor. Possible options:
  • Code — Raw representation of the message.
  • Text — ASCII representation of the message.
  • Dual — Includes both views, with the Code view on the left and the Text view on the right.
Encoding The encoding is used to view request and response messages.
Code Type How ReadyAPI should represent the message in the Code view.
  • Hexadecimal
  • Decimal
  • Octal
  • Binary

See Also

Virtual Service Specifics
JMS Support
Creating the Connector Plugin

Highlight search results