DingTalk Ops Bot Detail Strategy in Practice: Pushing Integration Exceptions into the Group
What This Strategy Solves
Once dozens of sync strategies are running in an integration project, what hurts the ops team is not "the data did not sync" but "when will I even know it failed." Between a Kingdee Cloud Cosmos-style ERP and DingTalk, hundreds of strategies run every day, and logging into the backend to scan logs is unrealistic.
The "DingTalk Ops Bot (Detail)" strategy does something very plain: every twenty minutes it actively pulls the recent error details of strategies from the Qeasy data integration platform, and then pushes them into an ops group through a DingTalk custom robot, so that whoever is on duty can see on their phone which strategy, which document, and at which step failed.
Its value is not in transferring data, but in shortening the time from "integration failed" to "a human noticed." In one real project, the customer's manual inspection originally took 1–2 hours; after this strategy was enabled, it was basically compressed to within 30 minutes, and night-shift alerts could also be seen directly in the group.
Data Flow and Field Mapping
This strategy is a "platform → platform + group message" structure. The source is a query interface of Qeasy itself, the target is a DingTalk custom robot webhook, and no intermediate persistence is required.
| Field (source query response) | Meaning | Target robot field | Notes |
|---|---|---|---|
| strategy_name | Strategy name | name | The first identifier seen in the group |
| lessee.name | Tenant name | lessee_name | Distinguishes ownership in multi-tenant scenarios |
| number | Document number | number | Pinpoints the exact document |
| response_at | Response time | response_at | Tells whether it just failed or has been failing |
| problem | Problem description | problem | Goes directly into the message body |
The source interface StrategyErrorDetail is a POST query interface that requires recentSeconds (how many seconds back to look; here it is 600) and ids (a comma-separated list of strategy IDs to monitor). The target interface DingTalkRobotDetail uses the standard DingTalk custom robot webhook. The access_token is generated once when the robot is created and stored in plaintext in the Qeasy connector configuration; do not hardcode it inside request scripts.
How to Configure It in Qeasy
In the Qeasy data integration platform, this strategy is configured as two nodes: the source node is the "Qeasy Platform" connector, selecting the StrategyErrorDetail API; the target node is the "DingTalk" connector, selecting the custom robot detail push API.
A few key configuration points:
- How to maintain the strategy ID list: do not hardcode all IDs into the request body. The safer approach is to build a lightweight mapping table in Qeasy that centrally manages "business strategy name → strategy ID"; when adding a new strategy you only modify this table, and the
idsfield can reference it through variables. - Variable-ize the request body: fields like
{{strategy_name}},{{lessee.name}},{{number}},{{response_at}},{{problem}}should all be carried over through the source response's JSON path, avoiding re-parsing on the target node. - Do not parse the response: set
autoFillResponse=false. The DingTalk robot only cares whether the send succeeded; it does not consume any returned content. - Disable model building: set
buildModel=false, because detail data is "consumed once" and does not need a cache table. - Centrally store the robot access_token: after the DingTalk robot token is created on the DingTalk side, place it into the connector's credential management in Qeasy, visible only to the ops role; group members should not see the full token.
Implementation Steps
Step one: get the source interface working first. Manually trigger StrategyErrorDetail once in Qeasy, confirm that recentSeconds=600 can pull data, and verify that the returned fields contain the five items: strategy_name, lessee.name, number, response_at, and problem.
Step two: configure the target node's DingTalk robot. First create a custom robot in the DingTalk group, obtain the access_token from the webhook address, and paste it into the Qeasy connector. Then map source fields to target fields through variables in the strategy, perform one manual send, and confirm that the group can see the complete detail.
Step three, phased scheduling. Ops bots are easiest to "spam the group," so the cadence should be slow:
- Incremental starting point: first set
recentSecondsto 600, and the schedule to*/20 9-20 * * *(every 20 minutes during working hours), covering daytime first. - Full trigger: after stable daytime operation for one week, then extend to nighttime, or increase
recentSecondsto 1800, to avoid nighttime noise. - Scheduling frequency: detail-class strategies should run every 20–30 minutes, not every minute; otherwise the group will be flooded and genuinely serious problems will be drowned out. In the material the source node is
*/20and the target node is*/30; this "source slightly faster than target" arrangement is intentional, so that the target side always has some backlog to send, avoiding empty runs.
Step four: add a fallback. If the same strategy reports errors continuously more than N times within 1 hour, Qeasy should trigger an alert escalation (phone call or SMS) at the platform level; it cannot rely solely on the robot push.
Lessons From the Trenches
Typical mistake 1: recentSeconds and scheduling period do not match. If the schedule runs every 20 minutes, recentSeconds must be at least larger than 1200, otherwise there will be a gap window between the two cycles where reports are missed.
Typical mistake 2: forgetting to sync the ids list. After a new strategy goes live, if you forget to add its ID into ids, then when that strategy fails, the group will simply not be notified. It is recommended to make "strategy goes live" and "join the monitoring list" into a single checklist.
Typical mistake 3: leaking the robot webhook. Many people paste the access_token directly into the group. Although the DingTalk robot token is not a highly sensitive credential, once it is obtained externally, messages can be forged and pollute ops judgment. Placing it inside the Qeasy connector for centralized management is the safer approach.
Typical mistake 4: in a multi-tenant scenario, lessee.name is not carried over. Once the platform serves multiple tenants and the group does not distinguish tenants, the on-duty person has no idea who should handle the issue. The lessee.name from the source response must be transparently passed into the message.
Typical mistake 5: the message body is not truncated. If fields are concatenated directly, some exception stacks are extremely long. DingTalk robots have a length limit on a single message; if it is too long, the send will fail. It is recommended to truncate at the target node in Qeasy, keeping only the first N characters.
When to Use and When Not to Use
It is suitable for projects with "many strategies, many tenants, and ops needing to see failure details as soon as possible," especially scenarios like Kingdee Cloud Cosmos-style ERPs, which expose many external interfaces and have long error chains.
It is not suitable for small projects with only one or two strategies, nor for scenarios that require failure attribution analysis — detail push is only responsible for alerting, not diagnosis. The real root-cause analysis still has to go back into Qeasy's run logs to look at the full stack trace.