Backend Development 24 min read

Drools Rule Engine and Rete Algorithm: Concepts, Implementation, and Application in a Collection System

The article explains how Drools, a business rule management system using the Rete algorithm, separates decision logic from code by generating DRL files from decision‑table data, enabling non‑technical users to manage collection‑system rules that assign overdue cases to queues, while noting current limitations and future upgrades.

vivo Internet Technology
vivo Internet Technology
vivo Internet Technology
Drools Rule Engine and Rete Algorithm: Concepts, Implementation, and Application in a Collection System

This article introduces the concept of a rule engine and explains the relationship between KIE and Drools. It focuses on how to write Drools rule files, the Rete matching algorithm, and the practical use of the engine in a collection (催收) system.

Business background

In Vivo's wallet collection module, overdue cases are imported into a collection system where a series of rules determine the assignment of cases to different queues based on overdue days, risk assessment, cost, and expected return. The original approach required many if‑else statements, which are hard to maintain.

Why a rule engine?

A rule engine separates business decisions from application code, allowing business users to maintain and modify rules without developer involvement or application restarts.

Drools overview

Drools is a Business Rule Management System (BRMS) that provides a forward‑ and backward‑chaining inference engine. Core components include:

rule : a business rule with conditions ( when ) and actions ( then )

Fact : data inserted into the working memory

Production memory : stores the compiled rules

Working memory : stores facts

Pattern matcher : matches facts against rule patterns

Agenda : holds activated rules ready for execution

DRL (Drools Rule Language) syntax

package com.example.rules;
import com.example.FactClass;

rule "Assign to A Queue"
    salience 1
when
    $f : FactClass(overdueDays > a && overdueDays < b && overdueAmt < W)
then
    $f.setTaskQueue("A Queue");
end

Key sections of a DRL file are package , import , optional global , function , query , and one or more rule blocks.

Rule generation workflow

Parse a rule‑type XML that defines entity‑to‑class mappings and result definitions.

Read rule data from the database (decision table).

Combine the metadata with the XML to generate a complete DRL script.

Store the generated script back into the rule‑set table.

Example of the generation code (simplified):

public String generateDRLScript(DroolsRuleEditBO rule, DroolsRuleTableBO def) {
    StringBuilder drl = new StringBuilder("package " + rule.getRuleTypeCode() + ";\n\n");
    // import classes
    ruleSetDef.getEntitys().forEach(e -> drl.append("import "+e.getCls()+";\n"));
    // write each row as a rule
    rule.getTables().forEach(t -> t.getRows().forEach(r -> {
        drl.append("rule \""+rule.getRuleTypeCode()+"_"+t.getTableCode()+"_TR_"+r.getRowSort()+"\"\n");
        drl.append("\tsalience "+(++counter)+"\n");
        drl.append("\twhen\n");
        // conditions built from columns
        drl.append(...);
        drl.append("\tthen\n");
        // result scripts
        drl.append(...);
        drl.append("end\n\n");
    }));
    return drl.toString();
}

Rete matching algorithm

The Rete algorithm consists of a compilation phase (building a decision network from the rule base) and a runtime phase (propagating facts through the network). Nodes include:

Root node – entry point for facts.

Object‑type node – filters by class.

Alpha node – evaluates single‑field constraints.

Beta node – joins two streams of partial matches.

Terminal node – activates a rule when all conditions are satisfied.

During execution, facts are inserted into the working memory, travel through Alpha and Beta nodes, and finally reach the Terminal node where the rule is placed on the Agenda and fired according to priority.

Practical application in the collection system

The system uses a visual decision‑table UI for business users to define conditions and outcomes. The table rows are transformed into DRL rules, compiled, and executed by Drools. This approach reduces the need for developers to write or modify if‑else code for each rule change.

Current limitations

Simple rule generation works well, but complex logic still requires manual coding.

The project uses Drools 7.x but still relies on the older Knowledge API (5.x style).

New rules can only be added by initializing database tables; the UI cannot create brand‑new rule types.

Conclusion

Introducing Drools separates business logic from code, saves development effort, and enables non‑technical users to maintain rules via a structured decision table. Future work includes upgrading to the newer KIE API, improving the UI to support dynamic rule creation, and optimizing performance for large rule sets.

Javarule-engineBackend Developmentbusiness rulesDecision TabledroolsRete Algorithm
vivo Internet Technology
Written by

vivo Internet Technology

Sharing practical vivo Internet technology insights and salon events, plus the latest industry news and hot conferences.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.