State Machine Design and Implementation for Marketing Automation Activities

The article introduces the business background of a marketing automation platform that supports multiple activity types (SMS, WeChat, App Push). Each activity follows a series of status transitions such as "Not Started → Data Preparing → Data Ready → Pushing → Finished".

To manage these complex state flows, the authors propose using a Finite State Machine (FSM), a well‑known theoretical model that consists of events, states, and actions.

1. Understanding the FSM

An FSM defines a finite set of states, transitions triggered by external events, and optional actions executed after a transition. The article explains the basic concepts and shows a diagram of the FSM components.

2. Implementation approaches

Three typical implementation methods are described:

Conditional branching (if‑else / switch)

State pattern (encapsulating behavior in state classes)

Domain‑Specific Language (DSL) – either internal (fluent API) or external (XML/JSON)

Code examples for each method are provided.

/** * SMS activity state enumeration */ public enum ActivityState { NOT_START(0), // activity not started DATA_PREPARING(1), // data preparing DATA_PREPARED(2), // data ready DATA_PUSHING(3), // pushing FINISHED(4); // finished } /** * SMS activity state machine */ public class ActivityStateMachine { private ActivityState currentState; public ActivityStateMachine() { this.currentState = ActivityState.NOT_START; } public void begin() { if (currentState.equals(ActivityState.NOT_START)) { this.currentState = ActivityState.DATA_PREPARING; notice(); } } public void finishCalData() { if (currentState.equals(ActivityState.DATA_PREPARING)) { this.currentState = ActivityState.DATA_PREPARED; notice(); } } // other transition methods omitted for brevity }

For the state‑pattern implementation, the article defines an IActivityState interface and concrete state classes such as ActivityNotStartState , each encapsulating the behavior for a specific state.

interface IActivityState { ActivityState getName(); void begin(); void finishCalData(); void beginPushData(); void finishPushData(); } public class ActivityNotStartState implements IActivityState { private ActivityStateMachine stateMachine; public ActivityNotStartState(ActivityStateMachine sm) { this.stateMachine = sm; } @Override public ActivityState getName() { return ActivityState.NOT_START; } @Override public void begin() { stateMachine.setCurrentState(new ActivityDataPreparingState(stateMachine)); notice(); } // other methods omitted }

3. DSL‑based implementations

The article shows how an internal Java DSL can be built with a fluent builder, and how an external XML DSL can describe states and transitions.

StateMachineBuilder builder = new StateMachineBuilder(); builder.sourceState(States.STATE1) .targetState(States.STATE2) .event(Events.EVENT1) .action(action1());

<state id="STATE1"> <transition event="EVENT1" target="STATE2"> <action method="action1()"/> </transition> </state>

4. Open‑source FSM frameworks

The authors compare three Java FSM frameworks:

Spring Statemachine – feature‑rich, Spring‑integrated, but heavyweight and not thread‑safe when used as a singleton.

Squirrel Foundation – lightweight, no Spring dependency, easy to use.

Cola Statemachine (part of Alibaba COLA) – stateless design, high performance, but lacks advanced features like nested or parallel states.

Sample configuration code for each framework is included in the article.

5. Practical case in Vivo’s marketing automation

The article describes how Vivo applied a stateless, high‑performance DSL‑based FSM to handle SMS push activities, emphasizing fast configuration, asynchronous post‑actions, and a clear core workflow.

Key steps of the core workflow are listed, accompanied by a diagram.

6. Reflections and future work

The authors suggest visual DSL configuration (e.g., JSON stored in a database) and extending the FSM to support more complex scenarios.

7. Conclusion

State machines, composed of events, states, and actions, provide a systematic way to manage system state, improve extensibility, and reduce coupling. Choosing the right implementation (conditional, state pattern, or DSL) and the appropriate open‑source framework depends on business complexity and performance requirements.