It's been quiet over the Christmas period and we haven't shown you too much about the cool stuff we are doing. Never fret this blog will more than make up for it :) Kris Verlaenen has been working his magic again and we now have graphical debug tool for Drools processes, which will be part of the Drools 5.0 release at the end of Q1.

The processes

Our RuleBase contains 2 processes and some rules (used inside the ruleflow groups):

• The main process contains some of the most common nodes: a start and end node (obviously), two ruleflow groups, an action (that simply prints a string to the default output), a milestone (a wait state that is trigger when a specific Event is inserted in the working memory) and a subprocess.

• The SubProcess simply contains a milestone that also waits for (another) specific Event in the working memory.

• There are only two rules (one for each ruleflow group) that simply print out either a hello world or goodbye world to default output.

I will simulate the execution of this process by starting the process, firing all rules (resulting in the executing of the hello rule), then adding the specific milestone events for both the milestones (in the main process and in the subprocess) and finally by firing all rules again (resulting in the executing of the goodbye rule). The console will look something like this:
Hello World
Executing action
Goodbye cruel world

Debugging the process

I added four breakpoints during the execution of the process (in the order in which they will be encountered):

• At the start of the consequence of the hello rule

• Before inserting the triggering event for the milestone in the main process

• Before inserting the triggering event for the milestone in the subprocess

• At the start of the consequence of the goodbye rule

When debugging the application, one can use the following debug views to track the execution of the process:

• The working memory view, showing the contents (data) in the working memory.

• The agenda view, showing all activations in the agenda.

• The global data view, showing the globals.

• The default Java Debug views, showing the current line and the value of the known variables, and this both for normal Java code as for rules.

• NEW! The process instances view, showing all running processes (and their state).

• The audit view, showing the audit log.

Figure: The process instances view, showing that there is currently one running process (instance), currently executing one node (instance), i.e. RuleSet node.

When double-clicking a process instance, the process instance viewer will graphically show the progress of the process instance. At each of the breakpoints, this will look like:

• At the start of the consequence of the hello rule, only the hello ruleflow group is active, waiting on the execution of the hello rule:

• Once that rule has been executed, the action, the milestone and the subprocess will be triggered. The action will be executed immediately, triggering the join (which will simply wait until all incomming connections have been triggered). The subprocess will wait at the milestone. So, before inserting the triggering event for the milestone in the main process, there now are two process instances, looking like this:

  

• When triggering the event for the milestone in the main process, this will also trigger the join (which will simply wait until all incomming connections have been triggered). So at that point (before inserting the triggering event for the milestone in the subprocess), the processes will look like this:

  

   

• When triggering the event for the milestone in the subprocess, this process instance will be completed and this will also trigger the join, which will then continue and trigger the goodbye ruleflow group, as all its incomming connections have been triggered. Firing all the rules will trigger the breakpoint in the goodbye rule. At that point, the situation looks like this:

  

   

After executing the goodbye rule, the main process will also be completed and the execution will have reached the end.

For those who want to look at the result in the audit view, this will look something like this [Note: the object insertion events might seem a little out of place, which is caused by the fact that they are only logged after (and never before) they are inserted, making it difficult to exactly pinpoint their location