All about SOAP UI and Groovy in it

Our business will continue as usual, only better;

via eviware becomes SmartBears | Eviware Blog.

Looping in Groovy Step

While testing several conditions or performing the same operations over a range of values, we intend to use loops. We have three ways to accomplish looping in a groovy step.

1)      while

2)      for

3)      closures

For developers ‘while’ and ‘for’ are familiar operations.


Usage:  while (condition) {

// useful code here, which keeps executing until the condition is true



def a = 3;

while (a > 0) {

a- -;‘ more ‘ + a + ‘ loop(s) left’);



Usage: for (x in <some range of values>) {

// useful code here, which executes till the iteration over range of values is complete



for ( ad in 0..9) { + ‘ inside’);


For more usages of ‘for’ loop click here.


closures are similar to iterators. We mention an array or map of values, and write a closure to iterate over it.

To access the current value in the loop ‘it’ is to be used (but not ${it})


def  sampleArray = [“dev”, “integration”, “qa”, “prod”];

def a = 1;

sampleArray.each() { + ‘:’ + it);



If you have a map to iterate in groovy step like below

def sampleMap = [ "Su" : "Sunday", "Mo" : "Monday", "Tu" : "Tuesday",

"We" : "Wednesday", "Th" : "Thursday", "Fr" : "Friday",

"Sa" : "Saturday" ];

then use

stringMap.each() {; it.key + ‘:’ + it.value );


Note: break and continue statements can be used only in for and while loops but not in a closures.

So if you wish to conditionally come out of the loop, its better you use for or while.

(break – as and when encountered comes out of the loop completely;

continue – as and when encountered, skips all the succeeding steps in the loop and starts with next iteration. )

(Please feel free to get back if u have any trouble…as i’m just a mail away…otherwise leave a comment)

Script assertion in SOAP UI helps the developer to immediately run some primary tests after the current messageExchange.

It feels/sounds similar to Groovy Script test step but, in a lot ways it’s more handy. If say we want to validate on the response time and proceed further for succeeding test steps, it feels heavy to have a Groovy step to do that; instead, the Script Assertion implicitly does that job (can be done using “assert messageExchange.timeTaken < 1000”). Using this we could make the Test Suite look more credible and modular.

Script Assertion has access to messageExchange, context and log objects.

We can access the request and response xml as below -

def groovyUtils = new context )

def requsetHolder = groovyUtils.getXmlHolder( messageExchange.requestContent )

def responseHolder = groovyUtils.getXmlHolder( messageExchange.responseContent )

using the above holders we can get hold of the all elements in response and request xml of the latest messageExchange.

While accessing the elements of request/response xml, using the corresponding namespace(s) for every element is very important. If the response xml is simple (that is, mostly all the elements are referenced by one namespace), then xpath would be simple to trace. But if various elements are referenced by various namespaces, then we should be cautious while framing the xpath.

Here are my observations regarding this:

Lets say following is the response xml obtained after running the Test Request step(which has the script assertion)

Sample Response xml

Sample Response xml - I

In the Script Assertion step, to access RefNum field (of the above response xml), we write

def refNum = responseHolder.getNodeValue(“//trans:ProcessMessageResponse/content/Response/RefNum”)

And say if the response xml has various namespaces to refer its elements as below

Sample Response xml - II

then to access the same RefNum value, the xpath used should be

def refNum = responseHolder.getNodeValue(“//trans:ProcessMessageResponse/ns1:content/ns2:Response/ns2:RefNum”)


def refNum = responseHolder.getNodeValue(“//ns2:Response/ns2:RefNum”)

This might raise some ambiguity regarding ‘ns2‘ namespace ref. which I have used to access the RefNum value, though it is nowhere present in the response xml.

What I figured out is default namespaces are named as ns1, ns2 and so on (as applicable) in the order of their occurrences. In the above xml, ‘content‘ element is referred with ‘ns1’; and ‘Response‘ element is referred with ‘ns2’. And thus the xpath is so.

We can verify which namespace is given which name, by clicking the ‘Declare’ button in XPath Assertion window (though this can be done to know the names of different namespaces present in response xml only). But to know, the names of different namespaces present in request xml, ordering logic (what i have mentioned above) should be employed.

Not only while applying Script Assertion, the above explanation (that is, building precise xpath with appropriate namespace references) applies to all the situations where developer needs to access any element of request/response xmls.

Groovy provides very robust methods with sql instance to retrieve and manipulate the ResultSet. 

There are methods for retrieving the first row,  the ResultSet of some sql query, directly executing insert/update/delete queries.

Prerequisite: Obtain sql instance using

import groovy.sql.Sql

def sql = Sql.newInstance(dbpath, dbusr, dbpwd, dbdriver)


Below are some comprehensive examples which use the above sql instance.

firstRow( sqlQuery ) : This method returns the first row entity out of the ResultSet that is obtained by executing the query passed to it as argument.

def  res = sql.firstRow(“SELECT * FROM TEST_TABLE WHERE USERID=’12345′”)

Result can accessed from res as

println( res[0]  )   OR

println(  res.COLUMN_NAME  )


eachRow( sqlQuery, {closure} ) : This method is generally used to retain/modify the whole ResultSet based on some condition.  The second argument of this method i.e., clousure actually consists as set of statements to be executed for each of the result set’s entity. For example



                        println( it.COLUMN_1 );

                        println( it[2] );

                      }  )

The println statements (present as a clousure) above are executed for each entity while iterating over the ResultSet, and it refers to the entity of ResultSet that is currently being iterated over. Clousure can have any number of statements.


execute( sqlQuery ) : Generally this method is used to INSERT/UPDATE/DELETE records, as it doesn’t return any ResultSet as such. 




                         [ "12345", "SOMENAME" ]   )

Second type of usage is to some extent similar to PreparedStatement right? And the query could also be a INSERT/UPDATE statement, if developer wants to log some value(s) to database during execution of the TestStep.


(Please feel free to get back if u have any trouble…as i’m just a mail away…otherwise leave a comment)

Property transfers become crucial steps in scenarios where validations are done mostly using derived data.

Lets say after some Groovy script execution we end up setting a property value in Properties step while testing an application’s functionality. And most of the times we would be in need of the obtained result out of that groovy step. As we have it in Properties Step we can access it using Property Expansion technique and also using Property Transfer Step.

Property Transfer Step shall be in between the Properties Step and SOAP request Step, but before placing the Transfer Step have Properties and SOAP request Steps in place. Property Transfer window would something like this:

Property Transfer Step

Property Transfer Step

After creating a new Property Transfer in the above window say ‘RefNumTransfer‘, select source, in this case it would be the ‘Properties’ Step, this inturn provides the list of all properties defined under that Step, select the property you wish to transfer.

Now come to Target block, where we would have our SOAP request to catch the property transfer. Initially declare all the namespaces that your request would use, separating each of them with ‘;’ and then provide the XPath of the target node which should capture the transfered value. 

For example if the SOAP request as is below

SOAP request to catch tranfered Property

SOAP request to catch tranfered Property

then the target block of Property Transfer should contain details like this:

Declaring namespaces and adding target XPath

Declaring namespaces and adding target XPath

Try running the Property Transfer step, you see the ‘Transfer Name’ and ‘Transfered Value’ in the Transfer Log, and also correspondingly that value is reflected in the SOAP request at the target XPath.


(Please feel free to get back if u have any trouble…as I am just a mail away…leave otherwise a comment)

Assertions are generally the simple and most sought validations that can be enforced in SOAP UI.

For SOAP response we have an assertion step called ‘XPath Match‘, which validates the value yielded by the specified xpath with the one provided staticly.

When we add ‘XPath Match’ assertion using the Add Assertion button, we see the below window.

XPath Match Assertion

XPath Match Assertion

There is a button called ‘Declare‘ (present in free version of SOAP UI also), it automatically declares all the namespaces of SOAP response. After declaring the namespaces using this ‘Declare’, mention the xpath of the node whose value is to be validated. Here the xpath could start from the node which comes just after the <soap:Body> node (i.e., <soap:Body> node’s immediate child). For example, if say the response xml is:

Sample Response

Sample Response

then to validate on the value of ‘Status‘ node, the xpath that should be present in XPath Expression blockalong with all the declared namespaces is


And, now we need to provide some expected value, inside ‘Expected Result’ block which shall validated against the corresponding node value. There is an option called ‘Select from current‘, which actually fetches the value of that xpath, from the current response. Another option called ‘Test‘, is used to test right away.


(Please feel free to get back if u have any trouble…as i am just a mail away…leave a comment otherwise)


At times there could be requirement of Load Testing a Web Service following different strategies based on the requirement.

But say if there are fields in the SOAP request which are supposed to be unique for every request that hits the service while load testing…really this could be tough to deal with.

With the new feature called in line scripting of SOAP UI 2.5, this could achieved with ease. 

For example, lets say we have a web service deployed on a server. And the service writes report files to the server’s file system, with the name having some unique value derived from the SOAP request.


Sample GenReportXml for the above service

Sample GenReportXml for the above service


We have a node called RefNum having value 123456 in the above request, using which the service writes a report to the file system with name say Report_123456.txt. Every time a request with some RefNum triggers the service to generate a report file, one hindrance would be the RefNum of every request that hits the servicve should be unique, to have a valid file in the local system.(weird web service right!.. i understand…just take it as an example).

Issue now would be to load test such service, which demands some unique value in the SOAP request evrey time it hits it.  In SOAP UI 2.5 we have a very simple solution for such weirdly complicated services, called in-line scripting!

SOAP request with in line groovy script

SOAP request with in line groovy script


In the above request, under RefNum node I included a Groovy Step to fetch the current time in milliseconds. The notation ${=…} is the next level of Property Expansion technique. The ‘=’ shall evaluate the script and provide the result as that nodes’ value.

This serves the purpose of Load Testing the service, providing unique RefNums for every request, no matter what strategy we follow to in testing, without doing any work around at the application level…(which sounds great!).

The above example seems to be explicitly specific, but I hope it would be usefull. There are still lot of ways we can explore the cool in line Groovy scripting feature , which the SOAP UI’s new version has got along.


(Please feel free to get back if u hav any trouble…as i’m just a mail away..leave a comment otherwise)


Tag Cloud


Get every new post delivered to your Inbox.

Join 44 other followers

%d bloggers like this: