Transforming Task Systems: Configurable Completion Rules with QLExpress

Hello everyone, I am your friend Architect Jun, a architect who writes code and poetry.

Preface

The author took over the company's activity middle‑platform last year, where tasks are an essential gameplay element.

Everyone has experienced various tasks in internet activities, such as:

Completing a ride‑hailing order to award a prize.

Applying for a credit line to receive JD beans.

Technically, these processes can be abstracted as: when a user completes a specific action, the system grants a corresponding reward.

The task system often integrates N upstream business tasks, each with different completion conditions, for example:

E‑commerce: User pays an order over 3000 CNY → order task completed.

Commercial: User downloads an app and stays for 10 seconds → app download task completed.

Life services: User recharges phone credit over 50 CNY → phone recharge task completed.

The workflow is illustrated in the diagram below:

Business sides notify the task system via RocketMQ.

Pain Point Solution – Avoid Code Changes for New Tasks

Whenever a task's completion condition changes, the task system currently requires code modifications, taking about a week to integrate a new task.

For example, if the e‑commerce order task changes from “order amount ≥ 3000 CNY” to “order amount ≥ 5000 CNY”, the system must adjust code each time, which is far too slow for business growth.

The action point is to make task completion conditions configurable , allowing operations to adjust them in a backend management console.

1. Unified Message Format

Analyzing the process, a task can be abstracted as: for a given behavior, determine whether the behavior meets the configurable conditions.

However, each business currently sends JSON messages with inconsistent structures, leading to a lot of custom adapter code. The solution is to enforce a standard message format:

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

Field meanings: userid – user ID; business – business domain; behavior – specific task action (e.g., pay_order_success, app_download, tel_recharge); behaviorTime – timestamp of the action; extraData – additional conditions such as order amount or first‑time flag.

Example message for a completed order:

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

All downstream tasks must now send messages adhering to this format.

2. Configurable Completion Conditions

To let operations manage task conditions, a simple backend UI prototype is designed (see diagram).

The best practice for such configurable rules is to use a rule engine. The author chose Alibaba's QLExpress and refactored the system accordingly.

QLExpress is a dynamic script engine designed for e‑commerce rule expressions, Boolean combinations, high‑precision calculations, and custom scripting.

After integrating the rule engine, task completion logic becomes a script, e.g.: tradeTotalMoney >= 300000 && firstTime == true During execution, the system extracts extraData into a Map and passes it to QLExpress:

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

The execution essentially evaluates the expression: 500000 >= 300000 && true == true System flow diagram:

Now, if operations want to change the order amount condition from 5000 to 3000, they simply update the configuration in the backend, no code changes required.

3. Configurable Backend Conditions

Even adding new task behaviors (e.g., “add to cart”) still requires backend development. To fully eliminate code changes, the next step is to make both task behaviors and their conditions configurable, with the backend dynamically reading configurations from a database.

This abstracts the rule‑engine functionality into a dedicated system that manages rule definitions.

Conclusion

After refactoring with a rule engine, integrating a new task now only requires a one‑minute metadata configuration in the backend, vastly improving efficiency compared to the previous week‑long integration process.

The author achieved strong performance metrics and extended the rule‑engine capability to other systems, truly enabling development‑driven business.