Webservice Testing With JMeter: Passing Data From a Response to Another Request

jmeter is great for functional and performance testing of many things, including web services (and to my surprise also ldap). it also provides means for extracting data from a response and passing them to a subsequent request, which is exactly what i needed. there is already a good tutorial on testing a ws with jmeter , so i won’t repeat the basic setup here. the steps are:

1. create a webservice (ws) test plan, as described in the tutorial (in my case it contains two ws calls)
2. add the user defined variables config element to the test plan and define there a variable for transferring the response data
3. add an xpath extractor post processor to the first ws call to extract the value of interest into the user defined variable (beware namespaces!)
4. add a beanshell post processor to the second call, which will replace a placeholder in the ws call’s xml data with the value of that variable

about the webservice

i needed to test a web service, which requires its client to call first its authenticate method, which returns an authentication token, called certificate, which is then used in subsequent requests.

a basic implementation

0. setup

download jmeter 2.3.4 and two dependencies, java mail api ( mail.jar ) and javabeans activation framework ( activation.jar ), necessary for the jmeter’s webservice sampler. put the jars in jmeter’s lib/ folder.

1. create a webservice (ws) test plan, as described in the tutorial (in my case it contains two ws calls)

well, follow the utorial . then duplicate the webservice call sampler, call the first one ws: authenticate with saba and the other one ws: pf – update employees .

2. add the user defined variables config element to the test plan and define there a variable for transferring the response data

we will need a variable to hold the data that we want to transfer from the 1st response to subsequent request. therefore open the test plan, right-click on thread group > add > config element > user defined variables. add there  a variable named sabacertificate . you can leave its value empty.

3. add an xpath extractor post processor to the first ws call to extract the value of interest into the user defined variable

now we will extract the “certificate” data from the first response. the response may look like this (i used eclipse’ tcp monitor to capture the soap communication):

<?xml version="1.0" encoding="utf-8"?>
<soapenv:envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/xmlschema" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance">
 <soapenv:body>
 	<saba:certificate xmlns:saba="http://www.saba.com/xml/infoservices">31323930326436636637635</saba:certificate>
 </soapenv:body>
</soapenv:envelope>

to extract the value of the element <saba:certificate>:

1. right-click on the first ws call ( ws: authenticate with saba ) and add > post processors > xpath extractor
2. for the reference name, type sabacertificate (the user variable we’ve created earlier)
3. for the xpath query, type //*[local-name()='certificate']/text()
   • problem with namespaces: beware that jmeter 2.3.4 supports only namespaces declared on the root element and thus the xpath query //saba:certificate wouldn’t work. the documentation for xpath extractor’s attribute “use namespace?” provides a workaround based on using the functions local-name() and namespace-uri() to match the local tag name and the uri associated with its namespace, which i’ve partly used.
   • you can test your xpath for example in the allans online xpath tester

4. add a beanshell post processor to the second call, which will replace a placeholder in the ws call’s xml data with the value of that variable

now we need to get the “certificate” into the subsequent web service request. i have put the placeholder “#sabacertificate#” into the sopa request, at the place where the actual authentication token shall be. now we will arrange for its replacement with the actual value:

1. right-click on the second ws call ( ws: pf – update employees ) and add > pre processors > beanshell preprocessor ( beanshell is a scripting language with java syntax and is included in jmeter)
2. type in the following script (notice that sampler is a variable provided by jmeter and refers to the parent ws call; check javadoc for details on the webservicesampler ):

case 1: soap request specified directly in the attribute soap/xml-rpc data

import org.apache.jmeter.protocol.http.sampler.webservicesampler;
webservicesampler wssampler = (webservicesampler) sampler;
string requestwithcertif = wssampler.getxmldata().replacefirst("#sabacertificate#", vars.get("sabacertificate"));
wssampler.setxmldata(requestwithcertif);

case 2: the soap request is read from a file (attribute file with soap xml data)

if the request data is read from a file then it’s a bit more complex because we need to load its content.

import org.apache.jmeter.protocol.http.sampler.webservicesampler;
import java.io.*;

webservicesampler wssampler = (webservicesampler) sampler;

bufferedreader xmlreader = new bufferedreader( new inputstreamreader(
	new fileinputstream(wssampler.getxmlfile())
	, java.nio.charset.charset.forname("utf-8")
));

stringbuffer xmldata = new stringbuffer();

string line;
while( (line = xmlreader.readline()) != null) { xmldata.append(line).append('\n'); }

string requestwithcertif = xmldata.tostring().replacefirst("#sabacertificate#", vars.get("sabacertificate"));

wssampler.setxmldata(requestwithcertif);
wssampler.setxmlfile("") ; // a file would override the data

// print("xml set: " + requestwithcertif); // print to the console jmeter was started from

well, that’s it!

going advanced: reading requests from several files

the approach descibed above makes it possible to send a request based on a single file. but what if we want to send a different data with each repetition of the test, e.g. to negate effects of caching? well, there is a couple of ways to achieve that. i’ve chosen the most flexible one, though absolutely not the easiest one to implement.

the trick is:

1. create a beanshell sampler . the sampler will list all files in a particular directory and store their paths into a numbered variables (g_updateemployeeswsrequestfile_1 etc., must start with 1), which will be then used by a foreach controller.
2. put all the test elements from the basic test plan under a foreach controller , which follows the beanshell sampler. configure it to use the variables generated by the beanshell sampler and store the current file name in the variable g_updateemployeeswsrequestfile.
3. in the webservice request element, replace the content of the filename field with a reference to that variable: ${g_updateemployeeswsrequestfile}

the beanshell sampler “ generate ws request file names “

import java.io.*;

print("generating files...");
log.info("beanshell sampler: generating request file names...");

file requestsdir = new file("/tmp/wsrequests");
string[] requestfiles = requestsdir.list();

for(int i=0; i<requestfiles.length; ++i) {
	string varname = "g_updateemployeeswsrequestfile_" + (i+1);
	vars.put(
		varname
		, requestsdir.getabsolutepath()  + file.separatorchar  + requestfiles[i]
	);
	// print("var created: " + varname + "=" + vars.get(varname));
}

log.info("beanshell sampler: finished generating request file names from dir " +
	requestsdir + "; files are: " + java.util.arrays.aslist(requestfiles));

return "soap input files generated";

the foreach controller “ foreach request file “

the controller’s configuration is simple:

• input variable prefix: g_updateemployeeswsrequestfile
• output variable name: g_updateemployeeswsrequestfile
• add “_” before before number: [x] (checked)

summary

we’ve parametrized the test by a set of files with soap requests that are read from a folder and supplied sequentially to the test thanks to the foreach controller.

resources

• the final basic jmeter test plan
• the advanced jmeter test plan (soap requests read from files in a folder)

from http://theholyjava.wordpress.com/2010/06/04/webservice-testing-with-jmeter-passing-data-from-a-response-to-another-request/