How to Refactor a Task System with SpringBoot, RocketMQ, and QLExpress for Rapid Business Integration

Preface

The author inherited an activity middle‑platform where tasks are essential, such as rewarding users for completing a ride order or applying for credit. Technically, each flow can be abstracted as a user performing some action and receiving the corresponding reward.

The task system must handle many business‑specific tasks with varying completion conditions, e.g., an e‑commerce order over 3000 CNY, an app download with 10 seconds of usage, or a phone‑bill recharge over 50 CNY.

Pain Point and Solution

Every change in task completion criteria currently requires a week of code changes, which is too slow for business growth. The solution is to make task conditions configurable via a backend management system.

1. Unified Message Format

Business services send messages through RocketMQ. To avoid custom adapters for each JSON format, a standard message schema is defined:

{
  "userid": "",
  "business": "",
  "behavior": "",
  "behaviorTime": "",
  "extraData": {}
}

The extraData field holds task‑specific attributes, such as order amount and first‑time flag.

Example of a completed order message:

{
  "userid": "12345",
  "business": "onlineShop",
  "behavior": "pay_order_success",
  "behaviorTime": "timestamp",
  "extraData": {
    "tradeTotalMoney": 500000,
    "firstTime": true
  }
}

After standardizing messages, the next step is to make the completion conditions configurable.

2. Configurable Completion Conditions

Operations should be able to define task rules in a management UI. The author chooses Alibaba's QLExpress as the rule‑engine solution.

QLExpress repository: https://github.com/alibaba/QLExpress

A rule can be expressed as a script, for example: tradeTotalMoney >= 300000 && firstTime == true During task evaluation, the system extracts extraData into a Map and passes it to QLExpress:

Object r = runner.execute(express, context, null, true, false);

The engine replaces map keys with actual values and evaluates the expression.

3. Configurable Backend Actions

Beyond conditions, the actual task actions (e.g., "add to cart") also need to be configurable. The backend reads metadata from a database, allowing new actions to be added without code changes.

System architecture diagram:

Conclusion

After refactoring with a rule engine, adding a new task now only requires a one‑minute backend metadata configuration, eliminating the previous week‑long development cycle and significantly improving efficiency.