Jushuitan and Xiaobangbang Master Data Integration: Product and Goods Synchronization Design

Scenario and Value

In retail and e-commerce business scenarios, the ERP system manages goods, inventory, and orders, while the CRM system handles customer, opportunity, and sales process follow-up. When these two systems operate independently for extended periods, problems emerge at the master data level: inconsistent product codes, fragmented category systems, and scattered customer records. These issues frequently cause coding mismatches and duplicate data entry when business documents such as sales orders and quotations flow across systems.

This solution targets the master data domain of products and goods, treating Jushuitan's goods (including combo products) as the authoritative source and synchronizing them to Xiaobangbang CRM's product library. At the same time, a group of query strategies pull product, product category, and customer master data from the Xiaobangbang side, providing the idCheck and code mapping references required by downstream synchronization strategies. The entire solution adopts a two-phase execution model of "query first, then synchronize," running stably in a private deployment environment and supporting subsequent expansion to business document-level integration.

Integration Architecture and Data Flow

The overall workflow consists of 6 strategies, divided into two phases by responsibility:

Phase 1: Master Data Query

• Query Xiaobangbang products: Call the /pro/v2/api/product/list endpoint to paginate and pull product master data; results are written only to the platform storage as the reference baseline for subsequent synchronization strategies.
• Query Xiaobangbang product categories: Call the /pro/v2/api/product/categoryList endpoint to pull category data; the original response is a tree structure (containing childList), which needs to be recursively flattened to a top-level list in the script.
• Query Xiaobangbang customers: Call the /pro/v2/api/customer/list endpoint to paginate and pull customer master data; results are written to platform storage for use in subsequent business document mapping.

Phase 2: Master Data Synchronization

• Synchronize Jushuitan goods to Xiaobangbang product management: Use Jushuitan sku_id and Xiaobangbang data.serialNo as the mapping keys for idCheck; if not matched, process as new addition.
• Synchronize Jushuitan combo products to Xiaobangbang product management: Based on regular product synchronization, mark the product type as "combo" and map child items as needed.

Both synchronization strategies depend on the product query and product category query from Phase 1; customer query and product synchronization execute in parallel without blocking each other.

Interface List

A represents Jushuitan, B represents Xiaobangbang.

Implementation Points

Core Field Mapping Rules

Key mappings from Jushuitan goods to Xiaobangbang products are: sku_id → data.serialNo, name → name, category → categoryId (looked up through category query), sale_price → price. Combo product synchronization marks productType as "combo" on this basis and maps child items as needed.

Category Mapping Handling

The product category endpoint returns a tree structure, with each node potentially nesting childList. The integration script needs to recursively flatten childList to the top level after source data is pulled; otherwise, downstream mapping can only retrieve root-level categories. When a Jushuitan category has no corresponding category on the Xiaobangbang side, it is recommended to log an alert and use a default category or skip that record to avoid blocking subsequent synchronization.

Code Mapping and idCheck

Establish product code mapping using Jushuitan sku_id and Xiaobangbang data.serialNo; establish category mapping using category names and categoryId; cross-system customer code referencing uses serialNo. Before synchronization strategies execute, idCheck is completed using Phase 1 query results: a miss in the query is processed as new addition, a hit is processed as update.

Exception Handling

For network or interface timeouts, use exponential backoff to retry 3 times (30s, 60s, 120s); for rate limit 429, use linear backoff to retry 5 times. Single-record failures are written to the failure queue without blocking subsequent data; alerts are triggered when the same strategy fails ≥5 consecutive times, when queue backlog exceeds 1000, or when code mapping is missing. For batch submission, 20–50 records per batch is recommended; a single batch failure does not affect other batches.

Best Practices

Scheduling Strategy

Product query in Phase 1 is recommended to execute every 30 minutes (daily 8:00–21:00); product category query executes once daily in the early morning or every 2 hours; customer query executes every 20 minutes. Goods synchronization in Phase 2 is recommended to execute every 9 minutes, and combo product synchronization every 8 minutes. All synchronization strategies must start after Phase 1 completes idCheck and category mapping.

Full Reconciliation

In addition to incremental synchronization, it is recommended to perform full reconciliation once weekly during off-peak business hours. Do not pass modified_begin/modified_end or pass a wide time range when synchronizing Jushuitan goods; do not paginate or pass conditions when querying Xiaobangbang, or traverse all data by fixed pagination.

Security and Privacy

During implementation, actual connection parameters must be configured in the integration platform following the principle of least privilege. Authentication credentials required for Xiaobangbang API calls must be securely stored and avoided in plaintext in logs. Solution documents and code should not contain real customer names, company names, keys, or other sensitive information.

Expansion Suggestions

After master data synchronization runs stably, expansion can proceed to sales orders, quotations, payment collection, and other business document levels. The customer query and product query results from Phase 1 already provide ready-made mapping foundations for these extensions, requiring no duplicate construction.