Kingdee Cloud Galaxy Document Echo to DingTalk Notification: A Practical Breakdown of One Strategy

What This Strategy Solves

After a business document is written into Kingdee Cloud Galaxy, approvers and initiators fear most the "black box" — the document has landed in the ERP, but the DingTalk group stays silent, and no one knows who to chase next. From our on-site observations, when a document completes without any receipt within 30 minutes, initiators tend to ask the same question 2-3 times, wasting communication effort.

What this strategy does is straightforward: once Kingdee has acknowledged the write, it automatically calls DingTalk's workflow notification API and posts a comment under the corresponding approval instance, echoing the document number, status, and result back to the initiator and approvers. This is not data synchronization — it is status receipt, making sure every ERP write is "heard" on the collaboration side.

Data Flow and Field Mapping

The chain has three legs: Kingdee Cloud Galaxy → Qeasy internal status validation → DingTalk workflow comment API.

Header fields (document number, document status, applicant) are obtained at the source validation stage. After assembly in Qeasy, they are passed as the comment body into DingTalk. Line-item fields are out of scope for this strategy — they belong to other strategies.

How to Configure It on Qeasy

In the Qeasy Data Integration Platform strategy editor, three configuration points deserve attention.

First, the source metadata selects "Request Null Operation" with type=QUERY. This step does not actually pull business data; it uses a lightweight look-up to confirm whether the previous node's Kingdee write is already visible. idCheck must be enabled — the platform uses the returned id field to decide whether the previous node really succeeded. If the upstream failed, this node is automatically skipped, preventing the awkward situation where "Kingdee didn't write it, but DingTalk still notified success".

Second, the target calls DingTalk's topapi/process/instance/comment/add, method=POST, type=EXECUTE. The request is an object containing the comment body, processInstanceId, and other fields. The key point here is that processInstanceId must come from the Qeasy runtime context, not hardcoded on the front end — the binding between the document and the approval instance is usually already written into the platform context by a preceding strategy.

Third, disable autoFillResponse and buildModel. The comment API is not sensitive to response content, so the platform does not need to generate a parsing model for it. This actually reduces unnecessary field-mapping maintenance. This is a common pattern on Qeasy for handling "notification-style" strategies: centralize code mapping management, but do not build models for every notification interface, saving long-term maintenance cost.

Implementation Steps

Phased scheduling is the key to whether this strategy runs reliably.

Step 1: Incremental starting point. After the upstream strategy writes the document into Kingdee Cloud Galaxy, this strategy's cron (1 1 1 2 3) acts as a fallback retry — the main chain is actually event-triggered, and this cron is more of a safety net for the rare case where an event is lost. The safe approach is: use event triggering for the main chain, and keep this cron as a health check every 3 hours.

Step 2: Full-volume triggering. Notification-type strategies usually do not run in full-volume; manual triggering is only needed during historical data repair — for example, when DingTalk approval instances are migrated, or after the workflow template changes and notifications must be re-issued. We typically use Qeasy's "manual trigger" plus "filter by document number" combination to precisely re-issue without bulk replay.

Step 3: Scheduling frequency. The target-side cron (*/7 8-22 * * *) runs every 7 minutes during working hours, covering 8 AM to 10 PM across most enterprises. Stopping outside working hours avoids disturbing initiators and avoids unnecessary DingTalk API calls.

Pitfalls and Lessons

Pitfall 1: Treating a notification strategy as a data synchronization strategy. A typical mistake is building full request/response models for the comment API, so that whenever DingTalk tweaks a field, a pile of mappings need updating. Safe approach: for notification APIs, only configure the required request fields, and disable autoFillResponse and buildModel.

Pitfall 2: Silent failures after disabling idCheck. Some engineers disable idCheck to "go faster", only to find that the previous node's Kingdee write failed and this node still calls DingTalk, sending a fake "success" notification to the business group. idCheck is the lifeline of this strategy — never disable it.

Pitfall 3: processInstanceId retrieved from the wrong place. Some people use the document number as processInstanceId, and DingTalk returns "instance not found". These two IDs come from different systems; the binding must be maintained in Qeasy's runtime context, never hardcoded on the front end.

Pitfall 4: Sensitive fields stuffed into the comment body. Kingdee echoes often contain customer names, amounts, and remarks; stuffing them all into the DingTalk comment leads to unauthorized visibility. The recommendation is to perform masking at Qeasy's field-mapping stage, only echoing the document number, status, and a one-line conclusion.

Pitfall 5: Mixing cron expressions with event triggering causing duplicate notifications. If the main chain is event-triggered and cron runs at the same time, two comments can be sent under extreme timing. Safe approach: event triggering as the primary, cron only for health checks, and the health check skips already-notified documents using a dedup key (document number + status).

When It Fits and When It Doesn't

Fits: Small and mid-sized enterprises where Kingdee Cloud Galaxy is the ERP backbone and DingTalk is the daily collaboration and approval entry point; document status changes need to immediately reach initiators and approvers; no appetite for building a dedicated notification service per document.

Doesn't fit: Complex notification scenarios that require rich-media cards, jumps to OA links, or role-based routing to different approvers; enterprises where neither Kingdee nor DingTalk is the primary approval chain.