Product Master Data Sync: Practical Guide to the No-Op Strategy from Guanyi Cloud to Qeasy
What This Strategy Solves (Scenario and Value)
In supply-chain integration between Guanyi Cloud and Kingdee Cloud Cosmic, product master data is the first thing that must be connected. In one real project, we encountered a retail enterprise that wanted to sync product records from Guanyi Cloud into Kingdee Cloud Cosmic, but downstream document sync is highly sensitive to consistency in product codes, names, and units of measure. If you use source data as target data directly, even small discrepancies will cause sales orders and inventory to drift within three months.
The safer approach is to build a "staging product catalog" layer inside the Qeasy Data Integration Platform first, sink the source product data into a unified schema, and then let downstream use this layer as the single source of truth when generating Kingdee materials and product records. The "Guanyi-Product -> Qeasy-No-Op" strategy discussed in this article is exactly the loading strategy for this staging layer: write the product data into the Qeasy staging table first, and do not perform any substantive transformation at the target end—hence the name "no-op."
This step looks like mere transport, but its value lies in three places: first, it creates a single source of truth on which all downstream strategies depend; second, code mapping can be managed centrally rather than scattered across sync tasks; third, it lays the groundwork for splitting header and body data into phases later.
Data Flow and Field Mapping
The data flow is: Guanyi Cloud (product records) -> Qeasy staging product table -> (consumed by downstream strategies) -> Kingdee Cloud Cosmic materials and other master data.
Key field mapping:
| Business Meaning | Guanyi Source Field (Example) | Qeasy Staging Field | Notes |
|---|---|---|---|
| Product code | item_code | product_code | Unique key, recommend a unique index in advance |
| Product name | item_name | product_name | Long text, watch for newline cleanup |
| Specification | spec | spec | Do not trim in the staging layer |
| Unit of measure | unit | unit | Keep the original unit, no conversion |
| Barcode | barcode | barcode | Merge multiple barcodes with a separator |
| Category path | category_path | category_path | Prevent inconsistent hierarchy levels |
| Active status | is_active | status | Boolean mapped to a unified enum |
At this stage we recommend "as-is transport": code mapping and unit conversion are pushed downstream so business rules do not leak into the loading step.
How to Configure It in Qeasy
Configuring this no-op strategy in the Qeasy Data Integration Platform typically has three parts:
-
Source connection: Pick the Guanyi Cloud connector and fill in authorization per the official docs. Credentials must be stored in Qeasy's credential vault, not scattered in scripts—this is where many customers run into trouble on-site.
-
Target table modeling: Create the staging product table in Qeasy. We recommend a unified prefix for field names (e.g.,
product_*) so it can be referenced by multiple downstream strategies. Build the schema by adding source fields first; resist the urge to delete fields too early. -
No-op mapping: Map source fields to staging fields 1:1, and tick "no transformation at target." This is the heart of the no-op strategy—we deliberately avoid business rules at this step and centralize all rules in the downstream consumption strategies.
There are a few common patterns we see Qeasy customers adopt: centralized code mapping (maintain a mapping table next to the staging table, shared by multiple strategies), header/body phased delivery (complete the product master layer first, then prices and inventory), and dual-track incremental + full sync (incremental by update time in production, one-shot full sync during initialization).
Implementation Steps
We recommend a three-phase rollout:
Phase 1: Incremental starting point. Start with incremental extraction by the product's update_time field, with the incremental cursor stored in Qeasy's cursor manager. Each run reads only records after the last successful timestamp, avoiding duplicate pulls.
Phase 2: Full sync trigger. Use a full sync as a cold start during initial go-live to move all existing products into the staging table at once. The safe approach is to switch back to incremental only after the full sync finishes, and run a "reconciliation task" to compare row counts on both sides.
Phase 3: Scheduling frequency. Product master data usually does not change very often, so we suggest running incremental every 15–30 minutes. When setting up scheduled tasks in Qeasy, remember to link dependent downstream strategies so they trigger only after the staging data has settled.
If the customer requires higher real-time performance (such as live-streaming e-commerce scenarios), the schedule can be tightened to every 5 minutes, but you must monitor the source system's API rate limits.
Lessons Learned
Pitfall 1: Smuggling business rules into the no-op strategy. A typical mistake is performing code conversion or unit conversion while loading. Downstream strategies then find conflicting rules and the mapping has to be revised again. The safe approach is to use the no-op strategy for transport only and centralize all rules in the downstream consumption layer.
Pitfall 2: Ignoring soft deletes in the source. Products in Guanyi Cloud are often "deactivated" rather than physically deleted. If you only sync the active flag and ignore the deactivation timestamp, downstream keeps seeing historical products. We recommend using both status and update_time on the source side instead of relying on a single field.
Pitfall 3: Inconsistent naming in the staging table. Different engineers use different naming styles across strategies, creating chaos later when joining tables. We recommend Qeasy customers adopt a unified prefix in the staging layer, such as product_*, and maintain a field dictionary document.
Pitfall 4: Skipping reconciliation after the full sync. After the full run, the numbers on both sides look correct, but dirty historical data may have been missed. We recommend configuring a one-shot reconciliation task in Qeasy to compare source row counts against staging row counts, and trigger an alert when the difference exceeds a threshold.
Pitfall 5: Scheduling frequency out of balance with API rate limits. If the incremental interval is too tight, the source system's QPS cannot sustain it; if too loose, product changes lag. Our rule of thumb is to start with half of the rate-limit ceiling stated in the official docs, then tune gradually based on alerts.
When to Use and When Not to Use
Use it when product master data needs to be staged before distribution, when upstream and downstream code conventions differ, when you want centralized code mapping, or when you need mixed incremental + full sync scheduling.
Do not use it when upstream and downstream already share the same product codes and no staging layer is needed, or when product changes are extremely frequent and end-to-end real-time expectations reach the second level—in that case, use a real-time message channel instead of a staging table.