views:

612

answers:

6

I'm trying to work out what a BizTalk call to a web service is failing, and want to see what the actual message content is. I found Elton Stoneman's blog on using WireShark which got me going, and I can now at least see the POST and SOAP response packets, but getting the actual content is very laborious ... copy and paste to Notepad ...

Is there a better way to to see the message ?
- I tried using Fiddler, but it didn't see any message
- whereas at least WireShark can see things

And if you do have suggestions, please spell them out as this is a new area to me :-)

+3  A: 

I see two choices here. In Wireshark you can select a packet from the connection of interest and from the Analyze menu chose Follow TCP Stream. This will bring up a new window displaying the properly sequenced TCP data for that connection.

It may, however, be more convenient to collect the data using a program called tcpflow, which will record this in to text files that you can use for later analysis.

Curt Sampson
Thanks for the response, but is there anything a wee bit more modern ? ... *The most recent version of tcpflow is v0.21, released 7 August 2003*
SteveC
It does seem to me that there's no more modern version of tcpflow because what it does is simple and fairly well perfected. In other words, you might as well ask for a more modern version of the Unix cat(1) command. :-)
Curt Sampson
I can't fault the "if it ain't broke, don't fix it" approach :-)
SteveC
Just spotted the comment about the Follow TCP Stream option ... that's a lot better, thanks again
SteveC
+1  A: 

Windows Network Monitor has always been my tool of choice:

Windows network Monitor 3.3

Requires some network protocol knowledge but very easy to use. I've debugged HTTP, SOAP and FTP with this.

ChrisLoris
+2  A: 

There are two really good SOAP debugging utilities...

** Fiddler2

http://www.fiddler2.com/fiddler2/

This is a relatively simple utility - you can capture requests and responses. If you are fortunate you can get it to act as a proxy so you don't have to reconfigure anything. I have had varied experiences with that, so I usually just reconfigure my ports to get it to capture.

The downside to Fiddler is that it matches a request to a response, so it won't show messages that don't receive replies. If you are debugging something that may not respond, or want more, try soapUI.

** soapUI

http://www.soapui.org/

This is like Fiiddler2, but goes a step further. You can capture requests and responses and then you can modify the request yourself and send it to your endpoint. You can also use the captured responses to get soapUI to act as a mock server for you. These two capabilities are really useful in cases where it takes a long time to generate a request or you want to see how your systems handles specific types of responses.

(I'm not affiliated with either, just a happy customer!)

Erik Westermann
I couldn't seem to get Fiddler to see any messages, but this all new to me, so I could easily be missing something SoapUI sounds interesting, will give it a lookThanks for the response
SteveC
A: 

You can use Microsoft's SOAP Toolkit, then, if you are using a WCF adapter, use the clientVia option.

If you are interested in the message itself (not the full SOAP stuff), you can configure a sent port group and send each message both to the WebService and to a local folder. This way, you can easily see the content of all the messages sent.

Philippe
+1  A: 

I've been happy with Simon Fell's YATT, "Yet Another Trace Tool" from PocketSoap.com. You can see all traffic over a given network connection or you can filter it.

Like all tracers, letting it run open and unfiltered will scare you as you find out how many of your benign applications "phone home" every once in a while.

Beware, though, that if you use SSL (HTTPS) you will have a hard time tracing the contents of packages.

Brian Travis
+1  A: 

To use Fiddler2 together with a BizTalk sendport pointing to a local service you will need to replace the hostname 'localhost' with 'ipv4.fiddler'

Eg. http://ipv4.fiddler:8080/UrlToYourService

magnus