top bar top logo bar top bar
left design right design
spacer bar

Testing and Monitoring Web Services With WebInject


More tools by Corey Goldberg:  www.goldb.org
Subscribe To Corey's Blog Subscribe To Goldblog


Web Services

Web Services use HTTP as the the application layer protocol to exchange messages over the network. WebInject can be used to send these messages (usually XML payloads) and verify/validate the response messages returned by your service. This enables you to functionally test your Web Service, and allows you to set up a transaction monitor for service-level monitoring of response times. It is useful for testing web service protocols such as SOAP or XML-RPC.

Example: The Google Web API (SOAP/XML Web Service)

Google provides a public SOAP/XML API to their Web Services. They provide a developer's kit with samples and instructions on how to use the service. We will go through an example of how WebInject could be used to test and monitor this Web Service.

(see: http://www.google.com/apis for information about the Google Web API)

The following example shows an XML payload which contains a SOAP envelope we will send to the Google Web API. This envelope will instruct the server to use Google's search engine to query for the phrase "webinject automated tool". For this example, we will save this in a file named 'doGoogleSearch.xml'.

<?xml version='1.0' encoding='UTF-8'?>

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" 
        xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" 
        xmlns:xsd="http://www.w3.org/1999/XMLSchema">
    <SOAP-ENV:Body>
        <ns1:doGoogleSearch xmlns:ns1="urn:GoogleSearch" 
                SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
            <key xsi:type="xsd:string">00000000000000000000000000000000</key>
            <q xsi:type="xsd:string">webinject automated tool</q>
            <start xsi:type="xsd:int">0</start>
            <maxResults xsi:type="xsd:int">10</maxResults>
            <filter xsi:type="xsd:boolean">true</filter>
            <restrict xsi:type="xsd:string"></restrict>
            <safeSearch xsi:type="xsd:boolean">false</safeSearch>
            <lr xsi:type="xsd:string"></lr>
            <ie xsi:type="xsd:string">latin1</ie>
            <oe xsi:type="xsd:string">latin1</oe>
            </ns1:doGoogleSearch>
    </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

*Note: This sample has the authentication key set to all zeros. To actually run this example properly, you will need to create an account with Google and use the license key you are provided.

WebInject Test Case File

We create a test case file (named 'test_google.xml' in this example) containing a case that will send our SOAP envelope file. We pass the XML file containg the SOAP envelope into our test case using the 'file=>' syntax in the 'postbody' parameter. We also set the 'posttype' parameter (which controls the HTTP Content-Type header) to "text/xml".

In the test case we specify the URL to send send this request to (as specified by Google), a pointer to our XML file containing the SOAP envelope (which is in the same directory as WebInject), and a string to verify in our response (the string "Corey Goldberg" must be present).

<testcases repeat="1">

<case
    id="1"
    description1="Web Services Sample - Google Search API"
    url="http://api.google.com/search/beta2"
    method="post"
    posttype="text/xml"
    postbody="file=>doGoogleSearch.xml"
    verifypositive="Corey Goldberg"
/>

</testcases>

*Note: Depending on your Web Service, you may need to change this to "application/soap+xml". Some SOAP services also require a SOAPAction header. This (or any other custom HTTP header) can be added using the 'addheader' parameter in your test case.

Running a Test (Pass)

Next we will see what happens when a test passes. In this case, we will see all 3 of our verification points pass. The HTTP response code will not be in the error range, our verifypositive keyword verification will exist in the response, and the payload received in the HTTP body will parse correctly as WebInject sends it through the XML parser to verify it is well-formed XML.

Here is the output as we run the test case file through WebInject (using command-line mode; you could optionally use the GUI):

$perl webinject.pl test_google.xml

Starting WebInject Engine...

-------------------------------------------------------
Test:  test_google.xml - 1 
Web Services Sample - Google Search API 
Verify: "Corey Goldberg" 
Passed XML Parser (content is well-formed) 
Passed Positive Verification 
Passed HTTP Response Code Verification (not in error range) 
TEST CASE PASSED 
Response Time = 2.673 sec 
------------------------------------------------------- 
    
Start Time: Thu Oct 20 16:56:15 2005
Total Run Time: 3.043 seconds

Test Cases Run: 1
Test Cases Passed: 1
Test Cases Failed: 0 
Verifications Passed: 3
Verifications Failed: 0

Running a Test (Fail)

Next we will see what happens when a test fails. I changed the test case (in 'test_google.xml') so it will submit our payload to an incorrect URL. In this case, we will see all 3 of our verification points fail. The HTTP response code will be in the error range or non-existent, our verifypositive keyword verification will not exist in the response, and the payload received in the HTTP body will fail as WebInject sends it through the XML parser to verify it is well-formed XML.

Here is the output as we run the test case file through WebInject (using command-line mode; you could optionally use the GUI):

$ perl webinject.pl test_google.xml 

Starting WebInject Engine...

-------------------------------------------------------
Test:  test_google.xml - 1 
Web Services Sample - Google Search API 
Verify: "Corey Goldberg" 
Failed XML Parser: 
syntax error at line 1, column 0, byte 0
 
Failed Positive Verification 
Failed - No Response 
TEST CASE FAILED
Response Time = 0.373 sec 
------------------------------------------------------- 
    
Start Time: Fri Oct 21 11:16:09 2005
Total Run Time: 0.809 seconds

Test Cases Run: 1
Test Cases Passed: 0
Test Cases Failed: 1 
Verifications Passed: 0
Verifications Failed: 3

A Simple Web Service Monitor

We can add 'repeat' and 'sleep' attrributes to the example above to create a simple monitor. This will hit the service every 60 seconds so we can make sure the service is functioning correctly and response times are within an acceptable range (to meet your SLA or quality of service criteria).

<testcases repeat="1000000">

<case
    id="1"
    description1="Web Services Sample - Google Search API"
    url="http://api.google.com/search/beta2"
    method="post"
    posttype="text/xml"
    postbody="file=>doGoogleSearch.xml"
    verifypositive="Corey Goldberg"
    sleep="60"
/>

</testcases>

Web Services Monitor Sample (with WebInject GUI):

Web Services Monitor Sample Output

(click image to enlarge)

Additional Ways WebInject Can Monitor Your Web Service

WebInject can also be integrated as a plugin for external monitoring systems. In this case, it is used in console mode as an intelligent test agent that returns status and response times to your external program.

For real-time monitoring of your web applications or web services, WebInject is able to run in a mode that makes it compatible with Nagios. Nagios is an open source host, service, and network monitoring program.

For graphical trending of web service-levels over a long period of time, WebInject is able to run in a mode that makes it compatible with MRTG. MRTG (Multi Router Traffic Grapher) is an open source tool for collecting, storing, and graphing time-series data.