Note: This information applies to Tracking Profile Editor in BizTalk Server 2006

You may face situations where Tracking Profile Editor does not work as expected or behaves in unknown ways. The help that ships with TPE is at times not descriptive enough to list each and every quirk associated with TPE. As I played around and experimented with TPE, I found it useful to list all the helpful hints that proved immensely useful to me later on. They are all listed here in no particular order of importance.

• Multiple instances of TPE can exist simultaneously. You can work on the same tracking profile in two different instances of TPE. While saving the tracking profile, the TPE instance that save the profile last will overwrite the previous changes, if any. Same is true while applying a tracking profile. It is recommended to work with one tracking profile in one instance of TPE to prevent accidental data loss.
• The management database setting specified via TPE is retained across sessions.
• While specifying the management database server, do not leave any spaces around the comma port separator when specifying a SQL port. For example, "foo,1234" (quotes not included)  is correct while "foo , 1234" (quotes not included) is not. Specifically, any connection string format that is acceptable to SQL server can be specified here. So, a . (dot) will be equivalent to localhost and will be perfectly acceptable to TPE.
• Original activity items, except for related activity names, can't be deleted in TPE.
• Mapping a data item to ActivityID folder is not mandatory. If nothing is mapped to ActivityID, then a GUID is generated and assigned to ActivityID by default. Interpreting GUIDs with a human eye is always a challenge. If the messages that are tracked by TPE contain a field that has a unique value, SSN in our case, then it becomes meaningful and convenient to map such unique valued fields (SSN) to ActivityID folder.
• Document Reference URLs folders can be used to track almost anything and not just document URLs. The only advantage that these folders offer that they appear on the BAM Portal. A single click on the BAM Portal link will take you to the document. Mapping anything other than the document URL is not very useful as, although visible as a link, it will take you nowhere in BAM Portal. The intent is to allow custom user interface developers to gain access to associated document information so that they can present it to the end user.
• If a continuation doesn't have a matching continuationID or vice-versa, TPE will warn you but not prevent you from applying the tracking profile. This is due to the fact that continuations can be established and populated using BAM APIs as well. In fact, one can mix TPE with BAM APIs freely. This is recommended for special situations where TPE alone can't fulfil the purpose. The whole purpose for using TPE is to avoid writing code as much as possible.
• You may define and map to any related activity but only those related activities will be visible on the BAM Portal that are under the same view. The same view restriction is forced by BAM Portal and not TPE.
• When you import an activity definition to start work on a brand new tracking profile, TPE shows the activities in the same view as related activity folders by default. TPE doesn't enforce this. You can add any activity as a related activity and map to it. TPE will allow this.
• If a tracking profile is modified and then re-applied, BizTalk will store the new version of the tracking profile along with the older versions. Older versions are not deleted or overwritten. This is because a long running orchestration might be using the older version. Any new instance of an orchestration will pick up the latest version of the tracking profile. A removal, results in the removal of all the versions of the tracking profile for that particular activity.
• There is no direct way to get a list of tracking profiles currently applied. The list of tracking profiles is stored in the BizTalkMgmtDb database in the bam_TrackingProfiles table. You can create a custom query to get that information.
• When tracking orchestration shapes, the end time for the shape's execution is reported by the engine as the milestone value.
• TPE lets you map multiple sources to the same item in an activity. In such a situation, the last artifact that was encountered during the BAM processing is the one whose value persists in the database and is viewable in the BAM portal.
• Not all message properties are available at design time. An example of this is when the listen shape is the first shape in a orchestration. When message properties are mapped from this shape, only the following properties have values: InstanceID, ServiceID and ServiceClassID. (MessageID is not in scope at this point and has a null value). MessageID will be guaranteed available for a send/receive shape. If your orchestration doesn't have a send/receive shape, you may not be able to track its value.
• Properties and message payload data items can be mapped to milestones. The value is evaluated at run time only. The date time values must be in a format that is acceptable to SQL server. Any casting problems will show up as an event log error.
• Message payload data, context properties and message properties can be tracked from both orchestrations and ports. The menu items and the final presentation is quite similar for both and is cause for confusion. The differentiating factor is the place from where they are chosen. For orchestrations, right click on an orchestration shape and select from the appropriate menu items. Stuff tracked there after will be in the orchestration context and there is no need to specify any ports. For ports, always go through the "Select Event Source" button menu items. The following sub menus: Select Messaging Payload, Select Context Property and Select Messaging Property track data from ports and would require a port mapping specified after creating a mapping. After mapping the item, right click the mapped node on LHS and you will see "Set Port Mappings" menu item. Choose this menu item to select the ports from which to track the data. If this menu item is disabled/unavailable, then you most likely ended up here from an orchestration shape and that may not be your intention. If you see this context menu item disabled, and would like to see this to be enabled so as to specify the port, delete this mapping and load your event sources via the "Select Event Source" button menu items.
• Pass through pipelines present a special challenge with respect to continuations. This is because pass through pipelines, by definition, are not aware of any XML message schema. Consequently, no data is tracked by engine including system properties like SessionID. The alternatives are to either remove all message payload tracking from a pass through pipeline or use an XML pipeline.
• Mime pipelines are not supported on 64 bit platforms and consequently can't be tracked by TPE. The workaround is to run a host instance in 32 bit mode and run the application on this 32 bit host.
• Removing a tracking profile removes all versions of it.
• Port start/end tracked time are the times when the pipeline finishes up. This means that if there is a an error in the pipeline and the message is suspended then the port start/end time will not be tracked. In the case of pipelines, it is not explicitly clear when the sampling of data occurs. The answer to that is, at the end of the pipeline. The easiest example to understand this is the case of sending data to a sharepoint document library. Well behaved transport adapters will populate a new property that will contain the target address (URL) of the data delivered by the adapter. In order for this to work, obviously, the tracking must occur after the transport completes, which implies "at the end of the pipeline."    

On the receive side, there is a slight nuance to be aware of. Specifically, because of the statement that tracking will occur at the pipeline's end, it might seem that properties like "ReceiveTime" or "PortStartTime" will not be available. However, it is in fact the case that the maximum amount of data (in the form of properties) is available at the end of the pipeline. Therefore, the statement that tracking occurs at the end of the pipeline does NOT mean that properties like "ReceiveTime" or "PortStartTime" will not be available. It simply means that this property value would not be tracked until the end of the pipeline, even though the value of this data source would have been set at the time the message was actually received (typically the lag here would be seconds or less, but it is conceivable that some stateful pipeline components could take significant portions of an hour or longer).

• TPE figures out the begin and end of an orchestration. This is fine and dandy except when TPE is faced with a parallel shape at the beginning/end. Then it is impossible for TPE to figure out the begin/end of the activity. In such a case you will see an error if you map from an orchestration shape on the parallel branch to the ActivityID folder. The only recourse in such a case is to not map to ActivityID at all. This will result in a GUID being assigned to the ActivityID.
• The following shapes can't be mapped and thus can't be tracked: group, message assignment, loop, suspend, terminate, throw exception, transform. These shapes are invalid shapes. Consequently, you can't map from an orchestration if it starts/ends with an invalid shape. TPE will provide GUI hint in the form of a blocked cursor if you try to map from one of these shapes.
• The MessageID can only be tracked from a send/receive shape.
• TPE touches upon a few databases. It stores tracking profiles themselves in the management database, interceptor configurations in the Primary Import Table database and the orchestration xsyms in the DTA database.
• The milestone information captures by TPE is in UTC. You can track the time in local time.
• BizTalk Server 2004 custom pipelines can't be tracked using TPE once they are upgraded to BizTalk Server 2006. This is due to the fact that pipeline tracking is a new feature of BizTalk Server 2006 that never existed in BizTalk Server 2004. Of course, the default xml and pass through and other pipelines are trackable after upgrade. The restriction applies only to custom pipelines.
• Orchestration variables are not exposed and thus can't be tracked using TPE.
• TPE does not allow mapping from adapters and web services. The only support is for tracking system/context properties that are populated by the adapters/web-services/code. An alternative is to use BAM APIs which require no TPE involvement.
• TPE can be used to map and track data from BizTalk artifacts only. This means that if you have a 3rd party custom component/code then there is no alternative but to use BAM APIs to track BAM data. However, what you could do is try to extend your 3rd party custom component to implement the tracking interface which BizTalk uses behind the scenes on every shape which is used by TPE to track and change BAM calls.
• Tracking profiles cannot be added to the BTS application package until sometime after the solution is first deployed to a live BTS management environment. There is no mitigation provided. It is assumed that tracking profiles are easily applied as a finishing act of the overall solution deployment by the IT professional. It is assumed that the BTS application package would include the tracking profiles in subsequent staging of the solution to other environments.
• Storing a tracking profile in the database is no longer referred to as a "deploy" action.  This is due to possible confusion with the more formal BizTalk server deployment feature set, as well as to make it clear that tracking profiles are more "in addition to..." as opposed to some item which is required for the BizTalk application to actually function.  This is a terminology change from BizTalk Server 2004, which called this action "Deploy."  It is now called "Apply."  Un-deploy, which is a new feature for BizTalk Server 2006, is now called "Remove."

THIS CODE AND INFORMATION ARE PROVIDED "AS IS" WITHOUT 
WARRANTY OF ANY KIND, WHETHER EXPRESSED OR IMPLIED,
INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND/OR FITNESS FOR A PARTICULAR PURPOSE.