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:
- Using orchestrations for everything
- Writing custom code instead of using existing adapters
- Using non-serializable types and wrapping them inside an atomic transaction
- Mixing transaction types
- Relying on Public schemas for private processing
- Using XmlDocument in a pipeline
- Using ‘specify now' binding
- Using BizTalk for ETL
- Dumping debug/intermediate results to support debugging
- 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 to 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 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)!