Mastering LiteFlow: A Lightweight Rule Engine for Complex Business Workflows

1. Introduction

In everyday development, serial or parallel business processes often lack clear correlation, making them hard to manage with traditional strategy or template patterns. A rule engine can solve this problem from a global perspective, and LiteFlow is the lightweight engine introduced here.

2. LiteFlow Rule Engine Overview

LiteFlow is a compact and powerful rule engine that works out‑of‑the‑box, allowing complex rule orchestration to be built 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.

Typical Maven dependency:

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

LiteFlow can handle complex flows, as shown in the diagram below:

3. Core Components

Ordinary Component – Implement NodeComponent, used in when and then logic. Business logic is placed in the process method, and you can override iaAccess, isContinueOnError, and isEnd to control execution.

Switch Component – Extends NodeSwitchComponent and overrides processSwitch to decide which node to execute, similar to a Java switch.

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

Condition Component – Extends NodeIfComponent and overrides processIf to return a boolean result.

4. EL Rule Files

Rule files are written in EL syntax. Examples:

# 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);
# Conditional composition
THEN(IF(x, a), b);

5. 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 converts input parameters into a context object for downstream nodes.

6. 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
  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

7. Business Practice Example

In an e‑commerce scenario, after an order is completed, the system awards points, sends messages, and concurrently sends SMS and email. The flow is defined as:

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

Before processing business logic, the input parameters are transformed into a context object for easy propagation.

During the points‑granting node, the context is accessed, and the isAccess method can be overridden to decide whether the node should execute.

8. Summary

Most of LiteFlow’s work—rule parsing, component registration, and assembly—is performed at startup, giving it high execution performance. It can log each business step’s duration and statistics. This article introduced LiteFlow’s core concepts and demonstrated how to use it in real projects.