通过

Means to BAM-Tracked “BAMified” Business Process Data:

  • 项目

Means to BAM-Tracked “BAMified” Business Process Data:

There are several means to enable business process data to be tracked in BAM. In Voyager (BizTalk 2004), programmatically there are the DirectEventStream and BufferedEventStream classes, and non-programmatically there is the Tracking Profile Editor (TPE) drag-and-drop mapping mechanism.

 

In Pathfinder (BizTalk 2006), both of these areas are further enhanced.  In brief, programmatically, there are the addition of MessagingEventStream and OrchestrationEventStream which are EventStreams that provide transaction consistent processing in the context of Biztalk pipelines and orchestrations respectively.

 

In the drag-and-drop TPE, in additional to the tracking from orchestrations, tracking can now be done from pipelines as well.

 

TPE, a shift from orchestration to activity centric view:

There is a fundamental shift in tracking profile view; what used to be an orchestration centric view has now changed to an activity centric view.  Data that you want to be tracked thru TPE for a single activity definition must be mapped in a single tracking profile.   For example, if you have a continuation scenario from one orchestration to orchestration, or a pipeline to an orchestration to a pipeline, all of the information must be presented in one single tracking profile.   In other words, one tracked activity must have only one tracking profile (*.btt) file.

 

So, what are these Continuation and ContinuationID folders?

A continuation folder is needed for every TPE-enabled tracking that is a source* segment of a continuation.  (Note: I am saying a source and not a main segment since in a multi- continuation scenario, there would be more than one source segments but only one main segment.)

On the other hand, a continuationID folder is needed for every TPE-enabled segment is continued to or the target.

 

Example:

For a simple scenario where you would continue from Orhestration1 to Orchestration2,  employing the non-programmatic mechanism via TPE drag-and-drop, you would need to create a pair of Continuation and ContinuationID folder.  The name of the folder must be the same, a good naming convention would be to go according to what it does such as “Cont_Orch1_2_Orch2”.  You would then need map the content of each of this folder with a schema item from each orchestration that would contain the same data as it passes from one orchestration to another.   Typically, this piece of data is from the message pay load schema.  This data must be unique from one instance message to another to avoid data from one activity instance polluting another.

 

You must be curious as to why, such a lengthy explanation.   This is because there are cases where you would not need Continuation and ContinationID folder in a pair.  In cases where you want have a mixed of TPE and non-TPE (DES/BES/MES/OES), you would then need to know exactly when to use Continuation and when to use ContinuationID folders.

 

Explain it in another way, if you have TPE continues to non-TPE segment, you would need a Continuation folder, and if you have non-TPE continues to TPE segment, you would need a ContinuationID folder.

 

Now when you do this, what would be the TokenID?   To be continue…

Comments

  • Anonymous
    February 01, 2006
    When is this story going to be continued?
  • Anonymous
    February 08, 2006
    Continues in this link: http://blogs.msdn.com/keithlim/archive/2006/02/08/527227.aspx

  • Anonymous
    May 23, 2006
    in the 3rd to the last paragraph, you used "Orchestration and when to use OchestrationID folders" but I assume you mean "Continuation and ContinuationId" folders
  • Anonymous
    May 23, 2006
    Thanks for pointing out the typo, I have fixed it.
  • Anonymous
    June 28, 2007
    Many of you guys are eagerly anticipating the release of the Microsoft BizTalk Server 2006 R2… and the