Monitoring XML and XML-RPC 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 application specific XML (Extensible Markup Language). This article will discuss using Alertra to monitor HTTP based XML services. The information in this article applies equally well to XML-RPC.
Note: For information on monitoring SOAP services, see this article.
To monitor XML 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 XML version and will need to alter this script to include the XML request and the HTTP request headers.
Formdata and HTTP Headers
To send the XML for the 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 XML for our search function might look like this:
formdata '<?xml version="1.0"?> <productSearch> <CustomerID>9999</CustomerID> <product> <desc attr="partial">Laptop</desc> </product> </productSearch>'
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.
The final script to check an XML service looks like this:
dns "www.example.com" tcp $HTTP_PORT noconnect formdata '<?xml version="1.0"?> <productSearch> <CustomerID>9999</CustomerID> <product> <desc attr="partial">Laptop</desc> </product> </productSearch>' header "Content-type:text/xml; charset=utf-8" 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 sort of XML in $CONTENT is:
<?xml version="1.0"?> <productSearchResult> <product> <name>Dell Inspiron 700m</name> <desc attr="complete">Feature packed ultra portable laptop</desc> <quantity>100</quantity> </product> </productSearchResult>
Then if "Dell Inspiron 700m" is in the results then we know the XML 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.
In this article I've shown how you can use Alertra's powerful scripting language to go from testing everyday web forms to XML based inter-process communications. XML and XML-RPC communications are typically used in business-to-business (B2B) scenarios. If your customers are using XML 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.
Copyright © 2000-2013 Alertra, Inc. All rights reserved. Please read our privacy statement and our terms of service. [C]