DingTalk Error Alert: Real-Time Notification for Supply Chain Integration Failures

What This Strategy Solves

In an on-premise supply chain integration environment with 27 sync strategies covering items, orders, and inventory, relying on humans to watch logs makes it hard to catch failures in time. We use the Qeasy data integration platform's "StrategyErrorDetail query + DingTalk robot push" combination to push error statuses to the operations group as group messages in real time, so an abnormal strategy and its document number can be located within 5–10 minutes.

Data Flow and Field Mapping

The whole link is split into two steps: first pull the error detail from the Qeasy internal interface, then call the DingTalk robot's webhook to send the message.

Stage	Interface	Purpose	Key Fields
Source	StrategyErrorDetail (Qeasy WebAPI, POST)	Query run records within the last N seconds with status "Error" for the specified strategies	recentSeconds, ids (strategy ID list), status
Middle	Qeasy Scheduler	Variable pass-through	strategy_name, lessee.name, number, response_at, problem
Target	DingTalkRobotDetail (DingTalk robot WebAPI, POST)	Push the error information to the DingTalk group	access_token, name, lessee_name, number, response_at, problem

If the status field is left empty, it defaults to "Error"; multiple values can be separated by commas. We recommend recentSeconds at 600 seconds, consistent with the scheduling frequency.

How to Configure in Qeasy

Create the source interface: Choose WebAPI / POST, pick the built-in StrategyErrorDetail, and fill in three parameters in the request body: recentSeconds, ids, status. Maintain the ids list in Qeasy's "centralized parameter table" so it is easy to add or remove strategies later.
Create the target interface: Choose WebAPI / POST, pick DingTalkRobotDetail, fill in the DingTalk robot webhook token as access_token, and reference the source interface return fields with {{variable_name}} for the other fields.
Write a minimal strategy: source pulls data → target pushes it; no complex cleansing is needed, Qeasy handles variable substitution automatically.
Stagger the scheduling: configure the source strategy with 1-59/10 * * * * (starts at the 1st second every 10 minutes), and the target strategy with 5-59/10 * * * * (offset by 5 seconds) to avoid concurrency at the same moment.

Implementation Steps

We split this "notification" strategy into three rollout phases:

Phase 1: Silent trial (incremental starting point). Enable the source interface but do not push to DingTalk. Let Qeasy write the query results to logs to confirm ids covers all running strategies and status=3 stably hits error records.
Phase 2: Full trigger. Enable the target interface, manually trigger 1–2 runs, and verify the DingTalk message format, @mention, and links; at the same time confirm variables are substituted correctly.
Phase 3: Lock down the scheduling frequency. Promote to the staggered combination 1-59/10 source + 5-59/10 target, and enter steady-state operation.

The dual-track of incremental and full here is: first observe error samples incrementally, then push everything—this avoids "bombarding" the ops group the moment it goes live.

Pitfalls and Lessons

A typical mistake is hard-coding ids in the request body. After new strategies go live or old ones are retired, no one updates the list, so months later the notification scope drifts. The safer approach is to lift ids into Qeasy's centralized parameter table or a data source for unified maintenance.
access_token is bound to the robot and is easy to mix across groups. When multiple projects share one Qeasy tenant, always build a separate robot per project, with the token mapped 1:1 to the project.
recentSeconds does not match the scheduling frequency. Scheduling every 10 minutes but only querying 60 seconds causes missed alerts; setting it too large causes duplicate pushes. We recommend recentSeconds = scheduling interval × 1.5.
Variables are sent out unsubstituted. This usually happens when the target interface has not enabled "auto-build request model". The safe move is to enable autoFillResponse in Qeasy so return fields auto-generate the variable template.
Leaving status empty only queries errors, but sometimes you also want to see "queued" items. Change status to a multi-value combination like 3,5; Qeasy supports comma-separated values.

Applicable and Non-Applicable Scenarios

Applicable: on-premise deployments with many concurrent strategies that need 7×24 ops response in supply chain integration projects. Not applicable: lightweight scenarios with only 1–2 sync strategies (reading logs is enough), and scenarios requiring sub-second real-time messaging (those should use event streams, not polling).