DZone
Java Zone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
  • Refcardz
  • Trend Reports
  • Webinars
  • Zones
  • |
    • Agile
    • AI
    • Big Data
    • Cloud
    • Database
    • DevOps
    • Integration
    • IoT
    • Java
    • Microservices
    • Open Source
    • Performance
    • Security
    • Web Dev
DZone > Java Zone > Debugging Processes in JBoss Drools 5.0

Debugging Processes in JBoss Drools 5.0

Mark NA user avatar by
Mark NA
·
May. 23, 08 · Java Zone · Interview
Like (0)
Save
Tweet
13.42K Views

Join the DZone community and get the full member experience.

Join For Free

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


Drools Milestone (project management) Event JBoss

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • GraphQL: A Deep Dive Into Benefits, Use Cases, and Strategies
  • Top 10 Criteria to Select the Best Angular Development Company
  • How to Use Geofences for Precise Audience Messaging
  • How Data and Analysis Can Power Agile Teams

Comments

Java Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • MVB Program
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends:

DZone.com is powered by 

AnswerHub logo