Data correlation typically works with strings without complex context. That statement carries some irony if one has ever taken the opportunity to examine some of the very intense regular expressions involved in some instances. Nonetheless, at its core, data correlation amounts to nothing more than “We found this string at this location in this response (a reference point). It also appears in this later request at this location (a substitution point). Let’s make sure to always tie those two strings together even as the values change.”
Consider this very rough representation of the communication between a client and a server:
Client Request 1: “What is 3+4?”
Server Response 1: “3+4=7”
Client Request 2: “What is 7 <the answer> * 5?”
Server Response 2: “7*5=35”
With data correlation applied the above becomes (in color):
Client Request 1: “What is 3+4?”
Server Response 1: “3+4=7”
Client Request 2: “What is 7 <the answer> * 5?”
Server Response 2: “7*5=35”
The string “7” is recognized in Server Response #1 as a string that is re-used in Client Response #2. A reference is created in Server Response #1. A substitution point is created in Client Request #2. The thing to keep in mind is that it’s all contextual. The reference doesn’t do any arithmetic; it simply recognizes the string of digits that follows the “=” in Server Response #1 and uses that same string in Client Response #2. In this case, it works.
What if the requests become a bit more complex?
Client Request 1: "What is 3+4 and what is 2*5? Which is greater?"
Server Response 1: "3 plus 4 equals 7. 2 times 5 equals 10. 10 is greater."
Client Request 2: "Use 10 <the greater number> to do <next step>".
Server Response 2: "OK. Done."
Data correlation might make this sequence look something like this:
Client Request 1: "What is 3+4 and what is 2*5? Which is greater?"
Server Response 1: "3 plus 4 equals 7. 2 times 5 equals 10. 10 is greater."
Client Request 2: "Use 10 <the greater number> to do <next step>".
Server Response 2: "OK. Done."
Again, it’s just string pattern-matching. The reference is going to be created following the 2nd occurrence of the word “equals”. The substitution is always going to use that value, regardless of the validity of the math.
Sometimes it is necessary to “do the math”.
This is where the combination of field references and custom code enters the picture. What is needed here is some sort of “super” reference, a reference that encompasses the entire response. These are called field references.
Client Request 1: "What is 3+4 and what is 2*5? Which is greater?"
Server Response 1: "3 plus 4 equals 7. 2 times 5 equals 10. 10 is greater."
customcode.FindGreaterValue(<field reference>)
Client Request 2: "Use 10 <the greater number> to do <next step>".
Server Response 2: "OK. Done."
The field reference, highlighted in yellow as it is in the DevOps Test Performance test editor, encompasses the entire response. This reference is accessible just as any reference is within a test. It can be passed to custom code as an argument.
public String exec(ITestExecutionServices tes, String[] args) {
String greaterValue = null;
// parse the input value
// compute the greater value
// ...
return greaterValue;
}
The custom code can then use string handling along with regular expressions to extract a value from the response with more control than is available with an ordinary reference. The substitution in Client Request #2 is then done from the custom code return value.
Script Examples
A field reference:
Right-click anywhere in the Content box.
Select Create Field Reference.
Provide a meaningful Name value. For the example, it’s “myFieldReference”.
Click the Apply and Close button.
Voila, a field reference:
The reference variable myFieldReference can be accessed at any later point in the script. For instance, as an argument to custom code.
In the custom code for MyCustomCode, we “do the math”, whatever the math may be.
The return value from the custom code is used to substitute to result in the appropriate request.