Backend Development 11 min read

Liteflow Rule Engine: Concepts, Configuration, and Practical Usage in Java Backend Development

This article introduces the Liteflow lightweight rule engine for Java, explains its architecture, configuration, component types, EL rule file syntax, data context handling, and demonstrates a practical e‑commerce workflow, highlighting hot‑deployment and performance benefits for backend development.

Top Architect
Top Architect
Top Architect
Liteflow Rule Engine: Concepts, Configuration, and Practical Usage in Java Backend Development

1 Introduction

In daily development, serial or parallel business processes often lack correlation. Combining strategy and template patterns can solve this, but code proliferation becomes an issue. The article proposes using a rule engine from a global perspective, introducing Liteflow as the solution.

2 Liteflow Rule Engine

Liteflow is a lightweight yet powerful rule engine that works out‑of‑the‑box and can orchestrate complex rules quickly. Its overall architecture supports multiple rule file formats (XML, JSON, YAML) and various storage options (SQL, Zookeeper, Nacos, Apollo).

3 How to Use Liteflow

3.1 Components

Components correspond to nodes in rule files. Types include:

Ordinary Component : Implements NodeComponent , used in when and then logic; overrides process , iaAccess , isContinueOnError , isEnd .

Switch Component : Extends NodeSwitchComponent and implements processSwitch to decide the next node, similar to a Java switch .

Condition Component : Extends NodeIfComponent and overrides processIf to return true/false and select a node.

3.2 EL Rule Files

Rule files are usually written in XML. Examples of serial, parallel, nested, switch and condition compositions are shown.

THEN(a, b, c, d);
WHEN(a, b, c);
THEN( a, WHEN(b, c, d), e);
SWITCH(a).to(b, c, d);
THEN(IF(x, a), b );

3.3 Data Context

The data context carries parameters between nodes. Execution example:

LiteflowResponse response = flowExecutor.execute2Resp("chain1", initialParams, CustomContext.class);

3.4 Parameter Configuration

Configuration items include rule source path, retry count, execution logging, monitoring, request‑id generator, slot size, thread‑pool settings, hot‑deployment options, etc.

liteflow:
  ruleSource: liteflow/*.el.xml
  retry-count: 0
  print-execution-log: true
  monitor:
    enable-log: true
    period: 300000
  request-id-generator-class: com.platform.orderserver.config.AppRequestIdGenerator
  slot-size: 10240
  main-executor-works: 64
  when-max-wait-seconds: 15
  when-max-workers: 16
  when-queue-limit: 5120
  parse-on-start: true
  enable: true

4 Business Practice

A typical e‑commerce scenario is presented: after an order is completed, points are granted, a message is sent, and SMS and email are sent in parallel.

<flow>
    <chain name="test_flow">
        THEN(
            prepareTrade, grantScore, sendMq, WHEN(sendEmail, sendPhone)
        );
    </chain>
</flow>

Images illustrate the flow, data preprocessing, and node execution.

5 Summary

Most of Liteflow’s work—rule parsing, component registration, and assembly—is performed at startup, giving it high execution performance and detailed timing statistics. The article covered Liteflow’s core concepts and practical usage.

Javarule engineworkflowBackend DevelopmentSpring BootLiteFlow
Top Architect
Written by

Top Architect

Top Architect focuses on sharing practical architecture knowledge, covering enterprise, system, website, large‑scale distributed, and high‑availability architectures, plus architecture adjustments using internet technologies. We welcome idea‑driven, sharing‑oriented architects to exchange and learn together.

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.