Installing and configuring BizTalk is not a straightforward process. Although it’s become easier in each version, installation is made more complex by the large number of subsystems and technologies that are required in a BizTalk installation. That is still true in BizTalk Server 2009.

The installation and configuration process for BAM is no different. It involves planning and design of your BAM server architecture and roles, installing several prerequisites, the installation processes, and configuration.

Because of the technical complexity of BizTalk Server and BAM, Microsoft offers official installation and configuration guides for BizTalk, which may be downloaded from http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=9c697e02-d1bc-4684-8748-28b3a292d5bf. Available as of the time of the publication of this book are guides on how to install

• BizTalk Server 2009 in a multicomputer environment
• BizTalk Server 2009 on Windows Vista
• BizTalk Server 2009 on Windows Server 2003
• BizTalk Server 2009 on Windows Server 2008
• BizTalk Server 2009 on Windows XP
• BizTalk Server 2009 via upgrade from BizTalk Server 2006
• BizTalk RFID Mobile
• BizTalk RFID on Windows Server 2003 or 2008
• BizTalk Server RFID on Windows XP or Vista

Additionally, Microsoft has published a troubleshooting document for BizTalk Server 2009 setup.

With BizTalk Server 2006 R2, Microsoft had also published a separate, stand-alone document on considerations when installing BAM, found at http://go.microsoft.com/fwlink/?LinkId=81041. As of the publication of this book, that document had yet to be updated for BizTalk Server 2009.

We have found these documents to be somewhat reliable, with some noted issues surrounding sequence of events and hotfix installation (hopefully these issues will be addressed and corrected). By and large, the guides target the broadest audience possible, and as such, don’t provide context surrounding questions you should ask specifically as they relate to BAM.

This chapter will attempt to bridge that gap by providing specific context surrounding

• How BAM software is structured
• Designing your BAM architecture
• Optimizing your BAM architecture
• Creating a BAM Virtual PC for the exercises in this book

This chapter will not cover the installation of BizTalk Server 2009.

How BAM Software Is Structured

As part of a marketing effort, the BizTalk team created a series of posters illustrating the concepts of BizTalk and BAM. While the BAM poster (available for download at http://www.microsoft.com/downloads/details.aspx?FamilyID=193CD7A4-E271-46BB-B4EE-8434DFA779A0&displaylang=en) is visually arresting and provides a great high-level visualization of the many BAM software components, without diving into several sets of documentation, it’s unclear as to where the various components reside or where they are conceptually installed.

Software for BAM falls into three major categories: presentation and tools, service façade and processing, and a database and platform services. Chapter 3 will cover more about the different roles within a BAM deployment, and who uses which tools.

Presentation and Tools

Software within this category is used for the visual presentation of data or tools with which a user will interface.

The BAM Portal

The BAM Portal is an ASP.NET-based application used for the consumption of BAM data. It may be used by all roles within a BAM project. It is installed as part of the BizTalk Server 2009 installation process and configured under the BAM Portal tab. It may be installed on any Windows server that runs IIS, as long as that server is joined to the same BizTalk Server group. It is then accessed by any data consumer with access to a web browser. While the BAM Portal may be installed on the same server as BizTalk, it is generally recommended you install it on a separate server dedicated to BAM and BAM tools.

The BAM Client: bm.exe and the BAM Add-In for Excel

The BAM Client tools are the core tools for building BAM solutions. The BAM Management utility, or bm.exe, provides for end-to-end management and deployment of BAM. The BAM Add-In for Excel provides for the creation of observation models to be deployed to the BAM infrastructure, and the capabilities to consume BAM data within Excel via a data connection (known as Live Workbooks). The tools of the BAM Client are used by business analysts, developers, system administrators, and data consumers. The BAM Client is installed as part of the BizTalk Server installation process, and configured under the BAM Tools tab. As per the installation instructions, ensure that you have already installed Microsoft Office Excel before installing the BAM Client. The BAM Client may be installed on the same server or another computer than BizTalk Server. It is generally recommended that a copy of the BAM Client be installed on each BizTalk server and each client desktop.

Information Worker Tools: Microsoft Office Excel, Microsoft Office Infopath, Microsoft Office Visio

Microsoft Office Excel, along with the BAM Add-In for Excel, is used to create observation models and consume data from Live Workbooks. Microsoft Office InfoPath is used to create XML-based forms for submission to a WCF service (optional). Microsoft Office Visio is used to create business process diagrams. Business analysts, developers, and data consumers use these tools, which are installed as part of the Microsoft Office 2007 installation software. It is generally recommended that a licensed instance of these tools be installed on the desktops of business analysts and developers, while data consumers require only Excel for data consumption.

The Orchestration Designer for Business Analysts

The Orchestration Designer for Business Analysts (ODBA) may also be used to define BAM activities and business processes. As its name suggests, business analysts use this tool. It is installed as part of a stand-alone web download and requires Microsoft Visio to function. It is generally recommended that ODBA be installed on business analysts’ desktops.

The Tracking Profile Editor

The Tracking Profile Editor (TPE) is used to map activities within a BizTalk orchestration or orchestrations to an observation model. This tool, which is for BAM developers, is installed as part of the BizTalk Server installation software and configured as part of the BAM Tools tab. It is generally recommended that an instance of the TPE be installed on developers’ desktops.

Visual Studio 2008

Visual Studio 2008 serves as the basis for the BizTalk Server development environment and as a means to create interceptor configuration (IC) files. BAM developers rely on this tool. It is installed as part of a stand-alone installation from the Visual Studio 2008 installation media. It is generally recommended that a licensed instance of Visual Studio 2008 be installed on the desktops of BAM developers.

Microsoft Office SharePoint Server

Microsoft SharePoint Server may be integrated with BAM and the BAM data stores by serving as a portal mechanism to display BAM data or by using the MOSS dashboard and portal to display KPIs from the BAM API (views); and/or may integrate the MOSS BDC with BAM using custom code. This tool, used by business analysts, developers, and data consumers, is installed as part of its stand-alone installation media and involves a great deal of planning. Integration between a SharePoint farm and a BizTalk group must be a carefully designed effort. It is generally recommended that a licensed version of SharePoint be installed on its own server farm. If the integration is performed via a data-enabled SharePoint web part, the web part must be deployed to each server in the farm using SharePoint Central Administration. The account utilized by the web part should have the necessary permissions to the BAM SQL Server databases. SharePoint Server is accessed by data consumers via web browser or mobile device.

Microsoft SQL Server Reporting Services

Microsoft SQL Server Reporting Services (SSRS) may be integrated with BAM and the BAM Primary Import database to build reports against the data stored within BAM. Using this tool, business analysts and developers design reports and data consumers view those reports. It is important to have Visual Studio 2008 installed before attempting installation of SSRS. SSRS is installed as part of the installation media included with SQL Server 2008. Depending upon the amount of network traffic and usage, it is generally recommended you install SSRS on its own server. Reports are then consumed by data consumers’ desktops via web browser or e-mail.

Microsoft PerformancePoint Server

Microsoft PerformancePoint Server is Microsoft’s Enterprise Performance Management application used to host dashboards and scorecards. It may be integrated with BAM by utilizing BAM data as the measurable objectives for scorecards and dashboards. Used by business analysts, developers, and data consumers, PerformancePoint Server is generally installed to its own server and accessed via web browser from the desktops of its users.

Custom .NET Applications: Web, Windows, and Console

If you have built any custom .NET applications, whether they be web-based using ASP.NET or Silverlight, desktop-based using Windows Forms or WPF, or console-based, they may access BAM data and serve as a presentation medium via the BAM API. These applications are consumed by data consumers. Custom .NET applications differ in their deployment strategy, but if they access the BAM API, the only requirement is that they be able to interface with SQL Server views (the only officially supported mechanism).

Service Façade and Processing

Software within this category is used to provide an application programming interface with which to interact with BAM, to process and track BAM data, or to monitor the processing and tracking of BAM data.

BAM Eventing: The BAM API, WCF, and WF Interceptors

BAM Eventing is the name for the collection of DLLs, executables, and config files that encompass the BAM API, WCF interceptor, and WF interceptor. BAM Eventing software is used to write data to the BAM data stores from a custom .NET application, a WCF service, or a WF workflow and is installed by the system administrator or BAM developer. BAM Eventing is required on any server or client that wishes to report data to BAM via one of these technologies. For instance, if you wish to instrument your WCF service, BAM Eventing must be installed on the machine hosting the WCF service as well. BAM Eventing is installed using the BizTalk Server 2009 installation media under the Additional Software selection.

BAM Web Services: Management and Query

The BAM Web Services, included as part of BizTalk Server 2006, largely serve to support the BAM Portal and its functionality. As a result, they are not a supported means for querying data for BAM or for managing BAM (however, the SQL Server views and bm.exe, respectively, are). They are not used by any role in a supported fashion; however, BAM developers have been known to use them to create custom BAM portals. When the BAM Portal is installed via the BizTalk Server 2009 installation media, these web services are created in the same web site within their own virtual directories. They require special permissions by default. It is generally recommended that you don’t use these web services unless you wish to build your own BAM portal, as they are unsupported.

BAM Interceptor Performance Counters

The BAM interceptor performance counters provide real-time data on the BAM interceptors via Performance Monitor. Typically used by systems administrators, these counters are installed as part of the BizTalk Server 2009 installation media. In order for the counters to function, BAM Eventing software must first be installed on the server.

BAM Tracking Host

Because BizTalk Server 2009 is optimized for performance, the primary orchestration execution and messaging engines are not geared toward moving messages to the BizTalk Tracking (DTA) or BAM databases. It is therefore recommended that a dedicated background process, the tracking host, be created with this intent. The tracking host exists to move DTA and BAM data from the BizTalk Message Box database to the BizTalk Tracking and BAM Primary Import databases. The tracking host is usually configured by developers and system administrators. It is part of BizTalk and therefore is installed as part of the BizTalk Server 2009 installation process from the BizTalk Server 2009 installation media.

WCF Services and WF Workflows

WCF services and WF workflows are technologies that serve as components of larger applications or solutions. BAM may be used to intercept data from these two technologies. Business Analysts create an observation model of the data to be monitored, while developers and system administrators develop and configure this integration, and data consumers actually use the data. Because they are components of larger applications, WCF services and WF workflows are installed as part of those larger applications. In order for data to be intercepted from them, the BAM Eventing software must be installed on the same server(s) on which the WCF and/or WF host reside.

Database and Platform Services

Software within this category is used for the storage and analysis of BAM data, including data created as a result of that storage (e.g., BAM alerts).

SQL Server Notification Services and the BAM Alert Provider for SQL Notification Services

Noticeably absent from SQL Server 2008 is SQL Server Notification Services. BAM utilizes Notifications Services, a technology from SQL Server 2005, as its implementation medium for BAM alerts. This is done by creating a BAM alert provider. Although it is architecturally messy and involves downloading hotfixes and the SQL Server 2005 Notification Services stand-alone components, the BAM alert provider may still be used within BizTalk Server 2009. BAM alerts are designed by the business analyst role, developed by the BAM developer role, deployed by the systems administrator role, and consumed by the data consumer role. They are installed using a series of stand-alone downloads from the Internet, as well as the BizTalk Server 2009 installation media. Notification Services include three separate roles as well: provider, generator, and distributor. Depending upon the number of BAM alerts you expect to generate, you may distribute these roles across multiple servers to provide for greater scalability (by modifying the application definition file). However, in general, it is recommended that Notification Services be installed on a single BAM-specific server.

SQL Server Analysis Services

SQL Server Analysis Services provides advanced analytical capabilities to BAM. Specifically, the BAM Analysis database is stored in SQL Server Analysis Services. It is installed as part of the SQL Server installation process using the SQL Server media. Analysis Services for BAM Aggregations is then installed atop SQL Server Analysis Services.

SQL Server

SQL Server is the persistence and storage mechanism for BAM data. BAM installs several SQL Server databases, and utilizes the SQL Server technologies quite comprehensively. SQL Server, used by system administrators, is installed in the BizTalk Server and BAM installation process with its own stand-alone media. It is generally recommended that SQL Server be installed on its own server(s). Depending upon your needs, the BAM databases (Primary Import, Archive, Star Schema, Analysis, and Notification Services) may be installed on different SQL Servers entirely. The installation documentation provides the necessary requirements for doing so. The BAM databases may also be shared across multiple BizTalk Server groups.

Designing Your BAM Architecture

The BAM software components were designed with flexibility in mind, providing the ability to install all components on a single server or distribute the components across multiple servers. With an understanding of the purpose of each component and a general recommendation of its conceptual installation, designing a logical and physical BAM architecture becomes a great deal easier.

The three categories of BAM software don’t necessarily map to physical installation location on a one-to-one basis. Instead, the design of a BAM architecture is usually based upon role and function. Where traditional deployment topologies include production, staging/UAT, test/QA, and development environments, BAM adds the dimension of roles.

Server Role Topology

If you’re a systems administrator, an applications developer, or a business analyst, you’ll interface with BAM and BizTalk in different ways. Typically, a BAM server role topology involves three structured environments: run-time, design-time, and usage-time. Each of these environments may or may not include a production, staging/UAT, test/QA, and development environment depending upon need. Members within a role will utilize different environments based upon function.

Generally, the server role topology maps to the deployment topology as shown in Table 2-1.

The Run-Time Environment

The BAM run-time environment (RTE) is where BizTalk and BAM processing occurs. It includes software components from all three categories. A basic BizTalk and BAM run-time environment can include the following (see Figure 2-1):

• BAM API
• BAM WCF interceptor
• BAM WF interceptor
• BAM tracking host
• Analysis Services for BAM Aggregations
• BAM alert provider
• SQL Server Notification Services
• BAM databases
• BizTalk run time
• BizTalk send and receive hosts
• BizTalk databases

While all of these components may be installed on the same server, availability and scalability will be greatly compromised in doing so.

Figure 2-1. An example of a single-server BAM software installation

As the number of WCF services and WF workflows being intercepted and the number of applications utilizing the BAM API grows, so too will the load on the server. Fortunately, the BAM Eventing software may be installed on multiple servers, making these technologies easy to scale out.

As the number of orchestrations executing and messages being received, transformed, and sent grows, so too will the load on the BizTalk in-process or isolated hosts allocated on the BizTalk server to handle the load. Because BizTalk servers may be added to the group, the hosts may be scaled across multiple machines. Additional BizTalk Message Box databases may be added as well to handle load. However, cross-cutting every BizTalk host instance is the ability to track. The BizTalk host instances are optimized for message exchange, not tracking. It is generally recommended that a separate host be allocated for tracking purposes. The tracking host should be run on two servers running BizTalk Server for redundancy purposes. Optimal performance conditions dictate that at least one tracking host service exist per BizTalk Message Box database, and that for redundancy purposes, an extra tracking host service be on the ready (that is, the total number of tracking hosts should be n+1 where n represents the number of BizTalk Message Box databases).

Analysis Services, as you may imagine, has the potential to introduce additional performance bottlenecks as load grows. Real-time aggregation is a memory-intensive operation. The SQL Server architecture and BizTalk configuration wizard provides the ability to scale Analysis Services out into its own server or series of servers if need be.

In general, BAM alerts are not memory intensive. We’ve seen BAM projects where numerous BAM alerts have been created, and then later refined and reduced in number to include only those of the most interest. Conversely, we’ve seen BAM projects where only a few BAM alerts were created initially, but the number later expanded as the scope of data flowing into BAM increased. Over time, you may wish to segregate BAM alerts and the Notification Services component onto its own server.

The BAM databases may also be installed on different servers than the BizTalk databases as load grows. The individual BAM databases themselves may also be installed on different servers to distribute load.

It’s very important to note that BizTalk is an optional component with BAM. BAM may be installed for the sole purpose of monitoring WCF services or WF workflows, with no monitoring of BizTalk orchestrations whatsoever. Because it is part of the BizTalk server installation, however, most BAM implementations include BizTalk’s execution engine.

Initially, a basic and common BAM run-time environment begins with four servers, configured as shown in Figure 2-2.

Figure 2-2. A basic BAM run-time environment

To provide even greater availability, and due to cost and space concerns, multiple, clustered SQL servers and a BizTalk Server group should be included in your topology. You may also consider test/QA, staging/UAT, and production instances for each of these four server roles.

The Design-Time Environment

The Design-Time Environment (DTE) is where the design and creation of BAM solutions occurs. This design occurs on workstations allocated for business analysts and BAM/BizTalk developers.

BAM solutions tend to be quite resource and artifact intensive. A standard set of tools should be made available for both roles, while the artifacts generated by those tools should be stored in a centralized location such as a Team Foundation Server or Visual SourceSafe repository.

Following are the BAM components that may be included in the design-time environment:

• The BAM Client
• Information Worker Tools
• ODBA
• The Tracking Profile Editor
• Visual Studio 2008
• Custom .NET applications
• BAM Eventing
• BAM Web Services
• WCF services and WF workflows

In a usage-time environment that includes multiple consuming applications, all of which typically have a large installation footprint much like BAM and BizTalk server, it can become very difficult to install all of the necessary tools to build BAM-enabled solutions. Many of the tools also have specific configurations that may cause incompatibility with other tools.

An effective technique to remedy this challenge is workstation virtualization, a technology used to rapidly deploy virtual machine images to BAM developers and BAM business analysts worldwide. A single virtual machine image may be created, updated, and deployed with the necessary tools to build to the specific scenario.

One of the benefits to this approach is also that a consistent, standardized development environment is made available to end users. BAM tools, such as Microsoft Excel, Microsoft Visual Studio, Microsoft BizTalk Server, and so forth, do take a great deal of time to install, uninstall, repair, and update (see Figure 2-3). For this reason, we recommend workstations use a virtualization technique, such as Microsoft Virtual PC and differencing disks or Remote Desktop, to help to overcome this hurdle.

Figure 2-3. A basic BAM design-time environment

The Usage-Time Environment

The usage-time environment (UTE) of BAM focuses on the consumption and utilization of data produced by BAM. Because BAM data is stored in a SQL Server database and a SQL Server Analysis Services database, applications such as the BAM Portal, Microsoft PerformancePoint Server, Microsoft SharePoint Server, and custom .NET applications may all take advantage of BAM.

The structure of the usage-time environment server topology (see Figure 2-4) will vary depending upon need. By its definition, a usage-time environment will include some consuming application. In general, most BAM solutions use the BAM Portal or an Excel Live Workbook.

Figure 2-4. A basic BAM usage-time environment

For peak demand times, the servers that host the BAM Portal should include network load balancing to better distribute the load.

Operating Systems per Environment

BizTalk Server 2009 is supported on Windows Server 2008, Windows Server 2003, Windows XP with Service Pack 3, and Windows Vista with Service Pack 2. Deciding upon which is a matter of the purpose of the BAM installation itself.

Servers existing within the run-time environment and the usage-time environment, including separate production, staging/UAT, and test/QA environment instances, should run Windows Server 2008 or Windows Server 2003.

Workstations within the design-time environment should run Windows Vista or Windows XP for development purposes including the rapid prototyping of BAM and BizTalk scenarios.

Currently, BizTalk Server 2009 is not supported on beta versions of Windows 7 or Windows Server 2008 R2.

Licensing

Because it is not a server component of BizTalk, but falls under the category of additional software, the licensing model for BAM differs from that of BizTalk. An additional license is not required when installing BAM on more than one server.

The BizTalk Server 2009 licensing FAQ includes the following:

You are required to have a valid processor license for each processor on which you install any component of the “server software.” However, you may install “additional software” on any number of internal devices for use solely in conjunction with the server software or other additional software. Additional software includes (but is not limited to):

• BizTalk administration and monitoring tools
• BizTalk-related schemas and templates
• Development tools
• Master Secret Server or Enterprise Single Sign-On
• Software development kits (SDKs)
• Business Activity Monitoring Event Application Programming Interface (API) and Administration Tools
• BAM Interceptors for Windows Workflow Foundation and Windows Communication Foundation
• Business Activity Services

Any components not specified “additional software” in your licensing materials are considered server software and require a valid processor license when utilized.

Optimizing Your BAM Architecture

With physical space becoming increasingly expensive in data centers and heat dissipation and energy consumption continuing to be major issues in on-premise hosting, one of the more common practices utilized is virtualization technology.

Virtualization technologies are typically utilized in production and staging/UAT environments using Microsoft’s Hyper-V technology, and on the design-time environment workstation in Windows Vista using Microsoft’s Virtual Server or Microsoft Virtual PC.

Microsoft offers a full guide to virtualization of BizTalk on the Hyper-V platform, currently written for BizTalk 2006 R2. Because the underlying architecture of BizTalk Server 2009 is nearly identical to that of BizTalk 2006 R2, the guide may also be used for the virtualization of BizTalk Server 2009. The guide may be found online at http://msdn.microsoft.com/en-us/library/cc768518.aspx and may be downloaded from http://go.microsoft.com/fwlink/?LinkId=123100.

The guide is divided into four major sections: “Getting Started,” “Deploying BizTalk Server on Hyper-V,” “Evaluating BizTalk Server Performance on Hyper-V,” and “Testing BizTalk Server Performance on Hyper-V.”

Virtualizing BizTalk, much like the virtualization of any technology, may incur some degree of performance degradation. Fortunately, Microsoft also provides two very strong guides to optimizing BizTalk performance:

• The Microsoft BizTalk Server Optimization Guide, which may be downloaded at http://technet.microsoft.com/en-us/library/cc296643.aspx
• The Microsoft BizTalk Server Performance Optimization Guide, which may be downloaded at http://msdn.microsoft.com/en-us/library/cc558617.aspx

Additionally, there are numerous professional services organizations with expertise in BizTalk that are able to help with your installation.

Creating a BAM Virtual PC for the Exercises in This Book

In order to perform the many exercises throughout this book, you’ll need to create your own Virtual PC image. While we won’t go through the process in painstaking detail (that’s what the installation and configuration guides are for), the general process for building a BAM development ready Virtual PC is as follows:

1. Download and install Microsoft Virtual PC.
2. Create and configure a new virtual machine with at least a 16GB dynamically expanding master drive and a 16GB dynamically expanding data disk.
3. Install Windows Server 2008 on the virtual machine image.
4. Install critical Windows updates.
5. Enable Internet Information Services.
6. Install Microsoft Office Excel.
7. Install Visual Studio 2008 with SP1.
8. Install SQL Server 2008.
9. Install SQLXML 3.0 with SP3.
10. Install Microsoft Management Console 3.0.
11. Install prerequisites for MQSeries Agent (optional).
12. Install SQL Notification Services.
13. Install SQL Server 2005 with SP2.
14. Install Windows SharePoint Services.
15. Disable the Shared Memory Protocol.
16. Join the local administrators group.
17. Configure the Application Event Log.
18. Install BizTalk Server.
19. Verify your installation.
20. Configure BizTalk Server.
21. Enable TCP/IP and named pipes.
22. Enable DTC on the local host server.

Summary

This chapter detailed the many software components of BAM and provided insight into the three server role topologies typically found in a BAM solution: run-time environment, design-time environment, and usage-time environment. The chapter also included recommendations as to which of these server role topologies should be duplicated in production, staging/UAT, test/QA, and development deployment environments. The chapter also examined the typical BAM components that are installed on each server in the server role topology.

The chapter included the considerations that must be undertaken when planning and deploying a BAM environment, including operating systems, virtualization, and licensing. The chapter concluded with instructions on how to set up a virtual machine using Microsoft Virtual PC to perform the exercises found in this book.

Now that your BAM development computer is ready, the next chapter will get your hands dirty in a real-world BAM scenario and walk you through creating your first BAM project.