Igor Kromin |   Consultant. Coder. Blogger. Tinkerer. Gamer.

I recently had to analyse the performance of a web service that can be used to upload documents into a database, SoapUI was the natural choice for this but I didn't want to run it from my laptop so I could avoid network transfer times interfering with my results. This meant I had to run SoapUI directly on the server where the web service was running.

SoapUI is available for Linux so at least that was covered, however I had some specific requirements:
  • Send a specific SOAP request
  • Had to run on the command line
  • ID within the SOAP request could not be hard coded (to avoid duplicate errors)

Sounds simple enough, but SoapUI doesn't just let you send arbitrary SOAP requests via the command line like it does in the GUI. I came up with a couple of workarounds to make it work. First I set up my project on my laptop just as I would if I were to do this testing on my laptop directly. I created all my SOAP requests (with their attachments cached). The trick here was to also add a test case for each of the requests that I wanted to run.

Inside my project, I had a SOAP request to upload a 1Mb file, for example. The name of this request doesn't matter so much but should be easy to identify. I created a test suite with the name 'UploadTests' and then added a test case, called 'Upload_1Mb_File' to this suite. The test case had one step, which was to send my request to the web service. The names of the test suite and test case do matter and are used later.

The first two points of my requirements were now covered, which left the last - ID couldn't be hard coded. I needed this since each of my requests would be run multiple times to collect data with some statistical significance. Luckily SoapUI has the ability to specify values via properties. With that I was able to put in a property variable instead of the actual value into my SOAP request. The name of the property I used was 'DocumentId'.

To run my project I used 'testrunner.sh', which comes with SoapUI. This works well enough, but I wasn't happy with its output. I didn't want to see all the logging it produced, but I did want to see the response message that the web service returned. This was a little bit more pain to implement than I have liked though. I came up with a simple script below that executes a particular test case, captures the output of the web service response and then prints out the test summary (which includes timing data that I was after) and the SOAP response.

This is what the script looked like...
rm -f "$1"-"$2"-*.txt
./testrunner.sh -s "$1" -c "$2" -e "$3" -r -a "$4" "${@:5}" > test.log 2>&1
sed -n -e '/TestCaseRunner Summary/ ,$p' test.log
sed -n -s -e '/TestStep/ p' -e '/- Response -/ ,$p' "$1"-"$2"-*.txt && echo

This script requires 4 command line arguments, it's usage is something like this...
./test.sh UploadTests Upload_1Mb_File https://test_server:8001/context_root/service_uri soapui-project.xml -P DocumentId=

You specify the test suite, test case, service endpoint, and the SoapUI project. Any parameters after this are simply passed onto testrunner.sh.

After testrunner.sh completes, my script extracts the summary out of the log files and displays that. It then extracts the SOAP response and displays that too.

The very last parameter I used was the -P parameter, which sets a project property to a value. In my case this is what I used to control what ${#Project#DocumentId} was set to before the SOAP request was sent to the web service.

The script I came up with definitely can be improved to make it more user friendly. I didn't see the need to do that since the task I was working on was essentially a one-off. The script also can't handle service endpoints that require authentication, I'll post a separate article on how to handle that in the future.


Did you like this post or found it useful? Considering supporting this Blog to keep its web servers running, any amount helps! Thanks!
Have comments or feedback on what I wrote? Please share them below!
comments powered by Disqus
Other posts you may like...