I often consult with clients who are in the early stages of building applications with BizTalk. While many find it easier than they expected to get started, there are some less-than-obvious things about BizTalk that newcomers can miss. Here is a roundup of tips I like to share with them.
Pipeline Configuration Dialogs
Applies to: Receive Locations, Send Ports
The dialogs for configuring receive locations and send ports have a dropdown for choosing the adapter and another dropdown (or two, if it’s a two-way port) for choosing the pipeline. Everyone knows that the adapter dropdown has a button to the right marked “Configuration” that launches an adapter configuration dialog. But not everyone notices another button, to the right of each pipeline dropdown, which is labeled with just three dots “…”. This button launches a configuration dialog for the pipeline. Here is the dialog for the XMLReceive pipeline:
You often don’t need this dialog because the pipeline works correctly by default. But when they need to change a default setting, some developers think the only way is to create and deploy a custom pipeline. They should try clicking the button first.
Applies to: XSD Schemas
ElementFormDefault is an attribute of XSD schemas that I think should have been named “BizTalkDoesNotWorkUnlessYouChangeThisFromItsDefaultToQualified”. If you want a full explanation you can read here and here. But all you really need to know is the answers to two questions:
- Do you want BizTalk to work the same way as the rest of .NET?
- Do you enjoy getting error messages that say, “The element ‘foo’ in namespace ‘http://blah.com/foo’ has invalid child element ‘foofoo’ in namespace ‘http://blah.com/foo’. List of possible elements expected: ‘foofoo’.”
If you answered “No” to the first question and “Yes” to the second, then leave ElementFormDefault alone. But otherwise you should make it your business, whenever you create a new XSD schema in Visual Studio, before you do anything else, to change ElementFormDefault from its default setting (innocently marked “Default”) to the correct setting, which is Qualified. And it’s easy: just double click on it in the Properties window, and it changes to Qualified. You should do this consistently until it becomes like a reflex.
(Yes, there could be times when ElementFormDefault would need to be Unqualified, most likely so BizTalk can interoperate with some unenlightened outside system. If I ever that situation should arise I would map the Unqualified schema to a Qualified one within BizTalk as quickly as possible. But I’ve seldom seen it arise.)
Let’s review: what’s the first thing you should do when you create an XSD schema in Visual Studio? Answer: change ElementFormDefault to Qualified
Applies to: Send Ports, Orchestrations and Send Port Groups
Receive locations have two states: Enabled and Disabled. The meaning of these is self-explanatory. But send ports, orchestrations and send port groups have three states: Started, Enlisted and Unenlisted. You can think of Started as being just like Enabled, and Unenlisted as just like Disabled. But what does Enlisted mean?
It means the port/orchestration/group has an active message subscription but is not currently handling messages. Suppose you have a send port that sends invoices to your customer Fabikom’s web service, and you know that Fabikom’s web service will be going down for maintenance. If you change the port’s state from Started to Enlisted, then any Fabicom invoices that come through BizTalk will be held in reserve for the port, but the port won’t try to send them. Then when Fabikom’s web service comes back online, you can change the port state to Started, and all the reserved invoices will immediately get sent, along with all new ones that come in. Orchestrations and send port groups work the same way.