Challenge Accepted

Thought I would share an interesting problem I recently had at work.

Our client has a collection of InfoPath forms it uses to connect to web services for testing BizTalk interfaces from external systems. On the whole, these are pretty stock standard affairs, the relevant BizTalk orchestrations are exposed as Web Services (through the magic of BTSWebSvcPub) and the InfoPath forms (prettied up for client usage of course) submit test messages. This enables them to do pseudo end-to-end testing without having to get half the world involved. Amusingly (amusing because it only just occurred to us), a few days ago I realised we would need to upgrade these forms in line with our BizTalk 2010 upgrade project.

Let the games begin.

As far as things go, it was pretty straight forward. I refreshed the web service references and checked the forms still compiled. So far so good (well, minus a few bits and pieces cropping up, but not relevant to this post). And then came the testing of the forms, and by that I really mean… *head-desk*.

When I clicked the “Submit” button… nothing. Absolutely nothing. Oh Infopath was happily assuring me everything was ok and working awesomely, but on checking BizTalk (and the DB of the relevant application), absolutely nothing. No messages were suspending (BizTalk side), nor were there any validation errors (application side). So a bit of head scratching, a bit of googling and this left me with a lot of issues completely not relevant to my problem. On a side note, googling “vanishing web service requests” unsurprisingly doesn’t yield too much useful information. I also scoured the event viewers of the BizTalk servers and application servers (I even got desperate and checked the event viewer of the machine I was calling the Infopath forms from), all to no avail.

Then I checked the IIS logs of the machine where the web services were hosted, and I spotted a HTTP code Id never really seen; the “202” code. This is the “Request Accepted” HTTP code and means that the server has accepted the request (Yay), and the request (this is important) might or might not be acted upon, as it might be disallowed when processing actually takes place. Initally I thought “Awesome, so its definitely hitting IIS and getting through the web service, so WHY OH WHY isnt it getting through to BizTalk?”. So some more headscratching, googling and *head-desking* later, the penny finally dropped.

Accepted != Ok.

The HTTP codes 202 and 200 are completely different (duh), meaning that while it DID hit the web service successfully, the fact nothing happened in BizTalk afterwards means something must be stopping it in between when it hits IIS and when its supposed to hit BizTalk/MessageBox (keep in mind BizTalk is just a bunch of SQL DBs that require the correct credentials to connect to). This was why I wasnt getting any suspensions in BizTalk, it denying the credentials supplied by the web service as they didnt exist in the DB! So on checking the service accounts that these orchestration web services were using, it stuck out like a sore thumb… I had configured the web services to connect to outside entities using our normal dev service account. While this is ok for our local dev environments (as its what we mostly configure our web services with), I had forgotten that these web services were a completely different beast, and as such should have been configured with the default service account the rest of the IIS Application Pools were using!!

So once Id reconfigured the application pools and fired off an Infopath message, they hit BizTalk (and then the application) successfully! Huzzah!

While this is a bit of a *facepalm* moment for me, I thought it was interesting that in terms of actual ‘error messages’ there were none immediately visible, only the symptom of a vanishing message. It made me look a bit deeper into things than I usually would (in this world of “GOOGLE ALL THE ERROR MESSAGES!!1!1”), and was quite satisfying when I did eventually figure out what was going on. Thinking about it now actually, I think if I checked the DB Server event viewers Id probably find a few Audit Failure events. Hope this helps someone out there with a symptom of (seemingly) vanishing messages 🙂

Night all!


Tags: , , ,

About AntiRich

I love gaming, across all platforms. My favourite game would be Counter Strike: Global Offensive.

4 responses to “Challenge Accepted”

  1. Johann says :

    Hi Adam, it always pays to browse to the wsdl for your BizTalk exposed service as (at least with WCF, I’m guessing asmx web services would be consistent) you will receive an error message that guides to you towards what the problem might be, in this case your application pool identity not having the appropriate rights to connect to the BizTalk SQL database. Good post.

  2. Adam Grande says :

    Hi Johann, thanks for commenting! 🙂 yep, the web services were browsing just fine… thats what made it so initially infuriating, because for all intents and purposes everything *seemed* fine. when you browse the web service, it wasnt actually creating the connection to whatever the web service is supposed to talk to (biztalk in this case), its just exposing the fact “hey, im a web service and im here!”, which is why (at that point) it was browsing ok. the app pool it was using (while not completely correct) still had the relevant permissions/config to allow someone to browse to it. like i said in my post, i just found it so fascinating that there were no immediately visible errors (like youd normally expect when an app pool is configured incorrectly). thankyou for the feedback 🙂

  3. Johann says :

    Just one more reason the wcf adapters are pretty cool. When you have a WCF service hosted within an isolated host which exposes metadata, browsing to the wsdl gives you a pretty good idea whether your service had the correct permissions or had any other configuration type errors(you’d have to turn on exception details in fault messages if you wanted the actual exception messages to be exposed on any PC other than that which the service is hosted on).

    Obviously when you’re dealing with a legacy BizTalk application you don’t have the luxury of WCF but it does make one more appreciative of the framework and how well it plays with BizTalk.

    • Adam Grande says :

      damn, that is cool. haha most of the stuff ive been dealing with the past few years has been legacy, but i will definitely keep it in mind for my future biztalk related stuff 🙂 thanks!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: