Skip to main content
Drools Rule Language (DRL) is a notation for defining and describing business rules. This guide provides a comprehensive overview of DRL syntax, components, and best practices.

Introduction to DRL

DRL allows business analysts and developers to express business logic in a declarative format. Files with the .drl extension contain one or more rules, each defining conditions and actions. A rule in DRL consists of three main parts:
  • Attributes: Optional configurations that affect rule behavior (like priority, timing)
  • Conditions (when): Patterns that match facts in working memory
  • Actions (then): Operations to execute when conditions are met

Basic Rule Structure

Rule Units

Rule units are a modern approach in Drools 10+ that provides a modular organization for rules and their associated data. A rule unit defines both the rules and the data sources they operate on.

Declaration Structure

Data Sources

Rule units support different data source types:
  • DataStore: Mutable collection that allows add/remove operations
  • DataStream: Append-only collection, ideal for event streams
  • SingletonStore: Holds a single value that can be updated
Example of using multiple data sources:

Packages and Imports

Package Declaration

Every DRL file must start with a package declaration:
Packages group related rules and provide a namespace.

Import Statements

Import statements specify the fully qualified paths for classes used in your rules:

Type Declarations

You can define new fact types directly in DRL:

Metadata in Type Declarations

Add metadata to types or fields:
Common metadata includes:
  • @role(event): Marks a type as an event (for CEP)
  • @timestamp: Specifies event timestamp field
  • @duration: Specifies event duration field
  • @expires: Sets automatic expiration time
  • @key: Marks fields used for equality comparison

Rule Conditions (When)

Rule conditions use OOPath expressions to match patterns in working memory.

Basic Pattern Matching

A pattern with constraints matches against a fact of the given type and the additional restrictions in brackets [] that are true or false. For example, the following condition is that the Persons RuleUnit’s age is greater than 21.

Binding Variables

Typical DRL syntax involves binding variables typically using $ before the variable name.

Multiple Constraints

Nested Properties

Advanced Navigation

Operators in Conditions

Comparison Operators

Compound Conditions

String Operators

Collection Operators

Rule Actions (Then)

Rule actions define operations to perform when conditions match.

Basic Actions

Working with Data Sources

Modifying Facts

Using the modify block:

Rule Attributes

Rule attributes allow you to control rule behavior:
Common attributes:
  • salience: Sets rule priority (higher executes first)
  • no-loop: Prevents rule re-activation if actions modify matching facts
  • date-effective: Rule only active after date
  • date-expires: Rule not active after date
  • timer: Schedule-based rule execution
  • duration: Delay rule execution
  • enabled: Enable or disable rule

Timers and Calendars

Timer Attribute

Timer formats:
  • Interval: timer (int: <initial delay> <repeat interval>)
  • Cron: timer (cron: <cron expression>)

Calendar Attribute

Conditional Elements

exists

Checks if at least one fact matches:

not

Checks if no facts match:

forall

Checks if all facts that match the first pattern also match the remaining patterns:

Accumulate and GroupBy

Accumulate

The accumulate element allows collecting and processing values from multiple facts:
Predefined accumulate functions:
  • average
  • min
  • max
  • count
  • sum
  • collectList
  • collectSet

GroupBy

GroupBy allows performing accumulate functions on specific groups:

Queries

Queries allow you to search the working memory for facts matching specific criteria:
With rule units, queries are automatically exposed as REST endpoints.

Performance Tuning for DRL

Optimize rule performance with these practices:
  1. Define constraints from left to right: `// Better /persons[ firstName == “John” ]
// Worse /persons[ “John” == firstName ] 2. **Use equality operators (==) when possible**: // More efficient /persons[ firstName == “John” ] // Less efficient /persons[ firstName != “OtherName” ] 3. **List most restrictive conditions first**: when person:/persons[age==25]//Morerestrictivecondition/addresses[owner==person: /persons[ age == 25 ] // More restrictive condition /addresses[ owner == person ] // Less restrictive condition 4. **Avoid deep property access with excessive path expressions**: // Better: Add both Person and Address to the knowledge base person:/persons/addresses[owner==person: /persons /addresses[ owner == person, city == “New York” ] // Less efficient /persons/addresses[ city == “New York” ] ` 5. Use event listeners for logging instead of System.out.println

Decision Tables in Spreadsheets

Drools supports defining rules in spreadsheet decision tables (XLS/XLSX). A decision table consists of:
  • RuleSet area: Global definitions and attributes
  • RuleTable areas: The actual rules, conditions, and actions

Basic Structure

  1. Label a cell RuleSet in column B
  2. Provide a rule set name in column C
  3. Add global attributes below the RuleSet cell
  4. Create a RuleTable section with a name
  5. Define rule attributes, object types, constraints, and conditions
  6. Add rule values in rows below the conditions

Example Decision Table

Decision table for shipping charges based on order details:

Complete Examples

Example 1: Loan Application Process

Example 2: Temperature Monitoring System

Example 3: Order Processing with Discounts

References and Resources

Language Levels

Drools supports different DRL language levels:
  • DRL6 (default): Compatible with previous Drools versions
  • DRL10: Introduces clarity-improving changes
  • DRL5, DRL6_STRICT: Deprecated and will be removed
To specify a language level, use kmodule.xml or system property:
Or in Java: