Working with Drools from a JRules perspective

I had heard a few good things about drools , so I had a play with it over the last few days. I decided to create a small project in JRules 6.7 and keeping the same object model port it to drools 4.07 and see what happens. I specifically wanted to test out porting the following:

• verbalisations
  
• a ruleflow , with a subflow
• business rules (brl rules)
  
• decision tables
• local variables

The projects I created can be downloaded from a link at the bottom of this post.

The rule project

I created a simple JRules project to process a train ticket. Given a journey start point (zone) and a journey destination, the rules would work out the cost of the journey and deduct it from the user's credit on their prepaid card(Oyster card). The price would also be influenced by the type of user (i.e. train staff, student, senior) . I have tried to keep a one-to-one mapping between rules I have created in JRules and rules I created in Drools.

Download the report of the jrules project from here.

The editors

JRules and Drools both provide an editor which is a plugin to eclipse. Actually, using eclipse is the only way to build the rules too. Even if you need to build from the command line , it runs in eclipse headless mode. However in Drools you are not tied to the editor, you can write all you rules in notepad or vi if you want then use the libraries to build them. That said, I would recommend using the eclipse plugin for Drools.

Verbalising the object model

Firstly if you are unclear about what an object model is in relation to rules, read Dan Serner's useful entry on his ILOG blog.

Ok, JRules , creates your object mapping for free, and creates default verbalisations for your object model. This is great so you can start writing rules right away. However some rules can end up with some convoluted verbalisations as you would have verbalised your object model without thinking about how each one will be used in the rules. You will probably have to go through a verbalisation refactoring stage to sort this out.

However in Drools, you need to create a dsl (domain specific language) file which maps expressions and actions to some given text. So you first think of your rule, then think of the verbalisation, then you add the mapping to your dsl file. This can lead to rules with greater readability, but you have to add each verbalisation yourself.

Here's a shot of my dsl file. (btw all the source code can be downloaded from a link at the bottom)

Writing business rules

Ok in Drools you can write rules directly in DRL (equivalent of IRL in JRules) or you can write rules in dslr which use verbalisations (equivalent of BRLs I guess).

Ok the first thing that threw me, was that you can't use an else in a rule. Weird huh? But there is probably a good reason for it. The other thing was, that I found myself getting into an infinite loop in a rule. You need to set the no-loop property on the rule otherwise it will keep evaluating if the when condition is true. Otherwise no other great surprises here.

Decision Tables

In JRules, you create decision tables within the eclipse editor. I have always found the Jrules decision table editor a bit flaky and pretty slow to open an existing decision table.

In Drools, you create decision tables in excel spreadsheets, csv or openoffice spreadsheets. You do not get autocomplete like the JRules editor, and auto static analysis and some other wizzy stuff, but it is very flexible. And given that while I have been working with JRules, I end up importing and exporting everything I do with decision tables to spreadsheets, I found this pretty useful.

Ruleflows

The ruleflow functionality is pretty similar between JRules and Drools. The major exception though is probably that a rule or decision table in Drools points to the rule group(ruleflow task in jrules) it belongs to, rather than in Jrules where a ruleflow task only knows which rules it contains, and a rule can end up in many tasks.

Actually one of our complaints about JRules was that it was difficult to find out which ruleflows a rule is referenced in. But in Drools as it is the other way round, it is a bit of a hassle to search for all the rules that belong to a group, hopefully in a newer release the editor will automatically show all the rules that belong to a group.

Another thing about decision tables in Drools is that individual rows can belong to different rule groups. In JRules the whole table goes in the task.

Local variables

Ok this is where I found the most pain in drools. The equivalent of local variables in drools are global variables. I just couldn't get these damn things to work properly, so I created a local variable class, and a local variable object was passed into the ruleset as a parameter to provide the same functionality. It was also a pain , because I wanted to use a global with a primitive type and drools just didn't like it, and I ended up with some weird errors.

Building and executing

As I mentioned earlier drools is a bit more flexible as you do not need to use eclipse to build your rules in the same way JRules forces you to do. But in drools you need to add each rule or rule package to your ruleset or Rulebase , in your code. In JRules you just build your jar , and you have all your rules neatly packaged up. The code to execute the rules in drools is slightly easier than jrules i would say. Look at the code in com.transport.ticketFeeRules.jrules.RuleEngineRunner and com.transport.OysterCardRules.droolsrulerunner.DroolsRuleRunner , and you will see the difference.

The verdict

I like Drools, but if I was choosing a rules engine at the moment for my project I would stick with JRules. I know Drools is free, but I think it still needs to mature a bit. All the features are there, and it has a web based BRMS too. I have never used JRules Rule Team Server so I didn't compare it to Drools' equivalent.

In a couple of years though I expect Drools to be a real challenger in this space and as it is opensource I expect a lot more expertise to be out there. So if you have been working with JRules I encourage to try out Drools, but don't expect it to be a replacement just as yet. But if you are going throught the decision process now of picking a rules engine, do not discount Drools, it maybe exactly what you need.

Download my comparision projects from here.

Related blogs:

Drools Rules - useful examples on using Drools and benchmarking
ILOG Blogs - the official blog from the company behind JRules
Drools - the blog from the guys who produce Drools

Building from command line in JRules 6.7

In my post last week [2 years of JRules] I had a bit of a moan that JRules didn't have out of the box functionality to build a ruleset from outside of eclipse. Ironically a couple of days after I posted that up I was trying out JRules 6.7 and it appears ILOG have pulled their finger out and provided a way of building a ruleset from outside the eclipse rule studio.

It works by running eclipse in headless mode and providing a script location as one of the command line arguments. The given script is written in javascript and calls the JRules API.

For those of you who just want to dive straight into the code here are the downloads:

rule-builder-script.xml - this is an ant build file to run eclipse in headless mode and invoke the script

RulesBuild.js - this is the script that builds and extracts a ruleset by calling the JRules API.

I won't go through the ant script in detail, but if you are new to ant, have a look at the ant user manual.

The target "BuildSomething" is a dummy target for you to change. Here are the parameters that need to be updated:

projectName - This is the name of the project which contains the main rule flow.
extractorName - Name of extractor to use
archiveFile - path of where to save the ruleset jar
workspace.dir - path to the eclipse workspace which contains your rule projects

The other target "buildAndExtractRuleset" which BuildSomething calls, calls the macrodef task "headless.appication" which actually fires up eclipse in headless mode. The variables in here that need to be updated are:

script.location - path to RulesBuild.js
eclipse.home - the install path to eclipse

Once you update these variables you can just run the task BuildSomething (command line: ant -f rule-builder-script.xml BuildSomething) .

The script will take a bit of time to run depending on the number of rules in your projects, and once you see RulesBuild.js ENDED , your ruleset jar should be in the location of archiveFile.
Now let's look at the script. Firstly get to know the global variables that are accessible in the script:

Global Variable Name	Java Type	Description
workspace	org.eclipse.core.resources.IWorkspace	Provides access to the projects
ruleModel	ilog.rules.studio.model.IlrRuleModel	Provides access to the Rule Studio Model
modelHelper	ilog.rules.studio.javascript.dom.IlrModelHelper	Modifies to Rule Studio rule model
importHelper	ilog.rules.studio.javascript.dom.IlrImportHelper	Imports projects into the workspace
buildHelper	ilog.rules.studio.javascript.dom.IlrBuildHelper	Builds the projects of the workspace
extractorHelper	ilog.rules.studio.javascript.dom.IlrExtractorHelper	Extracts the ruleset archives from the rule projects

The function main() is the entry point to the script. This reads in the arguments , turns off auto-building , calls the build functions, calls the generate archive action and then prints a report of all the projects built.

I'll skip to the function build in ArchiveBuilder (line 166):

First all the projects in the workspace are cleaned and refreshed:

Utilities.println("Begin Clean...");
buildHelper.clean ();
Utilities.println("End Clean...");

Utilities.println("Begin Refresh...");
for each( project in workspace.getRoot().getProjects() ) {
project.refreshLocal(2, null);
}
Utilities.println("End Refresh.");

You could add some code before this to open projects that are closed in the workspace.


Then a full build is called and for each project, a report is generated:

Utilities.println("Begin Full Build...");
buildHelper.fullBuild();
Utilities.println("End Full Build");

for each( project in workspace.getRoot().getProjects() ) {
var report = new BuildReport (project,buildHelper.getBuildErrors(project, buildHelper.SEVERITY_ERROR));
this.reports.push (report);
}

That's the build complete, i.e. the ilr has been created for all your business rules, decision tables, ruleflows, etc.

Now all this ilr has to be packaged up into a jar.

The generate function(line 192) is called to to this.

var rp = ruleModel.getRuleProject(ruleprojectName) ;
var jarfile = archivePath;
Utilities.println("Extracting ruleset archive " + rp.getName() + " with extractor '" + extractor + "'");
extractorHelper.extract(rp,jarfile,extractor);
Utilities.println("Successfully extracted in " + (new java.io.File (jarfile)).getAbsolutePath());

The extractorHelper is called to extract the jar. If you don't have an extractor, the extract method is overloaded to also generate a ruleset just with a RuleProject and a path location.

That's about it. I really advise you to go through the RulesBuild.js and look at the JRules API documentation. If you have any questions post me a comment.

2 years of JRules

Recently I came across the an an article on the register "ILOG launches JRules 6.0" which was written around the same time I first started working with the product. This was around a couple of years ago, so I thought I'd share my thoughts about the product , ILOG and rules engines in general.

What and why?

Firstly, what on earth is a rules engine and why would anybody bother using one?The wikipedia definition says "A business rules engine is a software system that executes one or more business rules in a runtime production environment".

The way I see it , a rules engine is a bit of software which contains the business logic for a system , instead of it existing in source code. These rules can be viewed and maybe manipulated by business users .The users should not need to understand the technical implementation (i.e. be able to understand java code), but should be able to view and change the business rules through the rules engine interface.

The example in the JRules documentation is of some kind of retail/sales application where certain customers receive discounts dependant on various details. A business analyst for example can come in and create a new rule to give a 10% discount to a customer who orders over $100 worth of goods. They can do this through the interface and it gets deployed , without the business analyst touching a line of code or the entire application being rebuilt and deployed.

This is one of the main selling points of a rules engine, it makes things a lot cheaper to change an applications behavior. Also the business is not totally dependent on some developer who knows all the intricacies of the code.

My Project

So before I joined the project, some bright sparks decided a rules engine fitted the bill for what they were doing and they chose ILOG JRules over a rival product from Fair Isaac. I think they went with ILOG because of better performance stats when they did a crappy POC.

As I was on a "rules developer" , I used the rules studio which was a plugin to eclipse. As we were the first project to use version 6.0, which really should have been a beta version, the product was riddled with bugs. Also the ILOG consultants on the engagement had little or no experience with version 6 which was significantly different to the previous version which was a standalone application.

So my first impressions of the product and the ILOG guys weren't great. A lot of the problems were ironed out over time, but the ILOG guys were pretty rubbish in communicting any problems back to hq and we had to repetively badger them to get anything done.

Some bugs still haven't been fixed , and we're now on version 6.7 and we have had a whole suite of helper tools as workarounds. Also some features are pretty shit. The reports that can be generated from JRules are almost useless. They are basically screen dumps of the rules and there are no links between rules and where they are referenced in the flow of the rules. We actually developed our own application to produce some really useful reports, which to be honest should be out of the box functionality.

When working on any business application, it is vital that the the requirements are good. Also it is pretty important to have people around who really understand the business domain. These two things are even more important when using a rules engine. Actually I would go as far to say, that if the requirements are pants and you don't have the business users around, who in the end will be defining and analysing the rules, then don't bother going with a rules engine.

On our project we had neither. In the article from the register mentioned earlier, David Norfolk says "Rules processing systems need configuration management and testing just like any other automated system; applying the wrong rules, or the wrong set of overlapping rules with a combined behaviour you didn't anticipate, can become very expensive very quickly." This is pretty much what happened on our project.

Also ILOG provided no recommendations on config management, source control, or build and deployment setups. We have ended up with unique setup. For example JRules out of the box doesn't let you build a ruleset (the collection of rules pacakged up as a zip) from a script or in any automated way. We had to have a custom built plugin to run eclipse in headless mode to create rulesets from an ant script ( See my post "Building from the command line in JRules 6.7").

Performance became a big issue with JRules. But with a few tweaks we were able to push things to an acceptable level. I post up some of the things we did later on.

Rule Engines

Whatever my gripes are with JRules, I think rule engines are more than just a passing fad. The technology is relatively immature and as more people in the industry gain experience in using these products we will see some really good implementations. Rules engines also do seem to be a natural progression from high level languages as they bridge some of the gap between the techie and business user. I have heard good things about Drools and it could be one of those projects the open source community will take to. Also there are companies like Pegasystems who have been primarily working on business process managment solutions, but now their products are crossing over into the business rules space.

Some things to look out for if you go for JRules or any rules engine

• Requirements , requirements , requirements - make sure the requirements have been nailed and you have people around who actually understand them
• Spend time with the business analysts to develop a good business object model and good verbalisations for the model. This will make your rules readable, understanble, maintainable, and you will end up with an overall better result. One of the most frequent complaints by the business analysts was the the verbalisations were rubbish.
  
• Spend time on design - just because you're using a rules engine doesn't mean you can chuck everything in and expect it to do what you want
• If the ILOG consultants aren't playing ball, get them replaced early
• Setup a process to build, unit and component test early on
• Plan time for refactoring
• Make sure the business users are involved - they will be the ones who will need to work with what you develop
• Rules engines can't do everything, you still need good code built around it.

Please let me know if you have any questions about Jrules or let me know about your experiences of using the product.

Further reading:

ILOG Lauches JRules 6 - The Register
ILOG White papers
Drools Documentation