Thursday, 22 November 2007

Hi

Inspired by my post some weeks ago about me mending a fuse on our car, I really have outdone myself this time.

First of all, I have changed a light bulbe on my parents car.

Secondly, I have exchanged the dripping faucet in our kitchen for a brand new none-dripping one. It was actually quite a mess, and after a couple of trial-and-errors, I got it working. So now we have a new faucet in the kitchen - it doesn't drip, and I made the switch!

:-)

--
eliasen

Thursday, 22 November 2007 00:37:43 (Romance Standard Time, UTC+01:00)  #    Comments [0]  | 

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

Thursday, 22 November 2007 00:34:20 (Romance Standard Time, UTC+01:00)  #    Comments [0]  | 

Hi

I am currently supporting an existing BizTalk 2004 environment, and came across the need to debug an orchestration in the production environment. Yes, I know - "Not in the production environment", you scream... but yes, indeed - in the production environment.

Anyway, I set some breakpoints, waited for the orchestration to hit the breakpoint and tried to attach to the orchestration. I got this error:

Debugging user validation against group '<servername>\BizTalk Server Administrators' failed with error: Debuging Client is not a BizTalk Server Administrator.

This seemed odd, so I investigated a bit further. It turns out, that the setup is a multiple server setup, ie. one server for SQL Server and one for BizTalk 2004. Also, it tunrs out, that the gyuy who installed the servers didn't use domain groups. The services were running under domain accounts, but the BizTalk groups were created on both machines. Not a supported setup, but I am hoping they will upgrade to BizTalk 2006 R2 before long, and therefore, we are not going to touch that.

Anyway, it turns out, that the user I was logged in as was a member of the "BizTalk Server Administrators" group - but only on the BizTalk Server. Once I added him to the same group on the SQL Server server, all was fine.

I googled the error, and didn't stumble upon an answer, so I just thought I'd blog about it in case anyone has the need for the answer some day :-)

--
eliasen

Thursday, 22 November 2007 00:11:37 (Romance Standard Time, UTC+01:00)  #    Comments [0]  | 

Theme design by Jelle Druyts