| Samples > Rule-Based Programming > How to Monitor Ruleset Execution |
How to Monitor Ruleset Execution |
PREVIOUS NEXT |
This sample shows how to configure the rule engine for tracing and logging. In particular, the sample provides a graphical tree-based trace for rule engine execution that can be used by other samples and projects.
Key features include:
IlrTool, IlrToolFactory, and IlrLocalTracerToolFactory API and connection mechanisms
IlrLocalTracerToolFactory subclassing for a customized trace
IlrToolAdapter for another customized trace
To import the monitoring sample:
samples > engine > monitoring sample.
If one or more files already exist in your workspace, a warning message is displayed indicating that the corresponding file(s) were not re-imported.
The imported sample project files are displayed in the Rule Explorer.
Make sure you are in the Rule perspective before running this sample.
To run the sample:
Java Application With Rules > monitoring-application launch configuration.
specificlog.txt) is generated with the customized tracer connected to a logger.
TreeTool, a graphical tree-based trace for rule engine execution.
The Java application project monitoring-application runs a ruleset from a Java application. A main method parses a ruleset, connects tracing tools to the engine, and then executes the rules.
The resource project financialevent-xom is imported automatically into the workspace and contains the classes used by the rules.
The Main class contains the main method. It reads an IlrRuleset ruleset and creates the IlrContext engine. Then it creates four IlrTool implementations:
IlrLocalTracerToolFactory which provides the default trace. It logs information in a file with a FileWriter.
TracerToolFactory, a derived class of IlrLocalTracerToolFactory. It logs information with a Logger.
IlrToolAdapter which overrides only four notify methods. It logs information in a StringWriter which is printed on the console at the end of the program.
TreeTool. It defines an Event inner class to model the high level events occurring in the rule engine and a specific EventRenderer class to display these events as tree nodes, with specific icons, tool tips, and a "dual selection" mechanism.
When the tool is connected to a rule engine, it records ruleflow events, working memory events, RetePlus agenda events, and rule execution events. The records are stored in a tree model. When the tool is disconnected from the engine, it pops a window displaying a tree of events, similar to the example shown below:
Each node displays an event, with its type, and complementary information such as the target object or the target rule and the matching objects. Each node has a tool tip showing more information, such as priority or counterpart.
Blue squares denote execution events (engine integration, ruleflow task start, rule instance execution).
Balls denote working memory events (insert, update, retract objects in working memory).
Triangles denote RetePlus agenda events (schedule and remove rule instances in the agenda).
Green color denotes "addition" events (insert object in working memory and schedule rule instance in the agenda).
Orange color denotes "modification" events (update object in working memory).
Red color denotes "removal" events (retract object in working memory and remove the rule instance).
The tree shows, from top to bottom, the chronological order of event executions. For example, in the previous screen shot, the main (ilrmain function or Java code integration) inserts four objects, then starts executing rules.
This allows you to understand the execution step by step.
The tree shows the event "execution dependency" using the parent-child relations. For example, in the previous screen shot, the insertion of the first object in the working memory causes the scheduling of a rule instance in the RetePlus agenda. The execution of the rule ProcessDepositEvent on the matching object DEPOSIT Event #ID1 inserts a new object CREDIT Event #ID5 in the working memory; this insertion causes the scheduling of three new rule instances in the RetePlus agenda.
This allows you to understand the execution process of the ruleflow, the sequential algorithm, and the inference process of the RetePlus algorithm.
The tree shows you the counterpart of a rule event and where it occurs. The counterpart of the schedule event of a rule is either its execution event or its removal event, and vice versa. Selecting one of these nodes also selects its counterpart. The selected node in green is the cause event (the schedule event), and the node selected in the default selection color is the result event (execution or removal). For example, in the previous screen shot, the scheduled rule UnprocessedEvent on the matching object DEPOSIT Event #ID1 is removed from the agenda when this object is updated by the ProcessCascade rule applied on it.
This mechanism allows you to understand why a rule that was initially scheduled was not executed, or why a rule that has been executed was rescheduled.
| Copyright © 1987-2008 ILOG S.A. All rights reserved. Legal terms. Documentation homepage. | PREVIOUS NEXT |