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.
Scott Robinson is a 20-year IT veteran with extensive experience in business intelligence and systems integration. An enterprise architect with a background in social psychology, he frequently consults and lectures on analytics, business intelligence and social informatics, primarily in the health care and HR industries.