Let's have a look at one of the most overlooked features in soapUI, the HTTP Monitor. This nifty feature allows you to monitor, record, analyze and even modify HTTP traffic as it is been transferred between an existing client and server application. It even supports WS-Security and SSL decryption (if you have all the necessary keystores available) for digging into encrypted messages.
The HTTP Monitor is a handy feature in soapUI for capturing and analyzing SOAP traffic going between an existing client and server. It is launched via the right-button menu of a soapUI Project, which opens the following configuration dialog:
Here you have two major options on how to run the monitor: Proxy and HTTP Tunnel (if you are familiar with apache tcpmon you should recognize this).
In proxy-mode, soapUI acts as a standard HTTP Proxy forwarding messages received from the client to the specified host. The client in its turn must be configured to use soapUI as an HTTP proxy, either via system properties or some other configuration option. This has the advantage of not requiring you to change the actual endpoint the client is using to access the service (usually the proxy can be configured "outside" of your clients environment).
In tunnel-mode, the client must be configured to send its requests directly to soapUI, which will tunnel the request to the specified target host and return the response back. The advantage is that it does not make use of the HTTP Proxy mechanism (which may not be supported/configurable/etc), and also allows for the possibility to intercept SSL-encrypted traffic.
WS-Security and SSL Support
In either mode you have the possibility to specify an Incoming WSS configuration that will be used to decrypt and/or verify signatures in these messages, either the request coming from the client or the response coming from the server. Adding WS-Security to an outgoing message is not currently possible.
In HTTP-Tunnel mode you can also configure soapUI to support SSL decryption, incoming requests will be decrypted using the specified keystore (which must be the same as on the target server) and an option client-keystore can be specified for re-encrypting the message when it is tunnel forward to the target server (if it requires client-certificates).
Either of these can be useful if you want to decrypt message content "on the wire" to be able to analyze their content, modify it, etc.
Once started as desired, the following SOAP Monitor window will be opened:
This displays logged messages in the table at the top and shows selected message details at the bottom, including all the advanced views and inspectors available in the standard message editors, which makes inspection and analysis of captured messages a "breeze" (especially for soapUI Pro-users).
Entries can be filtered with the different Combo-Boxes in the toolbar and there are a bunch of other actions available that you should look at a little later.
So that's the background, lets get going! Start by creating a new project for the CurrencyConverter service (http://www.webservicex.net/CurrencyConvertor.asmx?WSDL):
Once created, start the SOAP Monitor from the Project popup with the following configuration:
The Set as Proxy option will configure soapUI itself to use the Monitor as a Proxy (check the global Proxy settings to see the entered values), allowing us to capture traffic going from soapUI to the target service and back.
Once running, open a request to the service in soapUI and send it off, you will get a response as usual but with the addition of the entire exchange being logged in the monitor.
As you can see I've fired off a bunch of requests, the table shows response times, message sizes, etc.. Selecting a message shows its content at the bottom.
This is pretty basic, but you get the idea. All requests are routed through soapUI and captured for analysis. You can do now a bunch of cool stuff!
Generate Functional Tests and MockServices
Say you have captured a long-going conversation between an existing client and server and you want to be able to replay either the client or server part of it. Piece of cake! Select the captured messages in the log table and select the Add to TestCase button, which will prompt as follows:
Selecting OK will generate a TestCase containing the same Requests sent by the client which can now be replayed/reconfigured as desired.
Back to the monitor, now select the Add To MockService button.
Not surprisingly, pressing OK will generate a MockService containing all the received response messages, allowing you to mock the entire conversation.
Specify endpoint for MockService and apply that endpoint to all your requests. Now starting the MockService and running the TestCase will basically rerun the entire conversation inside soapUI (If you have still have the SOAP Monitor going you'll see it running through there as well).
The top shows the TestCase with its four captured requests, the bottom the SOAP Monitor as they passed through it (the first four entries are the ones I initially captured). You can see that the request/response messages are the same size, performance is slightly better for the MockService.
Measure Coverage for the WSDL
WSDL Coverage is one of the cooler additions in soapUI Pro (check out http://www.soapui.org/userguide/coverage.html for more details); in the SOAP Monitor you can use it to measure utilization of your WSDL contract in your captured traffic. For example you could run a day of traffic through this and then analyze the coverage to see if you are even using all of the elements/operation/faults defined or if some seem to be unused, etc.
To use it just switch to the Monitor Coverage tab and enable it, all logged messages will automatically be added to the current coverage calculation.
Here i just reran the recorded TestCase, which gives me 100% Coverage on the SOAP 1.1 binding of the CurrencyConverter, but it seems I forgot to capture/test the SOAP 1.2 version.
Wrapping it up
That's about it for now, also read about the SOAP Monitor in our User Guide at http://www.soapui.org/userguide/monitor/index.html.
Planned future improvements are currently as follows:
- Full HTTP support (not only POST/SOAP) so any HTTP/REST traffic can be captured/analyzed/etc
- Possibility to configure multiple monitors per soapUI Project, with assertions, etc.
- Simplified scripting possibilities
- Anything else our fantastic community asks for!