WeCom Internal Notification Strategy Tutorial: From Integration Platform Alerts to WeCom Delivery
What This Strategy Solves
In a supply chain integration project for a retail enterprise, dozens of synchronization strategies run between the source ERP and the target ERP. When one strategy fails overnight, operations staff usually do not notice until the next morning, by which time business data has already stalled for several hours. Using the Qeasy data integration platform, we built an internal WeCom notification strategy that aggregates all error or skipped records from the previous day and pushes them via an enterprise WeCom robot to the operations group, enabling same-day issue resolution.
Data Flow and Field Mapping
The pipeline consists of three stages: integration platform source API, intermediate assembly layer, and WeCom robot target API.
| Stage | Key Field | Source / Target | Notes |
|---|---|---|---|
| Source: StrategyErrorDetail | recentSeconds | Request parameter | How far back to query, in seconds |
| Source: StrategyErrorDetail | ids | Request parameter | Comma-separated list of strategy IDs to monitor |
| Source: StrategyErrorDetail | status | Request parameter | Status filter, commonly 3 (error) and 6 (skipped) |
| Source: StrategyErrorDetail | strategy_name | Response | Strategy name, auto-filled |
| Source: StrategyErrorDetail | strategy_id | Response | Strategy ID, auto-filled |
| Middle layer | number / response_at | Template variables | Document number and response time, auto-injected |
| Target: WeChatRobotDetail | access_token | Request parameter | WeCom robot credential |
| Target: WeChatRobotDetail | name / lessee_name / number / response_at / problem | Request parameters | Variables that render the message body |
For code mapping, a common pattern is to centralize the strategy ID list in a constant table so that adding new monitored objects only requires editing one place, avoiding scattered maintenance across multiple strategies.
How to Configure on Qeasy
- Source API metadata: Select API
StrategyErrorDetail, type WebAPI, method POST, effect QUERY. Configure three request fields—recentSeconds, ids, and status. Enable autoFillResponse for response fields so that strategy_name and strategy_id are auto-populated. - Target API metadata: Select API
WeChatRobotDetail, type WebAPI, method POST, effect EXECUTE. Manage the access_token through Qeasy's credential vault so it is never stored in plaintext within the strategy. - Request assembly: On the target side, bind variables such as strategy_name, lessee.name, number, response_at, and problem to the message card template. The problem description is composed via a script function from the source response.
- idCheck: Enable on both sides to avoid duplicate pushes.
- Build model: Leave disabled; this strategy does not rely on source data to build target entities.
Implementation Steps
We usually proceed in three phases.
- Incremental starting point: On day one, place only two core strategies in the ids list (for example, sales outbound synchronization and material synchronization) to verify the full pipeline from alert to push.
- Full trigger: After observing for 3–5 days, gradually add the remaining strategies to the ids list. Use a phased approach—first add error status 3, then add skipped status 6—to avoid being overwhelmed by historical skipped records.
- Scheduling frequency: Configure the source-side strategy with crontab
3 4 * * *, pulling the previous day's data at 04:03 every morning. Configure the target-side strategy with0 9 * * *, pushing at 09:00 sharp, leaving a processing window. If the customer needs earlier awareness, the push can be moved to 08:00.
Lessons Learned
- Strategy ID list drift: Customers forget to update the ids list after adding new strategies, leading to silent failures on the new strategies. The safe approach is to maintain ids as a lightweight mapping file reviewed weekly by a single owner.
- Access token leakage: Writing the token directly into the strategy value field is a classic mistake. Use Qeasy's credential vault, refresh periodically, and prevent plaintext from appearing in configuration snapshots.
- Duplicate pushes: When idCheck is not enabled, the same alert floods the channel. We once saw a group receive over 40 duplicate messages in a single morning, which was a poor experience.
- Mixed status values: When status is not specified, the default is 3. If you intend only to watch errors but forget to set the value, waiting and error states will be mixed. It is recommended to explicitly specify
3,6rather than rely on the default. - Skipped status 6 ignored: Many people monitor only errors, but in some scenarios the upstream has no data and the strategy is skipped. Long-term neglect creates hidden pitfalls. Including 6 in the filter helps detect data flow interruptions early.
Applicable and Non-applicable Scenarios
Applicable: scenarios with multiple parallel strategies requiring centralized operational awareness of failures and skips; teams that already use a WeCom robot as a unified alerting entry point. Not applicable: scenarios requiring minute-level real-time alerts, or environments without a WeCom robot or lacking group-sending permissions—in such cases switch to SMS or telephony gateways.