We are going to look at how to test SOAP Services using JMeter and some of the issues that you can face when testing these services.

We are going to provide some basic principles of SOAP in this post and while some requests can be complex in their definition and structure testing them is relatively straightforward.

The best approach to performance testing SOAP Requests is to discuss what the structure of the message is with your development teams or 3rd parties should the service be hosted external to your organisation. Fundamentally it is no different to any other HTTP Request in that you need:

• URL of the service,
• Payload,
• Request Header (including any authorisation).

SOAP Basics

In its simplest form SOAP:

• Is an open-standard, XML-based messaging protocol for exchanging information among computers,
• Can extend HTTP for XML messaging,
• Provides data transport for Web services,
• Can exchange complete documents or call a remote procedure,
• Can be used for broadcasting a message,
• Is platform and language-independent,
• Is the XML way of defining what information is sent and how,
• Enables client applications to easily connect to remote services and invoke remote methods.

There are many tutorials on the structure of SOAP and how and why the messages are constructed in the way they are, and here we recommend this one.

Defining our test service

If you have read the above tutorial, you will now have a good idea of how SOAP payloads are constructed, for the purposes of this blog post let’s assume we have an XML Payload that consists of:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:com="octoperf:update">
   <soapenv:Header/>
   <soapenv:Body>
      <com:updateContact>
         <UpdateContactRequest>
            <ContactAdjustment>
               <ContactId>1234</ContactId>
               <UpdateField>Surname</UpdateField>
               <Adjustment>Smith</Adjustment>
            </ContactAdjustment>
         </UpdateContactRequest>
      </com:updateContact>
   </soapenv:Body>
</soapenv:Envelope>

Which very simply is going to update a contact surname based on a contactId.

Let’s also assume that the URL of the request is https://octoperf-soap-service.com/contacts/integration/contactservice.

Before we move onto creating our test, we need to consider headers for our request. As we have mentioned previously this is a theoretical request and for any test you write you are best placed talking with your development teams or 3rd parties about what headers are required. In our example we are going to set Content-Type = text/xml;charset=UTF-8.

While we are on the subject of headers this is taken from the JMeter Documentation page found here.

Next, select “HTTP Header Manager” and update “SOAPAction” header to match your webservice. Some webservices may not use SOAPAction in this case remove it.

Currently, only .NET uses SOAPAction, so it is normal to have a blank SOAPAction for all other webservices. The list includes JWSDP, Weblogic, Axis, The Mind Electric Glue, and gSoap. Omitting the SoapAction header from a .NET service will cause your tests to fail, however you can include it in all requests and leave it blank if you are not using .NET. To demonstrate this SoapAction header, we will do this in our example test.

Building a test

We will create a test with a single sampler.

We have created an HTTP Request sampler and added the URL and the payload we discussed earlier. We also have a header.

We have added our Content-Type and a blank SoapAction as our service is not written in .NET. We have also added an Authorization header with the token being passed from a properties file.

It is more than likely that you will need to authorise your SOAP requests and the way you add this value is down to you, you may generate dynamically in your test, or you may read from a secure location or vault.

Let’s run our test, and then we can look at how we can check our response.

If we view our response in XML we get to see the message nicely formatted. We will look now at how we can check we have a valid response from the test.

Checking responses

Your test against your application under test will clearly return a response that is specific to your service but there are a couple of things to consider. Firstly, just because you get a 200 response code does not necessarily mean your request has been successfully processed.

It is a good idea to firstly check for a valid response code and then check the body of the response for a value or status that indicates that the service processed your request successfully.

If we once again take our example test response, we will create two assertions to check we have success. The first will be a check of the response code:

And the second a check of the status value in the body of the response:

Both these checks give us confidence that our request has been successfully processed.

Conclusion

Web services are commonplace in many aspects of computing and SOAP is still a popular protocol for these services.

Hopefully this guide will give you an insight in how you can performance test these using JMeter.

The JMeter project used in this blog post can be found here.