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.
- Create a BAM Activity and view (or use this sample)
- 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)
- Create a tracking profile, to bind all activity fields to context properties (or use this sample)
- 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.
Considerations
Orchestration Debugging
By turning of global tracking, you will not be able to debug orchestrations
Performance
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.
Result:
| Scenario | Received msg/sec | Total time/msg |
| Default * | 1005 | 49ms |
| Default * + BAM ** | 761 (-24%) | 52ms (+6%) |
| No Tracking | 1350 (+34%) | 37ms (-25%) |
| No Tracking + BAM ** | 1001 (0%) | 49ms (0%) |
* Tracking for promoted properties enabled
** all ports have been tracked