Refactoring a Task System with a Unified Message Format and Configurable Rules

Background

The activity middle‑platform required a generic "task" feature: when a user performs a specific action, the system should issue a corresponding reward. Different business lines (e‑commerce, app‑download, telecom) each defined their own task completion conditions, causing developers to modify the task service code for every new or changed task (often taking a week).

Unified Message Format

All upstream services were required to publish messages to RocketMQ using a standardized JSON schema:

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

userid : user identifier

business : business domain (e.g., "onlineShop")

behavior : specific action name (e.g., "pay_order_success")

behaviorTime : timestamp of the action

extraData : map of additional attributes required for condition evaluation (e.g., trade amount, first‑time flag)

Example of a completed order message:

{
  "userid": "12345",
  "business": "onlineShop",
  "behavior": "pay_order_success",
  "behaviorTime": "2023-07-01T12:34:56Z",
  "extraData": {
    "tradeTotalMoney": 500000,
    "firstTime": true
  }
}

Configurable Completion Conditions via Rule Engine

To avoid hard‑coding condition logic, the Alibaba QLExpress rule engine was introduced. Completion conditions are expressed as scripts, for example: tradeTotalMoney >= 300000 && firstTime == true During task evaluation, the service extracts extraData into a Map and passes it as the context to QLExpress:

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

QLExpress evaluates the script against the context and returns a boolean indicating whether the reward should be issued.

Implementation Steps

Standardize incoming MQ messages across all business lines.

Integrate QLExpress and replace hard‑coded condition checks with script evaluation.

Build a lightweight admin UI that stores rule scripts and condition metadata in a database, allowing operators to modify them without code changes.

System interaction flow after refactor:

Result

After adopting the rule engine and unified message format, adding a new task now only requires a one‑minute configuration of metadata and a script in the admin console, reducing integration time from a week to minutes and significantly improving development efficiency. The rule‑engine capability was also reused for other internal systems.

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