Overview of Master Data Integration between Jushuitan and Xiaobangbang

Scenario and Value

A mid-sized e-commerce seller runs Jushuitan as its back-end ERP and Xiaobangbang as its front-end CRM and sales platform. New product listings, price changes, and category edits happen first in Jushuitan, then get manually re-entered into Xiaobangbang hours later. Customer records live in two systems with two different code systems. During a promotion, the front-end quotes SKUs that have already been delisted, and sales reps submit orders against the wrong customer ID. Reconciliation only catches up three days after the holiday — not because the ERP failed to capture the data, but because there is no automated closed loop.

We split the chain into two phases: align master data first, then layer business documents on top. This article covers only the master data phase — six strategies that bring products, combo products, categories, and customer records into alignment between the two systems, paving the way for sales orders, payments, and other business documents.

Integration Architecture and Data Flow

The architecture has two directions:

• Jushuitan → Xiaobangbang: write product master data and combo product master data into Xiaobangbang's product management. This is the real "write" direction.
• Xiaobangbang → Qeasy (query landing): pull products, product categories, and customer master data from Xiaobangbang into the local store, used as the basis for idCheck and code mapping. This direction is read-only.

Execution is split into two stages:

Stage 1 — Master Data Query (3 + 1 strategies)

• Query Xiaobangbang products, landed by data.serialNo, used as the idCheck basis for subsequent sync strategies;
• Query Xiaobangbang product categories, mapping Jushuitan's category/c_id to Xiaobangbang's categoryId;
• Query Xiaobangbang products (backup channel) for different scheduling cadences or disaster recovery;
• Query Xiaobangbang customers, build customer master data mappings, ready for downstream sales order integration.

Stage 2 — Master Data Sync (2 strategies)

• Jushuitan products → Xiaobangbang products: depends on the product and category queries from Stage 1;
• Jushuitan combo products → Xiaobangbang products: also depends on Stage 1, with productType=Combo and optional child-item expansion.

When we delivered this on the customer site, the orchestration was carried by the Qeasy Data Integration Platform's visual strategy flow. Query strategies and sync strategies are chained by dependency order, while Stage 2 internal strategies can run in parallel.

Interface List

Note: A = Jushuitan, B = Xiaobangbang.

Implementation Highlights

Staged scheduling. Query strategies run first, sync strategies run after. Strategies 4 and 6 can run in parallel internally, but both must finish after the current run of Strategies 1 and 2.

Incremental fields. Pull increments from Jushuitan via modified_begin/modified_end; iterate Xiaobangbang queries page by page and dedupe by serialNo.

Full reconciliation fallback. Run a full reconciliation during the weekly business low period to clean up missed records and orphans.

Centralized code mapping. The three mappings — sku_id → serialNo, category → categoryId, dataId → Jushuitan customer code — are maintained centrally in Qeasy's mapping tables rather than scattered across transformation scripts. This is a common pitfall: mappings embedded per strategy get out of sync fast and become very hard to debug.

Exception retry. Network/timeout errors: exponential backoff 30s/60s/120s, up to 3 retries. 429 throttling: linear backoff, up to 5 retries. Single-record failures go to the failure queue without blocking subsequent records. Alert immediately if a strategy fails ≥5 consecutive times or the queue backlog exceeds 1000.

Batch submission. Strategies 4 and 6 should submit dataList in batches of 20–50 records. A failed batch must not impact other batches.

Privacy handling. The design itself carries no customer identifiers, tenant info, or secrets. At implementation time, credentials are encrypted and hosted by Qeasy's credential management module, and logs are field-level masked per configuration.

Best Practices and Pitfalls Revisited

1. Build the mapping before any write. A common mistake is to bulk insert everything, which produces duplicate product codes in Xiaobangbang. The safe approach: confirm the Stage 1 query strategies have fully landed the current product set before running sync strategies, then decide insert vs update by data.serialNo.
2. Don't force category mapping. Some Jushuitan categories have no counterpart in Xiaobangbang; passing empty values writes dirty data. Add "alert + skip when no mapping found" at the mapping layer, and let the business confirm whether a new category should be created before re-feeding.
3. Separate strategies for combo products and single products. Mixing combo products with ordinary products in one strategy causes productType and child-item expansion logic to contaminate each other. On the customer site, we split them into Strategies 4 and 6 so they don't interfere.
4. Stagger queries and syncs. Query strategies run every 20–30 minutes, sync strategies every 8–9 minutes, and every sync run must strictly follow the current run of the query strategies. Otherwise "write before query" causes false positives in idCheck.
5. Run full reconciliation during low periods. Schedule the weekly full fallback during off-hours or non-promotion days to avoid competing with increments for resources.

When to Use Qeasy

When master data needs to stay aligned across multiple SaaS systems over the long term, and the business requires hourly or even minute-level freshness, the Qeasy Data Integration Platform is a good fit. Its differentiators: visual dependency orchestration, centralized code mapping, out-of-the-box exception retry and alerting, and private deployment that can carry sensitive links like customer master data — a copy from ERP to CRM no longer depends on manual re-entry.