By now, hopefully I've nailed home the construct of when-then conditions. I think it's important to note here that while the taco shop rules we worked with were quite simple in nature, rules conditions can actually be very complex, meaning a rule may have more than one pattern. The syntax for each is basically the same:

Purchase ( $t : total > 15 )

This condition consists of a type, Purchase, a property that we're accessing, total, which we're binding to a variable, $t, and a Boolean evaluation on that property checking that the total of the purchase is greater than 15. Constraints can be made up of anything that evaluates to a true or false, or a Boolean value. Here we've done a simple "greater than" check, but patterns can also include Boolean properties, method calls, or other more complex Boolean expressions. Now's also a good time to point out that variables can either be bound to properties of an object, or the entire object itself:

rule "example rule"
when
   Purchase ( $t : total )
  $p :  Purchase ( total > $t )
then
  System.out.println("amount " + $p.getTotal() + " > " + $t);
end

As seen here, variables can be accessed in both, a condition and consequence of a rule. If used within a condition, the variable must have been declared and bound previously, and must be used on the right-hand side of the evaluator (that is you'll always use the order property, operator, then variable), otherwise our rule would expect that Purchase has a method get$t() to call, which would cause an exception to be thrown.

In order to introduce a few additional things you'll want to be familiar with, let's consider this example rule file:

package org.tacoshop

import org.tacoshop.model.Purchase

global int comboCount

// hey here's a rule!
rule "example rule"
when
  $p : Purchase ( tacoCount >= comboCount, ( tacoCount % 2 == 0 ) )
then
  /* this consequence is pretty simple,
    but let's give it a comment anyways */
  $p.setDiscount(addDiscount($p, 0.15));
end

function double addDiscount(Purchase p, double discount) {
  return (p.getDiscount + discount);
}

We're familiar with the package declaration and import syntax, nothing new there. However, we've not seen a global variable declaration yet. Normally in programming, the term "global variable" has been engrained into our minds as a bad thing, but with Drools that's not the case. Global variables are tied to our rule session, meaning they're only global within limitation and available inside all of our rule conditions and consequences. In the previous code, we've referenced the global comboCount variable inside of a constraint to check if we've bought enough tacos to qualify for a combo discount. So where did the value of comboCount come from? Our rule session provides us with methods for handling globals similar to those we have for facts. To get a value in there, we'd want to call session.setGlobal("comboCount", 2) prior to executing our rules with fireAllRules(). If we didn't set a value beforehand, Drools would throw an exception. Also keep in mind that globals should be immutable as to avoid any surprises in unexpected behavior.

Another new concept I've demonstrated in this file is commenting. Any good code should include comments. Rules files can often grow to be very complex and should be no exception. DRL files allow single-line comments using either the # or // prefix, as well as multi-line comments using the /* comment */ construct.

If you take a closer look at the rule condition, you'll notice that we've formed an evaluative statement checking that the number of tacos in the purchase is evenly divisible by two. We're able to use any Java expression within a pattern as part of the condition, so long as the return is a Boolean value contributing to the truth of that condition.

Lastly, notice the function declared in this file. Functions within rule files carry the same functionality and syntax you'd expect from any Java class method, and we've referenced our function from within the rule consequence. If you find yourself repeating a lot of code, then a function can help to eliminate redundancy and simplify refactoring.

Drools provides us with several ways to modify the behavior of a rule. Most are pretty complex in nature and beyond the scope of this book. We'll examine a few of the basic rule attributes here and recommend referring to the documentation later where the rest are covered in great detail. Rule attributes are added to the rule definition after the rule name, but before the when keyword.

Drools provides us with several operators for use within our rule constraints. Some of the most commonly used operators include the following:

There are also a handful of conditional elements that you should be aware of which allow for a more complex usage of patterns:

While I feel that these lists serve as a good basis for understanding various usages within DRL, note that it's not a list of all possible functionalities you will encounter in rules. For example, some words shown here, such as not, might be found within a constraint as a negation operator as well as outside of a pattern as shown in the previous example. As with any good software, Drools is also an ever-changing technology with a development team working hard to bring new functionalities to us with every release, so it's also safe to assume that new operators and conditional elements will be introduced. That being said, learning to yield those functionalities we just listed should provide for a very strong basis to author multitudes of business rules you'll find yourself in need of.

We've already seen how we insert a fact into a session from our executable code using session.insert(fact). However, if we need to modify or remove that fact from the session later, then we'll need a reference to correlate our changes to the proper object in memory. For this, Drools provides us with FactHandle:

Person person = new Person();
FactHandle personHandle = session.insert(new Person());

With a handle such as this, we could go on with our code, call various code blocks that alter our Person object, then update the object in session memory so that the two are in sync:

person.setGender("female");
session.update(personHandle, person);

If, for some reason, we decide in our code that we no longer want person to be reasoned over, then we could use our FactHandle to remove the Person object from the session's working memory:

session.retract(personHandle);

As your rules become more evolved, the ability to perform similar fact manipulation actions from within rule consequences becomes desirable. Since rules operate within the realm of the session, we are no longer on the outside peering in and don't need to use fact handles to reference our objects. Inserting a fact from within a consequence looks like this:

then
  insert ( new Person() );
end

In order to alter a fact from within a rule consequence, you'll find that there are two options available to you, modify and update. Though similar in concept, there's one very important difference between the two. When you use modify, the fact is altered and the engine is notified at the same time, preventing a gap between the two steps that could potentially lead to indexing issues with the engine. Update, on the other hand, does not provide this same functionality, so it is recommended that from within a rule consequence, you always use modify. The syntax is as follows:

then
  modify( $person ) { setMood( "happy" ) };
end

And lastly, we can also remove a fact from working memory from within a rule consequence. Retract is identical to its code equivalent, except instead of passing a fact handle, we work directly with the fact itself:

then
  retract ( $person );
end

If you're taking advantage of the Eclipse plugin provided for working with Drools, then you'll find that the debugging process has not been overlooked. If you've worked with breakpoints and debugging Java code within Eclipse before, the process is very similar when working with rules. Start by opening your rule file and placing breakpoints where you'd like execution to pause for you to examine the current state. Note that only breakpoints placed in rule consequences are valid. You can add them in two ways:

Now run your executable code as a Drools application by highlighting the method or class name, right-clicking on it, and navigating to Debug As | Drools Application. Execution should halt within your rule consequences at your breakpoints, provided the conditions for the rule have been satisfied and the rule has fired. Breakpoints placed in Java code will be respected as well, allowing us to examine what's happening both in and outside of rules in the same session.

If you aren't using the Eclipse plugin, or perhaps you'd prefer to enhance your debugging by adding a bit of logging to allow for closer examination or auditing, then Drools also provides this capability. In order to better understand how we can do that, we first need to define a few things:

Drools offers interfaces we can implement to customize event listeners for the working memory and the agenda. They are called, as you might expect, the WorkingMemoryEventListener and the AgendaEventListener. Each contain a series of methods that encapsulate all of the events potentially interesting to us when looking to debug or audit internal processes.

Due to complexity, there's one additional functionality, inference, that I've withheld up to this point so that we would be better prepared with debugging and testing methods to fully dive in and understand the concept. Sometimes upon examining an object, we can infer some other piece of information that we may want to add to our rule session for the evaluation of further rules. Since this new information is closely related to the object, the information is typically only important as long as the object remains in session. When the object goes away, the new information is no longer valuable to us, and thus can also go away. Utilizing the support that Drools provides for inference, we can take some of the guess work out of tracking inferred relationships and reduce the amount of maintenance rules needed to remove an inferred fact when the related fact goes away. Let's start with a simple, non-inference example that we can build on and put some of what we've learned so far to use:

rule "fire detected, turn on alarm"
when
    Fire ( $r : room )
    Sprinkler ( room == $r, !on )
then
    System.out.println("fire detected, starting alarm!");
    insert( new Alarm($r) );
end

rule "alarm should turn on sprinklers, extinguishing fire"
when
    Alarm ( $r : room )
    $s : Sprinkler ( room == $r )
then
    System.out.println("alarm sounding, turning on sprinklers");
    modify( $s ){ setOn(true) };
end

rule "sprinkler came on, that puts out the fire"
when
    $f : Fire ( $r : room )
    Sprinkler ( room == $r, on )
then
    System.out.println("sprinklers put out the fire in " + $r);
    retract ( $f );
end

rule "fire's been put out, we should remove the alarm now"
when
    $a : Alarm ( $r : room )
    not Fire ( room == $r )
then
    System.out.println("fire's out, we can turn off the alarm now");
    retract ( $a );
end

Here we have a basic set of rules to take us through the simple steps of sounding an alarm for a fire, turning on the sprinklers, and removing the alarm when the fire is extinguished. Let's write up a test to show that our logic is sound. For brevity, the session initialization and the test structure have been omitted as we've seen them before; feel free to reference the accompanying code for this book, FireAlarmTest.java, to see the test in its entirety as well as the model POJOs in use:

// we need to indicate that room "kitchen" has a sprinkler in it
session.insert(new Sprinkler("kitchen"));

// now let's indicate that a fire has started in the kitchen
session.insert(new Fire("kitchen"));

// we expect all 3 of our rules to fire in this scenario
Assert.assertEquals(3, session.fireAllRules(50));

// fire's detected
Assert.assertEquals(listener.getRulesFired().get(0), "fire detected, turn on alarm");

// sprinkler's turned on
Assert.assertEquals(listener.getRulesFired().get(1), "alarm should turn on sprinklers, extinguishing fire");

// fire gets extinguished
Assert.assertEquals(listener.getRulesFired().get(2), "sprinkler came on, that puts out the fire");

// and finally, we remove the alarm
Assert.assertEquals(listener.getRulesFired().get(3), "fire's been put out, we should remove the alarm now"); 

Everything looks good. All of our assertions passed and we can see from our console output that things progressed as intended:

fire detected, starting alarm!
alarm sounding, turning on sprinklers
sprinklers put out the fire in kitchen
fire's out, we can turn off the alarm now

So, now examine what these rules look like when using inference. Let's change our first rule to use insertLogical, reading as follows:

rule "fire detected, turn on alarm"
when
    Fire ( $r : room )
    Sprinkler ( room == $r, !on )
then
    System.out.println("fire detected, starting alarm!");
    insertLogical( new Alarm($r) );
end

Thanks to inference, we'll no longer have to keep up with removing the alarm ourselves, as it will be removed for us when the rule that initially put it in place is no longer satisfied. That means we can remove our last rule, "fire's been put out, we should remove the alarm now" entirely. Let's write another test that will exercise these rules and show that the alarm is removed from the session via inference:

// we need to indicate that room "kitchen" has a sprinkler in it
session.insert(new Sprinkler("kitchen"));

// now let's indicate that a fire has started in the kitchen
session.insert(new Fire("kitchen"));

// we expect all 3 of our rules to fire in this scenario
Assert.assertEquals(3, session.fireAllRules(50));

// fire's detected
Assert.assertEquals(listener.getRulesFired().get(0), "fire detected, turn on alarm");

// sprinkler's turned on
Assert.assertEquals(listener.getRulesFired().get(1), "alarm should turn on sprinklers, extinguishing fire");

// fire gets extinguished
Assert.assertEquals(listener.getRulesFired().get(2), "sprinkler came on, that puts out the fire");

// assert that working memory contains only the sprinkler, meaning alarm was removed
Assert.assertTrue( session.getObjects().size() == 1);
Assert.assertTrue( session.getObjects().toArray()[0] instanceof Sprinkler);

The console output reflects what we've asserted that our three rules fire, and we've also asserted that the session only contains one object, a Sprinkler, meaning that the Alarm object was successfully removed from the session via inference.

fire detected, starting alarm!
alarm sounding, turning on sprinklers
sprinklers put out the fire in kitchen

There's one remaining caveat to using inference that I should mention before we move on. You'll need to ensure that your classes properly override the equals and hashCode methods in order to properly handle collisions between "equal" of both regularly and logically inserted facts.

Business Process Management (BPM) is a means of describing some process that occurs within your organization as a series of steps involved, how those steps are connected, and who is involved in performing them. jBPM, which is based on the BPMN 2.0 specification (a standard for graphical representation), serves as a tool for describing such processes in a flowchart format, giving visibility, clarity, and organization to processes that might otherwise be lacking. jBPM supports the entire process lifecycle, from development to execution and management up to retirement. Let's take a look at the graphical representation of a simple process.

Oscar's Oatmeal Cookies is a small successful business, delivering baked deliciousness worldwide. Its process is simple; whenever a new order is received, Oscar needs to bake some cookies, calculate and print an invoice, and ship the cookies out to the customer. The baking and invoicing cannot happen until an order is received and must be completed prior to shipping, but these two steps can possibly occur simultaneously. With jBPM, that process looks something like this:

By now we've learned quite a bit about what makes up rules, how to compile knowledge packages, and how to evaluate our rules with rule sessions. All the functionality that we've exercised in our examples belongs to the Expert module, which is the core engine of the system. We tell the engine about our logic and facts, and then we ask it to reason over what we've told it about and make some decisions for us. All other modules extend or rely upon the functionality of the core module, Expert.

Fusion gives the rules engine the ability to perform event processing, often referred to as complex event processing (CEP). What's that, you say? Best to start with asking, "What is an event?" When something occurs in a point of time, that's an event. It may be instantaneous, or it may have a duration. What's important is that it has some temporal association. Using that definition of events, we can define CEP as the ability to take in masses of events, determine which are likely to be important, and figure out relationships and patterns between them. A proper example will go a long way in demonstrating what CEP is.

Ever got a call from your bank stating that some potentially fraudulent activity has been detected on your account? They're likely calling to verify a transaction or two with you as something suspicious has been flagged in their system. It could be something like an unusual amount, or maybe the transaction occurred outside of the geographical areas that you typically stay in. Your bank likely monitors massive amounts of transactions in a day. Each of these transactions is an event; something that occurred at a specific point in time. It's likely impossible for the bank to pore over each transaction manually and connect the dots and detect oddities in their records for every customer, so what is the best way to detect and overcome fraudulence? CEP to the rescue! By defining relationships between transactions that we're interested in, such as sudden spikes in amounts or purchases in two different countries within a short timeframe, the bank can feed all their incoming events into a rules engine and allow it to flag or notify someone when something seems a bit off.

The Guvnor module provides us with a centralized repository with a layer of user authentication in which we can store and manage our rules, processes (like the one we just discussed), models, and other entities related to knowledge bases. Guvnor offers a collection of graphical editors with which we can view and edit our rules, and when combined with authentication, provides an excellent avenue for non-techie types to access and work with rules in a guided and controlled way. This allows us to bring the people with the domain expertise into the rule creation and maintenance processes. If you're worried that exposing your rules to business users creates a potential black hole in which rules could disappear forever, worry not! Guvnor provides versioning for all of our rules, so we'll not only be able to recover when necessary, but we'll also be able to audit the change trail and take steps to prevent future recurrences.

Planner helps us (the name's a hint!) carry out automated planning. In order to optimize how we distribute and utilize resources in an organization, sometimes we need to consider multiple possible solutions and choose which works best for us. If Oscar's Oatmeal Cookies needs to make 100 deliveries in a day and only has 20 trucks to use, they'll probably want to figure out the best way to do it. While they could easily send out one truck to make all 100 stops, or all 20 trucks each with five stops each, these probably aren't the most effective options available. Instead, Oscar could plug his information into Planner, make some decisions about what factors are most important to him (for example, fuel cost versus number of stops any one truck must make) and let the rules engine figure out the optimal solution for his needs.

That's a wrap! Hopefully over the course of this book, I've armed you with the basics you need to get yourself started with Drools. We've only scratched the surface of syntax, features, and uses of Drools. There are many great resources out there when you're ready to start digging deeper, including some great reads from Packt Publishing and many blogs, tutorials, forums, and documentation available across the Internet. I implore you to check them out. Good luck and happy coding!