Introduction to LiteFlow Rule Engine and Its Usage in Java Spring Boot

In daily development, developers often encounter serial or parallel business processes that are unrelated, leading to scattered code when using strategy and template patterns; a global rule engine like LiteFlow can address this by centralizing workflow orchestration.

LiteFlow is a lightweight but powerful rule engine that works out‑of‑the‑box, allowing complex rule orchestration to be built quickly. It supports multiple rule file formats (XML, JSON, YAML) and storage options such as SQL, Zookeeper, Nacos, or Apollo. The overall architecture is shown in the accompanying diagram.

Using LiteFlow starts with obtaining a data context, parsing the appropriate rule file, and executing a chain via the LiteFlow executor; each chain consists of independent business nodes that can run scripts written in Groovy, JavaScript, Python, Lua, etc. The official site and Maven dependency are:

# liteflow rule engine official site
https://liteflow.yomahub.com
# Spring Boot integration
<dependency>
    <groupId>com.yomahub</groupId>
    <artifactId>liteflow-spring-boot-starter</artifactId>
    <version>2.10.6</version>
</dependency>

LiteFlow can orchestrate complex flows, as illustrated in the diagram, and also supports hot deployment, allowing nodes to be added or replaced in real time after rule files are modified.

Components

Ordinary components extend NodeComponent and are used in when and then logic; they implement process, can override iaAccess to control entry, isContinueOnError to decide error handling, and isEnd to terminate the flow.

Selection components inherit from NodeSwitchComponent and implement processSwitch to choose the next node, similar to a Java switch statement.

# flow rule expression – selection component
SWITCH(a).to(b, c);
# processSwitch must return "b" or "c" to trigger the corresponding logic
# flow rule expression – condition component
IF(x, a, b);

Condition components extend NodeIfComponent and override processIf to return a boolean result, directing the flow accordingly.

The official documentation also mentions loop components, but for most scenarios the simple ordinary component suffices.

EL Rule Files

Rule files are typically written in XML; the following examples show how to express serial, parallel, nested, selection, and condition flows.

# file orchestration – THEN for serial, WHEN for parallel
# serial example
THEN(a, b, c, d);
# parallel example
WHEN(a, b, c);
# nested serial and parallel
THEN( a, WHEN(b, c, d), e);
# selection example
SWITCH(a).to(b, c, d);
# condition example
THEN(IF(x, a), b );

Data Context

The data context is crucial for passing parameters between nodes. An example of executing a flow with a custom context class is:

# Execute flow with EL file, initial parameters, and custom context
LiteflowResponse response = flowExecutor.execute2Resp("chain1", flowInitialParams, CustomContext.class);

Typically, the first node populates the context with input parameters for downstream nodes.

Parameter Configuration

liteflow:
  # rule files, retry count, logging, monitoring
  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
  # maximum number of context slots
  slot-size : 10240
  # thread pool size (default 64)
  main-executor-works: 64
  # async thread max wait seconds
  when-max-wait-seconds: 15
  # global async thread pool for WHEN nodes
  when-max-workers: 16
  when-queue-limit: 5120
  # parse rules on startup
  parse-on-start: true
  enable: true

Business Practice

In an e‑commerce scenario, after an order is completed, points are granted, messages are sent, and SMS and email are dispatched in parallel. The flow is defined as:

# e‑commerce example: grant points, send MQ, parallel email and phone notifications
<?xml version="1.0" encoding="UTF-8"?>
<flow>
    <chain name="test_flow">
        THEN(
            prepareTrade, grantScore, sendMq, WHEN(sendEmail, sendPhone)
        );
    </chain>
</flow>

Before processing, input parameters are converted into a context object for easy propagation. Nodes such as the points‑granting component can override isAccess to decide whether to execute.

Overall, most of LiteFlow’s work—rule parsing, component registration, and assembly—occurs at startup, resulting in high execution performance and detailed timing and statistics logging. The source code is available on GitHub at https://github.com/thedestiny/springboot-auth/tree/main/order-server.