Debugging processes in JBoss Drools 5.0

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.

 <p style="margin-bottom: 0cm;" align="left">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:<br /><span style="color: rgb(0, 0, 0);"><span style="font-family:Courier New,monospace;"><span style="font-size:85%;">    Hello World<br />Executing action<br />Goodbye cruel world</span></span></span></p> <p style="margin-bottom: 0cm;" align="left"></p><p style="margin-bottom: 0cm; page-break-before: always;" align="left"><u><b>Debugging the process</b></u></p>  <p style="margin-bottom: 0cm;" align="left">I added four breakpoints during the execution of the process (in the order in which they will be encountered):</p> <ul><li><p style="margin-bottom: 0cm;" align="left">At the start of the  consequence of the hello rule</p>  </li><li><p style="margin-bottom: 0cm;" align="left">Before inserting the  triggering event for the milestone in the main process</p>  </li><li><p style="margin-bottom: 0cm;" align="left">Before inserting the  triggering event for the milestone in the subprocess</p>  </li><li><p style="margin-bottom: 0cm;" align="left">At the start of the  consequence of the goodbye rule</p> </li></ul>  <p style="margin-bottom: 0cm;" align="left">When debugging the application, one can use the following debug views to track the execution of the process:</p> <ul><li><p style="margin-bottom: 0cm;" align="left">The working memory  view, showing the contents (data) in the working memory.</p>  </li><li><p style="margin-bottom: 0cm;" align="left">The agenda view,  showing all activations in the agenda.</p>  </li><li><p style="margin-bottom: 0cm;" align="left">The global data view,  showing the globals.</p>  </li><li><p style="margin-bottom: 0cm;" align="left">The default Java Debug  views, showing the current line and the value of the known  variables, and this both for normal Java code <u>as for rules</u>.</p>  </li><li><p style="margin-bottom: 0cm;" align="left"><span style="color: rgb(255, 0, 0);">NEW!  </span>The process instances view, showing all running processes  (and their state).</p>  </li><li><p style="margin-bottom: 0cm;" align="left">The audit view, showing  the audit log.</p></li></ul><div style="text-align: center;"><img src="https://www.athico.com/blogimages/debuggingprocess/process_debug_html_3a85adef.gif" /></div><p style="margin-bottom: 0cm;" align="left"></p><p style="margin-bottom: 0cm;" align="center"><span style="font-size:100%;"><i>Figure: The process instances view, showing that there is currently one running process (instance), currently executing one node (instance), i.e. RuleSet node.</i></span></p>  <p style="margin-bottom: 0cm;" align="left">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:</p> <ul><li value="1"><p style="margin-bottom: 0cm;" align="left">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:</p></li></ul><div style="text-align: center;"><img src="https://www.athico.com/blogimages/debuggingprocess/process_debug_html_114fa092.gif" /></div><ul><li><p style="margin-bottom: 0cm; page-break-before: always;" align="left">  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:<br /></p><div style="text-align: center;"><img src="https://www.athico.com/blogimages/debuggingprocess/process_debug_html_6fc7e616.gif" /><img src="https://www.athico.com/blogimages/debuggingprocess/process_debug_html_m7dc9e323.gif" /></div></li><li><p style="margin-bottom: 0cm;" align="left">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:<br /></p><div style="text-align: center;"><img src="https://www.athico.com/blogimages/debuggingprocess/process_debug_html_m3ab49a1.gif" /><img src="https://www.athico.com/blogimages/debuggingprocess/process_debug_html_m7dc9e323.gif" /></div><p style="margin-bottom: 0cm;" align="left"></p></li><li><p style="margin-bottom: 0cm; page-break-before: always;" align="left">  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:<br /></p><div style="text-align: center;"><img src="https://www.athico.com/blogimages/debuggingprocess/process_debug_html_m318ba1e2.gif" /></div><p style="margin-bottom: 0cm; page-break-before: always;" align="left"></p> </li></ul>  <p style="margin-bottom: 0cm;" align="left">After executing the goodbye rule, the main process will also be completed and the execution will have reached the end.</p>   <p style="margin-bottom: 0cm; page-break-before: always;" align="left">For those who want to look at the result in the audit view, this will look something like this<span style="font-size:85%;"><i> [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</i></span></p><br /><div style="text-align: center;"><img src="https://www.athico.com/blogimages/debuggingprocess/process_debug_html_46539117.gif" /></div>

Author

Comments are closed.