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

In the previous year the author took over the activity middle‑platform of a company, where the "task" feature is essential for many user interactions such as ride‑hailing rewards, credit‑card sign‑up bonuses, and phone‑bill recharge incentives.

From a technical perspective each workflow can be abstracted as: when a user performs some action , the system should grant the corresponding reward . The original task system required code changes for every new business requirement, leading to a turnaround time of about one week for each new task.

Problem : When task completion conditions change (e.g., order amount threshold from 3000 to 5000), developers must modify the task service code, which is too slow for fast‑moving business needs.

Solution – Unified Message Format : The author standardized the upstream MQ message to a JSON structure:

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

Key fields: userid (user ID), business (business domain), behavior (specific action, e.g., pay_order_success ), behaviorTime (timestamp), and extraData (additional conditions such as trade amount or first‑time flag).

Example of a completed order message:

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

All downstream services now receive messages in this uniform format, simplifying integration.

Introducing a Rule Engine : To make task completion conditions configurable, the author adopted Alibaba's QLExpress engine. Business rules are expressed as scripts, for example:

tradeTotalMoney >= 300000 && firstTime == true

During task execution, the service extracts extraData into a Map and evaluates the script via:

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

This evaluates the expression against the provided context without needing additional network calls.

Configurable Conditions : With the rule engine in place, operations can modify task thresholds (e.g., change the required order amount) directly in the backend management UI, and the new rule takes effect immediately.

Further Extensibility : The author also abstracted task actions and conditions into metadata stored in a database, allowing new task types to be added by configuring metadata rather than writing code. The system flow diagram shows how the task service reads this metadata and evaluates the corresponding QLExpress script.

Conclusion : After refactoring with a unified message format and a rule‑engine‑driven, configurable task system, integrating a new task now takes about one minute of configuration instead of a week of development, dramatically improving efficiency and enabling faster business iteration.