Unlocking Liteflow: Build Fast, Flexible Rule Engines for Java Backends

1 Introduction

In everyday development, serial or parallel business processes often arise without direct correlation, and traditional strategy or template patterns can lead to an explosion of files. Introducing a rule engine from a global perspective—Liteflow—offers a concise solution.

2 Liteflow Rule Engine

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

Using Liteflow starts with obtaining a data context, parsing the corresponding rule files, and executing them via the Liteflow executor. Each chain consists of business nodes (components) that can run scripts written in Groovy, JavaScript, Python, Lua, etc.

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

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

Liteflow can handle complex flows such as the example below:

It also supports hot deployment, allowing rule files to be modified and take effect in real time.

3 Usage Methods

3.1 Components

Components correspond to nodes defined in rule files. Types include:

Ordinary Component : Implement NodeComponent, used in when and then logic. Override isAccess to control execution, isContinueOnError for error handling, and isEnd to terminate the flow.

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

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

# flow rule expression for selection 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 typically written in XML. Examples of serial and parallel composition:

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

3.3 Data Context

The data context is crucial for passing parameters between nodes. It can be set in the first node and accessed throughout the flow.

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

3.4 Parameter Configuration

Typical configuration (application.yml) includes rule file locations, retry counts, thread pool settings, and request‑ID generation.

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, points are awarded, messages are sent, and SMS and email are dispatched in parallel.

<?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 data context for easy propagation. Nodes can override isAccess to decide whether to execute specific business logic.

5 Summary

Most of Liteflow’s work—rule parsing, component registration, and assembly—is performed at startup, resulting in high execution performance and the ability to log each business step’s duration and statistics. This article covered Liteflow’s core concepts and demonstrated its practical usage.