Effective BizTalk

I've been on a pretty serious WCF kick for the past few months and more and more I love it. I like even more how well BizTalk works with WCF. BizTalk is the application server you normally need to provide yourself to make WCF very useful. In Handling Binary Messages in Orchestrations I had mentioned that I used SQL Reporting Services via Web Services to run reports and do something with the output. As I had been experimenting with the solution I tried using both the SOAP Adapter and the WCF Adapter and found the WCF Adapter to be much more to my liking.

Using the WCF Http Basic binding you are able to call existing SOAP services but I did run into a slight problem with the SSRS services. These services require impersonation and by default WCF handles impersonation differently than ASMX in IIS did. At first I thought I needed to change the web.config on the reporting server, but eventually I stumbled onto Delegation and Impersonation with WCF on MSDN. More digging informed me what it was I needed to do, change the default client credentials (which I think was delegate) to impersonate. This lead me down a quite difficult path with WCF and configuration files that helped me understand the concepts more, but didn't really help me solve my issue. Fortunately after searching around the WCF Custom Adapter settings for a while I found the solution and it was a lot easier than hacking configuration files.

To make my life easier I used the basicHttpBinding as my Binding Type In the properties for the WCF Custom Adapter. Also in these properties, under the Behavior tab, select EndpointBehavior on the left. Then right click and go to the menu option Add Extension; selecting clientCredentials as the extension. Now go into the client credentials and under the Windows section there is a dropdown for allowedImpersonation. This is not only exactly what I needed, it looks like most of the WCF config options are here and best of all you can import and export to a single config file for the bindings, so if you're sick of doing WCF bindings by hand you can use BizTalk to do them with a nice GUI.

Soon I'll post about some things I like more about the WCF Adapter over the SOAP Adapter.

It never ceases to amaze me how many people can start off with bad experiences with BizTalk (which is why I do this blog and share my experiences). It really is an amazing product, but most people don't (or often can't) give it the time or respect it really deserves / demands to make it work correctly. I suppose because it does have a nice installation and configuration UI most people just think it does what they want. I know people make this mistake with SQL Server as well. The following are what I consider some of the minimum best practices for configuring a BizTalk Server.

Separated Hosts

I see this one a lot. If you just configure BizTalk out of the box you will have one Host and Host Instance: BizTalk Server Application (isolated hosts don't really count for this). I don't even really like the name of this host, but it is what you end up with (although you can change it in the configuration tool). At the very least I recommend the following host configuration:

Receive

Send

Orchestration (you can leave as BizTalk Server Application if you like)

Tracking

I even make these hosts on my development machine. There are quite a few good reasons for this so I'll start with the most basic: resources. In .NET a process has only so many threads in its thread pool. Sure you can always increase this number via a global setting, but there is a point at which this will generally stop helping you and start hurting. Part of this has to do with context switching overhead part with pure resource allocation. BizTalk is a massively parallel product and as a result requires many threads to run. If you leave all of the above features configured in a single process (as it is by default) you will run into thread starvation. I've run into this just on a development machine during testing, but you will really see it pronounced in a production environment. BizTalk will run slowly, though like expected still run reliably.

Further in reality you probably want to have different user accounts for each of these hosts, this can give you tight security controls between parts of your application. You may not need the security aspect on your development machine, but any servers (Integration, UAT, Production) will definitely benefit from this. Better still isolating processing, sending, and receiving will allow you to monitor and profile your solution more closely. You can attach perfmon logs to each service as it makes sense; no need to track messages received per second in the Orchestration host.

Basic Database Configurations

It is truly shocking how often this one happens. Most people installing BizTalk Server are completely unaware that installing the BizTalk databases on a SQL Server changes the server's MaxDOP (Maximum Degree of Parallelism) to one. If you're not exactly sure what this means it does what it sounds like: limits how many processors will be used in a parallel query. The setting is per query so its impact may not be that big, but it affects the Server, not just the Database. This may not really matter too much for you, but if this database server is used by other applications it probably will have an effect. This option is required for proper functioning of the Message Box database only. Other databases installed with BizTalk actually benefit from being on a server with a higher degree of parallelism. This is a great argument for spreading your databases across multiple SQL Servers (or clusters).

The other one I see a lot is to put the databases on an Analysis Services server. Analysis and Transaction are two diametrically opposed types of processing. They each require a different set of configuration and resources and they do not live well together. If your BizTalk solution is going to face significant volume I would recommend against host its databases on a shared database server (i.e. a database server that hosts other applications). Most people totally underestimate how hard BizTalk will be on SQL Server. Since everything goes through the Message Box, which is in SQL, it will be under tremendous load. Usually when a BizTalk application is running slow, SQL Server is a big contributor.

Microsoft has published some excellent information here that can help you really optimize your databases for BizTalk. It is really worth taking the time to go through this and the other optimization resources Microsoft has made available for BizTalk. Soon I will post on my own test results from this optimization process.