In ServiceV, 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 ServiceV section. This section highlights specifics of creating and using JMS virtual clients in ServiceV.
In ServiceV, you create an empty JMS virtual service and then add JMS routes to it manually. A JMS route specifies:
the JMS server (if you use direct connection) or JMS session (if you use HermesJMS),
the JMS topic or queue.
Recording of JMS virtual services is not supported.
After you add a virtual service, configure the service as it is described in one of the topics below. ReadyAPI can work with virtual services by using the classes from the JMS provider or by using HermesJMS to establish a connection.
To send requests, you can use a JMS publisher application, or you can use the JMS Request test step in SoapUI.
Let’s see how you can do this with the JMS Request test step:
Switch to SoapUI, 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:
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.
Eventually, ReadyAPI will suggest starting HermesJMS:
Click “No” if you want to use a direct connection.
If you use HermesJMS, you can click “Yes” to configure it and create JMS objects (like sessions, topics and queues).
In this example, we will use a direct connection to a JMS server, so click No.
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:
This example shows how to configure a manual connection. To learn how to connect via HermesJMS, see HermesJMS Session.
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.
Click OK to create the endpoint.
You will see it in the JMS Request editor:
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 JMS Endpoint Types.
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.
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
Start the virtual service. You can do this for example, by clicking Run on the service editor toolbar. Also, see Running Virtual Services.
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:
Switch to SoapUI and run the JMS Request or run the test case. After the virtual service responds, you will see the response contents in the editor:
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:
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) and, if the service uses it, a JMS manager (like HermesJMS). For example, if you are going to run a JMS virtual service on VirtServer, you need to install ActiveMQ on the VirtServer computer.