Material Master Sync from Kingdee Cloud Cosmos to Jushuitan: A Practical Breakdown of One Strategy
What This Strategy Solves
In a real project at a retail enterprise, material master data had long been maintained in Kingdee Cloud Cosmos, while Jushuitan — the front-end e-commerce system — needed its own "product" records to support listing and order placement. When both sides relied on manual entry, after about three months the codes, names, and units of measure would inevitably drift, and all downstream order and inventory data would lose integrity. The problem this strategy addresses is straightforward: push material master data from Kingdee Cloud Cosmos, as the single trusted source, into Jushuitan's product records in near real time, keeping both sides consistent.
We used the Qeasy data integration platform to host this one-way synchronization link. Its role is "basic data sync," and with sequence A, it must run stably first in the entire supply chain integration.
Data Flow and Field Mapping
The data flow is clear: Kingdee Cloud Cosmos (source) → Qeasy integration platform (middleware layer for cleansing and mapping) → Jushuitan (target).
The table below summarizes the key field mappings we organized on site, selecting the parts most prone to pitfalls:
| Business Meaning | Kingdee Cloud Cosmos (Sample Source Field) | Qeasy Middleware Handling | Jushuitan (Sample Target Field) |
|---|---|---|---|
| Material code | FNumber | Pass through, used as unique key | Product code |
| Material name | FName | Strip leading/trailing spaces and invisible characters | Product name |
| Specification | FSpecification | Truncate overlong values, apply default placeholder | Specification |
| Base unit of measure | FBaseUnitId | Resolve to code via unit master | Unit |
| Material category | FCategoryId | Convert via category mapping table | Product category |
| Enable status | FUseOrgId / status field | Sync only "approved" records | Status |
| Barcode | Multi-row barcode subtable | Concatenate into comma-separated string | Barcode field |
One pattern commonly seen among Qeasy customers deserves special mention: centralized management of code mappings. Reference fields like units and categories should not be hard-coded into each strategy but maintained in a unified mapping table on the platform, so a single change takes effect everywhere.
How to Configure It on Qeasy
Configuration of this strategy on the Qeasy data integration platform can be summarized into five key points:
- Source system access: Configure the Kingdee Cloud Cosmos data source. It is recommended to use its open interface to query the material master view, filtering increments by "approved + last modified time."
- Target system access: Configure the Jushuitan product master write interface. Note that Jushuitan has strict requirements on product code length and character set — values that are too long or contain special characters will fail immediately at write time.
- Data mapping: In Qeasy's mapping canvas, lay out the field correspondences above. Reference fields use mapping tables; name-like fields use cleansing functions.
- Deduplication and idempotency: Use the material code as the idempotency key. The platform layer enforces upsert semantics, so repeated pushes will not create dirty data.
- Exception handling: Enable Qeasy's exception alerting channel. Single-record failures enter a retry queue; whole-batch failures block execution and notify operations.
The whole configuration does not require heavy scripting. The "header-body staged" pattern Qeasy customers often use is also applicable here — subtable data such as barcodes are first merged into a single field in the middleware layer, then pushed to Jushuitan, avoiding repeated record creation on the target.
Implementation Steps
When rolling out, we recommend proceeding in three phases:
Phase 1: Align the increment starting point. First perform a full sync, pushing all currently approved materials in Kingdee Cloud Cosmos to Jushuitan, establishing the baseline for subsequent increments. After this step, both sides must be manually spot-checked; only after confirmation should increments be enabled.
Phase 2: Full-sync trigger conditions. Full sync should not run daily but serve as a "compensation mechanism." We set up a manual trigger entry. When an increment fails one day or there is suspicion of data loss, operations can manually replay the full sync; it is normally closed by default.
Phase 3: Scheduling frequency. Material master data does not change frequently. Experience shows running increments every 15 minutes to one hour is sufficient. Qeasy supports scheduling via crontab expressions; the exact frequency can be tuned to the enterprise's actual modification volume. If the upstream approval flow is event-driven, it can also be switched to "event-driven" mode — once a document is approved, Qeasy pushes immediately. In actual Qeasy customer deployments, this approach saves more resources.
After the whole link has been stable for a week, downstream strategies (warehouse, customer, supplier, etc.) can be enabled. By then material codes are already aligned, and downstream strategies can safely depend on them.
Lessons Learned
This strategy looks simple, but the pitfalls encountered are numerous. The five most typical ones are:
- Inconsistent code character sets. Kingdee Cloud Cosmos allows a wider set of characters in material codes than Jushuitan. Codes containing slashes or spaces return HTTP 400 directly. The safe approach is to perform character-set validation in the middleware layer; non-compliant records enter the exception queue and are not allowed to pollute the target.
- Unapproved data slipping in. If the source system does not filter "approved," draft-state materials will also be pushed, creating a pile of half-finished products in Jushuitan. The classic mistake is forgetting to add status filtering in the source query.
- Unit of measure pushed as ID only. Kingdee Cloud Cosmos's FBaseUnitId is an internal code; Jushuitan needs the unit code, so the middleware layer must resolve it against the unit master — otherwise the units on both sides will not match.
- Subtable barcodes dropped. Barcodes live in the material's subtable. The default source interface returns only the master record; one must explicitly fetch the subtable rows and concatenate them. Skipping this step leaves Jushuitan products without barcodes.
- Full sync and increment racing. If the full-sync compensation and the increment scheduler run simultaneously, the same material may be overwritten twice. The safe approach is to add a mutex lock on the scheduler, or simply trigger the full sync manually during off-peak hours.
Applicable and Non-Applicable Scenarios
Applicable: Enterprises where Kingdee Cloud Cosmos serves as the ERP master data source and Jushuitan as the front-end business system, requiring consistent material/product master records on both sides. Scenarios with moderate change volume — tens to hundreds of modifications per day — are best suited.
Not applicable: If material master data is actually maintained in Jushuitan and Kingdee Cloud Cosmos is merely a downstream consumer, or if both sides require bidirectional editing — these scenarios should go through a Master Data Management (MDM) platform for unified distribution, not a one-way sync link. In addition, scenarios with SKU volumes in the millions and requiring sub-second sync fall outside the capability boundary of this strategy and require a separate streaming channel design.