This topic explains how to configure message proxies that send and receive messages over the JMS transport.

In this section:

JMS Prerequisites

JNDI

Queue Allocation

When traffic is exchanged over queues, we assume that a client application sends a request to a destination queue and that a server application receives the message from the queue. The server then sends a reply message onto a second queue for the client to receive. In this scenario, the message proxy serves as a "man-in-the-middle" between the client and the server, which requires two additional queues on the messaging provider in order to facilitate the mediation. Parasoft proxies receive messages from where the client places them, records the message contents (if recording is enabled), then puts the message on the queue where the server will receive it. Similarly, the server sends the message to a queue where the proxy picks it up, records it (if recording is enabled), and places it back on the queue where the client is expecting the reply response.

As a result, it is necessary to allocate two additional queues and either:

Adjust the client application to communicate over these two new queues (with the proxy connections configured for them).
Adjust the server application to use the two other queues.

Only one of the two application queues needs to be modified.

Specifying JMS Settings

Specify your JMS settings as follows:

In the Proxy Connection Settings dialog, choose JMS for Proxy Type.
Specify the JMS type (Queues/Point-to-Point or Topics/Publish-and-Subscribe).

If you are defining the connection settings in this panel (rather than referencing previously-defined global JMS settings as described in Using Global JMS Connections), enter JMS provider details in the Local Settings area. You can specify the Provider URL, Initial context class, and Connection factory (be sure to add the related jars to the classpath), as well as authentication and any additional initial context JNDI properties you want to apply.

SOAtest and Virtualize 2020.2 > JMS Configuration > Provider.png

Using multiple JMS connections in a single proxy

If you want to configure connections to different JMS servers within a single proxy (e.g., you want a specific proxy connection use two queues that are deployed on two different JMS servers), create a global JMS connection for each connection, then select the appropriate connections as you configure the proxy.

Specify the connection details. You can either enter the settings for each connection in this panel (via the Local Settings option) or reference a global JMS connection defined at the server level.
- For Queues (Point-to-Point):Virtualize or SOAtest will capture messages sent to the client Destination queue and forward them to the server Reply to queue for processing. The server Destination queue is the queue that the server will place a response message on (after processing the request message). Virtualize will capture these messages and forward them to the client Reply to queue.
  Queue Configuration Details
  See Configuring Queues For Recording for tips on how to configure recording in different scenarios.
- For Topics (Publish-and-Subscribe): Virtualize or SOAtest monitors incoming requests on the client Subscribe topic and outgoing responses on the server Publish topic.
Modify the Use JMSReplyTo for Response setting if desired. It specifies whether to use the message's JMSReplyToQueueName header to determine where the proxy sends the response.
- If it is enabled, values from the incoming request will be used to determine where to send the response.
- If it is not enabled, the response will be sent to the queue specified in the UI; the values in the JMS message header will be ignored.
Modify the Worker count setting if desired.

Adjusting the Worker Count

Each worker creates its own connection to the JMS provider. Whenever a proxy is deployed/redeployed with a worker count that is higher than the default value of 1, you should see messages like "Started x listener(s)" in the Console (where x is the number of workers configured).

Increasing the worker count can help performance under concurrency. The entire message processing chain of the proxy is parallelized, so each worker thread will do message correlations, response message generation, etc. in parallel with other threads. However, beware that if you provide a high worker count, deploying/undeploying/redeploying a proxy will take longer because there are more connections to create/destroy. Also, it is possible that the JMS provider has a limit on how many concurrent connections to allow. You should not exceed what is configured/allowed by your infrastructure.

The worker count feature is equivalent to the “maxThreads” attribute in Tomcat server.xml.

To adjust the server.xml file:

Launch Virtualize and ensure that at least one responder has been created
Modify the server.xml file at <INSTALL>/plugins/com.parasoft.ptest.libs.web_<VERSION>/root/tomcat/conf/server.xml

When using a high number of concurrent virtual users (i.e., during a load test), you can usually expect better performance by increasing these values.

Using Global JMS Connections

Global JMS settings that apply across a specific SOAtest and Virtualize server can be defined at the server level and referenced in these settings. See Connections Tab for details.

To use a global JMS connection, select it from the appropriate Queue or Topic box.

SOAtest and Virtualize 2020.2 > JMS Configuration > myprovider.png

To review the details of a predefined global connection, click View settings.

Queue Configuration Tips

See Configuring Queues For Recording for tips on how to configure queues in different scenarios.