BizTalk Server 2006 : Starting a New BizTalk Project - Organizing Artifacts in BizTalk 2006

You're likely to use BizTalk for more than one application. You'll then quickly run into the problem of organizing your application artifacts such as ports, schemas, and so forth. There are two facets to organizing. First you must understand the concept of a BizTalk application.

Then you can use the Administration Console to do the actual work of sorting your artifacts so that you can easily see which artifacts go with which application.

BizTalk Applications

In BizTalk 2004, artifacts such as ports and orchestrations were not organized according to what application used them. Each artifact was simply deployed to the management database and was not organized by logical criteria like in Figure 1. The result was that the task of managing these artifacts was increasingly difficult and was complicated whenever two or more solutions were installed to the same BizTalk Management Database. The situation has been dramatically improved in BizTalk 2006 with the introduction of BizTalk applications. Applications allow an administrator to logically group artifacts according to the application that uses them. This concept is extended to the improved deployment model within BizTalk 2006 that allows the exporting of a BizTalk application to a Windows Installer package.

Figure 1. BizTalk 2004 artifact organization

Applications can contain any number of BizTalk artifacts such as schemas, business rules, orchestrations, and ports. To facilitate such organization, the BizTalk Management tools have been redesigned in BizTalk 2006. The top-level logical grouping for BizTalk artifacts becomes the application instead of the artifact type as it was in BizTalk 2004, as shown in Figure 2.

Figure 2. BizTalk 2006 artifact layout

Using BizTalk Explorer to Manage Applications

One of the most requested features for BizTalk 2006 was to give developers the ability to control how their BizTalk artifacts were going to be deployed to the server. To some extent this existed in BizTalk 2004, but with the introduction of the concept of a BizTalk application, this has been extended. Developers now have the ability to tag their BizTalk assemblies within Visual Studio with the application name that the assembly should be installed within. This is shown in Figure 3. In essence, all that is needed is to right-click the assembly in Visual Studio and choose Properties. Under the Deployment Settings tab, there is an option to set the application name. This is the application that the assembly will be installed within once the assembly is deployed to the Management Database. If the application doesn't exist, it will be created upon deployment.

Figure 3. BizTalk Explorer

BizTalk's Administration Console

BizTalk's Administration Console is a Microsoft Management Console (MMC) that allows for the ability to create, configure, and manage one or more applications across multiple servers. Additionally, the MMC includes the ability to import and export applications for installation across multiple servers or to facilitate the moving of applications between staging and production environments. Finally, the console includes the message- and service-monitoring capabilities previously provided by HAT, the Health and Activity Tracking tool introduced in BizTalk Server 2004. While the Administration Console provides runtime monitoring, HAT must still be used for document tracking and orchestration debugging.

In Figure 4, you can see the organization of BizTalk applications in the Administration Console. Each application is contained within the applications root of the server. Fresh installs of BizTalk Server 2006 create a system application called BizTalk.System that contains all global schemas, assemblies, and artifacts and a default application called BizTalk Application 1. If you don't explicitly create a new application, each time you deploy, your artifacts will go into the default application.

If you are upgrading from BizTalk Server 2004, your artifacts will also be installed in the BizTalk Application 1 root. After the upgrade is complete, it is advisable to create a new logical application container and move the artifacts to it to avoid confusion.

Figure 4. BizTalk 2006 Administration Console