From State Machines to a Custom Workflow Engine: Scaling Quality Inspection Processes

1 Introduction: Real‑world Need for Process Orchestration

1.1 What is a quality inspection system?

A quality inspection system validates mobile phones, 3C digital goods, etc., through a comprehensive process that produces inspection reports, addressing trust issues in transactions and providing reliable evidence for warranty and after‑sale handling.

1.2 Challenges of increasingly complex inspection processes

Different product categories require different inspection nodes

Different sites have inconsistent process branches

New business models cause frequent adjustments to inspection chains

For example, a C2B flow may be "receive → inspect → shelf‑review", while a B2C flow could be "input → inspect → photo → shelf‑review".

Traditional control methods cannot support such frequent changes, prompting a shift toward configuration‑driven, visual, and quickly adaptable architectures.

2 Phase 1: Process Control with Finite State Machine

In the early stage, we adopted a Finite State Machine (FSM) to drive the entire process, a natural choice that satisfied basic control logic, bound well with business events, and kept implementation costs manageable.

2.1 Why choose a state machine

Initial inspection workflow was simple: "input → inspect → sampling → shelf‑review". Each step had clear start and end conditions, making it ideal for state‑machine modeling, where each task becomes a "process instance" and each stage is represented by a "state".

2.2 State machine model design

Core concepts include:

State : represents the current stage, e.g., 已录入, 已质检, 已抽检, 已上架审核.

Event : external triggers such as 录入完成, 质检完成, 上架审核完成.

Transition : flow logic determined by state plus event.

Action : business logic executed during state changes, like updating databases or pushing messages.

2.3 Example state transition (simplified)

We maintain a set of state definitions for each inspection task, driving the business flow via a state diagram.

2.4 Implementation

We built a lightweight state‑machine framework based on cola-component-statemachine. Development steps are:

Configure state enums and transition rules.

Register state‑transition listeners and bind handling logic.

Trigger transitions with fireEvent.

Persist state changes for traceability.

Example code:

stateMachine.fireEvent(context.getProcessState(), context.getEvent(), context);

2.5 Advantages

Clear process : transition rules are explicit, easy to understand and maintain. Stable execution : event‑driven logic naturally supports asynchronous handling and retries. High development efficiency : new flows can be launched by merely configuring states and events. Convenient state management : supports execution tracing for debugging.

2.6 Challenges

As business complexity grew, the state‑machine model exposed several issues:

1) Weak branching capability, messy control

Some nodes need conditional branches (e.g., whether to sample), which state machines handle poorly.

We introduced a "flow unit" concept to calculate the next node, adding extra complexity.

The coexistence of flow units and state machines confused maintainers about which mechanism to use, leading to chaotic control.

2) Poor parallel support

Inspection business often requires parallel task handling.

The linear nature of state machines lacks native parallel nodes, synchronization, and convergence.

Implementing concurrency required extra intermediate states and asynchronous logic, increasing code complexity.

3) Operations cannot control flow independently

All flow changes required developer involvement.

Product teams could not visually configure processes, severely limiting flexibility.

2.7 Summary

The state machine helped us pass the early "controllable but fixed" stage and laid a solid foundation for stable operation, but it struggled with rising complexity and frequent business adjustments.

Is there a more flexible, configurable, business‑friendly way to control processes?

3 Phase 2: Exploring Workflow Engines

Increasing complexity exposed the limitations of the state‑machine approach, prompting us to evaluate mature workflow engines that natively support conditional branching, parallel execution, task assignment, and traceability.

3.1 Comparison of mainstream engines

We evaluated Flowable, Camunda, Activiti, Zeebe, and Netflix Conductor, considering modeling support, integration difficulty, performance, micro‑service compatibility, learning cost, and customizability.

3.2 Engines meet basic needs but migration and performance issues stand out

High migration cost : Re‑modeling existing flows and adapting task systems would be labor‑intensive.

Poor performance : Engines struggled with high‑concurrency task execution and event response.

Black‑box nature : Debugging and extending complex business rules proved difficult.

3.3 Final decision: Build a custom workflow‑oriented engine

Although open‑source engines were functionally sufficient, they did not fit our specific needs. We decided to combine core ideas from mature engines (BPMN modeling, execution control) with our own requirements for granular control, flexible node configuration, and custom extensions, resulting in a lightweight self‑developed workflow engine.

4 Phase 3: Custom Workflow Engine

4.1 Core design goals

Lightweight and controllable : Simple architecture that integrates seamlessly with existing systems.

Full parallel and branching support : Native handling of conditional branches and concurrent execution.

Visual configuration : Web UI for process setup, lowering the barrier for product and operations teams.

Business‑friendly : Configuration more intuitive than BPMN, aligning with business semantics.

Simple model, efficient execution : Only five core tables, minimal code footprint, fast state switching under high concurrency.

4.2 Core module design

The engine is divided into three main modules:

4.2.1 Process modeling module

Key concepts:

Node template : Defines the business semantics and reusable execution logic of a node (e.g., inspection, sampling, photo).

Node : Instance of a template with line‑specific configuration.

Node configuration : Rules such as execution conditions, parameters, and validation attached to a node.

Connection line : Describes reachable transitions and conditions between nodes.

Transition rule : Determines whether the flow proceeds to the next node, similar to BPMN sequence‑flow expressions.

Gateway : Handles branching, merging, and parallel logic, integrated directly into node configuration.

Line : The complete process model composed of nodes and connections.

Job order : Records basic inspection information and the current position within a line.

Job task order : Core control unit generated when a flow enters a node, driving execution and recording results.

Concept diagram:

4.2.2 Engine scheduler

Four steps to schedule a flow:

Query the current job order from storage.

Load node and connection definitions based on the associated line.

Calculate the next executable node using a rule engine (supports branching and parallelism).

Create a job task order for the target node, serving as the core control unit for subsequent execution.

4.2.3 Node executor mechanism

Five steps to execute a node:

Enter node execution and start the associated job flow.

Load detailed node configuration and execution rules.

Execute the inspection, photo, or judgment tasks driven by the configured rules.

Mark the job task as completed and record the outcome.

Asynchronously trigger the scheduler (via events or message queues) to compute and run the next node.

5 Evolution Effects and Practice

5.1 Node configuration

The visual configuration page for a single node allows operations and product teams to adjust execution logic, inspection rules, and parameters without code changes, supporting line‑specific variations and providing a clear, editable view of the process.

5.2 Line configuration (simplified)

The full inspection workflow is presented as a drag‑and‑drop diagram, enabling intuitive adjustments of node order, branching conditions, and parallel paths, thus achieving "what you see is what you get" configuration.

6 Future Outlook

The custom engine now reliably supports the entire quality‑inspection lifecycle. Upcoming work includes smooth migration of legacy flows, unified scheduling for old and new processes, and introducing low‑code capabilities with richer visual configuration and extension interfaces to further improve agility.