Data driven web service testing with Apache Jmeter

You will not get enough coverage in your web service testing, if you repeatedly send the same request to the webservice under testing. You must read data from a data source and parameterize each request. If you are dealing with SOAP messages, you should parameterize SOAP message payload.
This post guides you how to do data driven web service testing using Apache Jmeter.

Pre-requisites:
Install Apache Jmeter 2.3.4 or later

Step 1

We are going to invoke a publicly available web service, Temerature Conversion service . The WSDL of this web service can be accessible through http://webservices.daehosting.com/services/TemperatureConversions.wso?WSDL
You can invoke the CelciusToFahrenheit operation of this webservice using SOAPUI and capture the request message. It will be similar to the below.

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:tem="http://webservices.daehosting.com/temperature">
<soapenv:Header/>
<soapenv:Body>
<tem:CelciusToFahrenheit>
<tem:nCelcius>37</tem:nCelcius>
</tem:CelciusToFahrenheit>
</soapenv:Body>
</soapenv:Envelope>
Step 2

Lets create a new JMeter test plan and add a thread group. Then, add SOAP/XML-RPC sampler into the thread group and copy and paste the above SOAP request into the SOAP/XML-RPC data section of the sampler.
Enter the URL of the service as http://webservices.daehosting.com/services/TemperatureConversions.wso (You can capture this from the location attribute of the address element in the WSDL)
Now add a listener to view the result.
Save your test plan. Your test plan will be similar to the below.



Run the test and check the results. You will get the Fahrenheit value of the provided Celsius figure.

Step 3

Now, you can increase the thread count and extend this test into a performance test. However, in that case you will be sending the same request again and again. It will not be a good simulation of a real-world scenario. You should be able to alter the payload (in our example, Celsius value) of the SOAP request with each thread.
In order to do so, you should read Celsius data from a data source. In Jmeter, you can easily read data from a csv file.
Lets create a csv file, temperature.csv and save it in the location where you saved the above JMeter test plan.
Enter a set of values row-by-row in the temperature.csv
eg:-
10
20
30
40

Step 4

Next, we will add CSV Data Set Config element which will read data from the csv file.
Right click on Thread Group and select Add --> Config Element ---> CSV Data Set Config
Now you can configure your CSV data source as follows.

Filename: <Give the full path of temperature.csv>
Variable Names: celcius

Keep the other values intact.

Step 5

Now access the SOAP/XML-RPC Data section of the request and replace the hard-coded celcius figure with the variable name we have configured in CSV Data Set Config element (i.e:- ${celcius})
After parameterizing, your SOAP request will be as follows.

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:tem="http://webservices.daehosting.com/temperature">
<soapenv:Header/>
<soapenv:Body>
<tem:CelciusToFahrenheit>
<tem:nCelcius>${celcius}</tem:nCelcius>
</tem:CelciusToFahrenheit>
</soapenv:Body>
</soapenv:Envelope>

Increase the thread count corresponding to the row count in your csv file and run the test. You will notice that the Celcius figure will be varied in each request by reading data from CSV data source.

In this way, you can easily do data driven web service testing using Jmeter.

How to deploy JSR181 annotated class in Apache Axis2

JAX-WS (Java API for XML Web Services) provides support for annotating Java classes with metadata to indicate that the Java class is a Web service. With the annotations, you can expose java classes as web services with minimum effort.
Apache Axis2 ships with JAX-WS support since its 1.4 release. This post explains the simplest possible scenario of JAX-WS support, how you can deploy an annotated class in Axis2.

Pre-requisites
Apache Axis2-1.4 or later
JDK1.5 or above

Step 1
Write an annotated class as follows.

package org.apache.axis2;

import javax.jws.WebMethod;
import javax.jws.WebService;

@WebService
public class Calculator {
@WebMethod
public double Add(double x, double y){
return x+y;
}
}

Here, the @WebService annotation tells the server runtime to expose all public methods on the above class as a Web service. Also, with the @WebMethod annotation, you can specifically denotes the methods which are exposed in the web service.

Step 2
Package the above class as a JAR (i.e:- Calculator.jar).
You need to create a directory in Axis2 binary distribution where the annotated jars are placed.
Therefore go to AXIS2_HOME/repository (AXIS2_HOME is where you extracted the binary distro) and create a new directory called, servicejars.

cd AXIS2_HOME/repository
mkdir servicejars

Step 3
Copy the annotated jar file to the servicejars directory. Then, start Axis2server (AXIS2_HOME/bin/axis2server.bat{sh})

Step 4
Go to http://localhost:8080
You will see that the calculator class will be exposed as a web service. Click on the service name.
You will be directed to the following URL and the WSDL of the service can be viewed there.
http://localhost:8080/axis2/services/CalculatorService.CalculatorPort?wsdl

Step 5
Service Deployement is over by now. Lets invoke this service using a client. I will use SOAPUI for the demonstration, you may choose any of the available mechanisms.

Open SOAPUI and start to create a new WSDL project.
Enter the above WSDL path(http://localhost:8080/axis2/services/CalculatorService.CalculatorPort?wsdl) as the initial WSDL.
Select the request, provide inputs and submit. You will get the expected results back.



You can find more information about Axis2 JAX-WS API from here.

How to use assertions in JMeter SOAP/XML-RPC sampler

Assertions are essential components in a JMeter test plan. They are very important in regression testing in which you can compare test results with a pre-defined output. 

As I explained here, JMeter Soap/xml-rpc request sampler can be considered as an one of the easiest mechanisms to test web services. 

Lets see how assertions can be added to a Soap/xml-rpc sampler so that you can use it easily in automated web services regression testing.

Before continue with this, you may go through  the following articles.

Six different ways to testing a web service

Using Apache JMeter to test Axis2 web services 

Step 1

In this example we are going to invoke the sample version service that ships with Apache Axis2.

Therefore, please download Apache Axis2-1.4.1 binary distribution from here and extract it in your file system.

Start Axis2server by runnning axis2server.bat{sh}

Step 2

Start JMeter by running jmeter.bat or sh.

Right click on Test Plan element and add a thread group.

Then add the SOAP/XML-RPC Request sampler element to the above thread group. 

(Add --> Sampler --> SOAP/XML-RPC Request)

Paste the following soap request in the Soap/XML-RPC Data section in the sampler.

<?xml version='1.0' encoding='UTF-8'?>

   <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">

        <soapenv:Body>

       <ns0:getVersion xmlns:ns0="http://axisversion.sample"/>

      </soapenv:Body>

   </soapenv:Envelope>

Enter "http://localhost:8080/axis2/services/Version" as the URL.

Enter "urn:getVersion" for "Send SOAPAction".

Step3

Right click on the SOAP/XML-RPC Request sampler element and Add --> Assertions --> Response Assertion

Enter a suitable name for the assertion. 

Enter "Hello I am Axis2 version service" as the pattern to test.

Select "Text Response" as Response Field to Test.

Select "Contains" as the pattern matching rule. 

Step 4

Now we need to visualize the result of this assertion. Therefore right click on the Thread Group element and Add --> Listener --> Assertion Results

Run the thread group. If test is successful, you will not get any errors in Assertion Results. 

Change the pattern matching rule of the assertion in to "Matches" and run the test again.

You will see the failed assertion in assertion results view.

You can extend this test with more complex web services and add assertions accordingly. Then this can be executed in regression testing of your web services. 

How to avoid "java.security.InvalidKeyException:illegal Key Size" error when invoking secured services in WSO2 WSAS

"java.security.InvalidKeyException:illegal Key Size" error is a common issue which occurs when you try to invoke a secured web service in an environment where the provision for java unlimited security jurisdiction is not done.
This can be avoided by installing Java Cryptography Extension (JCE) unlimited strength jurisdiction policy files.

1. Suppose you are using jdk15. Go to http://java.sun.com/javase/downloads/index_jdk5.jsp

2. Go to the Other Downloads section and click on download link next to "Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files 5.0"

3. Download jce_policy-1_5_0.zip and extract it in to a directory.

4. You will find local_policy.jar and US_export_policy.jar files there in the extracted directory. Copy these two files to $JAVA_HOME/jre/lib/security directory. (These files will already be there. you may replace them)

5. Restart WSO2 WSAS and invoke your secured service again. You will not encounter the "invalidkeyException" any more.

How to validate a WSDL using Eclipse

When you create a wsdl file from scratch or use an already designed one, you must make sure it is valid. In other words it should;

• consist of well-formed XML (All tags should be closed and nested properly)

• conform to XML Schema

• comply with the rules and standards defined in WSDL specification

• valid with the rules defined by WS-I (Web services interoperability organization)

Eclipse Web tools project (WTP) provides a very useful tool which validates a wsdl against above rules/standards.
Lets see how we can validate an existing wsdl using Eclipse wtp.

1. Download and install Eclipse wtp

2. Open eclipse IDE

3. Start to create a new wsdl (File --> New --> other --> Web Services --> WSDL)

4. Give a name to the wsdl (you can provide the name of wsdl which needs to be validated) and click on next. Accept the default options and click on Finish.

5. You will see a design view of a new wsdl file. Move to source view by selecting "Source" tab.

6. You will see an skeleton source of the new wsdl. Just remove it. (remove all elements in the wsdl)

7. Copy the contents of your existing wsdl (Suppose it is Myservice.wsdl) and paste in the source tab.

8. Save it by selecting save button in eclipse tool bar.

9. Right click on the wsdl file and select Validate

If your wsdl has errors, those will be shown in problems pane.

You may notice that we create a new wsdl, remove its content and copy the existing (already created) wsdl in to source view of wsdl validator. I suggest that as a work around because I could not find a way to import an existing wsdl directly into wsdl validator.

Domain hosting

Short notes on SOAP messaging

SOAP is the fundamental messaging framework for web services. It is the first piece of thing you should learn and understand when starting to deal with web services. I think most of the readers of this blog possess a good understanding of the concepts and techniques of SOAP. However, this blog is not restricted to folks who are working with SOA and web services. QA testers and non-web service specific developers are also a part of target audience.
I thought to describe a set of commonly used terms in SOA and web services in fairly simple and non-technical user oriented manner so that most novice users get benefit from it.

SOAP defines a standard message format based on XML. It provides a mechanism to bind messages to different network protocols. It also defines a processing model to serialize/de-serialize messages.

Structure of a soap message

<Envelope>
<Header>
<headerBlock1/>
</Header>
<Body>
<payload/>
</Body>
</Envelope>

SOAP message consists of 3 basic elements.
Soap Envelope

Body

Header

SOAP envelope should have one mandatory body element which contains the message payload.
One soap message can have zero or more header elements. The SOAP header is an extension that provides a way for information to be passed within a SOAP message that is not
part of the business message payload. Soap headers include information that controls QOS (quality of service) such as Security and reliable messaging.

Soap nodes are intended to receive or send soap messages in the message transmission path. If a node transmits a message it is known as a SOAP Sender. If it receives a message, then it is a SOAP Receiver. If a node does both transmitting and receiving of soap messages, then it is called a SOAP Intermediary.

The Soap sender which builds the message initially is said to be initial SOAP sender. The final target of the message is Ultimate Soap receiver. It is expected to process the payload of soap message.

There is an important attribute you may have seen in soap header elements. it is the "mustUnderstand" attribute. If this attribute is set to true, the target node should process the SOAP header block. If this attribute is false or not available, then target SOAP node can ignore processing the block.

SOAP fault is a model to handle exceptions when an error occurs in processing a soap message.
Soap fault is included in the body element of soap message.
Soap fault should have a mandatory fault code element. There are five fault codes defined in SOAP 1.1 specification.

VersionMismatch: message does not comply with the SOAP version
Sender: message was incorrectly generated when receiving node processing it
Receiver: Receiving node cannot process the message
MustUnderstand: The targeted node cannot understand the soap header
DataEncodingUnknown: The target node cannot understand the data encoding mechanism of the message

SOAP bindings allow a SOAP message to be transmitted over different transport protocols such as HTTP and SMTP.
In a web service interaction, the request and response SOAP messages can be sent via two different transports.

If you can understand the commonly used terms I explained above, you should be able to follow and explore more with the detailed reading materials published on various places.

Stay tuned. I will post a set of commonly used terms of WSDL soon.

Retrieving web service metadata using wso2-mex module

I have published a Knowledge base post at Wso2 oxygen tank which describes the procedure to retrieve web service metadata using wso2 WSAS and wso2-mex module .
You will find it useful since there are no much documents available on the web regarding ws-MEX (ws-MetaDataExchange) configuration and usage.

Exposing an Axis1 service through WSO2 WSAS

Do you want to make use of the powerful QOS features of Axis2 with your legacy Axis1 applications? Yes it is possible with WSO2 Web services application server. It allows easy deployment of any Apache Axis1-based Web service and engage advanced WS-* services, such as WS-RM and WS-Policy in front of legacy Axis1 services.
Lets see how we can use this cool feature.

Step 1

Write the service impl class.

package org.wso2.wsas.service;

public class Calculator{

public int addition(int x, int y){
return x+y;
}

public int multiplication(int a, int b){
return a*b;
}

public int subtraction(int c, int d){
return c-d;
}

public double division(double m, double n){
return m/n;
}
}

Compile and make a jar with the above class. Suppose it is Axis1resources.jar

Step 2

Write the deployment descriptor (*.wsdd) for your service impl class and save it as calculator.wsdd

<deployment xmlns="http://xml.apache.org/axis/wsdd/"
xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">
<service name="Axis1calculator" style="wrapped">
<parameter name="className" value="org.wso2.wsas.service.Calculator"/>
<parameter name="allowedMethods" value="*"/>
</service>
</deployment>

Step 3

Start WSO2 WSAS (If you haven't downloaded it yet, get it from http://wso2.org/projects/wsas/java

Access WSO2 WSAS management console using https://localhost:9443 (Default admin user credentials are admin/admin)

Go to Services and service group management page and click on "Upload Axis1 service" link. You will be directed to the following page



Browse for the above calculator.wsdd and Axis1resources.jar and click on Upload. Axis1 service will be deployed on WSAS and you will get a confirmation message.

Step 4

If the deployment is successful, you will see the Axis1 service is shown in the services and service group management page.
Click on "Axis1calculator" service.
In the "Service Management" page, select "Tryit"
Invoke service using some inputs and see the output.

Invoking a public web service programmatically using WSO2 WSAS

A Web service is defined as "a software system designed to support interoperable interaction over a network." Web services are referred to as Web APIs that can be accessed over a network and executed on a remote system hosting the requested services.
There are many publicly available web services which can be invoked remotely using client applications. www.webservicex.net is such a site that hosts different types of public web services.
I'm going to demonstrate how such web service is invoked programmaticaly using WSO2 Web services application server (WSO2 WSAS)

WSo2 Web services application server provides set of tools to interact with web services. You can download the latest version from here.

I'll use a public instance of WSO2 WSAS to generate client side code (stub). You will also try out WSAS public instance before downloading the server.

Step 1

First, we may access webservicex to identify a suitable web service which can be invoked remotely.
You may see 'Top Web Services' at the left menu of the home page. Click on 'Stock Quote'
You will get a page with stock quote service details.

Make a note of the followings;
Endpoint http://www.webservicex.net/stockquote.asmx
WSDL Location http://www.webservicex.net/stockquote.asmx?wsdl

Step 2

WSO2 provides a set of shared instances of WSO2 Web services application server at http://wso2.org/tools. You can easily try out several features of web services application server with these instances.

Go to WSAS 2.2 shared instances page and select 'shared WSO2 WSAS Instance 1'. You will be directed to the home page of WSAS management console. Select WSDL2Code from the left navigation menu.
You will see the following page.



Enter 'http://www.webservicex.net/stockquote.asmx?wsdl' as the uri of WSDL. We need to generate a client to invoke the stock quote service. Therefore, you don't want to configure server side settings. Simply click on 'generate' leaving the other fields blank.

Within a few seconds, you will be prompted to save a zip file in your file system. Save it in your machine.

Step 3

Go to the directory where you saved the generated zip file. You will see src directory, pom.xml and build.xml file inside the zip file. src directory contains the StockQuoteStub and StockQuoteCallbackHandler classes which can be considered as proxies used in our client.

Now open a command window and go to the extracted directory where the above pom.xml exists.
Assuming you are using Eclipse as IDE, enter mvn eclipse:eclipse to generate the complete project structure which can be imported in to your IDE. (If Intellij IDEA is used, then use mvn idea:idea)

Depending on your network connection and the contents available in your maven2 repository, the above command takes some time to download the necessary jars to your m2 repo.

If everything is successful, you will see 'BUILD SUCCESSFUL' message.

Step 4

Open eclipse IDE. Select File-->Import.
Select 'Existing projects in to workspace'. In the 'Import Projects' window, browse for the root directory of the above location (where you extracted the generated zip file)
Select the project and click next

The complete project structure will be created with the generated artifacts. You may need to define M2_REPO classpath variable if you have not done it previously.

Step 5

Now use the generated stubs to create a java client under the above project to consume Stock Quote service.

public class StockQuoteClient {

public static void main(String[] args)throws AxisFault {
StockQuoteStub stub = new StockQuoteStub("http://www.webservicex.net/stockquote.asmx");
StockQuoteStub.GetQuote req = new StockQuoteStub.GetQuote();
req.setSymbol("IBM");
try {
StockQuoteStub.GetQuoteResponse response = stub.GetQuote(req);
System.out.println(response.getGetQuoteResult());
} catch (RemoteException e) {
e.printStackTrace();
}

}

}

Run the application. You will get the stock quote for IBM.