Yet another Biztalk DebugTrackingInterceptor

Probably everyone working with Biztalk Rules Engine runs very soon into limitations of the provided rules execution tracing solution.

Few blog entries (http://martijnh.blogspot.com/2006/04/microsoft-business-rules-engine-ms-bre.html, http://wworkflow.net/blogs/_dispatches_/archive/2007/01/10/52.aspx) do provide some guidance for better solution mostly focusing on providing the output as an xml.

Provided here solution takes same xml based approach, although it tries to integrate more with standard .NET 2.0 logging pipeline in particular providing xml format compatible with WCF trace, so you can see your WCF and BRE events using the same viewer tool.

Attempt is also made to present data in a more usable for analysis and troubleshooting form.

That much of the ado, lets see the code.

First usability feature starts with a constructor, extra one is added to pass in the Action<string> to execute at the end of the every tracing method:

public XmlDebugTrackingInterceptor(Action<string> outputTracker) : this()

Possible usage would be chaining the output into the console:

using (XmlDebugTrackingInterceptor dti = new XmlDebugTrackingInterceptor(

                (s) => { Console.WriteLine(s);  }))

Or breaking into the debugger:

            using (XmlDebugTrackingInterceptor dti = new XmlDebugTrackingInterceptor(

                (s) => { Console.WriteLine(s); if (Debugger.IsAttached) { Debugger.Break(); } else { Debugger.Launch(); } }))

Moving from the constructor to the tracking methods we can see that first xml for the passed in parameters is combined:

using (XmlWriter xWriter = XmlWriter.Create(builder,

                    new XmlWriterSettings { OmitXmlDeclaration = true, ConformanceLevel = ConformanceLevel.Fragment }))

            {

                // Append a common with wcf trace record header

                AppendTraceHeader(xWriter);

                AppendContextHeader(m_agendaUpdateTrace, xWriter);

                // Write the trace description element

                xWriter.WriteElementString("Description", "Agenda Update");

At the end, it just uses standard .NET TraceSource to pipe the data in:

XPathNavigator navigator = new XPathDocument(new StringReader(builder.ToString())).CreateNavigator();

            // log

            source.TraceData(TraceEventType.Verbose, 0, navigator);

What does it give us?

We can use all the standard .NET system.diagnostics configuration and we can make our events to play well with other players using same logging infrastructure, which includes WCF (System.ServiceModel), System.Net, etc.

You can see the representation of events in the WCF Service Trace Viewer:

In addition to the WCF trace compatible format, the exhibit shows how focus is made on the instance ids of the facts asserted or during the condition evaluation. Instance ids are shown in both description and details to make troubleshooting of iteration and same type facts evaluation easier.

The code is still under development and still have to gain more of a test coverage, current version is available for grab and go here:

http://code.google.com/p/toolsdotnet/source/browse/trunk/Tools.Net/src/Tools.Logging.Biztalk/XmlDebugTracingInterceptor.cs