The corner store

Bam Best Practices

See Darren's blog on bam best practices

Posted Friday, May 04, 2007 4:27 PM by Vikas | 0 Comments

TPE case files

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

There are situations where TPE doesn't behave as expected. The product documentation provides all factual details but does little justice to resolving common issues. This post is directed at resolving common BAM cases that center around TPE. The cases listed are the ones that customers run into most often. If there is one that you are battling with and would like see the same appear here, let me know.

The case of multiple rows in the activity table with holes/null for values when a single message is processed by BTS solution.

Presence of multiple rows in the activity table when you expect a single row containing all the BAM data suggests that you have mapped the business data of interest correctly, however, your continuations are setup incorrectly. If you track BAM data from multiple BizTalk schedules, e.g., ports and orchestrations, then you would need to setup continuations between these schedules. See product documentation on how to do this. See my blog post on TPE and multiple continuations.

The case of orphaned Tracking profiles

Tracking profiles are associated with an activity. If an activity is undeployed, the associated tracking profiles can become orphaned, which means they are no longer associated with an activity. In such a situation, if you pump a message through your solution, you will notice an error in the event log saying that TDDS ran into some problem (or something to that effect). So, the tracking profile exists but there is no associated activity definition deployed. There is no way to persist the BAM data. This is a well documented scenario. See product documentation on how to remedy this common ill.

The error message are

Event Type: Error
Event Source: BAM EventBus Service
Event Category: None
Event ID: 6
Date:  **/**/****
Time:  *:**:** **
User:  N/A
Computer: **********
Description:
Execute event error. Error(s) occurred while executing events, see TDDS_FailedTrackingData table for more details. SQLServer: **********, Database: BAMPrimaryImport.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

</Event log entry>

<TDDS_FailedTrackingData table entries>

Could not find stored procedure 'dbo.bam_********_PrimaryImport'.
TDDS failed to execute event. Could not find stored procedure 'dbo.bam_********_AddRelationship'.
TDDS failed to execute event. Could not find stored procedure 'dbo.bam_********_EnableContinuation'.
TDDS failed to execute event. Could not find stored procedure 'dbo.bam_********_PrimaryImport'.
TDDS failed to execute event. Parameter is not valid.

</TDDS_FailedTrackingData table entries>

The case of dangling records and uncompleted activity when interchangeID is used for continuations

InterchangeID is available from two sources. One is the message context property bag and other is the system context property bag. You work with the first one through "select event source"->"select messaging property" menu and the other via "select event source"->"select context property" menu->BTS.InterchangeID. Although the values that you will get from either source is the same, the way they are extracted are different.

Regardless of which one you use, you must be consistent in your usage. Stick to one source only.

Posted Tuesday, November 07, 2006 4:01 PM by Vikas | 0 Comments

TPE and multiple continuations

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

For most part now, it seems that creating single continuation [say, between two orchestrations] is a breeze for most developers. The part where TPE is not explicitly clear is the case of multiple continuations. The situation is typical as a BAM activity spans multiple receive ports, orchestrations and send ports. In order to collect the Business Activity Monitoring (BAM) data in one record, one has to setup continuations between all the BizTalk schedules. This turns out to be non trivial through the TPE UI, hence this posting to illustrate the case of multiple continuations.

Let's discuss some special cases. Let me lay out the general terms first. The case of one port OR one orchestration is a special case of many port and many orchestrations scenario. Lets deal with the ramifications of many port and many orchestration scenario. The different ways in which a message can be received and processed by orchestrations presents some interesting challenges and solutions. The scenario consists of a number of receive ports (R), orchestrations (O) and send ports (S). We use interchangeID context property as the glue to bind the continuations. You can, of course, use any other context property, activityID or anything else in place of interchangeID. The choice is immaterial to the problem at hand. I exclude the discussion on the data item/milestone/context-property-value being tracked from these ports and orchestrations. You would do that part of the mapping as per your business logic. Our target is to capture all BAM data from all the ports and orchestrations in a single row in the completed activity table .

A message arrives at exactly one of the R receive ports and gets processed by exactly one of O orchestrations. In this case, you will create a continuation folder on the Left Hand Side (LHS) activity tree view and map the interchangeID context property from the context property schema via "select event source"->"select context property" menu item. Next you will right click on the newly created interchangeID node on the LHS and select the ports to map from. In the select ports dialog box that comes up, select all N receive ports. Next you will create a continuationID folder on the LHS. You will open all O orchestrations, one at a time, and map the interchangeID context property from a shape in the orchestration. The mapping will look something like this:

A message arrives at exactly one of the R receive ports and gets processed by each and every one of O orchestrations. This happens as the message is simultaneously and parallely sent to each of the O orchestrations. In this case, we would need O continuations. The mapping will look something like this:

Now, let's discuss a CBR scenario. A message arrives at exactly one of the R receive ports and gets sent to exactly one of S send ports. This routing happens based on a context property value in the message. In this case, we would need one continuation. The mapping will look something like this:

The above mapping will also hold true in the following case. A message arrives at exactly one of the R receive ports and gets sent to all of the S send ports.

A message is processed by exactly one of O orchestrations (we don't know which one will execute at runtime) and is then sent by that orchestration to all the S send ports. In this case, we would need one continuation. The mapping will look something like this:

A message gets processed by all O orchestrations in sequence, one by one. The mapping will look something like this:

Posted Friday, October 06, 2006 2:30 PM by Vikas | 1 Comments

Tracking interchange versus tracking interchange messages

Note: This information applies to Business Activity Monitoring in BizTalk Server 2006

There are a few tracking scenarios that need explaination as far as tracking options for messages that arrive wrapped in an interchange or batch are concerned. The choice is completely up to the user on how to construct the tracking profile for each of these scenarios. The reasons are:

Different activities for different port-schema pairs (or just port-no schema) scenario. Multiple activities are configured for the same port but for different schemas.
A single activity scenario. For different milestones and data items in the activity, map different XPaths from different schemas. Furthermore:
- If you choose the activity start point as the port start point and you want to track meta-data from the interchange and some payload data from the other created messages, then you will end up using change history table if the change history is turned on for the activity.
- If you choose the activity start after the port start, then, as the interchange is broken up into individual messages, you are will have multiple rows in the activity table. Each row will correspond to one message.
A single activity scenario. For different milestones and data items in the activity, map different XPaths from the same schema. In this case, there will be one row in the activity table. If a schema use is repeated and if change history is turned on for this activity, the change history tables will be populated.

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.

Posted Wednesday, March 15, 2006 10:40 AM by Vikas | 0 Comments

Tracking Profile Editor: Use Case

Note: This information applies to Business Activity Monitoring in BizTalk Server 2006

TPE is the provisioning tool for BAM instrumentation of hte runtime. As such, it is intended for use by someone expert in the implementation of the BizTalk solution. This would typically be the developer, Eddie, himself.

Eddie has been given a BAM Activity Definition file and is asked to develop a tracking profile to provision it. Eddie, given his understanding of the details of the solution, analyzes the BAM Activity Definition and makes a list of assemblies (contents: orchestrations, schemas/context properties, etc.) that he will need to configure in order to complete this task. He then

Launches TPE to edit existing or create new tracking profile.
Selects a management database source pointing to
- Directly - assemblies and their constituent parts which are the event sources.
- Indirectly - the BAM primary import table database and any deployed BAM Activity Definitions, which are the mapping targets.
Selects any artifact, in some cases by assembly (messaging properties being the exception) from which to map (orchestrations/ports).
Imports the BAM Activity Definition.
Drags and drops shapes or message-payload/context-property data items from RHS to the milestones and data items on the LHS.
- Orchestrations
- Schemas: payload-message/context-properties
Deploys and tests the tracking profile.
Saves the tracking profile and checks it into source safe with his notes.

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.

Posted Tuesday, March 14, 2006 5:10 PM by Vikas | 0 Comments

BAM Acronyms

Note: This information applies to Business Activity Monitoring in BizTalk Server 2006

There comes a time when even the experts get lost in the maze of technical acronyms. Almost everything can be, and will be, expressed in three letter acronyms. I am familiar with most of BizTalk Server Acronyms but find myself looking at the index for some long forgotten acronym or abbreviation. I started off with a list of BAM specific list and time is ripe now to publish it to the world.

BAM Business Activity Monitoring

BAS Business Activity Services

DTS Data Transformation Service

HAT Health and Activity Tracking

KPI Key Performance Indicators

RTA Real Time Aggregations

TDDS Tracking Data Decoding Service [Also known as BAM Event Bus Service]

TPE Tracking Profile Editor

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.

Posted Thursday, February 23, 2006 3:55 PM by Vikas | 0 Comments

Considerations when working with Tracking Profile Editor

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.

Posted Thursday, February 23, 2006 3:53 PM by Vikas | 2 Comments

Tracking Profile Editor Error Messages

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

BttDeploy.exe is the command line cousin of Tracking Profile Editor. It provides a subset of functionality that TPE provides. Nevertheless, it provides a very vital subset of TPE functionality. BttDeploy.exe error messages are also explained in this section. The two tools share plenty of common code. BttDeploy is just a thin wrapper over TPE functionality. There are no screen shots of error messages provided here. This is due to the fact that developers will search the error text and not the error dialog box. To make things straightforward, only the core of the error messages is listed here and only the important error messages are listed.

Failed to apply the tracking profile.

Unless you see some additional information along with this error message, it is extremely hard to say why tracking profile could not be applied. Error messages that appear as additional information are explained elsewhere in this document.

If you see the following error string under the main error, "Error HRESULT E_FAIL has been returned from a call to a COM component." on a 64-bit box, then you need to follow the solutions in the following KB article and/or apply the QFE. The error comes up because of an issue with MSDTC. This error has nothing to do with BizTalk or TPE.

Read the KB article on this issue

Download the QFE

Error retrieving activities from Primary Import Table Database.

Error retrieving tracking profile from Primary Import Table Database.

Failed to connect to the Primary Import Table Database.

Failed to enumerate assemblies in the BizTalk Management Database.

Failed to enumerate databases on the {0} server.

Failed to enumerate ports in the BizTalk Management Database.

Failed to enumerate schemas in the BizTalk Management Database.

Failed to open the messaging property schema.

Unable to connect to the BAM Primary Import Table Database to enumerate BAM Activity Definitions. Use Set Management Database from the Tools menu to point to a different location or contact your administrator if the problem persists.

There could be many reasons why these errors can crop up. The server is unreachable, is off the network, SQL server is not running on the server, remote connections might be disabled, etc. Fire up a SQL client utility and ensure that the SQL server foo can be pinged and the management database you select can be opened.

Failed to read server and database names from the registry.

The registry keys that contain the management server and database names are either missing or blank. This usually happens when BizTalk is installed but not configured. Or you have configured everything in BizTalk but not BAM. You might have manually whacked the registry keys. Either way, it is necessary to populate the registry keys with correct information. This can be accomplished by ignoring the error and setting the management server and database via tools->set management database menu item. Fill in the SQL server name on the set management database dialog box. Press {tab} key to automatically populate the database name combo box. Select the correct management database name and click OK. This will fix the problem.

Failed to remove the tracking profile.

Hmm... Can't think of a valid reason why this would happen in normal course of events. Check SQL connectivity?! Is there any additional information in the error message that sheds light on the precise problem that led to this error?

Failed to launch BizTalk Server Online.

I can't think of a solid reason why this error will ever show up. Are you able to launch Internet Explorer successfully and connect to a website?

Failed to launch help.

There are couple of reason why TPE can run into this error. The most simple and straightforward reason is that BizTalk documentation is not installed on the computer where you are trying to launch BizTalk help. Ensure that you have documentation installed and retry launching help. If you go kill the process, dexplore.exe, behind the scenes when the help is on display, then closing help and re-launching help from TPE will lead you to this error. Simply restart TPE and re-launch help.

Failed to load the WSDL for {0}.

Failed to load the current WSDL. Refer to HELP for information on possible causes and how to correct this issue.

The keyword here is WSDL. It seems that you are trying to track something from HTTP/SOAP ports or request-response ports associated with a web service. It is possible that while you were creating the tracking profile, the service was running fine. When time came to apply the tracking profile, the service became unavailable, for whatever reasons. Please ensure that the scenario that you are working with is still working. Check your web service URLs, etc.

Failed to save {0}.

Are you running out of disk space? Are you saving over a UNC path and your remote server is experiencing difficulties?

Failed to open {0}.

The tracking profile file either does not exist or you do not have security permissions to read the file.

This tracking profile does not contain some actions to which milestones or data items are mapped or contains invalid or missing port mappings.

There is a data item that you track from ports but you have not specified any ports to track this data item from. Go through all your mappings and see that there is a port specified for all mappings that track data from ports.

There is no active tracking profile for this activity definition. Would you like to import this activity definition instead?

As the warning message amply states, there is no tracking profile applied for the activity definition you are trying to import. This is just a warning message and you can choose to ignore it and go ahead and create a fresh tracking profile for this activity definition. If this message comes up as a surprise, then you probably forgot to apply the tracking profile last time when you worked with the tracking profile. Remember, creating a tracking profile and applying it are two different tasks. First one is necessary but does not imply the second.

In a multi-box scenario where there are two BizTalk Groups with two BizTalk Management Databases BUT with only one Primary Import Table database, this message may pop up. Say, on box one, you create and apply a tracking profile. Now, sitting on box one, you point TPE to the second management database (via set management dialog box). Next, you try to import the tracking profile for your activity definition. The second management database has no information on the tracking profile and TPE will tell you so. Of course, if you now create and apply a fresh tracking profile for the same activity definition, it will overwrite the first one. Tracking profile information is stored in the Primary Import Table database.

There are no ports associated with {0}.

TPE will talk about ports if the tracking profile tracks something from ports. This could be in the form of message payload in pipelines or messaging properties. Either way, TPE needs to know the port on which to track these payload data or properties. The name of the payload is mentioned in the error. Locate that node in the BAM activity definition view [the LHS view] of TPE and right click on it. Choose "Set Port Mappings" menu option and select the port from which you want the data to be tracked. Click OK on the "Select Ports" dialog box and save the tracking profile. The error will go away and you will be able to apply the tracking profile successfully.

The selected help topic is not available. This message typically appears when a custom installation of the product was performed and the documentation was not installed. To install the documentation, on the Start menu, click Control Panel, double-click Add or Remove Programs, and then click the Change/Remove button for the Microsoft BizTalk 2006 program in order to review and update the list of installed components.

This error message comes up as additional information to the error message, "Failed to launch help." This error message is the ideal error message. It tells you what the problem is and how to remedy the same.

The ContinuationID {0} does not have a matching Continuation. The activity will not complete if there is no corresponding Continuation defined elsewhere.

The Continuation {0} does not have a matching ContinuationID. The activity will not complete if there is no corresponding ContinuationID defined elsewhere.

This is a warning message only. TPE will not prevent you from applying the tracking profile. You have to ensure that the matching Continuation or ContinuationID is supplied via BAM APIs in your code somewhere.

The tracking profile for Activity Definition {0} is not applied.

This error will come up if you try to remove a tracking profile that has not been applied.

The Tracking Profile Editor cannot start the activity from the location from which you have selected the ActivityID or ContinuationID because of scope constraints. Please check your tracking profile.

Are you tracking data from an invalid shape? Invalid shapes being those that can't be mapped/tracked. They are group, message assignment, loop, suspend, terminate, throw exception, transform. OR you might be tring to map a shape from an orchestration that contains such a shape. For example, you might be trying to track from a loop shape and from a shape outside the loop shape. You might be trying to map something from one branch of a parallel shape to ActivityID and the parallel shape happens to be the first/last shape in the orchestration. This error will pop up in all these situations and many more.

This essentially means that TPE has found your mappings/orchestrations to be so convoluted that it can't figure out the Begin/End of the activity. There are multiple solutions, none of them particularly pretty. Rewriting orchestrations is one. Writing custom code in orchestrations using BAM APIs is another.

Example:

Orchestration1

Receive Shape

ShapeA

ShapeB

TaskShape

Mapping

Message Payload data from Receive Shape is mapped to ContinuationID

ShapeA, ShapeB mapped to activity milestones

A shape within TaskShape mapped to milestone

Now, the task shape can't be tracked and occurs at the end of the orchestration. This is well known and documented that you can't track from this orchestration using TPE. Alternative is to use BAM APIs. Another alternative is to split up the origional orchestration into multiple orchestrations, one calling the next. For the current example the two orchestrations will look like this:

Orchestration1

Receive Shape

ShapeA

ShapeB

Call orchestration2

Orchestration2

TaskShape

Now you can map your activity items to the two orchestrations as usual. On another note, you may still run into this error even if you have only valid shapes in the orchestration. In such a case, one way to "fix" this error is to map to the ActivityID/continuationID from a shape as far up in the orchestration as possible.

The "{0}" database is not a valid BizTalk Management Database.

This is straightforward. As the error says, the database selected on the set management database dialog box is not a valid BizTalk management database. Select the correct database and you should be good to go.

This error can also come up in a distributed environment where the server with the management database is no longer reachable.

There is no activity in the database {0} that matches the activity {1} in the tracking profile.

The {0} schema cannot be found in the BizTalk Management Database.

The {0} assembly cannot be found in the BizTalk Management Database.

The tracking profile and the BTS solution are out of sync. Either your solution has changed or the tracking profile has changed. In either case, rebuild the tracking profile and re apply.

{0} contains invalid character(s).

Tracking profile folder names must derive from a valid character set. The invalid characters are, apostrophy, open parentheses, close parenthesis, colon, comma and quote. Be extra careful of the characters if you are working on a non en-us language platform.

{0} is not a unique name.

The names of relationship and document reference URL folders must have unique names.

{0} is not a valid tracking profile.

The specified tracking profile is not valid.

The tracking profile has failed the schema check. Are you sure you are dealing with a valid, properly formed, xml looking tracking profile? Open the tracking profile in notepad or TPE and see that it looks like a tracking profile. It should be a valid XML file at least.

Tracking profiles are utf-16 encoded. This is to support unicode characters. Some text editors may save the file as ANSI or utf-8 and then you are likely to run into the above error. So, edit tracking profiles using TPE only. If TPE can open and display a tracking profile, then it is a correct tracking profile. If not, either the xml validation or the character encoding has screwed the tracking profile up.

{0} is too long for a Continuation or ContinuationId. Continuation or ContinuationId names cannot be longer than {1} characters.

{0} is too long for a Relationship. Relationship names cannot be longer than {1} characters.

{0} is too long. Names cannot be longer than {1} characters.

Continuation, ContinuationID, relationship and document reference URL folders may become column names in temporary tables. Or, they may appear as temporary data in some temporary tables. It is necessary that TPE abides by the length limitations imposed on column names, data lengths, etc., by SQL server. Ensure that the names are well below the limits imposed by TPE.

Tracking profiles can only have exactly one Trace ID dimension.

There should be exactly one "ActivityID" folder node. Your tracking profile is either missing one or has more than one. Tracking profiles created via TPE will not face this problem. Is this a hand crafted tracking profile? Hand crafted tracking profiles are not supported. Compare your hand crafted tracking profile with the one created by TPE and ensure that there is exactly one ActivityID node.

Error message in the TDDS_FailedTrackingData table: TDDS failed to deserialize streams. The annotation information for version xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx, track point 0 cannot be loaded from the database due to a database error.

This error may crop up in many situations. One such situation is when correct permissions are not setup in the database (something that should never happen in the first place if BAM configuration completed successfully). In SQL enterprise manager, go to bam primary import table > stored procedures > bam_metadata_getannotation > right click > select properties > select permissions tab on left frame > add execute permission to BAM_EVENT_WRITER role > click ok

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.

Posted Thursday, February 23, 2006 3:43 PM by Vikas | 2 Comments

The corner store

This Blog

Syndication

Search

Tags

Bam Best Practices

TPE case files

TPE and multiple continuations

Tracking interchange versus tracking interchange messages

Tracking Profile Editor: Use Case

BAM Acronyms

Considerations when working with Tracking Profile Editor

Tracking Profile Editor Error Messages