Instant Drools Starter

For starters, you will need to check that you have all of the required elements, listed as follows (all versions are as of time of writing):

Java is the core language on which Drools is built, and is the language in which we'll be writing, so we'll definitely be needing that. The easiest way to get Java going is to download from and follow the installation instructions found at:

www.oracle.com/technetwork/java/javase/downloads/index.html

Maven is a build automation tool from Apache that lets us describe a configuration of the project we're building and leave dependency management (amongst other things) up to it to work out. Again, the easiest way to get Maven up and running is to download and follow the documentation provided with the tool, found at:

maven.apache.org/download.cgi

If you happen to have some other IDE of choice, or maybe you're just the old school type, then it's perfectly acceptable to author and execute your Drools-integrated code in your usual fashion. However, if you're an Eclipse fan, or you'd like to take advantage of auto-complete, syntax highlighting, and debugging features, then I recommend you go ahead and install Eclipse and the Drools plugin.

The version of Eclipse that we're after is Eclipse IDE for Java Developers, which you can download and find installation instructions for on their site:

www.eclipse.org/downloads/

In order to add the IDE plugin to Eclipse, the easiest method is to use Eclipse's built-in update manager. First, you'll need to add something the plugin depends on—the Graphical Editing Framework (GEF).

In the Eclipse menu, click on Help, then on Install New Software..., enter the following URL in the Work with: field, and hit Add:

download.eclipse.org/tools/gef/updates/releases/

Give your repository a nifty name in the pop-up window, such as GEF, and continue on with the install as prompted. You'll be asked to verify what you're installing and accept the license.

Now we can add the Drools plugin itself—you can find the URL you'll need by visiting:

www.jboss.org/drools/downloads.html

Then, search for the text Eclipse update site and you'll see the link you need. Copy the address of the link to your clipboard, head back into Eclipse, and follow the same process you did for installing GEF. Note that you'll be asked to confirm the install of unsigned content, and that this is expected.

By this point, you should be ready to integrate Drools into your applications. If you find yourself stuck, one of the good parts about an open source community is that there's nearly always someone who has faced your problem before and likely has a solution to recommend. Check towards the back of the book for a list of resources that can help get you going again!

First things first, let's start a new project using the plugin's Drools Project Wizard to get things up and going.

Congratulations! You've now got a working rules application. If you're in a hurry to see what DRL, or the Drools Rule Language, looks like, you can navigate to Sample.drl and have a look. You'll find the executable portion of code inside the file called DroolsTest.java. You can run it and see the output in your console by right-clicking the file name and selecting Run As | Java Application.

Checking your console, you should now see two lines of output. The first reads Hello World, and the second reads Goodbye cruel world. If you're seeing both, then it's a success! You've just set up and executed your first rules-integrated application.

The creation wizard cranked out a lot of code for us, and if we were to just continue on with this project, we'd be omitting explanation of the most vital parts of the code, so let's build up our own project piece by piece and find out what makes it tick.

We'll be creating a simple rules system that will aid us in rewarding customers of our fictional company, Tucker's Taco Shop, for large purchases and combo deals.

In a new or existing Maven project, let's add the required drools dependencies. I've created a new project called DiscountProgram. Your pom.xml file should look something like this:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="maven.apache.org/POM/4.0.0"
         xmlns:xsi="www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="maven.apache.org/POM/4.0.0 maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    	<groupId>com.tacoshop</groupId>
  		<artifactId>DiscountProgram</artifactId>
  	<version>0.0.1-SNAPSHOT</version>
    
	<properties>
        <droolsVersion>5.5.0.Final</droolsVersion>
    </properties>

    <dependencies>
        
        <dependency>
            <groupId>org.drools</groupId>
            <artifactId>drools-compiler</artifactId>
            <version>${droolsVersion}</version>
        </dependency>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.11</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>commons-lang</groupId>
            <artifactId>commons-lang</artifactId>
            <version>2.6</version>
        </dependency>
    </dependencies>
</project>

So what have we done here? We've specified some information about our project, mainly the groupId, artifactId, and version number—all things that Maven uses to identify your application. Secondly, we've added a property called droolsVersion to keep life simple so that we can't accidentally forget to change one of the Drools component version numbers in the future. Next, we've included the three main JAR files we'll need to utilize the Drools rules engine. The first is the drools-compiler dependency. It's worth mentioning here that by including drools-compiler, we've pulled two transitive dependencies worthy of noting, knowledge-api and drools-core. When the time comes to start digging into drools code, you'll see these API names again. Lastly, we've included commons-lang, another required dependency, and junit at the test scope level, to provide some mechanism to run our rules.

Before we go much further, let's stop and think up a basic set of rules we'd like to include in our discount program. Let's allow customers a discount of 10 percent on purchases over $15. Let's also give 15 percent off for purchases over $25. Finally, we'll allow a combo deal discount of an additional 5 percent off for purchases containing two or more tacos and at least one drink. Remember, rules tend to follow the format of When...then, so let's word them as such:

Now that we know what rules we'll have, let's figure out what facts we need to know about. Since we're intentionally sticking to a simple rule set, we only need to know about one thing, the purchase; we need to know how much it costs, what it consisted of, and the discount total.

With a fact model in mind, we need to create a Plain Old Java Object (POJO) class to represent our model.

Nothing too out of the ordinary in there. We've got a simple POJO with a constructor, some properties, and their getters and setters. Moving along!

So we've established a data model and we've already defined what rules we need, so now let's build our DRL file.

Now let's break it down...hey, stop dancing, that's not what I meant. The rules! The package and import statements, as seen here at the top of the file, are structured the same way as they are in Java class files. The rules, however, aren't so familiar to us. Notice that each starts with a rule name, and follows the format of when ... then ... end. We've discussed something similar to that construct once or twice by now, right? It's all coming together.

Our rule conditions (the when bit) use a dialect called MVFLEX Expression Language (MVEL), which makes them seem a little foreign to us. For one, we're not calling getters to access properties. MVEL takes care of that for us. It helps to read each condition aloud to yourself:

  $p : Purchase ( total > 25 )

The previous code can be read aloud as "There exists some purchase having a total greater than 25." In the case that such a purchase is found, we set it to a variable, $p. In the consequences of our rules, we take some action desired when our condition is met. Notice the consequences in the rules look like Java, but also reference the $p variable set from the conditions. In our first rule consequence, we set a discount of 10 percent to $p and we print something to the console showing us that the discount has been added. The rest of the rules follow the same format. Feel free to take a moment to look them over and read them aloud. The last thing I should mention before we move on is the keyword seen on the combo rule, salience. This keyword sets priority to a rule. By default, all rules have a salience of zero. You can specify a negative or positive salience, so in our case, we've used a negative one. Why? Because we want our combo discount to be in addition to any other discounts added to the order, so we need to give it a lower priority to ensure it's done last.

Take a quick break, maybe grab some coffee (try not to think about coffee rules, it's a break). This is going to be a big one. I'll wait here.

Moving on! So now that we have a data model and a proper rule resource, we can get to executing our rules. We're going to create a JUnit test that will compile our rules, build a session, insert some facts, and fire our rules. Let's get started by taking a look at the whole test, then we can examine the contents:

@Test
  public void testRules() {
    
    StatefulKnowledgeSession session = null;
    
    try {
      KnowledgeBuilder builder = KnowledgeBuilderFactory.newKnowledgeBuilder();
      builder.add(ResourceFactory.newClassPathResource("discountRules.drl"), ResourceType.DRL);
      if (builder.hasErrors()) {
          throw new RuntimeException(builder.getErrors().toString());
      }
  
      KnowledgeBase knowledgeBase = KnowledgeBaseFactory.newKnowledgeBase();
      knowledgeBase.addKnowledgePackages(builder.getKnowledgePackages());
      
      session = knowledgeBase.newStatefulKnowledgeSession();
  
      // purchase > $15 and <= $25
        Purchase firstPurchase = new Purchase(new BigDecimal("16"), 1, false);
      FactHandle purchaseFact = session.insert(firstPurchase);
          session.fireAllRules();
          
    } catch(Throwable t) {
       t.printStackTrace();
     } finally {
      if (session != null) {
          session.dispose();
        }
     }
  }

Let's start at the top! We've made a standard JUnit test (for now, let's ignore the fact that we're not really asserting anything inside our test—we'll get to that later):

@Test
  public void testRules() {

It's good practice to wrap your rules code in a try/catch block. For that reason, we've extracted a variable declaration needed within the finally block to outside of the try block:

    StatefulKnowledgeSession session = null;

Let's talk a bit about what StatefulKnowledgeSession is. Our session is the main means of communication with the rules engine. It provides us with some handy methods for inserting, updating, and retracting our facts. It also gives us methods for setting global variables (more on these later), as well as a method I like to refer to as the Big Red Button, fireAllRules().

Whenever you work with a session, it's important to always remember to use the dispose() function to dispose of it when you're done. If you don't, the garbage collector won't be able to free up the resources for you, and that means problems. The purpose of our finally block is to ensure that won't be an issue. So how do we build a session? Let's start with KnowledgeBuilder:

 try {
   KnowledgeBuilder builder = KnowledgeBuilderFactory.newKnowledgeBuilder();
   builder.add(ResourceFactory.newClassPathResource("discountRules.drl"), ResourceType.DRL);
   if (builder.hasErrors()) {
    throw new RuntimeException(builder.getErrors().toString());
   }

What's happening here is the compilation of our rules resource. The KnowledgeBuilder is responsible for taking resources and compiling them into rule packages. If we have any syntax or other compilation errors within our rules (notice I didn't say logic!), now's the time that they'd show up. Once it's built, we'll need to do something with our nifty rule package. Moving on to KnowledgeBase:

 KnowledgeBase knowledgeBase = KnowledgeBaseFactory.newKnowledgeBase();
 knowledgeBase.addKnowledgePackages(builder.getKnowledgePackages());

Notice that KnowledgeBase accepts the packages created by our builder. The KnowledgeBase can be thought of as a manager for our collection of knowledge packages, or as I've been referring to it, rule packages. It primarily provides us with an interface for inserting and removing packages, as well as a method for creating sessions populated with our rule information:

 session = knowledgeBase.newStatefulKnowledgeSession();

So now we have a rule session loaded up with our logic. Next it's time for the data. Let's throw something in so we can see some results:

 // purchase > $15 and <= $25    
 Purchase firstPurchase = new Purchase(new BigDecimal("16"), 1, false);
 FactHandle purchaseFact = session.insert(firstPurchase);
 session.fireAllRules();

We've initialized a Purchase variable with an amount of $16, one taco, and no drink (man, that's an expensive taco!). If we refer back to our rules, we'll see that this should be enough to trigger our first rule. Notice the fireAllRules() function in there? We're executing now and should see some output from our rule consequence. Success! The console confirms that a discount of 10 percent has been added to our purchase:

Level 1 discount: 0.1

So our rules have done their thing and we're ready to close up shop. We finish up with a catch block that will relay any issues encountered, as well as dispose of the session:

 } catch(Throwable t) {
    t.printStackTrace();
 } finally {
    if (session != null) {
       session.dispose();
    }
 }

What if we wanted to trigger our other rules as well? Let's add a few more lines to our test after the first call to fireAllRules() to flex the other two rules as well. You may have noticed we set something called a FactHandle at the same time we inserted a Purchase fact. We'll use that to update our rule session once we've made some changes to the Purchase object. Add these lines immediately after fireAllRules() and rerun the test:

 System.out.println("----------------");
          
 // purchase > $25
 firstPurchase = new Purchase(new BigDecimal("26"), 1, false);
 session.update(purchaseFact, firstPurchase);
 session.fireAllRules();
 System.out.println("----------------");
          
 // combo purchase containing 3 tacos and a drink
 firstPurchase = new Purchase(new BigDecimal("26"), 3, true);
 session.update(purchaseFact, firstPurchase);
 session.fireAllRules();

Level 1 discount: 0.1
----------------
Level 2 discount: 0.15
----------------
Level 2 discount: 0.15
Combo discount: 0.2

Congratulations! You're now working with Drools rules. If you'd like to download the accompanying code for this book (which includes better format and comments!) you can find it at http://www.packtpub.com/.

Until now, we've only discussed the syntax of rules to the point of getting us off the ground. To continue working with the Drools Rule Language, there's more about the syntax you'll need to know and understand. To start off, let's reexamine a few of the basics we've seen thus far.

Purchase ( $t : total > 15 )

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

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);
}

As we learned previously, rules engines reason over logic and facts. Logic, or in our case rules, serve as the bits of knowledge we know while facts serve as the objects that we're considering. Thus far, the rules and sessions we've worked with have been fairly simple. We defined some basic rules, loaded up a session, fired the rules, and that's it. In practice, knowledge bases will often grow in complexity and sessions will grow in size as we add more facts. The eventual need may arise for long living sessions and the ability to alter, add, or remove facts from the session. Drools allows us all of these capabilities. Let's take a look.

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

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

session.retract(personHandle);

then
  insert ( new Person() );
end

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

then
  retract ( $person );
end

Once you've put the work into developing a nice starter set of rules, you're going to want to make sure that as you develop more rules or change application behavior, what you've defined so far continues to do the job originally intended. By writing tests against rules, we can not only ensure their integrity, but also offer a roadmap of sorts to others who may want to examine how the rules behave and flag problem points when things have been refactored to a point of altering rule behavior. So how do we go about testing our rules? We'll use JUnit tests, much like the one we used previously to create a session for our taco shop rules. However, we can improve greatly upon the structure of our test class and do much more than just run a rule set. Let's start with defining our @Before and @After methods, both aptly named as JUnit will run them before and after each test method, respectively. We'll also go ahead and define a helper method to load up our rules using the same approach we did before.

public class UsefulRuleTest {

  private KnowledgeBase knowledgeBase;
  
  private StatefulKnowledgeSession session;
  
  @Before
  public void setUp() {
         
    try {
       // load a new knowledgeBase with our rules
       knowledgeBase = populateKnowledgeBase();
       
       // initialize a session for usage
       session = knowledgeBase.newStatefulKnowledgeSession();
       
    } catch ( Exception e ) {
      e.printStackTrace();
        Assert.fail( e.getMessage() );
    }
  }

  @After
  public void tearDown() {
    
    // if session exists, dispose of it for GC
    if ( session != null ) {
      session.dispose();
    }
  }
   
  private KnowledgeBase populateKnowledgeBase() {
         
    // seed a builder with our rules file from classpath
    KnowledgeBuilder builder = KnowledgeBuilderFactory.newKnowledgeBuilder();
    builder.add(ResourceFactory.newClassPathResource("discountRules.drl"), ResourceType.DRL);
    if (builder.hasErrors()) {
        throw new RuntimeException(builder.getErrors().toString());
    }

    // create a knowledgeBase from our builder packages
    KnowledgeBase knowledgeBase = KnowledgeBaseFactory.newKnowledgeBase();
    knowledgeBase.addKnowledgePackages(builder.getKnowledgePackages());
    
    return knowledgeBase;
  }
}

Our setup method simply calls off to our helper method to get a knowledge base, then gets a session based on the knowledge base created. Notice that we're using the same rule set established for our taco shop scenario, discountRules.drl. The clean-up method checks if our session needs disposal, because as we mentioned before, we always want to ensure we free up session resources for proper garbage collection when we're done. So now that we have a shell to work with, let's start by adding a test that exercises two of our rules so that we can verify that no exceptions are incurred during rule compilation or execution:

  @Test
  public void testRulesCauseNoExceptions() throws Exception {
             
    // should trigger our first and last rule
    session.insert(new Purchase(new BigDecimal("16"), 2, true));
    
    Assert.assertEquals(2, session.fireAllRules(50));
     }

We've added a purchase that should satisfy the conditions for our purchase total between $15 and $25 and combo rules. To end the test, we've asserted two rules executed, as fireAllRules() will return the number of rules fired. Notice that unlike before, we've passed a parameter to fireAllRules() of 50. This number, when provided, indicates the maximum number of rule executions a session is allowed to perform before it stops and returns control to the calling code. The purpose of this is to handle infinite loops that may have been accidentally introduced in the rules. Without having some break-away mechanism, our thread would never end without intervention, thus it would not return to the test to fail the assertion.

As you can imagine, once you have a multitude of rules in place, the practice of getting tests to exercise a specific group and not triggering others becomes a tricky process. Rather than trying to balance these ever-changing expectations, we can selectively allow rules to fire, which means we can guarantee that only a single or specified set of rules will be exercised within a test. We do this using an implementation of AgendaFilter, which is a single-method interface we can use to filter out the rules we'll allow to fire. Let's add a class that will allow us to specify what rules we'd like to allow per test:

  class CustomAgendaFilter implements AgendaFilter {

    private List<String> rulesToAllow;
    
    public CustomAgendaFilter(String[] ruleNames) {
      this.rulesToAllow = Arrays.asList(ruleNames);
    }
    
    public boolean accept(Activation activation) {
      if (this.rulesToAllow.contains(activation.getRule().getName())) {
        return true;
      } else {
        return false;
      }
    }
  } 

We've set up a custom implementation of AgendaFilter with a constructor that accepts a string array of rule names that should be allowed to fire. The method that we need to extend, accept(), simply checks each activation's rule against the list of rule names, and if present, allows it to continue. Let's run a test with a Purchase variable identical to our first test that triggered two rules, but let's put our new filter to use and assert that only one rule fires:

  @Test
  public void testOnlyComboRuleFires() throws Exception {
    
    session.insert(new Purchase(new BigDecimal("16"), 2, true));
    
    String[] expectedRules = {"purchase contains combo"};
    Assert.assertEquals(1, session.fireAllRules(new CustomAgendaFilter(expectedRules)));
  }

Running this test will show that we did indeed trigger one and only one rule, but how can we be sure that it was the rule we intended to run? Well, the filter does the work for us here, but should we need to confirm rule names for any other reason or check the order in which multiple rules fired, we'd need a different approach. Before we get too far removed from filtering by rule name, it's worth mentioning that Drools provides a few filters for us to match single rules by various means:

Now for a final example; let's put a custom AgendaEventListener implementation into practice that will help solve our dilemma of asserting rule names and order. Here's our new class:

class CustomAgendaEventListener implements AgendaEventListener {

    private List<String> rulesFired = new LinkedList<String>();

    public List<String> getRulesFired() {
      return this.rulesFired;
    }
    
    public void afterActivationFired(AfterActivationFiredEvent event) {
      rulesFired.add(event.getActivation().getRule().getName());
    }
    
    }
}

There are many more methods that we must override in order to implement this interface, but for brevity, I've only included here what's important for this example. In real use, all other overridden methods could just have empty bodies. Now here's our test:

@Test
  public void testVerifyRulesViaListener() throws Exception {
    
    CustomAgendaEventListener listener = new CustomAgendaEventListener();
    session.addEventListener(listener);
    
    // should trigger our first and last rule
    session.insert(new Purchase(new BigDecimal("16"), 2, true));
    
    Assert.assertEquals(2, session.fireAllRules(50));
    Assert.assertEquals(listener.getRulesFired().get(0), "purchase over 15 and less than 25 dollars");
    Assert.assertEquals(listener.getRulesFired().get(1), "purchase contains combo");
  }

We've built our custom listener, attached it to the session, and inserted a fact that we know should trigger two rules. Using our listener, we can assert that not only were the two rules that fired exactly the ones that we anticipated, but also that they've fired in the order we expected due to their salience levels.

Maurice Wilkes, 1967 Turing award recipient, said the following:

Debugging is a necessity in most programming constructs, and working with rules is no exception. There will come a time when you need to understand exactly what's happening in a rule session and why something did (or didn't) occur. Thankfully, there are tools available to us that will aid us in our efforts.

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

// 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"); 

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

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

// 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);

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

Before we dive in, I need to confess a little white lie. These days, Drools only has four modules. The humanity! I know, I'm sorry. So why would I mislead you, the honest, caring, innocent reader into thinking there's five? Well, there used to be five, but one module turned into something much bigger. jBPM, having grown from the roots of the module once known as Drools Flow, has become a project of its very own. However, given that it's completely integrated with Drools and the two are often used together, I felt it very relevant and worthy of inclusion, so let's start there.

jBPM

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: