{"id":10505,"date":"2023-04-24T20:31:13","date_gmt":"2023-04-25T00:31:13","guid":{"rendered":"https:\/\/www.redline13.com\/blog\/?p=10505"},"modified":"2023-06-22T14:15:23","modified_gmt":"2023-06-22T18:15:23","slug":"a-guide-to-jmeter-preprocessors-and-postprocessors","status":"publish","type":"post","link":"https:\/\/www.redline13.com\/blog\/2023\/04\/a-guide-to-jmeter-preprocessors-and-postprocessors\/","title":{"rendered":"A Guide to JMeter Preprocessors and Postprocessors"},"content":{"rendered":"

\"A<\/strong><\/p>\n

When building your JMeter test, samplers<\/a> provide the core functionality. They are responsible for sending the actual HTTP requests and handling those responses. However, as your test becomes more complex and sophisticated, it may be desirable to add conditional logic to your requests. Furthermore, you may wish to dynamically process the inputs and outputs to these. JMeter provides this functionality though a host of preprocessors<\/a> and postprocessors<\/a>. This brief post will serve as a guide to JMeter preprocessors and postprocessors, comparing and contrasting their use in JMeter test plans.<\/p>\n

<\/a>JMeter Preprocessors<\/h3>\n

Most of the available preprocessors are included with JMeter (though a few exist as plugins). These can be added to your test plan just like any other element as shown below:<\/p>\n

\"JMeter
JMeter preprocessors can be added from the list of available test plan elements.<\/em><\/figcaption><\/figure>\n

The key difference between a preprocessor and a postprocessor is when<\/em> your custom logic is executed. As the name suggests, a preprocessor runs before any requests existing at the same level in your test plan.<\/p>\n

For the purposes of illustration we will add a JSR223 preprocessor<\/em><\/a> to a sample test plan. This simple component allows us to specify a few lines of Java-based code to run before our requests. In our case, we\u2019ll define a simple test plan consisting of a single thread group, with an HTTP Request<\/em> element and our preprocessor. We will also add a View Results Tree<\/em> element so we can see the output:<\/p>\n

\"JMeter<\/p>\n

Our HTTP Request<\/em> element we will set up with the following parameters. For this request we will be accessing a Wikipedia page, with the specific article to be determined by the preprocessor.<\/p>\n

\"Configuration<\/p>\n

Note that the request path takes the form of https:\/\/en.wikipedia.org\/wiki\/${path_to_article}<\/code>, where the ${...}<\/code> notation is shorthand for the insertion of a JMeter variable which we will define in our script. We then set up the JSR223 Preprocessor<\/em> with the following script:<\/p>\n

import java.util.Random;<\/code>
\n<\/code><\/strong>String[] paths_to_articles = [\"Hydrogen\", \"Oxygen\", \"Water\"]<\/code>
\nRandom random = new Random();
\nint number = random.nextInt(3);<\/code>
\nvars.put(\"path_to_article\", paths_to_articles[number]);<\/code><\/p>\n

The variable paths_to_articles<\/code> is an array containing references to articles on Hydrogen<\/em>, Oxygen<\/em>, and Water<\/em>, respectively. These are intended to correspond to Wikipedia articles on these topics. The purpose of the random<\/code> variable is to select a topic at random each time the test is run.<\/p>\n

We can then run our test and view the results within the output area of the View Results Tree<\/em> element.<\/p>\n

\"Subsequent
Subsequent runs of our example test plan select Wikipedia articles at random.<\/em><\/figcaption><\/figure>\n

After multiple runs of our test, each of the possible endpoints are hit by the single HTTP Request<\/em> element. We can certainly get more sophisticated with our preprocessor and execute more complex pre-request logic, however the concept conveyed here would remain the same.<\/p>\n

<\/a>JMeter Postprocessors<\/h3>\n

As mentioned earlier, the differentiating feature of a JMeter Postprocessor<\/em> is that it runs after<\/em> any request elements at the same level within our test plan. This is useful in the case where we would like to take an action depending on the response from any such request. There is an equivalent JSR223 Postprocessor<\/em><\/a> to the above example that would allow us to run a script to analyze the response. However, a simpler and more practical example might be worth a look in the form of the Result Status Action Handler<\/em><\/a>. If our request fails for any reason due to an error, we might want to abort the test or take some other action. Below is an example of how we would configure the Result Status Action Handler<\/em> to do just that:<\/p>\n

\"Available
The Result Status Action Handler can be configured to take action when a test error is encountered.<\/em><\/figcaption><\/figure>\n

Trying to request a URL from Wikipedia that does not exist, our HTTP Request<\/em> element throws an error, with the following output in the logs:<\/p>\n

15:50:34,931 INFO o.a.j.e.StandardJMeterEngine: Notifying test listeners of end of test<\/code>
\n15:50:34,931 INFO o.a.j.g.u.JMeterMenuBar: setRunning(false, *local*)<\/code><\/p>\n

This indicates that the Result Status Action Handler<\/em> has ended the test as a result of this error.<\/p>\n

<\/a>Other JMeter Preprocessors and Postprocessors<\/h3>\n

JMeter comes with a rich selection of preprocessors and postprocessors. The complete listing of all of these components can be found in the component reference section of the JMeter User\u2019s Manual<\/a>, but here are a few selections that can be particularly useful in your JMeter tests:<\/p>\n

JMeter Preprocessors<\/strong><\/p>\n