Introducing LiteFlow: A Lightweight Rule Engine for Complex Workflow Orchestration

1. LiteFlow Rule Engine

liteflow

is a lightweight yet powerful rule engine that can be used out‑of‑the‑box to compose complex workflow logic quickly. It supports multiple rule file formats such as XML, JSON, and YAML, and rule storage can be backed by SQL, Zookeeper, Nacos, Apollo, etc.

The engine starts by obtaining a data context, parsing the corresponding rule file, and then executing a chain where each node represents a business component that can run scripts in Groovy, JavaScript, Python, Lua, and other languages.

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

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

2. How to Use LiteFlow

2.1 Components

Components correspond to nodes in the rule file. The main types are:

Ordinary Component : Implement NodeComponent, used in when and then logic. Override process for business logic, iaAccess to decide entry, isContinueOnError for error handling, and isEnd to terminate the flow.

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

Condition Component : Extends NodeIfComponent and overrides processIf to return a boolean and choose the subsequent node.

2.2 EL Rule Files

Rule files are usually written in XML. Example snippets illustrate serial ( THEN), parallel ( WHEN), nested, switch, and conditional compositions:

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

2.3 Data Context

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

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

Usually the first node stores incoming parameters into the context for downstream nodes.

2.4 Parameter Configuration

Configuration items include rule file locations, retry counts, thread‑pool settings for parallel execution, request‑ID generator, and context slot size. A typical YAML snippet:

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

3. Business Practice

A typical e‑commerce scenario is shown where, after an order is completed, the flow grants points, sends a message, and concurrently sends an email and a SMS:

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

Before processing, the input parameters are transformed into a context object, and each business step is implemented as a node component that can optionally override isAccess to decide whether to execute.

4. Summary

Most of LiteFlow's work—rule parsing, component registration, and assembly—is performed at startup, giving it high execution performance. It can also log the duration and statistics of each business step, making it suitable for high‑throughput backend services.