Customer DingTalk Group Message Push: An End-to-End Integration Plan from Strategy Anomaly to Group Alert

What This Strategy Solves (Scenario and Value)

When an integration platform runs more than a dozen business sync strategies, one of them may fail at 2 a.m. because the target system's token has expired, and the operations team only finds out the next morning in the group chat — this kind of "8 hours too late" story is not uncommon in the projects we've worked on.

The "Customer DingTalk Group Message Push" strategy is designed exactly for this scenario: it periodically pulls strategy execution errors and skip records inside the platform, and pushes them to the customer's DingTalk group bot to achieve near-real-time anomaly alerts. It belongs to the "monitoring and alerting integration" category. Data flows inside Qeasy (Qingyiyun Data Integration Platform) and does not involve data persistence in external business systems.

Data Flow and Field Mapping (Source → Intermediate → Target)

The whole pipeline is relatively straightforward: Qeasy Integration Platform (StrategyErrorDetail) → Qeasy intermediate mapping layer → Qeasy Integration Platform (DingTalkRobotDetail → DingTalk group bot Webhook). The source side pulls strategy execution records in the "error (3)" or "skip scheduling (6)" status within a recent time window, and the target side assembles these records into DingTalk bot messages.

The only thing to watch out for is the nested property lessee.name: on the source side, lessee is an object, not a flat string field. The Qeasy platform usually supports the {{parent.child}} syntax for accessing nested fields, so just writing {{lessee.name}} works — but this is where newcomers tend to stumble on first-time configuration.

How to Configure on Qeasy (Typical Configuration Points)

Source Side (Source / StrategyErrorDetail)

• API: StrategyErrorDetail
• Type: WebAPI, POST, QUERY
• Key inputs: recentSeconds=600 (query the last 10 minutes), ids limits the strategy IDs to monitor, status=3,6 filters error and skip-scheduled records
• Business key: {{response_at}}{{number}}{{strategy_id}} for idempotent deduplication

Target Side (Target / DingTalkRobotDetail)

• API: DingTalkRobotDetail
• Type: WebAPI, POST, EXECUTE
• Key inputs: access_token (DingTalk bot Webhook token), name, problem, solution, response_at, etc.
• Authentication: In production, access_token should be injected via secret management or environment variables — do not hardcode it in the strategy configuration.

We have seen a classic pitfall: one customer hardcoded the access_token in the configuration file's value field. Later when the bot secret was rotated, operations had to edit each strategy one by one and re-publish them. Configurations like this must always go through the secret management capability provided by the platform.

Implementation Steps (Phased Scheduling)

Phase 1: Incremental Starting Point On first go-live, set recentSeconds to a slightly larger value (e.g., 3600 seconds) to confirm that the source side can pull historical anomaly records and the target side can correctly push to the group bot. After verification, shrink the window back to 600 seconds and enter near-real-time incremental mode.

Phase 2: Scheduling Frequency Configuration The source crontab is set to 1-59/10 * * * * (triggered at minutes 1, 11, 21…59 of every hour), and the target crontab is set to 5-59/10 * * * * (triggered at minutes 5, 15, 25…55). The target side is 4 minutes behind the source side, so the source can pull data into the intermediate layer first and the target can then read and push it. If both sides run at the same time, the source may not have finished pulling before the target reads, resulting in empty results.

Phase 3: Converging the ids Range The source ids field takes a comma-separated list of strategy IDs that need to be monitored. The Qeasy platform only returns data for "enabled" strategies, so strategies in the list must be in the enabled state. We recommend that customers manage strategies by business domain groups (e.g., "Material Sync Group", "Order Sync Group") so that when problems occur, troubleshooting can be done by group.

Phase 4: Full Trigger and Alert Drill After go-live, perform a manual trigger to simulate an error record and verify whether the DingTalk group receives messages correctly, whether the fields are aligned, and whether there is any truncation or garbled text. This step is mandatory before delivery.

Pitfall Recap (Field Experience)

1. Wrong nesting level on nested fields: The source lessee is an object, and the target needs lessee.name. If you write {{lessee}} directly, the platform will output [object Object] literally, and the group will receive a blob of garbled text.
2. Reversed scheduling order: If the source and target trigger at the same time, or the target runs before the source, you get an alert blind spot with "target gets an empty result set". The safe approach is to let the source run first and delay the target by 4 minutes.
3. Too broad status filter: In some projects, status was not constrained initially, so statuses like 0 (waiting) and 2 (completed) were also pushed to the group. The result was that the group was flooded with hundreds of normal completion messages every day, burying the real errors. You must fix status=3,6.
4. Hardcoded access_token: When rotating secrets, you have to change every configuration, which is insecure and easy to miss. In production, always use secret management.
5. ids list drift: When the business team adds new strategies, if nobody updates the ids list, anomalies from the new strategies will not be monitored. It is recommended to incorporate ids maintenance into the change management process, or simply not pass ids and let the platform return everything (the cost is a full scan — weigh the trade-off).

Applicable and Non-Applicable Scenarios

Applicable: Projects that need near-real-time visibility of integration platform strategy anomalies in business groups (e.g., DingTalk, WeCom); scenarios with a large number of strategies across business domains that need grouped monitoring by strategy ID.

Not applicable: When the alert channel is not a DingTalk bot (use the corresponding platform's message push strategy); when alert latency requirements are at the second level (this strategy's minimum window is 10 minutes); when alerts need to be persisted to a business system for further processing (use a database-write-style strategy instead).