Testing BizTalk WCF End Points with Anonymous Authentication

Sometimes, because my life’s so exciting, I need to test an HTTP push into my local dev instance of BizTalk. In other words, I have a one-way receive port ready to consume an XML message into BizTalk through a WCF web service. The web service IIS components and schemas have been generated through BizTalk WCF Service Publishing Wizard and deployed. Now I just want to try a local HTTP push of a sample message and ensure BizTalk picks it up.

There are various ways you could go about this, the below is just my preferred method.

First, I’d find the web service in IIS, look under Authentication, and ensure Anonymous is set to Enabled. This is because I don’t plan to use any security measures for this local test.

Then, I’d find the Receive Location for the web service in the BizTalk Administration Console. Hit Configure, and take a look at the Binding tab. I’m using basicHttpBinding, and under Security I would set the mode to None for the same reason (i.e. I’m not using certificates or other security practices for this local test).

Still in the Receive Location configuration, time to have a look at Behavior. I’m going to use the handy (and free) utility SoapUI to generate my HTTP request for me, because I’m lazy that way. If you want to do the same, you need to right-click ServiceBehavior and Add a serviceMetadata extension.

Then, select the new extension and set httpGetEnabled to True:

With these settings, if you access the web service with a normal GET (e.g. by navigating through a browser), you should see the web service definition in WSDL. Start a SoapUI project, and Add WSDL, providing the same address. SoapUI should consume the WSDL and use it to create a sample request message for you.

(NOTE: If you couldn’t/wouldn’t/shouldn’t use SoapUI, You can use BizTalk to generate an instance of your schema instead, but then you’ll have to wrap it in a Soap envelope yourself, and possibly tweak other settings in a client. Not loads of fun 🙁 )

Finally, you can use SoapUI to fire the sample message, and with any luck you might get a 200 response, and some indication that BizTalk received the message.

Sudden Bonus Section: Gotchas

The above’s all well and good, but I tend to find that in reality I run into some combination of errors when I’m trying to post to the web service. Here’s a bunch of things I’ve had to check/tweak, in no particular order:

Error 415: Cannot process the message because the content type is not the expected content type
Check the HTTP headers in your client request. They don’t match what the service expects.

Error 400: Bad request
Wasn’t there a Lady Gaga song about this? No? Anyway, the content of your request is bad. Did you remember to wrap it in a Soap envelope and check it’s valid XML?

Error 500 (without Soap response)
Loads of potential causes. The one I’ve had most commonly is that my web service can’t read its own web.config on the filesystem. I had to grant access to the App Pool account

Error 500 (with Soap faultcode FailedAuthentication)
The faultstring is “Access is denied”. Bit harsh if you ask me. This is the trickiest one I’ve encountered, and it was because the ServiceAuthorization Behavior was missing on my Receive Location. Once I added it back as a behavior extension, it started working.

Error 502: Connection refused
Even harsher than access denied. This might mean you’re trying to connect using HTTPS and certificates (rather than HTTP). My examples above are all http, so shouldn’t run into this.