Project Description

The main target is to integrate BAM tracking and allow the business analysts to track and link the entire progress of the transaction as it goes through many parts of the ESB solution. As we all know in any ESB solution you would come to a scenario where the message actually passes through and hits multiple systems and hence to be able to track the progress of this specific business transaction you would need to track from multiple sources including the following:
  1. ESB itinerary steps and not just the start and end of the itinerary itself.
  2. BizTalk orchestrations and shapes within the orchestrations.

Design Guidelines

The design objectives and assumptions used while crafting this design of the solution are:
  1. The proposed solution should have the minimal changes requirements on the ESB itineraries, or orchestrations already implemented.
  2. The proposed solution should have minimal performance delays on the currently running solution.
  3. The proposed solution should be dynamic enough to allow changes after the solution is deployed.
  4. The proposed solution should be linked and integrated with the BizTalk BAM infrastructure.
  5. The proposed solution should provide the functionality of tracking the body of the messages especially as they arrive.
  6. The proposed solution should be integrated within the ESB management portal.

Solution Architecture

The solution is based on a custom ESB itinerary manager implemented to integrate the BAM tracking functionality within the lifecycle of the request as it traverses the itineraries. Also custom orchestration events interceptor is used to keep track of events happening inside any custom orchestrations. This is needed if these orchestrations are not actually linked to any ESB itinerary and not tracking the message lifecycle through any itinerary. The solution architecture is highlighted as per the below diagram.
Overview.png

Solution Components

Custom Itinerary Manager

The solution core component is the development of a custom ESB itinerary manager to handle and intercept the advance itinerary event. This event happens every time the itinerary pipeline or executer (including any custom orchestration) is moving to the next step in the itinerary. By intercepting these events the BAM tracking calls can be tied up to the event of finishing that step. The target as detailed in the design guidelines section is to have minimal effect on the solution deployed itineraries. The below diagram shows for an example itinerary the call locations that would be intercepted by the itinerary manager.
itinman.png
As you see also the method “GetItineraryStep” is overridden as this will be needed to initialize the activity ID and add it to the itinerary properties header.

Orchestration Interceptor

This is needed to track events as they happen in any custom orchestrations. This is needed if these orchestrations are not linked to any ESB itinerary. The orchestration interceptor is an implementation that handles all fired orchestration events. These would include the start and end of an orchestration or the start and end of each shape within this orchestration.

ESB Tracking Profiles Database

The main purpose of this database is to hold the dynamic configuration of the mapping between the service names in the itinerary and the BAM activity milestones and business data names. This is to fulfill the requirement of having dynamic configuration for the linking between those. This database should have the following schema.
db.png
EsbTrackingActions Table
This table actually is just a constants table to hold the specific actions to be performed as the specific itinerary step. It has the following values.
Value Name Description
1 Start This action means that we should start the BAM activity at this itinerary step advance event. This would include getting the event time from the “AdapterReceiveCompleteTime” context property rather than the provided timestamp.
2 Update This action means that we should simply update the activity milestone and business data with the specified details and using the timestamp provided.
3 ChangeId This is similar to the update event but it also means that the message tracking Id is changing so we need to enable continuation on the activity, end this activity, and start a new one with the new Id. This will also update the itinerary header property for the activity ID to match that. The only supported change on Id is from the generic itinerary Id to the business Id.
4 End This action means that we should end the BAM activity.
5 Init This is the initialize step. This is required for each itinerary just once and you add the itinerary service name as “” and the associated milestone also as “”. This step is essential to initialize the itinerary header and add the activity tracking ID to the itinerary properties to be used later. For orchestrations this has to be linked to the message construction shape that would be constructing the message to have the activity ID - message id in our case. In that case the service name has to be equal to the construction shape name.
6 EndIfEmpty This is a special state used inside the orchestration interceptor to detect if the last executed if condition had a branch with no sending of messages within it then this means we should end the current activity. This is mainly used from custom orchestrations when we do not need a finalize stage after this orchestration and it completes executing this instance.

EsbTrackingProfiles Table
This is the core mapping table between the itinerary steps and the associated activity milestones.
Column Description
ID The identity primary key.
ItineraryName This is the itinerary name this and the ServiceName should be unique on the table level.

Or if this is a link profile to an orchestration then this would be the orchestration type name without the namespace. |
ServiceName This is the itinerary service business name set from the designer. We have a unique complex constrains on the ItineraryName and ServiceName or for initialize actions that would be “_”. Or if we are tracking from an orchestration then this is the orchestration shape name. (please note that for consistence the tracking of the event would only take the end shape event and not the start event)
ActivityName This is the BAM activity name to be updated.
MilestoneName This is the business milestone name within the activity. Or for initialize actions that would be added as “_”.
Action This is the required action to happen at this itinerary step advance event.
MsgIdXPath This is the XPATH statement to extract the activity Id to use from the sent message. This field is needed only for the initialize and the change ID action types and will not be used for the remaining actions.

EsbTrackingData Table
This table contains the mapping between the itinerary service advance event and the associated business data to be extracted at that step.
Column Description
ID The identity primary key.
ServiceMilestoneId This is a foreign key to the EsbTrackingProfiles table on the associated itinerary service name.
DataName This is the business data name in the BAM activity definition.
DataExtractionXPath This is the XPATH statement to extract the data from the message. If this value is equal to “BODY” this means that this is the entire message body to be tracked and in this case it will actually add a reference to the activity rather than adding a business data name within the BAM activity. If at the first itinerary service we add body tracking then this will be tracking the message body out of the initialize step not the advance step to make sure we are tracking the initial message coming on the wire.

ESBTrackingOrchestrationData Table
This table contains the mapping between the orchestration shapes end events and the associated business data to be extracted at that step. Also note that these are not linked to any milestone to allow them to be changeable without the need to change the BAM activity design.
Column Description
ID The identity primary key.
OrchestrationName This is the orchestration type name without the namespace this and the ShapeName should be unique on the table level.
ShapeName This is the orchestration shape name set from the designer. We have a unique complex constrains on the OrchestrationName and ShapeName.
ActivityName This is the BAM activity name to be updated.
DataName This is the business data name in the BAM activity definition.
DataExtractionXPath This is the XPATH statement to extract the data from the message. If this value is equal to “BODY” this means that this is the entire message body to be tracked and in this case it will actually add a reference to the activity rather than adding a business data name within the BAM activity.





Last edited Jun 10, 2013 at 5:25 AM by mmmalek, version 13