1 out of 1 rated this helpful Rate this topic

BAM Architecture

Business Activity Monitoring (BAM) provides visibility into business processes independent of the IT implementation or across a heterogeneous IT implementation. Using BAM, you can view business data in as close to real time as possible, referred to as zero latency. This distinguishes BAM from operational monitoring such as Health and Activity Tracking (HAT).

The following figure shows how data flows from the BAM API, to the MessageBox database, to the BAM Primary Import database, and then to the other BAM databases.

BAM architecture

Following is a description of the main BAM components.

BAM Definition Workbook

The business analyst uses the BAM Activity Wizard to specify what data to collect and how to interpret it. This is called the BAM view. When finished, he saves this view in a Microsoft Excel Workbook called the BAM Definition Workbook.

For information about the BAM Definition Workbook, see Prerequisites for Using BAM Workbooks. Instructions for using the BAM Definition Workbook are located in "Defining Business Activities and Views in Excel" in BizTalk Server 2004 Information Worker Help.

BAM Primary Import database

The BAM Primary Import database is the center of the Business Activity Monitoring system. Most of the SQL objects in this database—such as stored procedures, tables, triggers, and views—are dynamically generated based on the information in the BAM Definition Workbook.

BAM Analysis database

BizTalk Server stores data about activity instances in the BAM Primary Import database for a given period of time online (for example, six months). On a scheduled basis, the Cube Update Data Transformation Services (DTS) package moves the data to the BAM Analysis database.

When the data is in the BAM Analysis database, it is used to build activity aggregations and OLAP cubes.

For more information, see Activity Data Storage.

BAM activity aggregations and OLAP cubes

Activity aggregations are maintained in the form of OLAP cubes. For each view that has aggregations, BAM creates three cubes:

Completed instances cube, which contains the aggregations about activities that are complete, that is, no more events are expected. This cube is processed incrementally.
Current activities cube, which contains aggregations based on a snapshot of the Activities that are in progress. This cube is Fully Processed each time.
All instances virtual cube, which joins the above two cubes, and thus hides this implementation necessity from the user.

For more information, see Aggregations.

Real-time aggregations

The most important slices of the multi-dimensional aggregation structure can also be defined as real-time aggregations (RTA). To support real-time aggregations, special tables are created in the Analysis database. The aggregations are maintained synchronously with the incoming events via triggers.

When deploying a BAM Definition Workbook, a copy of it is created that is bound to the live-data aggregations in the OLAP or RTA tables.

For more information, see Real-Time Aggregations.

Cube Update DTS package

The system administrator schedules the Cube Update DTS package to run on a regular basis to update the data in the cubes. When the DTS package runs, it obtains a snapshot of the running instances, and puts high-watermark on the completed instances to be processed in one operation. The high-watermark ensures that each activity instance either contributes to the completed aggregation or the current aggregation, but never both.

When the DTS package obtains a snapshot, it does so instantaneously; it does not stop the event writers. After this, the DTS package transforms the data and processes the OLAP cubes.

For information about running the Cube Update DTS package, see Scheduling the DTS Packages.

For information about creating a custom DTS task, see Using BAM with Custom Analysis Tasks.

BAM API

The events for the business activities can be synchronously pushed into the BAM infrastructure via the BAM API.

To improve the performance, the business applications can quickly get rid of the activity events by storing them in raw binary format in the MessageBox database. In this case, the events will be processed later by the BAM Event Bus Service, using CPU and other resources on separate computers.

Independent of which EventStream you use, you can instrument the application once and forever with the BAM interceptor. When you instrument the application, the event format is controlled with metadata rather than being hard-coded. This enables you to develop tools that control the verbosity and content of the BAM events without taking the business implementation offline.

For more information, see Considerations for BAM Applications.

BAM Interceptor and the Tracking Profile Editor

The BizTalk Orchestration Engine is instrumented with the interceptor, so no programming is required to change the BAM tracking. For more information, see Using the BAM Interceptor.

You use the Tracking Profile Editor to import the BAM Definition Workbook, and to define the mapping via drag and drop of orchestration actions to business milestones, and items from the XML schemas into the business data items. For more information, see Tracking Profile Editor.