WeChat Work Push Strategy in Practice: Timely Delivery of Integration Exceptions to Group Chats

What This Strategy Solves (Scenario and Value)

In a supply-chain integration for a retail enterprise, over a dozen synchronization strategies run in parallel: sales orders, purchase receipts, inventory transfers. For the business side, the worst case is not the alert itself but "nobody noticing." On-site O&M staff stare at monitoring dashboards during the day, while on-call colleagues scan logs at night—far from ideal. Using Qeasy Data Integration Platform, we built a lightweight strategy: at 9:30 AM every day, it automatically pulls the last 24 hours of "error" and "scheduled-skip" records from designated strategies, cleans them up, and pushes a single summary to the O&M group via a WeChat Work bot. Within seconds, a "yesterday's integration exception list" appears in the group, with clear ownership for each item.

Data Flow and Field Mapping

The flow is "Qeasy built-in query API → Qeasy executor → WeChat Work group-bot WebHook," fully closed-loop inside the platform with no intermediate database.

Key field mapping (source → target):

The source side uses recentSeconds=86400 to limit the window to one day, and status=3,6 to keep only "error" and "scheduled-skip," filtering out completed, waiting, and other noise.

How to Configure in Qeasy

On the source side, choose "WebAPI / Query," select StrategyErrorDetail, method POST. Fill the ids field with the comma-separated list of strategy IDs to monitor (covering a dozen at once). Set status explicitly to 3,6, and recentSeconds defaults to 86400. Response fields can stay as _autoFillResponse; no manual schema is needed.

On the target side, choose "WebAPI / Execute," select the WeChat Work bot API WeChatRobotDetail, method POST. Inject access_token via a platform credential variable rather than hard-coding the bot key in the strategy—centrally managed credentials mean swapping a bot doesn't require editing the strategy. Map name, number, response_at, and problem directly from the source using {{variable}} references, achieving field-level mapping.

For both WebAPIs, disable idCheck, since these are batch sub-calls without primary keys.

Implementation Steps

1. Incremental starting point: On the first day, only configure the source-side query. Run it manually once and export the result to CSV as the "day-one baseline" to confirm the ID list is complete.
2. Full-volume trigger: During the first week, temporarily change recentSeconds to 604800 (7 days) and run a one-shot full volume to verify that all errors within the 7-day window are correctly aggregated to the group, and to spot any missing fields.
3. Schedule frequency: Use 30 9 * * * on the source (runs at 9:30 daily) and 31 9 * * * on the target—one minute apart—to avoid transient concurrency that could trigger bot rate limits.
4. Back-check mechanism: Qeasy retains execution logs for at least 30 days by default. When the group receives no message, operators can review the source-side execution record to confirm there really were no exceptions, rather than blaming a "bot glitch."

For encoding mapping, a common practice is to maintain the list of strategy IDs centrally in a "monitored-strategy manifest" table. Adding or retiring strategies only requires updating this single table, which all push strategies share. For header-body staged rollout, this step currently only pushes an error summary (header); once O&M teams are comfortable, the table body—e.g., per-error stack snippets—can be added later.

Pitfalls Recap

1. status default is "error," easy to miss skips. The source field description says "default 3 when omitted," so many only see errors—but "scheduled-skip" is often more dangerous: it means the upstream never fetched data, and the business silently stalls. Always write 3,6 explicitly.
2. access_token hard-coded in the value field. In early deployments we did hard-code the bot key into the strategy. The customer later requested centralized management, so we switched to a platform-credential variable injected by O&M at deploy time—swapping the bot no longer requires editing the strategy.
3. ids list keeps growing. Stuffing all 30 strategy IDs into one field is hard to maintain and easy to mistype. The safe approach is to extract the ID list into a "monitoring manifest" table and reference that table from the strategy.
4. Same-minute concurrency hits rate limits. When the source finishes at 9:30 and the target is also scheduled 30 9 * * *, the platform queues them in order, but network jitter can still cause collisions. Staggering by one minute is more robust.
5. recentSeconds is in seconds. Newcomers sometimes write 24, which only checks the last 24 seconds—and the group ends up empty. Always write 86400.

Suitable and Unsuitable Scenarios

Suitable: multi-strategy environments needing daily centralized inspection for supply-chain or finance integrations; O&M teams already collaborating in WeChat Work; latency tolerance of "next morning." Unsuitable: sub-minute real-time alerting (use single-strategy on-failure push instead); non-WeChat-Work target groups (switch bot protocol); scenarios with extremely high exception volume requiring triage (integrate with a ticket system rather than group messages).