Transform Complex Order Processing with LiteFlow’s Component‑Based Workflow Engine

Background

In logistics systems, order receiving is a critical information flow. Each business scenario (e.g., sales, procurement) has a standard order‑receiving process with unified interfaces, data models, and core responsibilities. Over time, evolving requirements, business integration, and organizational changes cause the process to become increasingly complex, with many departments, scenarios, personalization, switches, and extensions.

Problem

Waterfall‑style iteration leads to methods with thousands of lines, hard to read and maintain.

Personalized logic is scattered across many steps, making it difficult to organize.

When methods are linked, context styles vary, and lack of extensibility results in large later changes.

Idea

Strategy

The strategy is to adopt a "workbench" pattern: workers (components) produce tasks around a workbench (context) using resources (parameters). This decouples components, ensures stability, reusability, and keeps business processes flexible.

Tactics

Key tactical points around the workbench pattern include:

Component definition

Context

Execution rules

Component Definition

Components are the smallest executable units. Commonly used are ordinary components that execute upon invocation. In workflow rules, components can also be boolean, conditional, loop, parallel, or exception‑handling components, often implemented via code inside ordinary components, making the underlying logic invisible in the flow definition.

Two practical approaches for grouping logic into components:

If orders are already categorized into sub‑domains (e.g., shipping, receiving, carrier, product), define components per sub‑domain to achieve language uniformity.

Define components based on actions in the process (e.g., write‑to‑DB, dispatch to WMS, allocate).

Context

Each component defines a context that carries input and output parameters throughout the flow. Context should be:

Transferable

Shared

Dynamic

Components only interact with the part of the context relevant to them, reading and updating as needed, and the context can be extended during iterative development.

Execution Rules

Execution rules dictate how components are arranged and executed. Traditional implementations use XML, Spring injection, or explicit assembly into an execution chain, which often lack support for conditions, loops, or parallelism. Embedding rules in code makes them hard to discover. Abstracting execution rules into separate storage (e.g., database, Redis, Zookeeper) enables hot updates and better decoupling.

Solution

Through practice, the author discovered the open‑source component LiteFlow , which provides all the above capabilities.

LiteFlow converts waterfall‑style code into a component‑centric structure where components are decoupled, can be defined via scripts, and flow is driven by rules. Its DSL is simple, allowing a developer to get started in ten minutes.

Example

Flow rule (XML):

<?xml version="1.0" encoding="UTF-8"?>
<flow>
    <chain name="chain1">
        THEN(
            SWITCH(businessSwitch).TO(
                // small‑item sub‑flow
                THEN(smallChain).id("small"),
                // cold‑chain sub‑flow
                THEN(coldChain).id("cold")
            ),
            ITERATOR(goodsIterator).DO(goodsItem),
            SWITCH(kaSwitch).TO(dajiang, lining, nike).DEFAULT(defaultKa)
        );
    </chain>
    <chain name="smallChain">
        // parallel execution
        WHEN(commonDept, smallWarehouse);
    </chain>
    <chain name="coldChain">
        // parallel execution
        WHEN(commonDept, coldWarehouse);
    </chain>
</flow>

Project structure:

.
├── LiteFlowDemoApplication.java
└── demos
    └── web
        ├── BasicController.java
        ├── context
        │   └── OrderContext.java
        ├── dto
        │   ├── Dept.java
        │   ├── Goods.java
        │   ├── Request.java
        │   └── WareHouse.java
        ├── enums
        │   ├── BusinessEnum.java
        │   └── KaEnum.java
        └── node
            ├── BusinessSwitchCmp.java
            ├── ColdWarehouseCmp.java
            ├── CommonDeptCmp.java
            ├── GoodsItemCmp.java
            ├── GoodsIteratorCmp.java
            ├── KaSwitchCmp.java
            ├── SmallWarehouseCmp.java
            └── ka
                ├── DaJiangCmp.java
                ├── DefaultCmp.java
                ├── LiNingCmp.java
                └── NikeCmp.java

8 directories, 21 files

Business type switch component:

@LiteflowComponent("businessSwitch")
public class BusinessSwitchCmp extends NodeSwitchComponent {
    @Override
    public String processSwitch() throws Exception {
        Request request = this.getRequestData();
        if (Objects.equals(request.getDept().getDeptNo(), "dept1")) {
            return BusinessEnum.SMALL.getBusiness();
        } else {
            return BusinessEnum.COLD.getBusiness();
        }
    }
}

Iterator component:

@LiteflowComponent("goodsIterator")
public class GoodsIteratorCmp extends NodeIteratorComponent {
    @Override
    public Iterator<Goods> processIterator() throws Exception {
        Request requestData = this.getRequestData();
        return requestData.getGoodList().iterator();
    }
}

Loop item component (executed for each goods):

@Slf4j
@LiteflowComponent("goodsItem")
public class GoodsItemCmp extends NodeComponent {
    @Override
    public void process() throws Exception {
        log.info("goods item index = {}", this.getLoopIndex());
        // get current loop object
        Goods goods = this.getCurrLoopObj();
        // set current loop index as goodsId
        goods.setGoodsId(this.getLoopIndex());
        OrderContext orderContext = this.getContextBean(OrderContext.class);
        List<Goods> goodsList = orderContext.getData("goods");
        if (goodsList == null) {
            goodsList = new ArrayList<>();
            this.getContextBean(OrderContext.class).setData("goods", goodsList);
        }
        goodsList.add(goods);
    }
}

Features

Unified component definition: all logic is encapsulated as components.

Rule persistence: supports storing rules in databases, Nacos, Etcd, Zookeeper, Apollo, Redis, or custom extensions.

Context isolation: reliable isolation prevents data leakage under high concurrency.

Broad compatibility: works with Spring Boot, Spring, or any Java framework.

Lightweight rules: rule files drive the flow, lowering the learning curve.

Conclusion

LiteFlow is a powerful workflow rule framework. By analyzing the underlying problems and abstracting a solution, it demonstrates how thoughtful design and componentization can address complex order‑processing challenges, offering a reusable and extensible approach for developers.