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.
Building a Project
BizTalk ships with all sorts of samples. The CBRSample is perfect for exercising BizTalk’s Messaging Engine. You can find the sample in the BizTalk SDK folder shown in Figure 2.
Figure 2: CBR Sample Folder
BizTalk works with Visual Studio 2005. The loaded sample appears in Figure 3.
Figure 3: The CBR Sample
As you can see, the sample uses XML schemas. If you are unfamiliar with XML and XML Schemas (XSD), you’ll find XML resources at the end of the article.
The sample contains the following components:
- Three Schemas, an input Schema (CBRInputSchema.xsd), and two output Schema’s (CBROutputSchema.xsd, CBROutputSchemaCAN.xsd).
- Two maps map the input schema to each of the output schemas. A complete explanation of maps is beyond the scope of this article. To read more about maps, check out Creating Maps Using BizTalk Mapper on MSDN.
- A promoted properties Schema BizTalk uses to extract information from an XML file and place in the BizTalk Context.
- Sample XML files for testing the application.
See the BizTalk 2006 R2 documentation for a complete explanation of the sample code.
A Setup.bat file in the sample directory will automatically compile and deploy the entire solution. I’m going to walk through manually deploying the project.
To run the sample, you first need to compile the project. BizTalk assemblies are loaded in the GAC, so they must be signed. To deploy the project, execute the Deploy command on the project menu (see Figure 4).
Figure 4: Deploying a BizTalk Project
BizTalk applications are really groupings of related components. Deployment properties dictate where a project is deployed (see Figure 5).
Figure 5: Deployment Properties
The deployed sample appears in the BizTalk Administration application shown in Figure 6.
Figure 6: BizTalk Administration Application
The next steps are to configure the ports.
A binding contains the BizTalk port configuration information. If you run the setup.bat file, the binding is loaded automatically. I’m going to show you how to manually configure the ports.
The sample utilizes the File Adapter and the XML Pipeline. The XML Pipeline pulls data out of the XML file and places the data in the BizTalk Context. Figure 7 illustrates how you configure a Receive location with the File adapter.
Figure 7: Configuring a Receive Location
As stated earlier, Send Ports subscribe to data in the Messagebox. A filter is configured on each Send Port. The Filter looks for information contained the context and only pulls a message matching the filter criteria into the Send port. A Map translates the CBRInputSchema XML data coming out of the MessageBox to one of the Output formats. Figure 8 illustrates how you configure a Send port with a filter and a map.
Figure 8: Configuring a Send Port
Running the Application
You need to enable the CBRApplication before you run the sample (see Figure 9).
Figure 9: Enabling an Application
To run the sample, copy the sample data file to the folder of the Receive location. The file will pass through the Messagebox, as described above, and appear in the Send port folder.
Where you go from here depends on your goals and interests. Here are some sources you’ll find particularly useful.
- The BizTalk Home Page: http://www.microsoft.com/biztalk/default.mspx
- Connected Systems Division Blog, the people who brought you BizTalk, WCF, and WF: http://blogs.msdn.com/biztalk_server_team_blog/
- BizTalk Patterns and Practices: http://technet.microsoft.com/en-us/library/ms935116.aspx
- BizTalk MSDN articles: http://msdn2.microsoft.com/en-us/magazine/cc163423.aspx
- Articles on this site: http://www.developer.com/xml/article.php/10929_3714631_2
- An excellent book on Messaging and Integration: http://www.enterpriseintegrationpatterns.com/
- The future of BizTalk lies in “Oslo”, Windows Communication Foundation, and Windows Workflow. Here
are sites covering these technologies:
- XML Resources:
Special thanks go to Ofer Ashkenazi of Microsoft Corporation for creating the BizTalk Messaging Engine graphic for this article.
- BizTalk 2006 R2 Documentation
- Enterprise Integration Patterns by Gregor Hohpe and Bobby Woolf
About the Author
Jeffrey Juday is a software developer with Crowe Chizek in South Bend, Indiana. He has been developing software with Microsoft tools for more than 12 years in a variety of industries. Jeff currently builds solutions using BizTalk 2004, ASP.NET, SharePoint, and SQL Server 2000. You can reach Jeff at firstname.lastname@example.org.