DingTalk Error Alert Strategy Tutorial: Real-time Integration Exception Notifications with Qeasy

What This Strategy Solves

Anyone running supply-chain integrations has lived this scene: you're on the subway home and a group chat pings "Sales order sync failed"—the platform knew 30 minutes ago, but nobody saw it. The DingTalk Error Alert strategy closes that gap. It moves no business data; it simply asks every few minutes "which strategies are failing?" and pushes the answer to an on-call engineer via a DingTalk bot.

Data Flow and Field Mapping

This strategy is a self-inspection loop inside the platform—both endpoints are Qeasy's own WebAPIs, not business systems.

Nothing is persisted in between. The request body uses placeholders like {{strategy_name}}, {{number}}, and {{response_at}} to pipe the source response straight into the DingTalk message. recentSeconds defaults to 300, aligned with the schedule, to prevent both misses and duplicates.

How to Configure on Qeasy

Source API: Pick StrategyErrorDetail, WebAPI / QUERY / POST. The two request fields that matter are recentSeconds (hard-coded to 300) and ids (comma-separated strategy IDs you want monitored). Tick strategy_name, strategy_id, number, response_at, and problem in the response; Qeasy auto-fills them.

Target API: Pick DingTalkRobotDetail, WebAPI / EXECUTE / POST. access_token is obtained from DingTalk's group settings (Group Settings → Smart Group Assistant → Add Robot → Custom). Store it in Qeasy's credential vault, not as plaintext in the request body. The message fields—name, number, response_at, problem—all use {{}} placeholders that reference the source fields by name.

Strategy assembly: Chain the two APIs into one strategy and register it in the scheduler. The same two patterns customers use everywhere—centralized credential management and placeholder-based field passthrough—apply here.

Implementation Steps

1. Create a standalone "alert channel" strategy. Don't bury it inside a business strategy; keep it separate so you can start/stop it independently.
2. Scope the monitoring gradually. Start with one or two high-frequency strategies in ids for end-to-end testing, then expand to the full set. Sixty IDs at once makes triage painful.
3. Schedule cadence. Source crontab: */5 8-22 * * * (every 5 minutes, business hours). Target crontab: 1-59/5 8-22 * * *, offset so the two calls don't collide—and so alerts don't race with the business strategies themselves.
4. Message template. Four elements in the DingTalk text are essential: strategy_name, number (the failing doc number), response_at (when it failed), and problem (the error summary). An on-call engineer should be able to triage at a glance.
5. On-call handoff. Outside 8–22, either stop the strategy or stretch the interval to 30 minutes. Midnight alert fatigue is worse than a missed ping.

Pitfalls and Lessons Learned

1. recentSeconds set too high. One customer changed 300 to 3600 and watched the same failure re-broadcast every 5 minutes. Keep it aligned with the schedule—at most slightly larger to absorb clock drift.
2. Pushing all strategy IDs at once. With many strategies, failures cross-reference each other and triage slows dramatically. Roll out in phases: core (orders, inventory) first, then periphery.
3. access_token written in plaintext. A leaked DingTalk token means forged group messages. Always go through Qeasy's credential vault or a private-deployment secrets store.
4. Overlooking idCheck. This strategy ships with idCheck=true, but it's tempting to flip it off when copy-pasting into other strategies—result: failed docs get silently dropped.
5. Too many people in the alert group. A 200-person company-wide group turns alerts into noise. Limit to ops + the relevant business owner, and enable "strong reminder" only for the on-call rotation.

When to Use (and When Not To)

Use when: you're on a private deployment, running many integration strategies, and the ops team prefers push-based alerts over proactive dashboard checks. Don't use when: you're on lightweight SaaS with a handful of strategies you can count manually, or when compliance requires alerts to flow through an internal IM approval gateway rather than directly to a custom bot.