|HermesJMS is no longer developed. ReadyAPI 3.0 or earlier supports it only for backward compatibility.
ReadyAPI 3.1 or later does not support HermesJMS.
We strongly recommend that you use manual JMS configuration or create a JMS Connector plugin.
To use JMS virtual services via Hermes, you need to install and configure HermesJMS. You can install it from a standalone distribution package – see Installing HermesJMS for details.
HermesJMS supports many JMS providers. We recommend that you use it together with ActiveMQ or WebSphere. For complete information on installing and configuring HermesJMS and a provider, see JMS Support.
|Note:||It is convenient to call Hermes for configuration directly from within ReadyAPI: select the APIs node in the Navigator panel and, on the main menu, select Tools > HermesJMS.|
Add JMS routes
After you created a JMS virtual service, you need to add JMS routes to it. To do this, right-click the virtual service in the Navigator panel and select JMS Route.
In the subsequent dialog, select the Hermes tab and specify the HermesJMS configuration file, the JMS session and the JMS destination (topic or queue) that the virtual service will listen to:
Configure virtual service properties
General JMS Specifics
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!ExampleExample
Imagine you create a JMS Request test step that sends a message to the Topic1 destination and monitors the Queue1 destination for an answer.
Now imagine that you create a JMS virtual service with two virtual operations:
Operation A listens to Topic1 and replies to Queue1, and
Operation B listens to Queue1 and replies to Queue2.
So, we have two consumers subscribed to Queue1: the JMS Request test step and Operation B of your virtual service.
Now, if you start your JMS virtual service and run the JMS Request test step, the messages will be processed in the following order:
The test step will send a message to the Topic1 destination.
The service will receive this message and will reply to Queue1 (according to the Operation A settings).
Now the message at Queue1 can be read by Operation B or by the JMS Request test step. Each of them can be faster than the other.
If it is Operation B that captures the message from Queue1, then the test step will not receive the message. It will run in an infinite loop waiting for an answer at Queue1, and you might think your test has hung.
For each incoming request in your virtual service, you specify the JMS session and JMS topic (or queue), from which the service will receive that incoming request. These values should coincide with the sessions and topic (queue), to which your JMS Request will send a message.
For each response, you specify the JMS session and JMS topic (or queue), to which the service will send a response. These session and topic (or queue) should be the same as you specify in the “Receive/Subscribe destination” field of the endpoint.