Liteflow Rule Engine: Concepts, Usage, and Business Practice

1. Introduction

In daily development, serial or parallel business processes often lack direct correlation. Combining strategy and template patterns can solve this, but writing many files makes the logic hard to grasp. Introducing a rule engine from a global perspective helps, and the main subject of this article is liteflow .

2. Liteflow Rule Engine

liteflow is a lightweight yet powerful rule engine that works out‑of‑the‑box and can compose complex rules quickly. It supports multiple rule file formats (XML, JSON, YAML) and various storage back‑ends such as SQL, ZK, Nacos, Apollo.

The official website is https://liteflow.yomahub.com . Add the following Maven dependency to use it:

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

liteflow can orchestrate complex flows, including parallel execution and hot‑deployment, allowing rule files to be updated in real time.

3. Usage of Liteflow

3.1 Components

Components correspond to nodes in rule files. Types include:

Ordinary Component : Implement NodeComponent , used in when and then logic. Override iaAccess , isContinueOnError , and isEnd as needed.

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

If Component : Extend NodeIfComponent and override processIf to return true/false and choose a branch.

3.2 EL Rule Files

Rule files are usually written in XML. Example snippets:

# serial composition
THEN(a, b, c, d);
# parallel composition
WHEN(a, b, c);
# nested composition
THEN(a, WHEN(b, c, d), e);
# switch composition
SWITCH(a).to(b, c, d);
# conditional composition
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);

Parameters are usually set in the first node and then accessed throughout the flow.

3.4 Parameter Configuration

Typical liteflow configuration (application.yml) includes rule source location, retry count, logging options, monitoring, request‑id generator, slot size, thread pool settings, and hot‑deployment flags:

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: after an order is completed, the system grants points, sends messages, and concurrently sends SMS and email. The flow definition looks like:

<?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 transformed into a context object for easy propagation.

5. Summary

Most of Liteflow’s work is done at startup: rule parsing, component registration, and assembly, resulting in high execution performance. It can log each node’s execution time and statistics. This article covered Liteflow’s core concepts and practical usage.

Note: The latter part of the original source contains promotional content for ChatGPT services, private groups, and paid courses, which is not related to the technical tutorial.