If you’re reading this article, you’ve probably read all the literature, sat through a sales presentation or two, and now you want to understand the BizTalk development experience. You may even have some lingering doubts. For example, do you need this tool? If you share any of these thoughts, you’ve just clicked the right hyperlink.
BizTalk has a lot of working pieces. Not all pieces are needed for every project solution. There are, however, core pieces you will use regardless of the project. Understanding these core pieces is the best place to start grasping BizTalk development. In this article, using a sample BizTalk application from the BizTalk SDK, I’m going to explore BizTalk’s core features housed in what I commonly refer to as the BizTalk Messaging Engine.
BizTalk at 50,000 feet
When two software systems need to interact and have no pre-built interaction capabilities, developers often turn to an integration tool to build the interaction capabilities. When multiple systems need a coordinator for a multi-step process, developers utilize business process management software.
BizTalk is an integration and business process management platform rolled into one server. It’s a Windows Service built on top of SQL Server and the .NET Framework. BizTalk development is hosted in Visual Studio. BizTalk can be deployed on a single server or across multiple servers. BizTalk is based on common integration patterns and is a component of Microsoft’s Service Oriented Architecture (SOA) offering.
BizTalk includes adapters to integrate with common technologies and business software. BizTalk ships with File, SharePoint, SAP, and other adapters so you don’t need to develop the software to interact with these systems.
As I stated earlier, understanding the Messaging Engine is the first step to understanding BizTalk development. In many ways, the Messaging Engine “is” BizTalk. The Messaging Engine makes everything in BizTalk move. Even the business process management portion of BizTalk, called Orchestration, relies heavily on the Messaging Engine. So, the remaining portion of this article I’m going to show you how a typical BizTalk application leverages the Messaging Engine.
Messaging Engine 101
I’ve used the term “Messaging,” but haven’t really explained what the term means. A message is simply a package of data and accompanying meta-data used by the integration tool. Integration technologies and documentation often refer to the exchange of information as Messaging.
Much of how the Messaging Engine works is covered in the BizTalk documentation. So, I’m going to present a simplified overview of all the essential points. Figure 1 depicts the movements of data through the BizTalk Messaging engine.
Figure 1: BizTalk Messaging Architecture
A message is received in the receive port. A receive port is associated with a receive location. A receive location is configured with and an adapter, an optional map, and a pipeline. I’ll cover maps later in the article.
Adapters are intimately aware of the underlying technology they’re built to interact with. As mentioned earlier, adapters exist for SQL, SAP, SharePoint, the File system, FTP, and so forth. An adapter extracts or writes the data from/to the source system.
The BizTalk MessageBox is one of many database components of BizTalk server. It’s also the most critical component of the messaging engine. As a message is passed into the MessageBox, BizTalk attaches identifying information, also called Context, to the message. Context includes information such as: the port name where the data was received, the id of the message (each piece of data receives a unique id), information unique to the adapter, and whether the data is XML, the namespace of the XML data.
The BizTalk MessageBox stores messages emitted by the receive port. Data moving through BizTalk moves in a publish and subscribe fashion. Receive ports publish the message, and Send Ports and Orchestrations subscribe to incoming messages based on the message’s Context. MessageBox not only governs subscriptions it also stores executing orchestrations. A further discussion of the MessageBox is beyond the scope of this article.
As mentioned earlier, Send ports subscribe to data in the MessageBox and move data out of BizTalk. Send ports either subscribe to data using a filter or are directly attached, or rather, bound to an orchestration. Like Receive ports, Send Ports are configured with an Adapter, an optional map, and a pipeline.
Modularity and decoupling are two major reasons why companies purchase Integration tools. As you can see from the earlier explanation, each component of BizTalk has a focused role in the overall solution. The publish and subscribe mechanisms greatly decouple receiving data from how the data is used. So, for example, you can add more subscribers (Send ports), without changing how the data is received.
Now, you’re going to look at how the concepts above apply to the development environment.