Creating a JMS Application Emulator with JMeter

On Habré, there was already a publication devoted to load testing of speakers, interacting via JMS using JMeter. It describes the use of JMeter as a source of load, an external system that initiates a business process in our (tested) system. But what if the process is initiated inside our system, it sends requests to the external system and waits for a response (that is, we need the external system stub)?

We had to find the answer to this question during one of the load testing projects.

At that time, we saw two solutions:

1. Writing your own JMS application that implements the simple logic necessary for testing;
2. Using JMeter.

The first way promised uncertain labor costs (albeit relatively small) due to the fact that there was no experience in creating JMS applications (even simple ones).
Given the fact that there was some experience with JMeter, thanks to elements like Aggregate Report, you can monitor the work of a future stub in real time, it was decided to stop at the second option.

The first step was formulated requirements for our stub:

1. Read the message from the queue;
2. Retrieve the CorrelationId and business data from it to select and send the appropriate response;
3. Wait a certain time (for the emulation of the delay in response from the external system);
4. Send a suitable response with some dynamic data.

')
The initial configuration of JMeter is identical to that described in the publication “Automated testing of services using the MQ protocol using JMeter” , except that JMeter Plugins (specifically, Dummy Sampler for debugging) were also used.

As a Thread Group, the test plan was fairly standard (no special regulation of the number of threads during operation was required).

Next, add the JMS Subscriber, which is responsible for reading the message from the queue. The figure below shows the Subscriber settings.



After reading the message from the queue using the View Result Tree, you can see its properties. An example of the properties of a message being read from the queue is shown below:



To retrieve the JMSCorrelationID (one of the message properties that will allow the queue manager and the application under test to understand which request the message sent by the stub is a response) and business dates (in our case, the value of one of the XML fields of the request that will allow you to select the appropriate answer) Regular Expression Extractor (example of use in the figure below):



Due to the fact that, according to the NT method, the response delay from the external system was fixed, for its emulation Constant Timer was used (see below), creating a fixed delay between successive requests. If you need a variable delay during your tests, we recommend that you look at any of the Random Timers.



Now, based on the read message, we can choose the appropriate answer. To do this, use the switch controller:



To send a response to the request inside the Switch controller, we enclose the JMS Publisher samplers with the names corresponding to the possible values ​​of the variable p_destination (which was extracted by a regular expression from the Subscriber).

Inside the body (Text Message area) of JMS Publisher samplers we add dynamic data using JMeter variables (for example, timestamp, etc.).

In the JMS Properties area of ​​the JMS Publisher samplers, add the JMSCorrelationId with the ID value: $ {corrId}.



To analyze the statistics of the work, you can add the Aggregate Report, which allows you to analyze the statistics of the stub in terms of the number of received and sent messages.

To summarize, let us once again dwell on the advantages of creating a JMS stub using JMeter compared to self-development:

1. Fewer opportunities to shoot yourself in the foot (the amount of code you need to write is minimized, most of the logic can be implemented using JMeter elements);
2. There is a graphical interface and Listener for collecting statistics on the work of the stub, which is not necessary to fasten to the stub yourself;
3. No need to install any additional software to deploy the stub (Tomcat or Glassfish);
4. Startup convenience (runs as a normal JMeter test).