Strategy Sync in Practice: Pushing Integration Platform Error Logs to a DingTalk Robot

What This Strategy Solves

When dozens of sync strategies run on an integration platform, a single failure—caused by target-system rate limits, missing fields, or transient network issues—usually surfaces only when business users complain about wrong data. In one retail customer engagement, we used the Qeasy (轻易云) data integration platform to implement a "strategy execution error/skipped record -> DingTalk group robot" strategy, turning post-mortem detection into near-real-time broadcast.

Data Flow and Field Mapping

The source is the platform's internal StrategyErrorDetail query API; the target is the DingTalk robot webhook DingTalkRobotDetail. The overall flow is "platform -> platform."

Key field mapping:

The field that trips people up is lessee_name: the source lessee is an object, not a string. Writing {{lessee}} will only return [object Object]. You must use {{lessee.name}} to reach the nested property.

How to Configure It on Qeasy

Source configuration essentials:

• Select api StrategyErrorDetail, effect QUERY, method POST.
• In the request, set recentSeconds to a default of 900 (a 15-minute window), status to 3,6 (errors and skipped schedules only), and ids to a comma-separated list of strategy IDs to monitor.
• Build the business key id from the template {{response_at}}{{number}}{{strategy_id}} so the same error record is consumed only once.
• Enable autoFillResponse so response fields flow back automatically, removing the need to hand-build a model.

Target configuration essentials:

• Select api DingTalkRobotDetail, effect EXECUTE.
• Inject access_token as a CONSTANT. Do not hard-code it in the request body—use a secrets manager or environment variable in production.
• Map each field per the table above using DIRECT. No _findCollection lookups are needed.
• Recommended schedule: 1-59/15 * * * *, every 15 minutes around the clock so alerts do not pile up.

Implementation Steps

1. Initial run: Trigger a full first pass and confirm that historical errors with status=3,6 are pulled and pushed to a test-group robot.
2. Steady-state scheduling: source on 1-59/15 7-21 * * * (every 15 minutes from 07:00–21:00), target on 1-59/15 * * * * (every 15 minutes, all day). The source pulls only during business hours, matching the "high frequency by day, low frequency at night" ops rhythm; the target runs all day to drain daytime backlog.
3. Dependency and timing: The target depends on the source being ready first. In real projects we use an implicit "source QUERY completed -> trigger target EXECUTE" dependency to avoid empty pushes.
4. Quiet-period validation: After go-live, observe three consecutive business days to check whether alert volume during off-hours (21:00–07:00) is reasonable, avoiding nighttime noise.

Hard-Won Lessons

1. Hard-coding access_token is the classic mistake. As soon as the robot rotates its secret, every strategy breaks. The safe approach is to reference a variable backed by a secrets service.
2. {{lessee}} returns nothing useful. The source field is an object, the target is a string—you must use the dot-path syntax {{lessee.name}}. Qeasy supports nested references, but first-time builders often miss this.
3. Business-key collisions. We initially used strategy_id alone as the id, which caused deduplication to drop consecutive errors from the same strategy. Switching to the concatenated {{response_at}}{{number}}{{strategy_id}} makes each error record unique.
4. Misaligned schedule windows. With the source restricted to 7-21, errors that occur overnight would be missed if the target ran only during business hours as well. The target must run all day—the source window defines "how fresh," the target window defines "how often to push"—and the two should be designed independently.
5. Alert storms. During a brief target-system outage, hundreds of errors piled up within an hour and flooded the DingTalk group. We later added a pre-processing step that merges identical errors from the same strategy within five minutes, and the noise dropped immediately.

When to Use and When Not To

Use it when you need to push the integration platform's own strategy exceptions out to an IM tool (DingTalk, WeCom, Feishu), especially the "error" and "skipped schedule" statuses. Do not use it for business data sync (items, customers, orders)—that is a different strategy template. It is also not suited for real-time, second-level alerting; a 15-minute granularity is the natural boundary of this strategy.