BizTalk Server BAM – Limitation of Tracking Profile Editor (TPE)

The Tracking Profile Editor (TPE) is often the first tool developers reach for when implementing Business Activity Monitoring (BAM) in BizTalk Server. It’s intuitive, graphical, and requires no code changes. However, it isn’t a “magic bullet.” There is one specific limitation that often catches developers off guard.

BizTalk artifacts only!

The most important limitation of TPE is that it can only be used to capture data from BizTalk artifacts. If you want to use BAM to capture data from custom code, you will need to use the BAM API.

Messages and elements limitations

Some messages and elements can’t be tracked with TPE. You can only track messages that have a schema that is known at design time, so you can’t track messages of type string or System.XML.XMLDocument.

Also, you can’t capture data from repeating fields.

Some limitations exist on the length of data item names. The combined length of a folder name and data item instance value cannot be longer than 128 characters.

Orchestration shapes limitations

You also can’t track any of the following orchestration shapes:

• Group (Task)
• Loop (While)
• Message Assignment
• Suspend
• Terminate
• Throw Exception
• Transform

You can work around these limitations for some shapes by wrapping them in a nontransactional scope shape and tracking the scope. However, this doesn’t work for the Suspend and Terminate shapes, as they never fire the Shape End event.

Common Scenarios Where TPE Fails:

• Correlation across different Orchestrations: If your business process spans multiple, decoupled orchestrations, the TPE cannot easily maintain the “thread” of the activity across them without complex correlation sets.
• Non-BizTalk Data: If you need to include data that never passes through a BizTalk port or orchestration (like a step happening in a custom .NET portal), the TPE simply cannot see it.
• Complex Logic: If you need to perform a calculation before sending data to BAM (e.g., adding two message fields together), the TPE cannot do this; it only tracks “raw” values.

The Solution: When to use the BAM API

When you hit these limits, it’s time to switch to the BAM API. By using the OrchestrationEventStream or BufferedEventStream. You gain total control. You can:

• Pass an Activity ID across any number of systems.
• Update a single BAM record from multiple different applications.
• Perform complex data transformations before the data is logged.

The TPE is excellent for 80% of tracking needs. But for the remaining 20%—the complex, multi-message, or cross-platform processes—don’t fight the tool. Understand the limitations of the TPE early so you can choose the BAM API when your business requirements demand it.