Hi
Recently, I ran into a peculiar problem, which really had me fooled a long time.
Basically, I had a BizTalk Server 2006 R2 solution running. It consisted of 10 assemblies. One of the orchestrations in each of 9 of the assemblies was exposed as a web service, all using complex types - no strings, ints and so on.
And then there was the system, that was to call my web services. I had no saying over that system. We started calling the first web service. Everything went ok. Then they implemented code to call the second web service, everything OK... all was well (except some minor things here and there) for the first eight web services.
But at the ninth web service, strange things started to happen.
Basically, the other system would call my web service, IIS would return http 200 OK, but still, no data came into BizTalk. I had NOTHING in group hub page, nothing in HAT, nothing in the eventlog, NOTHING! IIS log said: I received a post on this url and responded with 200 OK - that's it - nothing more.
Really weird - I mean... where did the XML go? Why were there no errors? So we installed YATT, which is an http sniffer tool, that would be able to tell us what was exatly sent across the wires. Basically, what we found out was, that allthough the sender might have send 13000 bytes, the sniffer only reported maybe 10500 bytes. So we started investigating the network. The two servers were on the same subnet, one hop away from eachother. So no servers on the route could mingle with the traffic.
I decided that I would write my own little C# test program, that would call the web service and see if that failed as well. It didn't. I ended up calling the web service succesfully with more than 100k (I didn't bother to try anything higher than that.)
But it turned out, that the sniffer must have a bug - it reported all sorts of different numbers, when using my test program, and none were correct. Apparently, it wasn't created to handle large packets, but just a few kilobytes. So we installed wireshark instead (get it from sourceforge). Now THAT is a nice tool! Totally professional (and free), and it showed us everything that came in and out - no limitations.
So we did a test with my tool, and a test with the other system, and tried comparing the http headers, the soap action, and so on. It turned out, that all the other web services, when called by the other system, returned http 202 Accept and not http 200 OK. And when my test program called the web service, it got the http 202 Accept.
We ended up discovering what the issue was. The other system (programmed in .NET) wasn't calling my web services the "right way". They were sending everything using httprequests. Now, this is a perfectly legal way of doing it, but it really requires that you know what you are doing. I mean: They added a header to the httprequest for the SOAPAction, and then they built up XML with the soap envelope, soap body, elements for the web method and inside that the actual XML. This was just a string that they sent using httprequest.
The answer ended up being that the XML that the other system was sending me had invalid data in elements of type xsd:date. So basically, the XML couldn't be deserialized into the object that my web method on the web service was expecting. Therefore, the web method was never called, and therefore there was no data in biztalks log, the eventlog or anywhere else.
So, I have learned two things from this:
1. You should always accept the help your programming environment gives you. If the programmer of the other system had added a web reference to the web service and built XML and deserialized it into the object that was the parameter, he would have gotten an exception at runtime, that he could debug. The way he did it meant that we got NO errors at all - the data just disappeared (which I think .NET shouldn't do. Some sort of warning somewhere would have been nice.)
2. When debugging, don't trust the tools you download you to help debugging 
I hope this can help someone.
--
eliasen