Another common issue solved with Soap UI

Well, I think it is clear now I am a big fan of SoapUI. So here is another post about it. This time I explain how you can use it to perform a load test for your webservice and how to work around a common issue with this test. One of the business rules we have is that a message may only be processed succesfully once. To implement this, a unique referenceNumber is supplied in the body of the SOAP message (I know, it was better to use a policy for that by adding a SOAP header, but this is a piece of legacy I have to deal with). In the webservice (actually in a XFire handler) the referenceNumber is checked against all processed referenceNumbers in a database and if it already exists, a fault message is returned.
To avoid this fault message in our load test we added several steps to our Soap UI testcase that increases this referenceNumber, so it’s unique for every message.
Here is an example of how to do this. First I created a webservice that just echoes the inputted string. Here is the WSDL:

<wsdl:definitions targetNamespace="">
  <xsd:schema targetNamespace="" elementFormDefault="qualified" attributeFormDefault="qualified">
    <xsd:element name="s" type="xsd:string"/>
    <xsd:element name="echoAnswer" type="xsd:string"/>
<wsdl:message name="echoRequest">
  <wsdl:part element="tns:s" name="s"/>
<wsdl:message name="echoResponse">
  <wsdl:part element="tns:echoAnswer" name="echoAnswer"/>
<wsdl:portType name="EchoService">
  <wsdl:operation name="echo">
    <wsdl:input message="tns:echoRequest" name="echoRequest"/>
    <wsdl:output message="tns:echoResponse" name="echoResponse"/>
<wsdl:binding name="EchoServiceHttpBinding" type="tns:EchoService">
  <wsdlsoap:binding style="document" transport=""/>
  <wsdl:operation name="echo">
    <wsdlsoap:operation soapAction="urn:echo"/>
    <wsdl:input name="echoRequest">
      <wsdlsoap:body use="literal"/>
    <wsdl:output name="echoResponse">
      <wsdlsoap:body use="literal"/>
<wsdl:service name="EchoService">
  <wsdl:port binding="tns:EchoServiceHttpBinding" name="EchoServiceHttpPort">
    <wsdlsoap:address location="http://localhost:8080/XFireTest/services/EchoService"/>

I then created a TestCase based on this WSDL and added four steps:

  • A properties step
  • In this step a property is defined to be used in this TestCase.

  • A Groovy Script step
  • This step has the logic to increase the property that is defined in the step before.

  • A Transfer step
  • With this step we copy the value of the (modified) property into the SOAP request before we send it to our webservice.

  • The SOAP request step
  • Final step is sending the request with the modified value.

Now when all this is in place you can run a simple loadtest like this:

In the server where my webservice is running you will get out put like this:

As you can see each call gets a unique number.

Now we change the LoadTest to have multiple threads accessing the webservice at the same time. When we do that like this:

the output becomes:

Now the generated numbers are no longer unique!

To fix this I have added a property and changed the Groovy Script Step so it adds the thread index to the unique part. The Property Step and the Groovy Step become like:


And the output now is:

Now that looks better, doesn’t it? All generated ID’s are unique again for every message.

About Pascal Alma

Pascal is a senior software developer and architect. Pascal has been designing and building applications since 2001. He is particularly interested in Open Source toolstack (Mule, Spring Framework, JBoss) and technologies like Web Services, SOA and Cloud technologies. Lately he is having great fun by building iOS apps with Swift. Specialties: JEE AWS XML/XSD/XSLT Web Services/SOA Mule ESB/ WSO2 ESB Maven Cloud Technology Swift/ iOS
This entry was posted in SoapUI and tagged , . Bookmark the permalink.

15 Responses to Another common issue solved with Soap UI

  1. Kenny says:

    This is great! Exactly the sort of thing I need to do. Googled it and found you. Thanks!

  2. Rob Augustinus says:

    Good to see you like the tool Pascal! You have some nice posts here btw..

  3. cnu says:

    Great Work Pascal, your text is very informative. Thanks for the info, i’m just about to start using this tool. Keep up the great work!

  4. Gabriel Falkenberg says:

    You might want to try and use the properties you define directly in the request using jstl-like syntax like this: ${uniqueTxt}

    Using properties like this makes it possible to skip the property transfer step.

  5. Pascal Alma says:

    Hi Gabriel,

    You’re right about the EL syntax. In real life I would use this notation in this simple case. The Property Transfer step should be used in more complex cases.

  6. natarajan says:

    Hi, anyone help me to read data from excel sheet and dynamically appy that value into SoapUI request


  7. Pascal Alma says:

    That would be a nice feature. I haven’t seen it anything like it until now, but maybe someone else has done it before??

  8. Ricard Mayerhofer says:

    Is there a way to change a testsuite property rather than teststeps property?

  9. Pascal Alma says:

    Yes, I believe in a Groovy step you can refer to ‘context.setProperty( “myValues”, “blabla”)’ but you might check the documentation for the details. But is must be possible.

  10. Ricardo Mayerhofer says:

    Thanks for your response Pascal. I tried this. unfortunately I couldn’t get it to work. Perhaps I’m doing something wrong…

  11. raman says:

    hii pascal is this Soap UI a Record and Play back testing tool?????

  12. Pascal Alma says:

    Hi Raman,

    I am not sure what you would like to record, but you can use the Response from one Soap call as input parameter for a next call.
    Hope this helps.

  13. Frank Cohen says:

    Thanks for the great tutorial. I will point my soapUI users to it.

    Please take a look at PushToTest TestMaker to take soapUI to the next level. TestMaker enables soapUI tests to run at large load test levels, run in a cloud environment, provides hundreds of root cause analysis reports, and correlates soapUI activity to monitored resources. A tutorial on soapUI integration in TestMaker is at

    -Frank Cohen

  14. karthik says:

    is there a option to record and play back it in soapUI

  15. sandy says:

    I need to send the input parameter as text file like mobile no’s.

Comments are closed.