Overview
The Enterprise Manager test harness that comes bundled
with SOA Suite 11g is a great tool for doing smoke tests and some
minor load testing. When a more robust testing tool is needed, often
times soapUI is leveraged for many reasons ranging from ease of use
to cost effective. However, when you want to start doing some more
complex testing other than synchronous web services with static
content, then the free version of soapUI becomes a bit more
challenging. In this blog I will show you how to test asynchronous
web services with soapUI free edition.
The following assumes that you have a working knowledge
of soapUI and will not go into concepts like setting up a project
etc. For the basics, please review the documentation for soapUI:
http://www.soapui.org/Getting-Started/
Asynchronous
Web Service Testing in soapUI
When invoking an asynchronous web service, the caller
must provide a callback for the response. Since our testing will
originate from soapUI, then it is only natural that soapUI would
provide the callback mechanism. This mechanism in soapUI is called a
MockService.
In a nutshell, a soapUI MockService is a simulation of a Web Service
(aka, a process listening on a port). We will go through the steps
in setting up the MockService for a simple asynchronous BPEL process.
After creating your soapUI project based on an
asynchronous BPEL process, you will see something like the following:
Notice that soapUI created an interface for both the
request and the response (i.e., callback). The interface that was
created for the callback will be used to create the MockService.
Right-click on the callback interface and select the Generate
MockService menu item:
You will be presented with the Generate MockService
dialogue where we will tweak the Path and possibly the port (depends
upon what ports are available on the machine where soapUI will be
running). We will adjust the Path to include the operation name
(append /processResponse in this example) and the port of 8088 is
fine:
Once the MockService is created, you should have
something like the following in soapUI:
This window acts as a console/view into the callback
process. When the play button is pressed (green triangle in the upper
left-hand corner), soapUI will start a process running on the
configured Port that will accept web service invocations on the
configured Path:
At this point we are “almost” ready to try out the
asynchronous test. But first we must provide the web service
addressing (WS-A) configuration on the request message. We will edit
the message for the request interface that was generated when the
project was created (SimpleAsyncBPELProcessBinding > process >
Request 1 in this example). At the bottom of the request message
editor you will find the WS-A configuration by left-clicking on the
WS-A label:
Here we will setup WS-A by changing the default values
to:
Must understand: TRUE
Add default wsa:Action: Add default wsa:Action
(checked)
Reply to: ${host where soapUI is
running}:${MockService Port}${MockService Path} … in this example:
http://192.168.1.181:8088/mockSimpleAsyncBPELProcessCallbackBinding/processResponse
We now are ready to run the asynchronous test from
soapUI free edition. Make sure that the MockService you created is
running and then push the play button for the request (green triangle
in the upper left-hand corner of the request editor). If everything
is configured correctly, you should see the response show up in the
MockService window:
To view the response message/payload, just double-click
on a response message in the Message Log window of the MockService:
At this point you can now expand the project to include
a Test Suite for some load balance tests etc. This same topic has
been covered in various detail on other sites/blogs, but I wanted to
simplify and detail how this is done in the context of SOA Suite 11g.
It also serves as a nice introduction to another blog of mine: SOA
Suite 11g Dynamic Payload Testing with soapUI Free Edition.
