Implementing Tracing with Rules for .NET
By Chris Berg, ILOG.
The RES.NET team has done some great work with managed execution using WCF. While WCF offers most of the things we need for management (PerfMon, Service Layer, etc) it provides no visibility into the execution context of the engine itself which offers a rich set of events.
As a solution, the RES.NET team has created a contribution (with source code) that makes it easy to trace the execution of Rulesets for both the stand-alone engine and RES.NET. Let’s take a look.
The first step is to integrate the Trace utility as a member of the BOM. Register the dll as a reference for your rule project. Next, establish the “Contrib.ExecutionServer.DebugTracer” object as a parameter for the Ruleset itself:
Once this done, you will see that it’s now a member of the BOM in our rule project. Notice that it has both a “Begin” and “End” method:
These methods can be verbalized if you like or you can use them as is. Mine are verbalized. The trace utility is designed to work with your ruleflow. You call the “Begin” and “End” methods before and after a specific set of tasks in your ruleflow. For example, here is a simple ruleflow where I have created a wrapper of an existing ruleflow that activates the trace:
The flow task calls my existing or production ruleflow and then I add “initial” and “final” actions to the task itself. This is what my initial action looks like:
This action activates the trace by passing in the instance of the engine and allows the events to fire and be monitored by the utility. By using a flow task, I am preserving both my rules and production ruleflows. The “Trace Wrapper” is called only when I am interested in debugging my ruleset.
Here is a sample output from the trace to a command window but you can also drop this to a file and view it from within XML Spy:
By now you might be asking yourself how this all works and how can this be extended if it’s missing a feature. Let’s take a closer look.
There are only two key integration points with the utility if you focus on the DebugTracer object:
public void Begin(RuleEngine engine) {…}
public void End(RuleEngine engine) {…}
I won’t walk you through the code but if you look at it you will find familiar features for logging and good coverage of the engine’s event model. What may not be apparent is that while the methods above require an instance of the rule engine, you may remember that the BOM showed these methods as “void”:
The trick is in the use of an extender. When the BOM is extended with the wizard, it generates a new artifact that extends the BOM. If you open it up you will notice that the signature for the new method passes in the engine as required parameter. The RES.NET team provided a pre-built extender for the utility. When the BOM is loaded it picks up the extender and shows the methods as void even though the engine is passed behind the scenes. Moreover, because the extender uses the same name as the methods of the DebugTracer “begin” and “end” the methods override the methods provided by the extender.
using ILOG.Rules;
using ILOG.Rules.BusinessObjectModel;
namespace Contrib.ExecutionServer
{
[ExtendType(typeof (DebugTracer))]
public class DebugTracerExtender
{
[Method(UseRuleContext = true)]
public static void Begin(RuleEngine engine, RuleInstance instance, DebugTracer eventTracer)
{
if (eventTracer != null) eventTracer.Begin(engine);
}
[Method(UseRuleContext = true)]
public static void End(RuleEngine engine, RuleInstance instance, DebugTracer eventTracer)
{
if (eventTracer != null) eventTracer.End(engine);
}
}
}
In turn, the wrapper methods pickup the engine instance and pass it into the underlying methods of the DebugTracer object.
In all, it’s a handy piece of work and the code can be easily modified to support many different requirements. The trace utility cannot be downloaded just yet but you can ask your TAM for a copy. Post your questions about the utility to the Rule Execution Server for .NET forum: http://forums.ilog.com/brms/index.php?board=32.0 .
Have fun.
CCB =)
