Exam Reviews

Getting Down to BizTalk

The world of EAI awaits you. Just enter the realm of HIPAA, RosettaNet, UDDI and document exchange, then prove yourself with this new exam.

• By Larry Cooper
• 03/01/2002

A complex dilemma has haunted systems engineers for a long time:

• Applications X and Y are both mission-critical.
• Applications X and Y carry some common data, but each in its own format and data store.
• Application X doesn’t natively talk to Application Y.
• Application X doesn’t export data in a format that Application Y can understand

Sound familiar?
Certain types of business documents have become standardized over the years. EDI has allowed businesses to exchange purchasing data successfully. With the advent of XML, the technology was suddenly relabeled as B2B (business-to-business integration), but the concept of integrating application and trading partners through documents still held true.

More recently, XML and the concept of self-defining data and documents have created an entirely new breed of technology: Enterprise Application Integration (EAI). Literally any kind of data can be moved from one application or company to another using XML as an intermediary format. Microsoft has entered this enterprise computing space with BizTalk Server 2000.

BizTalk was originally introduced during a time when B2B was the big buzz on the street—e-commerce sites and internal procurement connecting seamlessly with an unlimited number of trading partners via XML document interchanges. Today, many active BizTalk installations are using BizTalk not only to handle their procurement and purchasing, but also to implement their business processes to pass information from one system to the next.

Data Expert
Because of the nature of BizTalk—moving, transforming and converting data—you might consider this area of specialty to be the realm of developers and MCSDs. Not true.

BizTalk has extensive requirements in the architectural planning, deployment and on-going administration of the system. In fact, I’d liken BizTalk to Microsoft’s SQL Server. There’s a need for people to run the servers and a need for people to write code that runs on the server.

As a side note, if you happen to be an MCSE with SQL Server experience, understanding BizTalk will be that much easier. BizTalk not only requires SQL Server as its back-end data store, but also requires an understanding of database administration and optimizing the locations of your databases. Also helpful is experience with IIS and Active Server pages.

You need a tremendous amount of effort and skill to integrate applications within an enterprise as well as applications among various trading partners. Not surprisingly, you can prove your expertise now by tackling exam 70-230, which is an MCSE and MCSD elective.

The Process
You’ll find BizTalk easy to understand as long as you know where to go for particular functions. The software doles out the work of the “BizTalk process” to several useful tools, thereby increasing the possibility of getting lost in its services. Fortunately, the tool names describe what they do. Let’s go through each.

The BizTalk Editor has one central purpose: to define the structure of an incoming document for treatment by BizTalk. Ultimately, BizTalk uses the schema you create to convert the document into XML. I spent quite a bit of study time taking document formats and bringing them into the BizTalk Editor. Since BizTalk ships with the templates for the more common document formats (ANSI X12 and EDIFACT), I took the time to open some of the templates and define a structure in BizTalk. I also, thankfully, built my own XML document and flat file and learned how to import them into the BizTalk Editor to define a structure.

Tip: Because the heart of BizTalk is XML documents, it’s impossible to sit the exam successfully if you’re not familiar with how an XML document is structured. Check “An Education in XML” for resources to jumpstart your XML education.

The BizTalk Mapper takes those wonderful specifications you developed in the BizTalk Editor and connects to them for translation. Simple, right? Try it out. I spent a good deal of time mixing and matching the different specs I developed in the BizTalk Editor and connected them with the BizTalk Mapper.

You do a lot of the work in the BizTalk Mapper by drawing connections from one document’s field to another’s field (in other words, CustomerName field to CustNme field). This can be done in a variety of ways (one to one, one to many, many to one).

There are also cases in which you’ll need to massage the data as it moves from one document to another. This doesn’t mean just drawing lines (although that was quite fun), but using the various functoids (I told you there were a lot of terms). Functoids are pre-built functions that transform data in the BizTalk Mapper. I took some time to use (but not memorize) some of the functoids available to do string and numeric calculations. I even tried to use the Scripting functoid to build a small function that returned a word based on the range of the data. If you’re a burgeoning VBScript developer, this should be a piece of cake.

Now that you’ve figured out what your documents look like and how they translate from one to another, you get the job of practicing the connection of your applications with BizTalk. BizTalk Messaging Manager lets you go about the business of connecting applications with two important objects: ports and channels.

Channels allow you to specify how your documents will enter BizTalk. This includes the document that will enter, how it will be tracked and logged and what port it will enter.

Messaging ports allow you to specify the destination for a document, including its final format. A port can be secured so it only accepts documents from a particular organization or it can be left as “open.”

I took the time to develop some simple channels and connected them to ports.

At this point you’re probably asking yourself, “Why did I have to install Visio before installing BizTalk?” Microsoft Visio allows you to leverage yet another configuration tool, the BizTalk Orchestration Designer.

The Designer allows you (as a business analyst) to build flowcharts of document workflows that might occur in your document transformation process. This can be anything from passing a document to an Exchange e-mail system for approval via CDO to doing a database lookup in a business system via ADO. These XLANG workflow schedules are developed using the three kinds of Visio-like objects:

• Flowchart shapes for logic routings and branches.
• Implementation shapes for the implementations of scripts or COM+ objects.
• Communication shapes for working with ports that might be involved in the XLANG workflow.

In my preparation, I started simple. I created branch workflows that fired scripts that displayed on screen message boxes or sent SMTP e-mail and then dumped the document to several ports. The idea is to get familiar with the shapes and connections that can make up the XLANG workflow diagram.

Talking to BizTalk
BizTalk has an incredible library of COM+ connectors available to do real enterprise application integration work. However, there are going to be times when applications don’t support COM+ or rely on more traditional methods of data exchange: message queues and “dump” directories.

I used the BizTalk Administration module to configure both a File Receive function and an MSMQ Message Queue Receive function. Both these items are essential to the integration capabilities of BizTalk.

Tip: A minor sideline I took in my preparation strategy paid off down the road. I studied how to build an Active Server Page that used the Interchange object (CreateObject(“BizTalk.Interchange”). Using the Submit and SubmitSync method, I configured the Active Server Page to take an HTML form, write it to a file, then submit the file to BizTalk via the Interchange object and HTTP.

Growing the Environment
BizTalk can grow in your environment both vertically (the concept of adding more CPU, memory and storage resources to a particular server) and horizontally (by adding more servers). The concept of scaling BizTalk horizontally is also known as building server groups.

Server groups are an administrative unit. All servers in a group share the same Shared Queue database and Tracking database. All the server groups can share a single Messaging Management database.

As a note on the subject of scalability and performance, Microsoft recommends that you dedicate separate database servers to the Shared Queue and Tracking databases. It also advises that you place that the Messaging Management and Tracking databases on different servers as well.

Tip: I’d recommend the BizTalk Operations white paper (see “Additional Information”) when it comes to learning about tracking documents and how to manage XLANG Orchestration schedules.

Securing BizTalk
BizTalk seems to have been built on a variety of standards in terms of its security architecture. Like most of Microsoft’s line of .NET servers, it relies on Windows 2000 to secure its administrative functions.

A full BizTalk Administrator must have an account that’s part of the Win2K Administrator group on that server, as well as be a member of the BizTalk Administrators group. This doesn’t require that a user be a Win2K Domain Administrator; only that the person have administrative privileges on the servers in the group being managed.

All Win2K Administrators on BizTalk have the ability to administer server groups (but not create them) and modify BizTalk properties. They can also free up document interchanges, a permission that’s required when removing a server from a group.

Tip: This is something I’d recommend seeing to believe: Remove yourself from the BizTalk Administrators group and attempt to manage servers within an existing group.

As far as security standards for communication at the channel level, documents can be submitted via HTTPS and secure MIME encoding via SMTP (S/MIME). You also have the ability to implement public/private certificates within MSMQ. Just as easily, inbound or outbound channels and ports can be protected with certificates by defining the certificates in the BizTalk Messaging Manager.

“Do, or Do Not. There Is No Try.”
It appears the market is ripe for people with the skills required to work with BizTalk. Microsoft has recently released turnkey “accelerator” products for HIPAA, RosettaNet and supplier integration—making it that much easier for MCSEs to implement BizTalk as part of an enterprise architecture.

I would say that only about a tenth of any enterprise environment I’ve encountered has integrated its business critical systems—either internally or with a trading partner. Most of my consulting customers have indicated that this is part of their strategic plan. Better yet, the industry projections are that most organizations will move in this direction—making a wealth of opportunities for people with EAI skills and BizTalk certification. Good luck!