Top 10 BizTalk Server Mistakes

All of my projects during about the past four and a half years are based on BizTalk Server 2004, BizTalk Server 2006, and (recently) BizTalk Server 2006 R2. During this time, I have seen mistakes in the way developers use, deploy, and manage BizTalk Server.

Although there are a lot of common mistakes - there are ten that occur very often:

1. Using orchestrations for everything
2. Writing custom code instead of using existing adapters
3. Using non-serializable types and wrapping them inside an atomic transaction
4. Mixing transaction types
5. Relying on Public schemas for private processing
6. Using XmlDocument in a pipeline
7. Using ‘specify now' binding
8. Using BizTalk for ETL
9. Dumping debug/intermediate results to support debugging
10. Propagating the myth that BizTalk is Slow

Lists are great for reminders, but you need to know the details too. So, let's go through each mistake in more detail. You'll learn why each mistake is an error and how to address it.

1. Using Orchestrations for Everything

Why it's a mistake - Orchestrations to BizTalk are like antibiotics to us - overuse them and they become ineffective.

How do I fix it?

Change how you think about solutions when you work with BizTalk - think about messages and how they flow through business processes. In many cases, Orchestrations are the last resort. Use port-based transforms and routing, direct binding, and trading partner management before going to orchestrations.

2. Writing Custom Code Instead of Using Existing Adapters

Why it's a mistake - BizTalk offers adapters that make it easy to invoke stored procedures, call web service methods, interact with MSMQ, etc. Why re-invent, maintain, and configure when the facilities are present, tested, and supported by someone else (Microsoft)?

Background - Many developers call web service methods or stored procedures by writing some code in an assembly and call it from an Expression shape. While doing that is convenient, the custom code needs a way of getting configuration information, it needs to be deployed, and someone will eventually have to update the code.

How do I fix it?

BizTalk adapters, like the SOAP and SQL adapters, are great. Built-in adapters are easy to use and configure - and you won't have to worry about unnecessarily maintaining a bunch of custom code!

Research BizTalk adapters by reviewing the product documentation, reading blogs, and - most importantly - trying them yourself. Your clients will be glad you did because you'll have less to maintain and deploy later.

3. Using Non-serializable Types by Wrapping Them Inside an Atomic Transaction

Why it's a mistake - Atomic transactions have their limits and can contribute to performance issues.

Background - some BCL (.NET Base Class Library) types are non-serializable; therefore, using these types in a Long Running transaction is not possible. Some developers work around this ‘problem' by setting their transaction to Atomic - which allows you to use both serializable and non-serializable types.

How do I fix it?

Use non-serializable types as a last resort. Try using BizTalk's facilities to solve your problem: use adapters, research the XLANG's xpath function, try promoted or distinguished properties - there are a lot of choices.

4. Mixing Transaction Types

Why it's a mistake - Switching between transaction types within an orchestration forces BizTalk into persisting some information about the orchestration to its internal database.

How do I fix it?

Try to avoid using nested Atomic transactions altogether - use one atomic transaction instead, or consolidate processes such that you do a lot of work within an Atomic transaction.

Also refer to "Writing Custom Code Instead of Using Existing Adapters", and "Using non-serializable types by wrapping them inside an atomic transaction" for more guidance.

5. Relying on Public Schemas for Private Processing

Why it's a mistake - A public schema is one that you don't own or control. By using types that you do not control, you introduce a tight coupling (or dependency) on types that belong to someone else. Changes in the public type force you to change your solution.

Background - For example, your solution could call a web service and directly use the resulting message for further processing. You could receive a flat file from a trading partner and use its format as the basis for further processing.

Both approaches are dangerous, from the point of view of managing types within your solution.

How do I fix it?

Address this issue early in your design phase. Transform public messages into an equivalent private representation or by take a bus-like approach to moving messages through your solution. Both approaches are not as easy as directly using Public types, but the extra work makes your solution much more resilient to change.

By the way, thinking about creating a ‘canonical' type to solve this problem? Don't bother - that's mistake number eleven!

6. Using XmlDocument in a Pipeline

This is for developers that create their own pipeline components - not for those that create BTP files using the pipeline editor and use the regular BizTalk pipeline components.

Why it's a mistake - the XmlDocument type uses a lot of memory for each facet of an XML document. Pipelines are like the passing lane on a highway - you need to be fast and lean.

Background - Pipelines are known to be efficient because they use streams when processing the information they receive or send. Some developers either don't know about streaming or are unaware of how to use streaming and opt for loading XML into an XmlDocument type instead. While the XmlDocument type is useful, it does not have any legitimate use in a pipeline because it adds lots of memory overhead.

How do I fix it?

Before you create your first pipeline component, see how other developers do it and read through their code. If you cannot find any open source pipelines, you could use Reflector to browse through Microsoft's XmlReceive pipeline. From there, experiment with the stream types and understand how to handle your scenarios before committing to write a new pipeline because pipeline debugging can be an involved process.

Already stuck with a pipeline that uses an XmlDocument? Try to split the document into smaller parts and perhaps call the pipeline from an orchestration instead.

7. Using ‘specify now' Binding

Why it's a mistake - BizTalk Server is designed to decouple solutions from their operating environment, thereby making it possible for systems administrators to deploy applications in the best possible way. Specify now binding couples the developer's workstation configuration to other environment's configuration.

Background - When you add a port to your orchestration, the wizard that pops-up gives you some options for binding the logical port to a physical port. If you want to use a self-correlating port or direct binding, select those options using the Wizard if you don't plan to use either of these options.

How to I fix it?

Avoid using the "Specify Now" binding - prefer the use of "Specify Later" binding instead.

Specify Later binding offers much more flexibility, and makes it easy to transition your solution from your workstation to another environment (you might even be able to drop the "Works on my system" certification!).

Specify Now binding can be useful for demos and, maybe, testing on your local workstation but nothing more.

8. Using BizTalk for ETL

Why it's a problem - ETL solutions usually handle a lot of data in a short amount of time. ETL solutions are typically linear and don't change often. BizTalk is not designed for this type of use.

Background - ETL stands for Extract, Transform, Load.

How do I fix it?

If you're using BizTalk to do ETL, you're using the wrong tool. BizTalk is a messaging platform. SQL Server Integration Services (SSIS) is perfect for ETL - use SQL Server Integration Services instead.

9. Dumping Debug/Intermediate Results to Support Debugging

Why it's a problem - BizTalk offers plenty of support for debugging, so this is completely unnecessary.

How do I fix it?

You can debug your BizTalk solutions. Did you know that you can use Visual Studio to step through code in custom components called by BizTalk Server from Maps, Orchestrations, pipelines, etc? Do you know that you can actually step-through Orchestrations too? You can also save just about any message in your solution too.

So, there's really no reason to add send ports to your solution - send ports that drop intermediate files to someplace on your system's hard drive for you to inspect messages.

Thinking of using a custom component along with the clever trick if using the DEBUG symbol too? That relates to mistake number two!

10. Propagating the Myth that BizTalk is Slow

Why it's a mistake - BizTalk Server is fast - really fast. I have yet to come across a situation where BizTalk Server was too slow to handle a particular problem.

Background - BizTalk offers a lot of performance measurement and tuning options to help you use your system's hardware to its full capabilities.

How to I fix it?

Understand the type of messaging in your system; understand the difference between latency and throughput; measure performance (consider getting Team Foundation for Developers - it offers a great toolset for measuring performance); understand the tuning options available to you.

Have a project that needs help? Need Mentoring? Contact me - click the Contact link for, possibly, free help (never hurts to ask)!