Why This Lightweight Rule Engine Lets You Ditch If‑Else Statements

1 Introduction

In many projects developers face serial or parallel business flows that are unrelated to each other. Combining strategy and template patterns can solve the problem, but hard‑coded implementations lead to a proliferation of files and obscure the overall logic. The article proposes using a rule engine—liteflow—to address this from a global perspective.

2 liteflow Rule Engine Overview

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

liteflow operates by obtaining a data context, parsing the corresponding rule file, and executing a chain where each node represents an independent business component. Nodes can run scripts 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>

3 How to Use liteflow

3.1 Components

Components correspond to nodes in rule files. Types include:

Ordinary Component – implements NodeComponent, used in when and then logic. Developers override process for business logic, iaAccess to decide entry, isContinueOnError to continue on failure (default false), and isEnd to terminate the flow (default true).

Switch Component – similar to Java switch, extends NodeSwitchComponent and implements processSwitch to return the target node name.

Condition Component – the “if” component, extends NodeIfComponent and overrides processIf to return a boolean‑based node name.

# 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 written in XML (or JSON/YAML). The DSL uses THEN for serial execution, WHEN for parallel execution, and supports nesting.

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

3.3 Data Context

The data context carries parameters between nodes because each business step may require different inputs and outputs.

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

The context class is passed to the first node, where parameters are stored for later nodes.

3.4 Parameter Configuration

Configuration items include rule file location, retry count, thread‑pool settings for parallel nodes, request‑ID generator, and context slot size.

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

The article demonstrates an e‑commerce scenario: after an order is completed, the system awards points, sends a message, and concurrently sends SMS and email.

<flow>
  <chain name="test_flow">
    THEN(
      prepareTrade, grantScore, sendMq, WHEN(sendEmail, sendPhone)
    );
  </chain>
</flow>

Before processing, input parameters are transformed into a custom context object for easy propagation. In the points‑granting node, developers can override isAccess to decide whether the node should run.

5 Summary

Most of liteflow’s work—rule parsing, component registration, and assembly—occurs at startup, giving it high execution performance. It can also log the duration of each business step and provide statistics. The article covered liteflow’s core concepts and detailed usage steps.