BizTalk Server 2004, Microsoft’s third incarnation of its
business process integration server, is the one they got right. Integrated with
Visual Studio .NET 2003 and leveraging XML as its data transport backbone,
BizTalk 2004 is Microsoft’s most powerful offering yet as the company persists
in making a serious entry into enterprise integration.

The
downside is that there is frustratingly little documentation, from Redmond or otherwise, on exactly how
best to put this latest, greatest BizTalk to work. (And, fair warning,
criticisms of this sort of thing are not the least of the things you should
know!) On balance, BizTalk is powerful and versatile but in the long run very
difficult to use. Here’s a heads-up on both the pro and con.

1. You can interact with your SQL Server databases from within BizTalk

BizTalk 2004 can communicate with other sources of data via
TCP, file folders, HTTP, ftp, and others. It can also communicate directly with
SQL
Server, and a configurable SQL adapter. Reducing what would otherwise be a
multi-stage process to a single one is very efficient and convenient: BizTalk
can select or update SQL tables via existing stored procedures specified in the
adapter configuration, and will generate easy-to-use and easy-to-map request
and response objects for you.

But there’s
a downside. Each SQL adapter you create for BizTalk is database-specific, very
inconvenient when you have a business process you wish to orchestrate that
needs to get into more than one database (if, for instance, your databases are
customer-specific but your process isn’t). It’s possible but not simple to
create more than one SQL adapter per orchestration, but no getting around the
hard-coding of adapter-to-database (another unfortunate example of Microsoft
making our design decisions for us). A more dynamic approach would be welcome,
and something we can hope for in future versions.

2. You can synchronize business processes with BizTalk

BizTalk orchestrations permit you to correlate processes,
based on available data. As it is common in many business processes to make
certain events and decisions contingent upon the arrival of inbound data, you
can stagger or make conditional any business-layer decision or process you
choose, with the BTS correlation feature. You can actually make processes that
are architecturally asynchronous (for transaction integrity, robustness,
scalability, etc.) logically synchronous by leveraging this feature.

3. BizTalk can take over your EDI, out of the box

BizTalk 2004 ships with a number of canned adapters,
including a Base EDI Adapter that offers the fundamental transaction sets
(Purchase Order, Invoice, etc.) and mapping utility to replace your existing
EDI interfaces or to launch new ones more economically than you otherwise
might, making BizTalk an increasingly attractive investment. The process of
configuring and deploying an EDI
interface using this adapter isn’t painless by any means, but also offers you
management options for tracking activity with EDI partners. If you’re doing
industry-specific EDI, such as health care HL7 transactions, there are
BizTalk-compatible packages available from Microsoft.

4. You can deploy a BizTalk application as a Web service

It is possible, and even surprisingly convenient, to create Web
services from BizTalk orchestrations.
The process mapping of a BizTalk orchestration can be deployed as a service
transaction, either network-internal or external, simply by running a wizard.
Care must be taken to correctly identify and configure the schema representing
the data the Web service will receive, but it can actually be easier to create
and deploy a Web service using BizTalk than by other, more conventional means
(depending on the job the Web service will be doing).

5. You can monitor processes and track business activity

BizTalk Server 2004’s Business Activity Monitor is both an engine and a set of
tools that can report process status (in real time, if necessary). This
information can be handed off to SharePoint Portal Server, and in turn received
by applications in the Microsoft Office suite. The usefulness of the metrics
that can be extracted by these tools is obvious, and includes partner-specific
performance measures, but the unpolished gem in this capability is the capacity
to inform users throughout a process chain of new information as it emerges,
allowing them to react immediately if necessary.

6. You can create your own adapters

Need to roll your own adapter? BizTalk permits you to create
custom adapters in order to communicate with proprietary external systems,
using the same framework employed by BizTalk’s built-in adapters. You can adapt
to the external system’s communication patterns, and you can (if necessary)
embed logic required for message handling. You don’t need any additional
software to accomplish this, apart from BizTalk 2004, the SDK, and Visual
Studio 2003. There are sample adapters included that you can use as a
guide.

7. You can leverage MSMQ for asynchronous messaging

MSMQ is, as they say, the best Microsoft feature you’re not
using. Few are even aware of this convenient and versatile messaging capability
that comes built-in with XP or MS Server 2003. It’s an easy and economical way
to connect applications asynchronously – and until now, it wasn’t
BizTalk-friendly. There was MSMQT (not quite the same thing), but no MSMQ adapter for
BizTalk was available, until earlier this year. Now you can download it for free and use it to create Receive and Send Ports in BizTalk systems, to communicate with other
applications or with remote business partners.

(A word of warning: seek out documentation on potential
incompatibilities between MSMQT and MSMQ, when used in the same context.)

8. Some of the most commonplace and important functions are obscure

Since BizTalk is about connecting systems and applications
through messaging, it is built on the assumption that messages are coming in
and going out of any process. To this end, a BizTalk orchestration typically
starts with a Receive, and that Receive assumes an initial inbound
message. Naturally, it wants to type that message to the schema carrying it.
And since Microsoft likes to build “do-it-our-way” safeguards into
these processes to urge us away from design mistakes, the orchestration won’t
receive any message that doesn’t match the message type specified in the Receive block.

You must generate a type schema from a well-formed XML
instance, in order to give BizTalk a selectable type for the Receive block. Yet, amazingly, BizTalk doesn’t ship with this capability
enabled! You have to
do it yourself. The software to perform the schema import XDR schemas is
enabled out-of-the-box, but you must run two scripts—InstallWFX.vbs and InstallDTD.vbs, both found in the SDK\Utilities\Schema
Generator subdirectory of your
BizTalk install—in order to enable the import of XML or DTD for the generation
of precise schemas that BizTalk can use for typing. And there are many more
examples of critical functions not clearly spelled out in documentation or
examples. Be on the lookout!

9. BizTalk orchestrations don’t always perform as you’d expect them to

Another friendly warning about BizTalk is that you’re likely
to be blind-sided by undocumented inconsistencies between the way you expect
things to work and the way they work in BizTalk. One such inconsistency is the
manner in which BizTalk orchestrations handle XML.

You can’t
be very deep into XML manipulation without availing yourself of xPath, an indispensable utility for extracting data from
its XML trappings. In most conventional expressions, you can extract data using
xPath with an argument including the source instance
and the instance xPath (given in Visual Studio.NET’s
Properties window, when you’ve clicked on a particular data item in an XML
schema). If you try to use the instance path given in Properties inside a
BizTalk orchestration, BizTalk gets lost.

They don’t
bother telling you that, nor is there any formal documentation that shows you
how to pull out single, discrete data items within an orchestration (though we
should qualify this statement by saying that this xPath
failure only occurs some of the time, depending on the structure of the XML
schema and the placement of the desired data item). I’ve seen some informal
explanations for this failure, to do with BizTalk’s implementation of XLANG. Whatever the cause, this is one of a number of bugs
in BizTalk that you won’t read about, and must confront without assistance.

10. Your time cost will be enormous

If there ever in the history of Microsoft was a product that
was hyped through the roof and then thrown upon the sea, it’s BizTalk.
Originally a Microsoft acquisition that is now well-integrated into Microsoft’s
family and lovingly nurtured by its caretakers, BizTalk is powerful,
well-conceived, and at this point married to the rest of the MS family—but at
the expense of correct and thorough documentation. To say that useful BizTalk
how-to and real-world labs are scarce is howling understatement. Buy into
BizTalk and you’re more or less on your own, bringing it around to your
particular applications and environment.

In short,
prepare for endless hours of blogging, followed by
endless hours of trial-and-error. You’ll get plenty of frustrating hints from
the BizTalk Server Administration event log, vague exception messages, and
precious little real debugging assistance from the Health and Activity Tracking
utility. The upside is that once you’ve learned the quirks and fixes and
tricks, you’ll feel incredibly empowered. But, oh, what a learning curve! Don’t
underestimate it.