BizTalk: Architectural Tips: Custom Message Audit

The message audit can be implemented by BizTalk Tracking (BizTalkDTADb) database.
But there is one big "But". This database has predefined, undescribed structure, it should be used only by special BizTalk tools as HAT. We cannot change the audit points, cannot freely create user queries, cannot change structure of this database.
 
It is not so hard to create the custom audit, it is the standard practice to make the custom audit database and gather data for it from the BizTalk application with additions for the Orchestrations.
 
It is good practice to use some standard for the audit architecture. Here I give you two of them.
They are pretty easy and repeat the "Generic Error handling" pattern. They use the Direct port subscription.
  
I. One audit send port, the audit messages are created in different ways. All audit messages have the same message type. The Audit send port is subscribed to the one audit message type.
II. One audit send port with set of the maps, the audit messages are created by these maps.The Audit send port group is subscribed to the all audited message type.
 
We create the standard audit message type; send all audit messages in all audit points to the Direct send port shape; create the Direct send port with subscription to this audited message type. That is all.
[The audit points are the all audited milestones as receiving/sending the message; transforming the message; routing the message , etc.]
 
ToDo list:
  1. Create the generic_audit schema. It can, for example, include elements: "Operation datetime", "Operation type"(Send/Receive/...), "Original message parameter (like File Name)", "Success/Fail status", "My_Specific_parameter" etc.
  2. Create simple maps to produce the generic_audit schema from all other messages. It is not necessarily all audit parameters be mapped from the source message. Some of them might be produced inside map or expressions, for example, the "Operation datetime" parameter.
  3. Create the Audit Send Direct port with these maps in the entry. Make filters for all audited message types, i.e. subscribe to all these message types.
  4. If we want to save the audited messages in the database: Create the Audit database. The simplest database might be with one table and one stored procedure to fill-in this table.
 FYI You can see in MSDN forum (http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2452186&SiteID=1) a comment of Kent Weare [BizTalk MVP] about using BAM for auditing:

"...On at least a couple of occasions I have heard MS employees endorse BAM for auditing.  We brought a Microsoft consultant to review our architecture and design with respect to auditing.  He suggested we use BAM for this purpose.  Note he did not endorse message body tracking inside of BAM.  The other place that I have seen it endorsed is at TechEd at one of Darren Jefford's sessions.  
Without a doubt building up the required BAM infrastructure is not a trivial task(especially in an enterprise scenario).  Keeping things simple is often the best solution, so I do think that you have brought up some valid points. ..."

One more discussion about using HAT for tracking messages is here (http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1991237&SiteID=1).

Print | posted on Tuesday, April 29, 2008 8:14 PM

Feedback

# re: BizTalk: Architectural Tips: Custom Message Audit

left by Leonid Ganeline at 6/4/2010 2:01 PM Gravatar
BAM is a good tool. The problem with it is BAM creates a lot of infrastructure and a lot of deployment artifacts. Moreover it is OLAP system and BizTalk MessageBox is an OLTP system with opposite requirements to the SQL processing. Microsoft has done a good job to marriage both systems but take in mind the BAM overhead.
Post A Comment
Title:
Name:
Email:
Comment:
Verification: