Configuring Connection via HermesJMS

Applies to ReadyAPI 3.9, last modified on July 16, 2021

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:

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

Click the image to enlarge it.

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!


HermesJMS specific

  • 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.

    JMS service virtualization and API testing: Destination properties of JMS incoming messages

    Click the image to enlarge it.

  • 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.

    JMS service virtualization and API testing: Destination properties of JMS outgoing messages

    Click the image to enlarge it.

See Also

JMS Virtual Services
JMS Support
Creating the Connector Plugin

Highlight search results