Testing your WSO2 proxies and APIs with SoapUI

In my role as WSO2 Trainer at Yenlo I regularly need to check the training materials. With the advent of WUM (WSO2 Update Manager) we go to a delivery cycle of new WSO2 product releases that warrant the use of a tool to test if all labs in the training still work. I want to be able to deploy a car file to a new server for training (i.e. a new patched version of WSO2 Enterprise Integrator) and run tests. In essence, this is the same goal as a regular test for any production environment. So, I’ve spent some time developing a set of test cases using SoapUI.

SoapUI

I assume that you have installed SoapUI on your computer or instance. Please go to this SoapUI page to find all the instructions. I’ve used the open source version of SoapUI for this test. The paid version has more functionality but the price of EUR 595 per year is prohibitive for this blog purpose. There is a free trial version that we can download that will give more functionality. The trial period is 2 weeks.

Setup

For this blog, we use a setup of the WSO2 Enterprise Integrator 6.2.0, WSO2 Application Server 5.3.0, SoapUI (an older version, 5.2.1) and a sample back-end WAR file called HiRollerBank.

The HiRollerBank back-end is a WAR file that is used for training purposes. It has very simple functionality but it suffices for training setup. You can download the source of the HiRollerBank from this location. If you do not want to build the target WAR file yourself, download it here.

You can either upload the WAR file to the Management UI of the Application Server or drop the war file directly to the [AS-HOME]/repository/deployment/server/webapps directory.

The AS has a port offset of 1 since we deploy both products on the same instance / server / computer. If you have a different setup please change the URL for the service accordingly (i.e. port offset).

We will call the proxy on the EI that will call the back-end and hopefully give a reply when the proxy is correct, the supplied data is correct and no errors are thrown.

Setting Up Soap UI

We create a new Soap project called EI Project. We use the wsdl from the HiRollerBank back-end, the http://localhost:9764/services/HiRollerBankWS/services/accounts?wsdl to be specific. You can find the wsdl in the Management UI (Services) of the Application Server.

To test out the backend, use the checkBalance service with an account number of 1111. You should receive the response of 1234.50.

Now we will set up a TestSuite. Using the menubar, select the New TestSuite option. Alternatively, use CTRL-T.

Name the TestSuite something meaningful.

We now have an empty set of TestCases in our Training Test Set. Go to the TestCases checkmark and click it.

Also name this TestCase.

A new window is created where we can create TestSteps.

We will now create a TestStep in the TestCase. We click the SOAP button and name the TestStep.

Since we created a Soap Project already it suggests using one of the two requests. I am using the checkBalance request we use earlier.

After pressing OK, we get the possibility to specify options.

I am not making any changes to the default options.

Start the test (green Triangle left top corner) and see that the step was ok, it finished without a problem. But what about the content of the message?

It seems that we did not put in a valid account number. The message needs a valid number. We change the message to include a complete message with a valid account number (1111). The message looks like this:

A careful reader will see that we do not call the proxy, but still the back-end.

We will create a proxy that you can use. This is a simple pass-through proxy that shows a log mediator on the console. The proxy looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<proxy name="AccountProxyLAB2" startOnLoad="true" transports="https http" >
    <target>
        <endpoint>
            <address uri="http://localhost:9764/HiRollerBankWS/services/accounts"/>
        </endpoint>
        <inSequence>
            <log description="" level="custom" separator=",">
                <property name="Status" value="Account Balance Request"/>
            </log>
        </inSequence>
        <outSequence>
            <send/>
        </outSequence>
        <faultSequence/>
    </target>
</proxy>

As you can see it is a simple proxy. We called it AccountProxyLAB2 because it is actually one of the training labs.

What about the response?

If we want to assure that the proxy works we need to look at the response. We know that the account number 1111 will return 1234.50 as a balance.

So, what we will do is fill in the account number in the message and instruct SoapUI to automatically confirm that the response contains the correct balance. These checks are called Assertions in SoapUI.

We already have one assertion: the soap response is valid. We go to the assertions tab on the soap message and Press the ‘Green +’ to add an assertion. Since we are using the open source version of SoapUI we have limited choice but we use the Contains option. Alternatively, you can use XPath assertions (using Xpath to check the contents) which is more appropriate for checking XML contents.

Fill in the required response

We rename the assertion

If we either change the accountNo to 1112 or the required response, we get an error.

The response is now of course different and therefor does not pass the test. 

We finally save everything in our project followed by an API test case.

Testing an API

We also want to test an API. In order to make it simple we will use an API that still talks to our same SOAP back-end. The Integrator will make the REST invocation into a SOAP call. What happens is that we have a defined context /myBankAccount and a resource that does a GET on /checkBalance{AccountNo}.

In the InSequence we set the payload with the required Soap message and send the message to the backend. In the OutSequence we set the message type to application/json in order to get the message back in json.

<?xml version="1.0" encoding="UTF-8"?>
<api context="/myBankAccount" name="HiRollerAPI" >
    <resource methods="GET" uri-template="/checkBalance/{AccountNo}">
        <inSequence>
            <payloadFactory media-type="xml">
                <format>
                    <hir:checkBalance xmlns_hir="http://hirollerbankws.training.wso2.com/">
                        <accountNo >$1</accountNo>
                    </hir:checkBalance>
                </format>
                <args>
                    <arg evaluator="xml" expression="get-property('uri.var.AccountNo')"/>
                </args>
            </payloadFactory>
            <property description="" name="messageType" scope="axis2" type="STRING" value="text/xml"/>
            <send>
                <endpoint>
                    <address format="soap11" uri="http://localhost:9764/HiRollerBankWS/services/accounts"/>
                </endpoint>
            </send>
        </inSequence>
        <outSequence>
            <property name="messageType" scope="axis2" type="STRING" value="application/json"/>
            <send/>
        </outSequence>
        <faultSequence/>
    </resource>
</api>

Let’s create a REST service from a URI in SoapUI.

Test the project by trying it out. You see you get a response and a balance. If you get the message ‘cannot be viewed in XML, switch to JSON view as shown in the screenshot below.

We create a new TestCase and add a step. In this case we create a new rest call

And select the REST method.

We again use the Contains option.

We fill in the required value. See that we get 1234.5 back, not 1234.50. However, 1234.50 is also considered valid.

We now see the complete response when we try the API.

You can rename the assertion to something more meaningful.

Building on this example

This was a simple example using EI, AS and SoapUi to build a test set. You can build on this example, looking at different types of assertions, more test sets and test steps and so on.

Please leave a comment in the section below if you have any questions.