Conquering soapUI
for Dummies like Me

Russell Bateman
Feburary 2010
last update:

soapUI is a free and open source desktop application for inspecting and debugging (SOAP-based) web services. It runs on Windows, Linux, Macintosh, etc. It's aimed at developers and testers of software that consumes web-services description language-based (WSDL) and representational state transfer-based (REST) web services.

Basically, with soapUI, you can carry on specific conversations with a web service, throwing requests at it, to see how it answers. This will help you either a) learn by observation how the service works or b) find bugs in a service you wrote.

Note: This page will take me a great deal more time to put together than my ordinary how-to documents. Check the date and come back again later for more information my experience will incite me to add.


Table of Contents

How to set up soapUI
SOAP debugging: What soapUI is used for
Creating a new soapUI project
Executing a SOAP operation from soapUI
A practical demonstration...
Appendix: Creating a test suite in soapUI

How to set up soapUI

Setting up soapUI is simple: just download it from sourceforge.net on this link, then begin the installation for your platform. 32-bit and 64-bit versions are available. There are also documents at this URL.

In addition, soapUI is available as a professional tool that costs money and is available from the soapUI site. Here I review only the open source (free) version which, by all accounts, is just about all you'll need.

There is documentation for the professional version of soapUI that is quite relevant to the usage of the free version. It's probably the next place to go after reading my little page here. Additionally

During installation, you'll need to direct it to a JRE. This can get complicated for 64-bit platforms because typically you'll be thinking about the 32-bit JDK you've installed. If you chose to dowload the 64-bit version of soapUI, you'll have to make certain you've got a 64-bit JRE to point soapUI at. Just think about it and you'll soon sort it out.

On my present, Windows 7 Professional 64-bit host, I run Eclipse so I've got C:\Program Files (x86)\Java\jdk1.6.0_18 and am therefore using a 32-bit Sun JDK to run it with. However, along side, I've also installed Sun's 64-bit JRE on the path C:\Program Files\Java\jre6. As I downloaded soapUI 64-bit, that's what I point at during the installation.


SOAP debugging: What soapUI is used for

It's not my objective to teach SOAP, WSDL, REST, etc. and general web services. Please see other sources such as w3schools to learn things like this. On that page, look down the left-hand side for "Web Services."

Originally known as simple object access protocol, SOAP is a specification for exchanging structured information in implementing web services over a network. It is based on Extensible Markup Language (XML) as its format, so it's extremely easy to read and debug as compared to ancient, proprietary information exchanges.


Creating a new soapUI project

     

1. Create a new soapUI project starts with the File -> New soapUI project menu.

2. When you create a new project, you can create a test suite. Most developers won't want to do this, since they're only interested in working through problems in one or two operations. However, a QA person would certainly want to create a test suite. Creating a test suite leads to additional interaction—not covered here (or, perhaps, I will cover it later in an appendix).

Find more quick-start help at http://www.soapui.org/gettingstarted/.



Executing a SOAP operation from soapUI

     

1. Open the operation by clicking on the box containing a plus sign. Rename the name of the request from "Request1" to something more recognizable like "authenticate."

2. Double-click the authenticate operation you just renamed. You see the "request" operation.

3. You'll modify the elements of the request in order for it to be accepted by the service.

 
 

4. Add the service endpoint—where the request will be sent. You can add a new one—that will be remembered for the next time you try.

5. Click the green arrow to execute the SOAP request and get the reply back. In this case, it's successful and it yields a session key that you'll want to retain for other uses: it's good for about 30 minutes.



A practical demonstration...

Here's how to debug a change in AMP, a service I'm working on. In this example, we're debugging its use of Flexera licensing on Red Hat Enterprise Linux 5.4. Before getting started, AMP must be installed. As this is a proprietary consideration, you may not have access to this document, but the details are similar for any piece of software you're working on: get the service installed and working.

In my case, I'm trying to track down missing symbols that are keeping my JNI, a shared object, from loading when a Java class is loaded.

  1. Halt the service running, in my case, Apache ServiceMix: 
        russ@rhel-32:~/AMP/licensing/AMPLicJni/Release> sudo /etc/init.d/smx stop
  2. Replace what it is you're updating, trying out, etc. in the target software. You should have stopped the dæmon prior to attempting to replace these. 
        russ@rhel-32:~/AMP/licensing/AMPLicJni/Release> cp libamp*.so $AMP_HOME/esb/lib/
  3. (Note to self: Always change the check property setting to "false" in $AMP_HOME/esb/conf/servicemix.xml. This will make it so it is not necessary to go authenticate a ServiceMix bus session, then fetch the header and paste it into our SOAP request. It will just ignore that we don't have an authentication header—lots of work and grief saved.)
    4.  
  4. With the new parts we are debugging or testing in replacement for the old ones, re-launch the dæmon: 
        russ@rhel-32:~/AMP/licensing/AMPLicJni/Release> sudo /etc/init.d/smx start
  5. At this point, launch soapUI. This is how we're going to force our application to encounter the new code we've written.
     

6. Create a new project, "Licensing." I've named it thus because it's my new licensing stuff that isn't quite working and I'm trying to figure out why.

7. For the Initial WSDL/WADL value, I have to get this from my application. I launch a browser and browse into my application to find this address:

8. I got a 404 error, probably because the URL I typed into the browser is incomplete. No matter, I get what I'm looking for: a list of services including "Licensing," which I click on. I'm going to copy the resulting address line in the browser and use that in soapUI.

 
 

9. Now I'm able to paste the URL in for the Initial WSDL/WADL value of my new soapUI project. Click OK.

10. Via the WSDL at that URL, soapUI is able to populate my project with all the possible (SOAP) operations of my service. Just what and why happens to be something you would only know upon understanding the whole SOAP thing. (See exhoration to learning SOAP above.)

11. Because I'm debugging licensing, I decide to use the "activateLicense" operation. I click on the funny flyspeck at the left of this operation and it opens up to reveal a request named "Request1." Double-clicking that, I get a content window with an XML editor that will allow me to tailor the request I want to send.

 
 

12. I happen to know of available licenses for activation ID "act3" and I'll just use up one of them. Here I show modifying the SOAP request before sending it. soapUI makes this pretty much an exercise in filling in the blank.

13. I click the little green send arrow at the top left to fire the operation at my service. The reply comes back with an error.

  1. I can examine the error here or I can look (more easily) at my log file, which I've tailed. (I've narrowed the log lines to shorten them and wrapped the extremely long ones to better fit this page.) 
        russ@rhel-32:/usr/local/avocent/Management_Platform/logs> tail -f amp-esb.log

    2010/02/10 13:50:56 | Feb 10, 2010 1:50:56 PM org.apache.cxf.transport.jbi.JBITransportFactory setDeliveryChannel
    2010/02/10 13:50:56 | INFO: configuring DeliveryChannel:    org.apache.servicemix.common.EndpointDeliveryChannel@196a464
    2010/02/10 13:50:56 | INFO  - ActivationUtilitySvrJNI        - activateServedLicenseJNI(): activationID=act3 concurrentCount=1
    2010/02/10 13:50:56 | INFO  - ActivationUtilitySvrJNI        - ActivationUtilitySvrJNI.checkLibInitialization: Initializing JNI
    2010/02/10 13:50:56 | INFO  - ActivationUtilitySvrJNI        - initJNI():
    2010/02/10 13:50:56 | INFO  - ActivationUtilityCommon        - loadLibraries: Operating System: LINUX
    2010/02/10 13:50:56 | ERROR - ActivationUtilityCommon        - loadLibraries(): Error loading one of the following libraries:
        FnpCommsSoap and/or FNP_Act_Installer and/or amplicactsvr and/or amplicactapp. If amp-licensing-sa was changed in hotdeploy,
        ServiceMix may need to be restarted.
    2010/02/10 13:50:56 | Exception: /usr/local/avocent/Management_Platform/esb/lib/libamplicactsvr.so:
        /usr/local/avocent/Management_Platform/esb/lib/libamplicactsvr.so: symbol ridjYW, version GLIBC_2.0 not defined in file
        libc.so.6 with link time reference
    2010/02/10 13:50:56 | Feb 10, 2010 1:50:56 PM org.apache.cxf.phase.PhaseInterceptorChain doIntercept
    2010/02/10 13:50:56 | INFO: Application has thrown exception, unwinding now:
        com.avocent.amp.licensing.exceptions.ActivationErrorDetailException:
        Error loading one of the following libraries: FnpCommsSoap and/or FNP_Act_Installer and/or amplicactsvr and/or amplicactapp.
        If amp-licensing-sa was changed in hotdeploy, ServiceMix may need to be restarted.
  2. Examining the error here, I see that I'm still stripping (obfuscating) symbols from my JNI. I resolve to comment out symbol-stripping in Makefile and try again. I will find out a real symbol name, figure out what library I'm not loading (will probably be the wrong version on the executing host) and, I hope, find a solution for supplying the symbol.
    3.  
  3. Save the project for next time.

This concludes my practical demonstration of one way in which I use soapUI.


Appendix: Creating a test suite in soapUI

I'll add something here one day...