Liteflow Rule Engine: Concepts, Usage, and Business Practice

1. Introduction

In daily development, serial or parallel business processes often lack direct correlation, making it difficult to manage them with traditional coding approaches. Combining strategy and template patterns can help, but the resulting codebase becomes fragmented. This article presents Liteflow, a rule engine that solves these problems from a global perspective.

2. Liteflow Rule Engine

Liteflow is a lightweight and powerful rule engine that can be used out‑of‑the‑box to compose complex rule flows quickly. It supports multiple rule file formats such as XML, JSON, and YAML, and can store rule files in SQL, Zookeeper, Nacos, Apollo, etc.

The overall architecture of Liteflow is shown below:

Liteflow operates by obtaining a data context, parsing the corresponding rule file, and executing the chain via the FlowExecutor. Each chain consists of business nodes that can be implemented in various scripting languages (Groovy, JavaScript, Python, Lua, etc.).

Official website: https://liteflow.yomahub.com

<dependency>
  <groupId>com.yomahub</groupId>
  <artifactId>liteflow-spring-boot-starter</artifactId>
  <version>2.10.6</version>
</dependency>

3. Usage

3.1 Components

Components correspond to nodes in rule files. There are three main component types:

Ordinary Component : Extend NodeComponent , implement the process method, and optionally override iaAccess , isContinueOnError , and isEnd .

Switch Component : Extend NodeSwitchComponent and implement processSwitch to decide which node to execute, similar to a Java switch .

Condition Component : Extend NodeIfComponent and override processIf to return a boolean result.

Example of a switch expression:

# flow rule expression for switch component
SWITCH(a).to(b, c);
# processSwitch must return "b" or "c"
# flow rule expression for condition component
IF(x, a, b);

3.2 EL Rule Files

Rule files are usually written in XML. The following snippets illustrate serial, parallel, nested, switch, and condition compositions:

# Serial composition
THEN(a, b, c, d);
# Parallel composition
WHEN(a, b, c);
# Nested serial and parallel
THEN(a, WHEN(b, c, d), e);
# Switch composition
SWITCH(a).to(b, c, d);
# Condition composition
THEN(IF(x, a), b);

3.3 Data Context

The data context carries parameters between nodes. Execution typically looks like this:

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

3.4 Parameter Configuration

Key configuration items include rule file location, retry count, thread pool settings for parallel nodes, request‑ID generator, and context slot size. Example YAML configuration:

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 demonstrated: after an order is completed, the system grants points, sends a message, and concurrently sends SMS and email. The corresponding XML rule file is:

<?xml version="1.0" encoding="UTF-8"?>
<flow>
  <chain name="test_flow">
    THEN(
      prepareTrade, grantScore, sendMq, WHEN(sendEmail, sendPhone)
    );
  </chain>
</flow>

Execution flow diagrams and screenshots illustrate how the context is prepared, how nodes are invoked, and how hot‑deployment allows rule changes to take effect instantly.

5. Summary

Liteflow performs most of its work during startup—parsing rules, registering components, and assembling metadata—resulting in high execution performance. The article covered Liteflow’s core concepts, component types, EL rule syntax, data context handling, configuration options, and a concrete e‑commerce use case.