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

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 ------------------------------------------------------------------------ _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev