Building Business Rules Engines with Drools - Power to the SMEople

One of the most amazing things about working in software development is the ability to work in many different industries - especially if you’re a consultant. Most software development skills you learn while working within one industry are directly transferable to any number of other industries, companies, projects, and niches.

I’m speaking about topics like database design, design patterns, GUI layouts, event management, etc. Then, of course, there are topics specific to one particular industry, company, or project.

SME Meets IT, Knowledge Transfer Begins

This is where the Subject Matter Expert (SME) comes in. A SME will typically be very involved in the design stage of the project.

The SME has been working within the industry for a long period of time, knows the lingo, and understands the business logic behind the coding. The SME may have some understanding of software development, but this is not necessary for the project to succeed.

For many projects, unless the software developer has a great understanding of the business logic, completing a successful software application will be relatively difficult. The amount of time that needs to be spent on knowledge transfer will vary widely based on the project’s complexity.

Assuming that an agile approach is taken and one or more SMEs are available throughout the development phase of the project, knowledge transfer will continue during all stages of the project.

What If Complete Knowledge Transfer Is Not Feasible?

Depending on the industry and project, it may not be possible for an SME to deliver complete knowledge transfer.

For example, imagine if the SME is a physician with 25 years of experience, and you have 6 months to complete a project. Or, imagine the SME as a biologist with 40 years of experience – such a level of knowledge simply cannot be transferred in a realistic timeframe for software development projects.

But what if the knowledge area is dynamic?

Typically, software is released on a set schedule based on time or features. However, the business rules within some industries change much more frequently.

In many cases, it may not be feasible to release software as often as necessary to keep up with industry changes. Having the ability to externalize business rules within a business rules engine may make sense in such scenarios. The ability for a software project to be able to withstand change will go a long way toward assuring its ultimate long-term success.

When and Where Do Rules Engines Make Sense?

For many software projects, it is feasible for full knowledge transfer to take place, and for the business logic to be coded in a computer language such as C# or Java.

However, there is a subset of projects where the amount of understanding of a specific subject is so large, or the business rules are subject to so much change that it makes more sense for a non-programmer to have direct access to the business logic. This is the subject of this tutorial; with that in mind, let’s discuss Rules Engines in depth.

What Is a Business Rules Engine?

A rules engine is a tool for executing business rules. Business rules are composed of facts and conditional statements. Any “if-then” statement that appears in traditional business logic qualifies as a business rule.

For example: if an employee is out sick for more than 5 days in a row and does not have a doctor’s note, then they need to be written up. If a business associate has not been contacted for over 6 months and they have made no purchases during that time, then it may be time to send them a cordial email. If a patient has a high body temperature, vision problems, and there is a family history of glaucoma, then it might be time to request an additional MRI or other tests.

How Do SMEs Write Business Rules?

Instead of expecting an SME to learn Java, C#, or another programming language, IT will create a mini-language for him or her to express their business rules. The building blocks of these rules will consist of facts that can be queried for. Some examples of facts by industry/practice areas are:

• Human Resources: salary, position, manager, years with company
• Medical: temperature, blood pressure, current medication
• Financial: current stock price, 52-week highest/lowest price, P/E ratio, date of next earnings release

Essentially, the information necessary to make business decisions must be available to the SME in a streamlined fashion.

What Do These Rules Look Like?

For the remainder of this rules engine tutorial, I will be using Drools, an open-source Java based rules engine, which can be found at www.drools.org and is a JBoss project. In Drools, rules are written as Java code and have the following structure:

Import statements go here:

rule “Name of rule”
when
        	“The if” part of the business logic goes here.
then
        	The “then” part of the business logic goes here.
end

Drools and Working Memory

Drools employs a concept called Working Memory.

Application code will be responsible for loading appropriate facts into Working Memory so that SMEs can write rules that query these facts. Only facts relevant to application business logic should be loaded into Working Memory, in order to keep the rules engine running at top speed.

For example, if an application is determining whether to approve a customer for a loan, relevant facts would include salary, credit scores, and outstanding loans. Non-relevant facts would include day of the week or gender.

Rules Evaluation

After Drools Working Memory has been loaded with rules and facts, the rules are evaluated according to the “then” part of their rule. If the “then” part evaluates to true, the “when” part of the rule will then be executed.

Typically, all rules are evaluated at once, although rules can be grouped together and evaluated on a per-group basis. The “then” part of the rule can change the contents of the Working Memory. When this occurs, Drools will reevaluate all rules to see if any rules now evaluate to true. If so, their “when” parts will be executed.

This recursive nature of rule evaluations can be a blessing or a curse – so rules need to be created with this architecture in mind.

The “If“ Side of a Drools Rule

In Drools, facts are represented by objects. The existence or non-existence of an object type can be queried for. Additionally, the object’s attributes can be queried as well.

Here are a few examples:

Determine if an employee earns more than 100,000.

Employee(salary > 100000)

Determine if a patient has cholesterol level of greater than 200 and is taking Lipitor.

Patient(cholesterol > 200, medications.contains(“lipitor”))

Determine if the price of a stock is within 1% of its yearly high.

Stock(price >= (yearHigh * .99))

Combining Queries

When writing complex business logic, business rules can combine queries by using Boolean operators AND, OR, and NOT and nesting using parenthesis.

For example:

Determine if there is a manager making less than $75,000 or a director making less than $100,000.

Employee(position.Equals(“Manager”),salary<75000) OR Employee(position.Equals(“Directory”),salary<100000)

Using Multiple Object Types

All of the examples so far have been based on a single object type, such as Employee or Patient. However, Drools allows queries to be based on multiple object types.

For example:

Determine if customer has a salary higher than $50,000 and has not filed for bankruptcy.

Customer(salary>50000) AND not exists Bankruptcy()

The “Then” Side of a Rule

The “then” side of a rule determines what will happen when there is at least one result in the “when” part of the rule.

In Drools, anything that can be written in Java can be written in the “then” part of the rule. However, in order to make rules more reusable, it is generally a good idea not to place any I/O, flow control code, or general execution code within a rule.

As an alternative, the “then” part of a rule can be used to modify Working Memory. A common practice is to insert a fact into Working Memory when a rule is evaluated as true.

For example:

rule “LoanApproved”
when
        	Customer(credit>700) && not exist LoanOutstanding()
then
        	insert(new LoanApproval())
end

How Do We Know When a Rule Has Evaluated as True?

After all rules have fired, the application needs to know which rules evaluated as true. If rules insert objects into Working Memory when they evaluate true, code can be written to query Working Memory for those objects.

In the above example, after all rules have been fired, a query can be made to see if a LoanApproval() object is in Working Memory.

query "GetLoanApproval "
        	$result: LoanApproval()
end

How Does a Business Rules Engine Interact with an Application?

Typical applications contain business logic, GUI, I/O and flow of control code.

For example, an application may process a user request like this:

GUI ? Flow Control ? I/O ? Business Logic ? I/O ? Flow Control ? GUI

Embedding a rules engine adds a few steps to this process:

GUI ? Flow Control ? I/O ? Create Rules Engine Session ? Add Facts to Working Memory ? Fire Rules ? Determine which rules have evaluated true ? I/O ? Flow Control ? GUI

How do SMEs work with Rules?

Creating, Editing and Deleting Rules

In order for SMEs to work with rules, they will need a user-friendly GUI. Some business rules engines ship with such an interface.

For example, Drools ships with two GUIs that I find user friendly. The first resembles a spreadsheet and allows SMEs to create rules without ever writing any actual code. The second GUI allows more complex business logic to be created.

While both of these GUIs can be helpful for entering simple conditions, they will not work as business logic becomes more complex. In that case you will have to create your own custom GUI.

Elements of SME Custom GUI

In order for SMEs to work effectively, consider creating a custom GUI with the following capabilities:

• Syntax Checker – a “check syntax” button can call Drools code to check for possible errors and their line numbers.
• Drag/Drop – instead of requiring an SME to remember the Objects and Attributes available to them, consider offering them a pick list from which they can drag and drop.
• Web Interface – a thin client interface will be available to SMEs without distribution concerns. This will come in handy as the GUI needs additional features and general maintenance.
• Rule Tester – having the ability to test individual rules without interfacing with the entire application will greatly increase SME productivity. Allow the SME GUI to determine facts and then fire individual rules.

Where Should Rules Be Stored?

In Drools there are typically two ways to store rules. Drools works out of the box with file-based rules that will usually have a .drl extension.

This works well when the number of rules is small. As the number of rules grow, you will want to use a database. Storing and retrieving rules from a database requires more work, but should give you a much more manageable architecture.

This rules engine tutorial has only touched upon a very small portion of the Drools Rules Language. For a complete description please consult at the official reference documentation.

The decision to use a rules engine should not be made lightly. While a rules engine will make your application more extensible by SMEs, it will also become more complicated to develop, test and deploy. For additional considerations on this topic, you may want to review the following guidelines.

Now we can proceed to show you something a bit more interesting – a simple real-life example of Drools in action, in a use case that most Toptal blog readers should find familiar.

Using Drools In A Real-Life Scenario

Toptal, a leading provider of high level Software Development talent, currently uses Applicant Tracking software to take job applicants through various stages in the hiring process. Here is a simplified visual flowchart of this process:

Currently, the business logic to decide if an applicant will continue in the hiring process has been hard-coded into the software. Everytime Human Resources needs to change the business logic, they must have IT involved. They would like to have the ability to directly change the way their software runs.

The Applicant Tracking software will be modified to run HR supplied rules at each decision point in the hiring process. HR will have a ‘Candidate’ object that will represent a job applicant whose status has just been modified by an initial entry, completion of online exam, or a number of different factors. The Candidate object will have fields to represent experience, test scores, interview scores, etc.

The following example presents a simplified set of rules for your consideration. It has not been deployed, it’s just a simple example consisting of four interconnected rules:

• Submitted -> Testing
• Testing -> Interview
• Interview -> Project
• Project -> Hiring

Submitted -> Testing

Based on current client needs, HR would like to write a rule that will determine if a candidate should be scheduled for online testing.

Rule “Schedule For Testing”
when
	$candidate: Candidate(status=='Submitted',yrsExperience >= 10, 
		skill(name=='Java', yrsExperience>=5) or Skill(name=='C#', yrsExperience>=5))
then
	$candidate.setStatus('Testing');
end

Testing -> Interview

After the candidate has taken the online exam, their score needs to be evaluated. HR would like to have control over this rule as well. The online exam tests for a candidate’s ability to understand software development theory, problem solving, and syntax. HR would like to decide what mix of scores will enable a candidate to be considered for a technical interview.

Rule “Schedule For Interview”
when
	$candidate: Candidate(status=='Testing', testScore(theory>.8 && syntax>.6 && problemSolving>.8);
then
	$candidate.setStatus('Interview');
end

Interview -> Project

A technical interview will test a candidate’s ability to speak about their experience, answer problem solving questions, and it will test their ability to communicate in general. HR will write the rule that determines a passing score for the technical interview.

Rule “Schedule For Project”
when
	$candidate: Candidate(status=='Interview', 	interviewScore(speakExperience>.9 && problemSolving>.8 && communication>.9 );
then
	$candidate.setStatus('Project');
end

Project -> Hiring

If a candidate passed the technical interview, they will be given an off-line programming project. They will submit the project and it will be judged for completeness, architecture, and GUI.

Rule “Schedule For Hiring”
when
	$candidate: Candidate(status=='Project', projectScore(completeness>.8 && architecture>.9 && gui>.7 );
then
	$candidate.setStatus('Hiring');
end

As you can see, even this basic example offers a number of possibilities for HR, and it can streamline operations. The fact that HR could alter rules without having to involve IT in the process would inevitably save time and speed up the screening process.

Since the rules can be changed on the fly, the HR department would also have a lot more flexibility. For example, HR could expand or restrict the selection process by setting different parameters.

If there are too many candidates that tick all the right boxes, the bar could be raised in minutes, thereby reducing the number of candidates. Alternatively, if the process yields few or no candidates that meet all of the requirements, HR can choose to reduce or drop some of the standards, shifting their focus to more relevant skills until an adequate number of candidates meet the requirement.