Tracking data with BAM

  • Article

Business Activity Monitoring (BAM) is a powerful feature in BizTalk server which enables to track the required data in business processes to monitor the progress. Purpose of this post is to share my learnings on using BAM.

  • BizTalk comes with Tracking Profile Editor (TPE), which provides developers a graphical way to instrument orchestrations and ports by mapping the data with the items in the BAM activities. Although for many solutions this works great, it has certain limitations. These can be met by using BAM API.
  • Consider using OrchestrationEventStream and MessagingEventStream instead of DirectEventStream, when using BAM APIs. These temporarily writes the data to MessageBox database unlike DirectEventStream which writes the data directly into BAM database. The tracking host (TDDS service) moves the data from message box database to BAMPrimaryImport database, periodically. This performs better as calls are asynchronous i.e. caller does not wait for data to be committed in BAM database, and it is transactionally consistent with orchestrations and pipelines i.e. if orchestration rolls back for some reason then BAM entries are also rolled back.
  • If you use DirectEventStream, you will need to specify the database connection string, as it directly writes to database i.e you will need to store the connection parameters in your application. The best way to do this is by storing this as configuration data (in BizTalk configuration file or in SSO database). When using OrchestrationEventStream, you don’t have to worry about the server and database names as BizTalk automatically takes care of database connections based on BizTalk configuration.
  • It is better to use BAM to track message body data than the built in message body tracking for performance reasons. Built in message body tracking is good for debugging scenarios, temporarily. But if you always need to track message body data, consider using BAM.
  • In general, avoid BAM continuations if you can as it incurs performance overhead. If you can not do without it, but try your best to limit to using 2 continuations with a BAM activity.
  • The data traced from BizTalk Server is received in UTC format. If you use the event stream APIs to provide date and time tracking data in local time format, the data in the BAM portal will be incorrect as the expectation is that all times in BAM data are in UTC format.
    If you have existing applications that use local time, and you are now upgrading and planning to use the BAM portal, you must modify your data to make it conform to UTC format. You also need to modify your custom application to convert to UTC format. 
  • It is recommended to review and monitor the BAMPrimaryImport database size over a period of time. By default, the configuration is to archive the data older than 6 months into BAMArchive database. For more information, see this article: Archiving Primary Import Database Data.
  • To identify the bottleneck with BAM ensure that the active Instances count is not climbing, the SQL agent service is running, and BAM_DM_ (Data Maintenance) job is scheduled to run at periodic intervals. Also if OLAP Analysis is configured ensure that the BAM_AN_ job is running at periodic intervals.

There is a great whitepaper available on MSDN: Business Activity Monitoring in Depth for Developers. This is recommended for all developers starting to work on BAM.

Please do leave comments, if any questions or issues or suggestions. Thanks!