Chapter 7. Rules and Processes

Table of Contents

Why use rules in processes?
Why integrate rules and processes in a single engine?
Approach
Teaching a rules engine about processes
Inversion of control
Example
Evaluating a set of rules in your process
Using rules for evaluating constraints
Assignment rules
Describing exceptional situations using rules
Modularizing concerns using rules
Using rules to dynamically alter the behaviour of the process
Integrated tooling
Domain-specific rules and processes

Drools Flow is a workflow and process engine that allows advanced integration of processes and rules. This chapter gives an overview of how to integrate rules and processes, ranging from simple to advanced.

Why use rules in processes?

Workflow languages that depend purely on process constructs (like nodes and connections) to describe the business logic of (a part of) an application tend to be quite complex. While these workflow constructs are very well suited to describe the overall control flow of an application, it can be very difficult to describe complex logic and exceptional situations. Therefore, executable processes tend to become very complex. We believe that, by extending a process engine with support for declarative rules in combination with these regular process constructs, this complexity can be kept under control.

  1. Simplicity: Complex decisions are usually easier to specify using a set of rules. Rules can describe complex business logic more easily by using an advanced constraint language. Multiple rules can be combined, each describing a part of the business logic.

  2. Agility: Rules and processes can have a separate life cycle. This means that for example we can change the rules describing some crucial decision points without having to change the process itself. Rules can be added, removed or modified to fine-tune the behaviour of the process to the constantly evolving requirements and environment.

  3. Different scope: Rules can be reused accross processes or outside processes. Therefore, your business logic is not locked inside your processes.

  4. Declarative: Focus on describing 'what' instead of 'how'.

  5. Granularity: It is easy to write simple rules that handle specific circumstances. Processes more suited to describe the overall control flow but tend to become very complex if they also need to describe a lot of exceptional situations.

  6. Data-centric: Rules can easily handle large data sets.

  7. Performance: Rule evaluation is optimized.

  8. Advanced condition and action language: Rule languages supports advanced features like custom functions, collections, not, exists, for all, etc.

  9. Higher-level: Using DSLs, business editors, decision tables, decision trees, etc. your business logic could be described in a way that can be understood (and possibly even modified) by business users.