Monitoring SOAP Services

HTTP (HyperText Transfer Protocol) has typically been used as a means of publishing HTML data for display by web browsers to be seen by end users. But HTTP itself is really a general query and response mechanism that can support many different kinds of queries and responses. Queries are not limited to requests for HTML pages or graphics and responses not limited to data to be displayed in a browser. HTTP is now being used as a means of IPC (Inter-process communication) where programs exchange data between themselves.

One of the ways IPC is accomplished over HTTP is by using the XML (Extensible Markup Language) based SOAP protocol.

Note: For information on monitoring application specific XML and XML-RPC services, see this article.

Getting Started

To monitor SOAP services you'll need to use an Alertra Script device. Alertra custom scripts allow you fine grained control over how a device is checked. With ASL (Alertra Scripting Language) complex interactions with Internet connected devices can be easily constructed. You can find a tutorial on writing ASL scripts here.

Here is a basic script to post to a page on a web server:

dns "www.example.com"
tcp $HTTP_PORT noconnect

form customerID="9999"
form searchProductID="Laptop"

http post "/search.asp"
if not "Dell Inspiron 700m" in $CONTENT then error "Search not functioning"

This script could be used to monitor the product search page on a web site to see if the proper data was returned. However, we want to test the SOAP version and will need to alter this script to include the SOAP request and the HTTP request headers.

Formdata and HTTP Headers

To send the XML for the SOAP request, we'll use the formdata command instead of form. Formdata allows complete control over the data sent to the server, while form packages up the variables and their data into an encoded format expected by most web forms. The formdata and SOAP XML for our search function might look like this:

formdata '<?xml version="1.0" encoding="UTF-8" ?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <SOAP-ENV:Body>
  <productSearch xmlns="urn:ProductCatalog">
   <query>
<CustomerID>9999</CustomerID>
<product>
<desc attr="partial">Laptop</desc>
</product>
   </query>
  </productSearch>
 </SOAP-ENV:Body>
</SOAP-ENV:Envelope>'

This formdata looks a little different that the examples in the ASL reference. First of all, the alternate quote character " ' " (the single quote) is used instead of the regular double quote. This is because the data we are sending has embedded double quotes which would cause a parser error. Secondly, the string spans multiple lines. You could take out all of the newlines and make it fit all on one line, but it makes the script easier to read to leave them in; ASL doesn't care either way.

Next we need to override the Content-type header. Normally ASL sets the Content-type header for you to "application/x-www-form-urlencoded" when you post data to an HTTP URL. But that isn't what we want since we are not dealing with a traditional form. To override the Content-type use the header command:

 

header "Content-type:text/xml; charset=utf-8"

This specifies that we are sending plain XML data, not encoded form data.

Finally we need to set the SOAP Action:

header 'SOAPAction: "urn:ProductCatalog/productSearch"'

Final Script

The final script to check a SOAP service looks like this:

dns "www.example.com"
tcp $HTTP_PORT noconnect

formdata '<?xml version="1.0" encoding="UTF-8" ?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <SOAP-ENV:Body>
  <productSearch xmlns="urn:ProductCatalog">
   <query>
<CustomerID>9999</CustomerID>
<product>
<desc attr="partial">Laptop</desc>
</product>
   </query>
  </productSearch>
 </SOAP-ENV:Body>
</SOAP-ENV:Envelope>'

header "Content-type:text/xml; charset=utf-8"
header 'SOAPAction: "urn:ProductCatalog/productSearch"'
http post "/search.asp"
if not "Dell Inspiron 700m" in $CONTENT then error "Search not functioning"

This removes the form statements and replaces them with formdata which gives us finer control over the data being sent. It also now includes our header command that explicitly sets the type of data we are sending.

If the response to this request in $CONTENT is:

<?xml version="1.0" encoding="UTF-8" ?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <SOAP-ENV:Body>
  <productSearch xmlns="urn:ProductCatalog">
   <result>
<CustomerID>9999</CustomerID>
<product>
<name>Dell Inspiron 700m</name>
<desc attr="complete">Feature packed ultra portable laptop</desc>
<quantity>100</quantity>
</product>
   </result>
  </productSearch>
 </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Then if "Dell Inspiron 700m" is in the results then we know the SOAP service is working properly. If it is not there, then the script fails and you are notified that there is a problem with the service.

Summary

In this article I've shown how you can use Alertra's powerful scripting language to go from testing everyday web forms to SOAP based inter-process communications. SOAP communications are typically used in business-to-business (B2B) scenarios. If your customers are using SOAP to interact with your ordering system or any other mission critical system, use an Alertra script to verify the integrity of the service. Know about the problem before your customers know.