[rules-dev] Debugging, Tracing and Visualization of rule execution

[Daniel Gebler]

For our integration of Drools 5.0 we want to provide end users with limited
technical skills the possibility to debug, trace and visualize the rule
execution as well as the fact base.

 

Questions that are frequently asked by users as well as by the
development/qa team:

-          Did my rule r1 fire for this query?

-          Why did rule r1 not fire (i.e. which constraint doesn't match)?

-          Which kind of rule dependencies (chaining) do I have in my rule
base? Rule r1 and r2 are dependent iff action of r1 (e.g. publish a fact)
makes constraint of r2 true.

-          Which rules need to fire in order to generate the additional fact
f1 in the fact base?

-          What is the smallest change in the fact base (additional facts
etc.) in order to make rule r1 to fire (abduction)?

 

Problems:

-          Eclipse plugin doesn't provide information of what didn't happen
and why it didn't happen ( 'Audit' view allows just tracking of positive
cases, i.e. what happened). Furthermore the stability of the eclipse plugin
seems to be limited.

-          Integrating over SPI doesn't allow to show the Rete network
because Rete view works only with drl files

-          How to provide feedback to a normal end user of the search server
(limited tech skills) about rule-related information?

 

Solution ideas/approaches + our assessment:

1.       Use a run time monitor providing on-demand log trace information
when facts are being published.  The log trace provides the information
about which and why a particular constraint is or is not satisfied. Our
initial implementation uses an aspect oriented approach (JBoss AOP) to
gather relevant information. In detail: Our initial implementation uses an
aspect oriented approach (JBoss AOP) to gather the information by
intercepting EntryPointNode.assertObject(), and traversing the rete network
to collect the constraint information for every unique alpha/join node. This
will allow to visualize the log trace (GUI) and interpret the trace in the
context of our product. We discussed this approached in #drools with Edson
Tirelli and he was very interested.

2.       Use drools AgendaEventListener. Listener does not gets enough debug
info exposed, esp. we cannot extract the cause to reject a rule. Not enough
information available therefore this one is not an option.

 

Additionally, it would be nice for our development to also visualize the
Rete-OO network, but that seems to be impossible when integrating drools
directly via the SPI classes. Is there a way to connect the viewer to a
network inside a running VM?

 

We would like to hear whether you know any other opinions, or have points
how to implement those features. Please share your experience how to bridge
the gap between end-users with limited technical backgrounds expressing and
investigating the rule inference.

 

Thanks,

Daniel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20090616/2b8da0a8/attachment.html