Jushuitan Product Master Data into Qeasy: A Single-Strategy Sync Playbook
What This Strategy Solves
A retail client runs Jushuitan for online storefronts and Kingdee Cloud Xingchen for offline finance and inventory. After three months, SKUs, units, and barcodes drift apart between the two systems, and purchasing, warehousing, and e-commerce teams start pointing fingers.
The first step we took was to land the "product master data" on a single integration platform—exactly what this "Jushuitan → Qeasy" strategy does. It does not push to Xingchen on its own; it only collects, cleans, and stages Jushuitan's product records into the Qeasy middle layer as the shared input for the 40+ downstream strategies.
Data Flow and Field Mapping
The link is unidirectional pull: Jushuitan (e-commerce backbone) → Qeasy Integration Platform (middle layer) → consumed by downstream strategies. This strategy only covers the first half.
Key field mapping:
| Business meaning | Jushuitan source | Qeasy middle layer | Notes |
|---|---|---|---|
| Product code | sku_id | product_code | Primary key, must be stable |
| Product name | name | product_name | UTF-8, watch special chars |
| Category path | category_name | category_path | Joined with "/" |
| Base unit | unit | base_unit | Dictionary must be unified |
| Barcode | barcode_list | barcode | Multi-barcode as array |
| Status | status | is_enabled | Boolean enabled/disabled |
| Last modified | modified | _updated_at | Acts as the delta cursor |
Principles: source field names pass through unchanged into the middle layer; dictionaries (units, brands, categories) are mapped centrally in Qeasy so downstream stops translating.
How to Configure It in Qeasy
We use the Qeasy Data Integration Platform to carry this out. The point of configuration is not "connecting an API," it is describing the strategy semantics clearly.
- Source connection: choose the Jushuitan adapter and authorize. We recommend a dedicated read-only account just for integration, which makes auditing and revocation easy.
- Request template: the Jushuitan product endpoint is typically paginated by modified time; the template needs page_size, page_no, modified_begin, modified_end.
- Field mapping: map field by field in Qeasy's canvas. For dictionaries (unit, category), attach a centralized mapping table—never hard-code them in a script. Change once, propagate to all downstream. This is one of the most common patterns among Qeasy customers.
- Data quality rules: product_code non-null and length-compliant, barcode format check, is_enabled must be boolean. Non-compliant rows go to an error queue; do not silently drop them.
- Target write: land into Qeasy's "Product Master" business table, used as input for "Qeasy → Xingchen Material" and other downstream strategies. Do not try to push to Xingchen at this step—phasing header and body separately is another repeatedly validated engineering practice.
Implementation Steps
We recommend three phases:
- T0 — Full initialization: first-time rollout pulls all existing products from Jushuitan into Qeasy. Run during off-peak hours, paginated at 500 per page, with write throttling (empirically 20–50 records/sec, adjust per load test). After completion, run a reconciliation: source total vs middle-layer total, and locate differences by SKU.
- T1 — Delta starting point: set the modified timestamp at the end of T0 as the cursor. Qeasy persists this cursor by default, so a restarted job resumes from the checkpoint—no losses, no duplicates.
- T2 — Schedule frequency: poll every 15 minutes. Jushuitan product changes are not frequent, so 15 minutes keeps online updates timely without exhausting the API. During promotions, switch temporarily to 5 minutes.
Dual-track: regular delta runs continuously, and a weekly full reconciliation on the same data domain catches any mid-week misses.
Field-Tested Pitfalls
- modified gets distorted by manual ops. Some Jushuitan operations (like bulk repricing) refresh modified without changing the product itself; using modified as the sole cursor produces "no-op updates." Compare key business fields (name, unit, status) and only push when they actually change.
- Multi-barcodes get truncated. The source barcode_list is an array; legacy code treats it as a string and keeps only the first one, breaking POS integration later. Preserve the array structure in the middle layer and split rows only when the target can handle them.
- Unit dictionary not unified. Jushuitan's "piece" and Xingchen's "piece" may not be the same UOM. Build the centralized mapping table first, or the numbers will always be off by a step.
- Discontinued items get mistakenly deleted. Jushuitan "disabled" is not "deleted," but Xingchen treats deletion as physical. Mark a soft-delete flag (is_enabled=false) in the middle layer; do not filter at the source, or historical documents cannot be traced back.
- Full reload collides with delta. If delta opens before the full load finishes, both write to the same table and cause primary-key conflicts. Always serialize: full load finishes → lock the table → confirm → then open delta.
When to Use and When Not to
Use when: Jushuitan is the single source of product master data and you need to land it on a middle platform for multiple downstream consumers; multi-store, multi-owner setups that need a unified SKU view.
Do not use when: Jushuitan and Xingchen both maintain product archives (causing primary-key conflicts, requiring a more complex merge strategy); SKU volume is very large (millions) with high change frequency, where streaming CDC is more appropriate than polling.