Correlating Dynamic Values in JMeter

Image from www.howtoliveit.co.uk

In previous posts I have covered:

If you’ll recall from that last post, the login script wasn’t working yet. The actual login request (i.e. the submission of the login credentials as a request to the server to initiate a logged-in session) was failing because we weren’t providing it with all of the information it needed.

1

In the Send Parameters With the Request section of the HTTP Request sampler, request login, above, we can see that there’s an AppActionToken that looks as though it’s been generated by the server, probably to uniquely identify the session. If we continue to scroll down the list of parameters, we’d see that there are a number of other tokens that are required in order to successfully login:

  • appActionToken = 1m8mf7N5vmsDvbmwR42h5gcGufAj3D
  • openid.pape.max_auth_age = ape:MA==
  • openid.ns = ape:aHR0cDovL3NwZWNzLm9wZW5pZC5uZXQvYXV0aC8yLjA=
  • openid.ns.pape = ape:aHR0cDovL3NwZWNzLm9wZW5pZC5uZXQvZXh0ZW5zaW9ucy9wYXBlLzEuMA==
  • prevRID = ape:MTFESk4zWkIwQzhSSjg5SlQ0SjA=
  • pageId = ape:Z2JmbGV4
  • openid.identity = ape:aHR0cDovL3NwZWNzLm9wZW5pZC5uZXQvYXV0aC8yLjAvaWRlbnRpZmllcl9zZWxlY3Q=
  • openid.claimed_id = ape:aHR0cDovL3NwZWNzLm9wZW5pZC5uZXQvYXV0aC8yLjAvaWRlbnRpZmllcl9zZWxlY3Q=
  • openid.mode = ape:Y2hlY2tpZF9zZXR1cA==
  • openid.assoc_handle = ape:Z2JmbGV4
  • openid.return_to =
  • ape:aHR0cHM6Ly93d3cuYW1hem9uLmNvLnVrL2dwL3lvdXJzdG9yZS9ob21lP2llPVVURjgmcmVmXz1uYXZfc2lnbmlu

In addition to the dynamic parameters, we also need to submit the username and password, which are currently hardcoded as can be seen below.

2

We could parameterise these also, but I’ll talk about that another time.

So how do we go about obtaining the correct values for these parameters, such that when we send them all, along with some valid login credentials, we get a logged-in session back from the server?

Well, the first thing is to figure out from whence they came. Experience has taught me that it’s usually (though by no means always) from the immediately preceding server response. So let’s go back to the results of our test and take a look:

3

The HTML response isn’t telling us much… We need to switch to text mode, and then take a look for the parameter name. Let’s start with the appActionToken parameter:

4

Voila! We’ve found the token, and the value. But if we run the test again, we’ll probably see a different one:

5

It’s a fair (in fact guaranteed) bet that we’ll find the rest of our parameters embedded within this response too.

So what we need to try and do is extract the parameters from the server response, each time we get one – and then pass it into the next request. Performance testers call this process correlation. JMeter provides us with the Regular Expression Extractor so that we can go ahead and correlate our parameters from one request/response to another.

The first step is to add a Regular Expression Extractor to the request login page HTTP Sampler, by right-clicking on it and then selecting Add > Post Processors > Regular Expression Extractor, thusly:

6

Next we need to write some Regex with which to extract the parameter.

If, like me, the idea of writing regex makes your toes curl with horror, don’t worry. I’ll share a special piece of JMeter goodness with you. It’s the only piece of regex I’ve ever really needed to know. And it goes like this:

(.+?)

Did you get that? I’ll repeat it just in case you missed it…

(.+?)

To use this regex and get the parameter we’re looking for, I reckon something like the string below should work:

name=”appActionToken” value=”(.+?)” /

Trying it out in the RegExp Tester view of the response, shows that it will indeed work, since the test came back with only one match:

7

The RegExp Tester shows me how many matches the regex pattern will create, what the match is, and the value to be extracted – 1, 2 & 3 below respectively:

  1. Match count: 1
  2. Match[1][0]=name=”appActionToken” value=”pmHS1gy9iYMSJOWBIPlCWZGq1SIj3D” /
  3. Match[1][1]=pmHS1gy9iYMSJOWBIPlCWZGq1SIj3D

What I’ve done here is, take the HTML response, and apply the simple bit of regex I described above, in order to capture only the string that we’re interested in.

<input type=”hidden” name=”appActionToken” value=”pmHS1gy9iYMSJOWBIPlCWZGq1SIj3D” /><input type=”hidden” name=”appAction” value=”SIGNIN” />

The “pmHS1gy9iYMSJOWBIPlCWZGq1SIj3D” bit, basically.

I’m not going to go into how the regex works, because that’s beyond the scope of this particular post. What we do need to do now is plug it into the regex extractor so that we can use it in the request login sampler.

Here’s how the finished extractor looks:

8

The important things to note are these:

  • I’ve given the Regular Expression Extractor a meaningful name – appActionToken Extractor
  • I’ve given the variable into which I want to put the extracted token a meaningful name (in the Reference Name field) – appActionToken
  • The regular Expression field contains our regex – name=”appActionToken” value=”(.+?)” /
  • The Template, Match No and Default Value fields are filled out more or less as per the Apache JMeter guide.

You can learn more about the Template, Match No and Default Value fields by reading through the online guide from Apache here. I’d recommend sticking with the defaults, but you may gain some mileage in experimenting with them.

Having extracted the value successfully and placed it in a JMeter variable, we now need to use the variable in the submit login sampler. We can do that by referencing the variable where the token was originally.

JMeter knows we want to use a variable when we place the name inside curly parenthesis with a leading dollar sign – ${variableName}, like the below:

9

With that done, we’re almost ready to go. Except, our script still won’t work because there’s those other 10 dynamic variables we need to correlate as well. Fortunately, the process is exactly the same for all of them:

Locate the variable in the preceding response – the request login page response in the case of our script.
Construct the regex to extract the variable – as discussed above.
Create a Regular Expression Extractor for each variable to be correlated.
Refer to the extracted variable in the subsequent request – the submit login page in our example, as discussed above.

Once you’ve gone ahead and done all of that, you’ll likely end up with something that looks like the below:

10

And, assuming that you’ve done everything correctly, running the test again will result in the desired logged-in response from the server:

11

We can see above the JMeter is logged in by the “Hello, jmeter” message in the response.

We’re done! Our login script is now ready to rumble. And having covered the basics, we’re ready to tackle some more advanced JMeter topics. So stay tuned for those…

- Simon

P.S If you're interested in learning more about performance testing, checkout my Performance Testing 101 course here.


11 Comments

  • Viki says:

    Thanks ! Very use full for Us!

    Can u post Advanced performance testing ?

    Thanks!

  • Hanumanthu says:

    Thank you.. This post is very helpful for correlation. I was able to figure it out easily by following this procedure.

    Appreciated.

  • Sastry says:

    Hello Simon, very helpful posts and I gained good knowledge with the information provided.

    got a quick question,
    capturing a parameter value from fitst sampler that has “/” and “:” in there (for ex: https://gmail.com). however, when the parameter value is used in the subsequent sampler, I see JMeter replaced those special charectors into “%2F” and “%3A” respectively. I have noticed thse incorrect submitted values in the results tree. can you help fixing this issue?

    Thank you

    • Simon Knight says:

      Hi Sastry. Assuming I’m understanding your question correctly, I’d just manually set the host name in the sampler. Or set it up as a variable in the test plan – then add the variable to my samplers. So https://gmail.com would become gmail.com in your sampler (with protocol set to https accordingly), or gmail.com as a variable in your test plan and utilised as e.g. ${hostname} in your samplers.

      • Sastry says:

        Thanks for quick reply Simon. The dynamic variable value I get from the first sample is “/oracle/home/cap/xxyy18m/task::12345”. I captured it with regex extractor and passing it to the subsequent request. The problem is, value is changing as “%2Aoracle%2A……..” due to this, I get unsuccessful response. I want to send as is. Please let me know if any further questions to help understand the question. And I appreciate your help.

        • Simon Knight says:

          Hi Sastry. It looks to me like you’re trying to capture too much data with your regex. Instead of extracting “/oracle/home/cap/xxyy18m/task::12345” in which I would guess “/oracle/home/cap…” Is probably not the dynamic bit – just focus on extracting the piece of data that does actually change each time and using that, and only that, in your script? Thereby probably bypassing the encoding issues.

          Failing that you may need to look at modifying the regex further and/or splitting the dynamic data into a couple of different variables you can implement in your sampler.

          • Sastry says:

            Hi Simon,
            I tried the approach you suggested yesterday, but, did not see any luck with it. with the earlier example, the post data in the sampler, this is how it looks like:
            usernameField=sastry&passwordField=xxxxx&Accessibility=Nj-GsO06Y&_fwkAbsolutePageName=%2Foracle%2Fapps%2Ffnd%2Fsso%2Flogin%2Fwebui%2FMainLoginPG%3A%3A%3A2z4tM4g8&

            But, I actually want to send as below:
            usernameField=sastry&passwordField=xxxxx&Accessibility=Nj-GsO06Y&_fwkAbsolutePageName=/oracle/apps/fnd/sso/login/webui/MainLoginPG:::2z4tM4g8&

            so the parameter _fwkAbsolutePageName has been defined as, /oracle/apps/fnd/sso/login/webui/MainLoginPG:::${fwkAbsolutePageName}. still the sampler substitutes “/” with %2F (unselecting Encode? check box didn’t help). How can I overcome this problem?

          • Simon Knight says:

            I don’t have a specific solution for you I’m afraid Sastry. You’ll just have to experiment with different approaches and see what works. Switching to body data in the sampler may help, as discussed here: http://stackoverflow.com/questions/22306977/jmeter-authenticity-token-has-been-encoded-how-to-decode

          • Sastry says:

            That’s not a problem Simon. Thank you for your timely responses though. In case I crack this problem, I will let you know. Thanks again.

  • Rumesh says:

    Hi Simon, these posts are very helpful. Hope you will post more and more posts about the Jmeter & performance related topics in the future.
    Thanks

  • Geetha says:

    Can we submit the values to a form using jmeter and then view the inserted values in the application

Leave a Reply