Inventory Monitoring + WeCom Alerts: A Hands-On Guide to the Request-Message Push Strategy on Qeasy

What This Strategy Solves

A retail customer runs dozens of supply-chain sync strategies on Qeasy between two ERP systems. Manual monitoring meant issues surfaced only after downstream business felt the pain. We deployed Qeasy's Request-Message Push strategy to periodically pull strategy error details and forward them to a WeCom robot, turning firefighting into early warning.

Data Flow and Field Mapping

The strategy is a two-stage query-and-push pipeline:

The source ids field accepts a comma-separated list of strategy IDs for batch pull. recentSeconds controls the incremental window—172800 seconds (48h) covers two inspection cycles. On the target side, template variables like {{strategy_name}}, {{number}}, {{response_at}} populate the alert card.

How to Configure on Qeasy

Source side

• API: StrategySourceErrorDetail, type WebAPI, method POST, effect QUERY.
• Map number to strategy name and id to response_at; enable idCheck for incremental de-duplication.
• Declare recentSeconds (int) and ids (string, comma-separated) explicitly; disable buildModel, enable autoFillResponse.

Target side

• API: WeChatRobotDetail, type WebAPI, method POST, effect EXECUTE.
• Manage access_token via Qeasy connection settings, never hard-code it.
• Use template variables {{strategy_name}}, {{lessee.name}}, {{number}}, {{response_at}}, {{problem}} so the WeCom message shows which strategy, which record, when, and what went wrong.
• Qeasy's built-in "only push on non-empty error" mechanism keeps noise low.

Implementation Steps

We rolled this out in three phases:

1. Incremental start: Week one, monitor only 3–5 core strategies (e.g., inventory sync, shop-to-partner mapping). Set recentSeconds to 86400 (24h).
2. Full coverage: Week two, expand ids to all active strategies; raise recentSeconds to 172800. Source cron at 3 3 * * *, target at 0 9 * * *.
3. Steady-state scheduling: Source every 6 hours; target twice daily at 09:00 and 18:00. This is the classic "incremental + full coverage" pattern common among Qeasy customers.

Pitfalls and Lessons Learned

1. Never hard-code access_token in the strategy—store it in Qeasy's credential vault.
2. Don't overload ids: too many IDs slow the source and may trigger throttling; group by business domain.
3. Always enable idCheck on response_at to prevent duplicate alerts.
4. Align time zones: source returns UTC; format explicitly in the target template to avoid 8-hour confusion.
5. Don't silently swallow empty responses: a "zero-error daily report" line item prevents the ops team from thinking the inspection died.

When to Use and When Not to

Use when: you have many parallel strategies needing unified ops alerting; your ops team uses WeCom robots; alert frequency is manageable (sub-minute pushes will spam the group). Don't use when: you need sub-second real-time alerting (use a dedicated APM); the channel isn't WeCom (other EXECUTE targets work but require field adjustments); single-strategy, single-tenant lightweight scenarios—Qeasy's built-in alerts suffice.