Integration Solution for Kingdee Cloud Galaxy and DingTalk Master Data: Risk Supplier Onboarding Management

Scenario and Value

In supplier master data governance, some enterprises first onboard suppliers under a "risk supplier" category and decide whether to convert them to formal status after an observation period. This process typically involves two systems: the ERP maintains supplier master data and status fields, while the OA collaboration platform handles approval flows and notifications. When the two sides are disconnected, problems such as "approval passed but ERP not updated" and "overdue without reminder" become common.

This solution focuses on risk supplier onboarding management and designs bidirectional integration between Kingdee Cloud Galaxy and DingTalk around master data. Kingdee identifies risk suppliers by creation date and sends reminders; DingTalk receives approval results and writes them back to Kingdee to complete onboarding and unbanning. Incremental sync is used for daily operations, with full sync reserved for initialization and data repair.

Integration Architecture and Data Flow

The overall architecture consists of three parts: Kingdee Cloud Galaxy as the supplier master data source, DingTalk as the approval and notification channel, and the integration platform as the orchestration layer. The middle layer handles three responsibilities: lookup from supplier code to internal ID FSupplierId, mapping from organization code to DingTalk user ID, and dependency orchestration between upstream and downstream strategies.

There are two main data flows:

• Kingdee → DingTalk (reminder): The integration platform filters risk suppliers by FCreateDate. Matching records are sent to DingTalk as Markdown messages via batch robot messaging, reminding the responsible person to initiate the onboarding approval.

• DingTalk → Kingdee (writeback): After a DingTalk approval is passed, the integration platform retrieves approval details using the approval instance ID, first calling the Kingdee batchSave API to perform onboarding, then calling the Enable API to unban the supplier. These two strategies have a strict sequential dependency and cannot run in parallel.

There are four strategies in total, all of type SYNC: two push onboarding reminders from Kingdee to DingTalk, and two write approval results back to Kingdee. Reminder strategies are independent and can be scheduled in parallel; approval writeback strategies depend on the upstream approval instance ID retrieval and have a strict order constraint between themselves (onboarding first, unbanning second).

Interface List

Implementation Points

Phasing: The execution is split into two phases. Phase 1 covers reminder strategies and can run in parallel. Phase 2 is approval-driven and must strictly follow the order "approval instance ID retrieval → onboarding → unbanning". The two strategies in Phase 2 cannot be swapped, otherwise the status becomes inconsistent ("unbanned but not onboarded").

Code Mapping: Suppliers have two identifiers in DingTalk forms and Kingdee master data. The integration platform should use a hub to look up the supplier code and return the Kingdee FSupplierId internal ID. The mapping from organization to DingTalk user ID is best maintained centrally in a configuration layer using case-when logic, avoiding hardcoded values scattered across multiple sync tasks.

Incremental vs. Full: Daily operations use incremental mode—DingTalk pulls by start_time, Kingdee filters by FCreateDate. Initialization and data repair scenarios require removing time limits to pull the full dataset. Both modes should be switchable through a parameter within the same strategy, not maintained as two separate tasks.

Retry Handling: API timeouts and 5xx errors use exponential backoff (30s/60s/120s, up to 3 retries). DingTalk 429 rate limiting uses fixed 60s retry (up to 5 retries). Business validation 4xx errors are not retried and are routed directly to the alert queue. Code mapping failures retry once and then alert for manual investigation.

Alert Thresholds: Single-strategy failure rate above 10% triggers a warning; 3 consecutive failures escalate to critical. Code mapping failure rate above 5% triggers a warning. Alerts should point to the specific strategy ID and the most recent failed batch to help operations quickly locate the issue.

Best Practices

1. Make Sequential Dependencies Explicit: Approval writeback strategies have strong dependencies. Declare the order explicitly in scheduling orchestration rather than relying on fixed time windows.

2. Use a Centralized Hub: All code-to-internal-ID conversions should go through a single hub, avoiding duplicated lookup logic across strategies and easing future traceability.

3. Separate Configuration from Code: High-frequency changes such as organization-to-user mapping, robot codes, and message templates belong in the configuration layer, while business logic remains stable, reducing change risk.

4. Match Retry and Alert Levels by Error Type: Retryable errors (timeout, rate limiting) and non-retryable errors (business validation, missing mapping) should follow different branches, avoiding wasted retries that consume quotas or mask root causes.

5. Privacy by Design: The solution explicitly excludes sensitive information such as company names, API keys, and tenant IDs at the design stage. All environment-specific parameters are injected through configuration, which is helpful for multi-environment delivery and version reuse.

Conclusion

Risk supplier onboarding management is a typical scenario in master data integration: small data volume, but high requirements for state consistency and timeliness. Through clear phasing, explicit dependency declaration, and tiered exception handling, cross-system state synchronization can be brought onto a track that is observable, retryable, and alertable. The four-strategy, two-phase structure described in this article also serves as a reference template for other "status change + approval writeback" master data integrations.