DingTalk Error Push Strategy in Practice: Pulling Error Details to DingTalk Robot Alerts via Qeasy

What This Strategy Solves

In a real project, a retail enterprise handed off more than a dozen business-document syncs between Kingdee Cosmic and DingTalk to the Qeasy data integration platform. The daily run was stable, but ops quickly hit an awkward reality: when an integration task fails, the platform only writes it to its own logs. Nobody gets notified. By the next morning, financial reimbursements or expense applications have been stalled for hours, and manual recovery only starts half a day later.

The "DingTalk error push" strategy is built precisely for this pain point. It periodically pulls strategy details in "error" status from Qeasy, then uses a DingTalk custom robot to push anomalies to a designated group. It does not move business data itself; it acts as a "monitoring sentinel" for all business strategies — a typical operations-oriented integration.

Data Flow and Field Mapping

The data flow is one-way pull + push. Think of it as: Qeasy error log → in-memory assembly → DingTalk robot message body.

We strongly recommend treating recentSeconds and ids as "centralized configuration": every ops strategy should share the same lookback window and strategy list, so each alert channel does not have its own copy.

How to Configure It in Qeasy

This strategy actually only has two integration actions inside Qeasy: the source is StrategyErrorDetail (an internal WebAPI), and the target is DingTalkRobotDetail (also a WebAPI, but with effect = EXECUTE).

Key configuration points:

1. Source API: WebAPI / QUERY. It returns an array of error details. Make sure "auto-fill response fields" is enabled so you do not have to add fields manually each time a new strategy is added.
2. Target API: WebAPI / EXECUTE. This is a write action that directly invokes the DingTalk custom robot's webhook. The access_token is generated in the DingTalk group; store it in the platform's secret manager instead of leaving it as plain text in the request body.
3. Field mapping stage. Pass strategy_name, strategy_id, number, response_at from the source directly into the target body. lessee.name uses the platform's built-in variable for multi-tenant separation.
4. Do not enable build-model. The error-detail structure is fairly stable. Modeling it separately only slows down scheduling.

Implementation Steps

We recommend landing this strategy in three phases.

Step 1: Build a minimal viable alert strategy. Monitor only one or two of the most critical strategies first, with a schedule of "every 2 hours". Pass just a single id to the source API, and point the target at a test-group robot. Once the DingTalk card arrives correctly, scale up.

Step 2: Expand to all strategies and switch to production frequency. Maintain all monitored strategy IDs in one centralized constant — Qeasy supports centralized variable management, which maps nicely to the common "centralized code mapping" pattern. Switch the schedule from a test 30-minute run back to a steady 0 */2 * * *. Move the target robot to the production group, and offset it by 10 minutes (10 */2 * * *) so it does not fire at the same second as the source.

Step 3: Separate the incremental start point from the full trigger. Treat the first go-live as a "full trigger" — temporarily widen the lookback window (for example, 7 days) to flush out historical accumulated errors and give ops a complete baseline. After that, use the default 3-hour window for "incremental" runs. This way you do not lose historical alerts, and you are not pestered by the same old errors every day.

Lessons Learned from Real Projects

1. Lookback window and alert frequency are out of sync. At first we set recentSeconds to 1 hour but scheduled the job every 2 hours. The 1 hour between windows was completely missed. The safe rule is: window ≥ schedule period × 1.5, to leave overlap.
2. ids list misses new strategies. When a new business strategy went live, ops forgot to add it to the ids list, so the robot never fired for it. We later made this a fixed item in the launch checklist.
3. DingTalk robot got rate-limited. During one mass error event, hundreds of alerts fired at once and the DingTalk group robot was throttled, so ops actually did not receive the messages. The fix is either to deduplicate errors for the same strategy inside Qeasy, or to use a smaller lookback window to cap the burst.
4. access_token accidentally pushed to a code repo. This is the most sensitive and easiest mistake to make. Always store it in the platform's secret field, never as plain text in the request body.
5. Alert body lacks locating context. The earliest version only pushed strategy_name, which was useless in multi-tenant scenarios — you could not tell which subsidiary's error it was. After we added lessee_name, response_at, and number, ops could locate the issue at a glance.

When to Use It and When Not

Use it for: multiple business strategies running together that need a "unified alert entry point"; multi-tenant SaaS integration environments; combinations like Kingdee Cosmic + DingTalk, SAP, or Yonyou. Do not use it for: a single low-frequency strategy (just read the logs directly); scenarios that demand sub-second alert latency (use event-driven instead of polling); or compliance-sensitive scenarios where business error summaries should not appear in a DingTalk group.