Message Push – Qeasy Internal: An Alerting Strategy for Supply Chain Integration

What This Strategy Solves

In a supply chain integration between a mainstream ERP and an e-commerce SaaS, dozens of sync strategies usually run side by side—items, business partners, sales orders, real-time inventory, and so on. In one real project, the operations team asked a simple question: "When a strategy fails or gets skipped, can someone in the group chat actually see it?" We used Qeasy's built-in Message Push – Qeasy Internal strategy to answer that. The source side calls StrategyErrorDetail to pull errors and skipped runs within a recent time window. The target side calls WeChatRobotDetail to deliver the details to a WeChat Work bot. The result: failures are visible inside the group within minutes, not hours.

Data Flow and Field Mapping

The whole pipeline lives inside Qeasy and does not touch the business systems directly.

Source side – StrategyErrorDetail (WebAPI, POST, QUERY)

• recentSeconds (int, default 172800, seconds): the look-back window.
• ids (string): a comma-separated list of strategy IDs to monitor. The source material lists 18 sample IDs representing the "high-attention" set.
• status (string): status filter, multi-value. A typical pair is 3,6 – 3 means error, 6 means scheduled skip.

Middleware: the Qeasy scheduler runs on crontab (56 3 * * *) and auto-fills _autoFillResponse fields, so strategy_name, strategy_id, and response_at from the response become variables available downstream.

Target side – WeChatRobotDetail (WebAPI, POST, EXECUTE)

• access_token (string, required): the WeChat Work bot access token.
• name (string): strategy name, mapped from {{strategy_name}}.
• lessee_name (string): tenant name, mapped from {{lessee.name}} for multi-tenant traceability.
• number (string): strategy document number, mapped from {{number}}.
• response_at (string): the time of the anomaly, mapped from {{response_at}}.
• problem (string): description of the problem.

Key field mapping table:

How to Configure It in Qeasy

There are two pieces: first the source "strategy error query", then the target "WeChat Work push".

Source configuration notes: pick API StrategyErrorDetail, type WebAPI, effect QUERY, method POST. Start recentSeconds at 172800 (48 hours) for easy triage. Strongly recommend defaulting to status = 3,6 to cover errors and scheduled skips, the two most overlooked cases. Enable autoFillResponse so downstream can see strategy_name, strategy_id, and response_at. Use an id template like {{response_at}}{{number}}{{strategy_id}} so the same anomaly cannot be pushed twice.

Target configuration notes: pick API WeChatRobotDetail, type WebAPI, effect EXECUTE, method POST. access_token is required – store it in Qeasy's credential manager instead of pasting it into the strategy body. Map name, lessee_name, number, and response_at directly to the middleware variables.

Implementation Steps

A staged schedule is the safer path: for the initial cutover, run a "full trigger" covering the last 48 hours to flush historical backlogs; then switch to incremental, with crontab set to 56 3 * * * (off-peak hours) so it does not fight the business during the day. Alerts are for ops eyes – once a day is enough. For strategies that really need real-time alerting (like order sync), build a separate high-frequency variant.

Concrete steps in Qeasy: 1) drag the source StrategyErrorDetail into the canvas and configure request parameters; 2) attach the target WeChatRobotDetail and map variables; 3) set crontab and save; 4) trigger once manually and verify a message lands in the group; 5) observe for 3–5 days and tune recentSeconds and status based on team feedback.

Lessons From the Trenches

First, never hard-code access_token into the strategy JSON. In one project the token expired and was scattered across multiple places; it took a long time to find. The safe move is to centralize it in Qeasy's credential manager and change it via the config center.

Second, be careful with the default status. If left empty, you will pull every status (waiting, complete, error, skip, ignore…) and the group chat will be spammed. In production, keep only 3 (error) and 6 (scheduled skip), and add others only when needed.

Third, do not set recentSeconds too large. In one project we set it to 30 days, then a historical backfill flooded the group with hundreds of alerts. 48 hours is a sane default. For long-horizon audits, use a separate strategy.

Fourth, the idempotent id must include strategy_id. Using only response_at collapses multiple anomalies in the same second. Adding strategy_id makes it naturally unique.

Fifth, in multi-tenant scenarios always carry lessee_name. In one SaaS delivery we saw multiple tenants share a single group chat, and without the tenant name nobody could tell whose problem it was.

When It Fits, and When It Does Not

Fits: multi-strategy, multi-tenant supply chain pipelines that need a single alerting view; "silent failures" like errors and scheduled skips that must be visible; small and mid-sized customers whose ops teams live in WeChat Work. Does not fit: core transactional paths that need second-level real-time alerting (use a dedicated APM instead); customers without an available WeChat Work bot channel; minimal environments that only rely on log inspection.