Unlocking Complex Business Logic with LiteFlow’s Component‑Based Workflow Engine

Introduction

LiteFlow is a lightweight, fast, stable component‑based rule engine framework. Official sites: https://yomahub.com/liteflow, Gitee repository, GitHub repository.

Why Use LiteFlow?

In many systems, complex business logic becomes tangled, hard to maintain, and any small change can affect many modules. LiteFlow solves this by turning each business fragment into a component, allowing hot‑loading of rule configurations and real‑time workflow changes.

Design Principle – Workbench Model

Imagine several workers around a workbench, each producing a part without needing to know others' work. The workbench holds shared resources, enabling decoupling, stability, reusability, and dynamic re‑arrangement of workers. In LiteFlow, workers are components, the workbench is the context, and the assembled machine represents the business process.

Each component works independently.

Components can be reordered without changing their internal logic.

Components are reusable across different workflows.

Real‑time changes to the workflow are possible by inserting, removing, or replacing components.

Using LiteFlow – Non‑Spring Environment

Add the Maven dependency:

<dependency>
   <groupId>com.yomahub</groupId>
   <artifactId>liteflow-core</artifactId>
   <version>2.6.13</version>
</dependency>

Implement a business node by extending NodeComponent and overriding process. Place the XML rule file under resources, defining <nodes/> and <chain/> elements. Run the demo, modify the XML to change the execution order, and observe the updated results.

Using LiteFlow – SpringBoot Environment

Add the starter dependency:

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

Annotate component classes with @LiteflowComponent instead of declaring <node/> in XML. Configure the XML rule path in application.properties. The execution result matches the non‑Spring example.

Core Components

Parser – Parses rule files (XML, JSON, YAML) into Java objects (Node, Chain, Condition). Supports multiple file types and storage back‑ends (local, ZK, custom).

FlowBus – Stores parsed Nodes and Chains for later execution.

FlowExecutor – Executes a Chain by retrieving it from FlowBus, creating a Slot (shared context), and invoking pre, then, when, and finally conditions.

Slot – Holds the execution context shared across all components; a default implementation exists but custom implementations are recommended.

DataBus – Manages Slots during execution.

Parsing Process

The LocalXmlFlowParser reads each XML file, converts it to a DOM document, and extracts <node> definitions to build Node objects, then parses <chain> elements to create Condition objects (PreCondition, ThenCondition, WhenCondition, FinallyCondition) and assembles them into Chains.

Chain Execution Flow

FlowExecutor.execute2Resp

calls doExecute, which obtains a Slot, fetches the target Chain, and runs executePre, execute, and executeFinally. execute distinguishes ThenCondition (serial execution) from WhenCondition (parallel execution).

Node Execution

Each Node wraps a NodeComponent. Before execution, isAccess can skip the node. NodeExecutor (default DefaultNodeExecutor) runs the component’s process method, supporting retries and interceptors.

Conclusion

LiteFlow translates rule configurations into executable Java code, builds reusable Nodes and Chains, and runs them through a flexible executor, enabling developers to manage complex business workflows with minimal coupling.