I’ve done plenty of development projects on my own to make sure I know how to expose an orchestration through a webservice (”expose” is probably the wrong word but it’s what the industry uses.) What I haven’t done is deployed a webservice created for an orchestration to another server, such as a test box. Guess what I’ve been doing recently??
Deploying the BizTalk bits is standard stuff so I didn’t have any issues on that end. I was hoping the web service deployment would be a simple copy-paste and set up the website. Turns out there is plenty of other stuff to do along the way. Most of it, I learned the hard way: Fix error retest research error fix error retest…You get the idea. I say it’s the hard way, but I enjoy it. I get to learn a lot of things I wouldn’t had there been a simple checklist to follow (which, by the way, there isn’t (at least a complete checklist.))
The main reason for this post was to publish the checklist that worked for me. Not so folks can blindly follow it, because depending on your architecture this may not work for you, but rather to get some information out there so that it can get folks thinking along the right lines. I also wanted to have a trail of what I ran into and how it was solved in case I’m ever in a similar situation.
Before I run through what was done I should explain the architecture. I was deploying the web service on the BizTalk box (Win2003), which connects to a SQL Server on another box (Win2003). That’s it. Simple. That’s what I thought, too!
So without further ado, here’s what I went through to get the web service and orchestration set up so they could talk properly. Like I said before, deploying the BizTalk piece was nothing new so I won’t go over that.
Web Service install: Getting the service there is a simple copy-paste. Now comes the fun part.
- SOAP and SQL adapters run in through the BizTalk Isolated Host. What this means for the web service is that it needs to run under a user that has access to run this service. To do that, set up an Application Pool in IIS and configure the identity that it runs under to be a user that is a member of the group that runs the Isolated Host. In my case, it was a domain group. Now configure the web application (I’m assuming this was already created) for the web service to run in this new Application Pool.
- Remember (or in my case, write down) the user you used for the App Pool identity
- In my case, I wanted to set up a separate website just for web services published for BizTalk. So I did. On my dev box I didn’t do that (WinXP). So after I set up the new website on the desired port, I thought I needed to modify the receive port binding. The virtual directory setting on the binding remains relative, meaning “/ApplicationName/WebService.asmx“. There is no documentation on this setup and my search came up empty, so I assumed BizTalk would need something more to tell it the website was not on the default web site. After playing around quite a bit with the virtual directory and public address values, turns out my assumption was wrong and BizTalk is smart enough to figure it out. Good little BizTalk…sit…stay…rollover…Good Boy!! End result: No changes to the binding. I still have no idea what good the Public address setting is, though.
- This one took me a while, mainly due to the webservice being one-way. One of the aspects of one-way services is that if there is an error, the client doesn’t get to know about it. Which means when I would test it, I could see in the IIS logs that there was a 500 response, but the client would never get the error. In hindsight I could’ve updated the webservice to log the error, but I instead modified it to return something. In the end I added an exception log for when it is one-way so future errors will be logged. Anyway, turns out I was battling a permission issue for quite some time and didn’t even know it. Another area where the docs are lacking is in security setup. Turns out the user that you wrote down in step 2 above needs to be a member of the IIS_WPG group on the box. This one was easy to find in the docs and I had done this up front. What wasn’t covered was that the user also needs to be a member of the STS_WPG group. Mainly so the user has access to the temp folders.
That’s it. I left out a lot of debugging steps and the trial and error stuff in the hopes of keeping this short. Seems like my posts are getting longer and longer these days.