Search
Close this search box.

Debugging SOAP messages with WireShark

If you’re debugging Web service calls, you may want to capture incoming requests so you can see exactly what’s reaching the service. If BizTalk’s hosting the Web service, it’s a simple process of adding a FILE send port filtered on the receive port name to copy all incoming messages. If this isn’t an option, or if you want the full SOAP envelope together with metadata about the call, you can use a packet sniffer.

Packet sniffers monitor traffic over a machine NIC, and show you exactly what was sent or received over the wire. An excellent, free tool is WireShark (previously “Ethereal”), which has an rich suite of functionality, but has a bit of a learning curve. To use it exclusively for SOAP debugging is a matter of correctly configuring filters.

Run WireShark on the machine hosting your Web service. Open Capture…Options (screenshots below are from version 1.0.5). You’ll be shown all the NICs on your machine, select one (it may be trial-and-error to pick the right NIC if you have multiple cards on a server) and configure it as shown:

The key options to set are:

  • Enable network name resolution (makes identifying traffic much easier)
  • Capture Filter = tcp port http (this captures TCP packets over default port 80).

Specifying a Capture Filter limits the amount of traffic logged, but isn’t necessary if you’re not using the default port, as you can also filter results. Click Start and send some calls in to your Web service. Note the capture only operates over the selected NIC, so calls to localhost won’t be recorded – you’ll need to make requests from a separate machine. You’ll see the network traffic building up in the results pane:

Source and Destination will show the names of the communicating machines if WireShark has been able to resolve them, IP addresses if not. Enter a filter of xml and only packets representing XML exchanges over HTTP will be shown. It’s simple to identify the service calls as they will be listed as POSTs to the service endpoint. Note that these are individual TCP packets. WireShark can reassemble all the packets in an exchange to show the full conversation – right click one packet and select “Follow TCP Stream”.

The full stream will be shown, and can be converted between known formats or saved. The stream includes metadata information on the exchange and the full SOAP envelope:

POST /ESB.ItineraryServices.Response/ProcessItinerary.asmx HTTP/1.1

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; MS Web Services Client Protocol 2.0.50727.3053)

Content-Type: text/xml; charset=utf-8

SOAPAction: "http://microsoft.practices.esb/Process/SubmitRequestResponse"

Host: itinerary-service

Content-Length: 1635

Expect: 100-continue

Connection: Keep-Alive

 

<?xml version="1.0" encoding="utf-8"?>

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">

    <soap:Header>

        <Itinerary xmlns="http://schemas.microsoft.biztalk.practices.esb.com/itinerary">

            …

    <soap:Body>

        <SubmitRequestResponse xmlns="http://microsoft.practices.esb">

            <Root xmlns="http://schemas.microsoft.com/BizTalk/2003/Any">

                …

– in this case, a request to the itinerary service from Microsoft’s ESB Guidance package, capturing the full itinerary in the header and the service payload in the body. Any response sent to the caller will also be shown.

This article is part of the GWB Archives. Original Author: Elton Stoneman

Related Posts