How to replace Tracking with BAM in BizTalk

Listen with webReader
Published 22 May 08 02:00 AM | wmmihaa

There are several reasons why you’d consider using BAM as your primary tracking source, rather than the regular tracking (BizTalkDTADb).

  • The BAM infrastructure allows purging and partitioning of tables while updating views allowing you to access the data from all tables. The Tracking database (BizTalkDTADb) comes with correspondent jobs, but leaves no aggregated way of querying all purged tables in a single view.
  • Filtering for promoted properties in a large Tracking database, most often result in a time out exception.
  • The Tracking database does not come with any support for Analysis Services.

Enabling BAM Tracking does not take much effort.

  1. Create a BAM Activity and view (or use this sample)
  2. Export the activity to XML, and deploy it to BizTalk using the bm tool. Eg. C:\program files\Microsoft BizTalk 2006\Tracking\bm.exe deploy-all -definitionfile:[path]\generictracking.xml (the sample above, includes a sample bat file)
  3. Create a tracking profile, to bind all activity fields to context properties (or use this sample)
  4. Set the port binding for each context property using the Tracking Profile Editor. This step is kind of tedious, since you have to complete this step for every port you add. You might be better of using this tool instead.


(the screen-shoot was taken after a new BizTalk installation, but I'm sure you get the point...)

Completing each of the steps above will cause each selected port to be tracked to BAM. This serves many purposes as-is, however, at this point you are tracking to both the tracking database and the BAM database. To turn of global tracking, you need to complete some additional steps well described in Mick’s Breeze Blog.

You should maintain a dedicated tracking host, even if you disable global tracking. This is because BAM events use the Tracking Data Decode Service (TDDS).

All successful messages will now only be tracked to your BAM tables. However, failed messages will not be tracked to BAM. You will still see them in the BizTalk Administration Console, but they will not appear in the BAM activity. If you want to resolve this, you could build a Windows Service that subscribes to suspended messages using WMI events, or you could just use this sample. The service expects the BAM Activity to include FaultCode and FaultDescription.


Orchestration Debugging

By turning of global tracking, you will not be able to debug orchestrations


According to my testing there is a <10% overhead, replacing Tracking with BAM.

Testing environment:
Application Server:
HP BL465c G1 2Gb RAM
Windows Server 2003 Standard Edition
BizTalk Server 2006 R2 Developer Edition X64
Database Server:
HP BL465c G1 2Gb RAM
Windows Server 2003 Standard Edition
SQL Server 2005 SP2 Standard Edition X64

BizTalk Setup environment:

Receive Location using the FILE adapter, passthrough pipeline.

Send Port using the NULL Adapter (since I didn’t want any extra overhead) , passthrough pipeline

When using the BAM Tracking, all ports have been tracked.


Scenario Received msg/sec Total time/msg
Default * 603
Default * + BAM ** 457 (-24%) 52ms (+6%)
No Tracking 810 (+26%) 37ms (-25%)
No Tracking + BAM ** 601 (0%) 49ms (0%)

* Tracking for promoted properties was not enabled

** all ports have been tracked

Filed under: , ,


# Sune Nielsen said on May 22, 2008 08:09 AM:

Is there not a limit to the size of messages tracked in BAM ? around 1 MB max.

# wmmihaa said on May 22, 2008 08:55 AM:


Yes there is, however tracking the message body is seldom an option, due to the performance impact. The solution described above does not track the message body, unless you create your own BAM Activity and profiler. However, if this is nessecary you might want to take a look at the

SQL Archiver component I worte about a couple of months ago:

Thanks for the input


# Be Logical - writings by Johan Hedberg said on May 22, 2008 01:31 PM:

Mikael Håkansson has a post called How to Replace Tracking with BAM in BizTalk that features a performance

# Antti Somersalo said on May 25, 2008 10:00 PM:

I believe you should do not bind receive port to SPName or OutboundTransportLocation. Same goes with send port and ReceivePort or InboundTransportLocation. At least after this adjustment the rows in BAM look more meaningful.

This Blog


    MVP - Microsoft Most Valuable Professional BizTalk User Group Sweden BizTalk blogdoc

    Follow me on Twitter Meet me at TechEd


    Locations of visitors to this page


    The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.