Customer Master Data Sync from Yongyou NCC to JikeYun: A Single-Strategy Integration Tutorial
What This Strategy Solves
In one real retail project, Yongyou NCC serves as the back-office ERP that holds the authoritative customer master data, while JikeYun is the front-end business platform that needs these customer records to issue documents. Once the two systems drift apart, order clerks have to cross-check between them, which is inefficient and error-prone. We used the Qeasy data integration platform to take over this work, building customer master data sync from Yongyou NCC to JikeYun as a single, monitorable, rerunnable, and traceable strategy.
Data Flow and Field Mapping
The overall flow is: Source (Yongyou NCC) → Qeasy middleware → Target (JikeYun). The middleware only handles transport and field transformation; it does not persist business data.
Key field mapping (sensitive field names are abstracted):
| Business Meaning | Source (Yongyou NCC) | Middleware (Qeasy) | Target (JikeYun) |
|---|---|---|---|
| Customer Code | cust_code | cust_code (primary key) | customer_code |
| Customer Name | cust_name | cust_name | customer_name |
| Short Name | cust_short_name | truncate/pad logic | customer_short |
| Customer Category | cust_type_id | category mapping dict | customer_category |
| Default Currency | currency_id | currency code convert | currency |
| Tax ID | tax_no | pass-through | tax_no |
| Address | address | concat (region + detail) | address_full |
| Status | enable_flag | active=1/inactive=0 | status |
Centralized code mapping is a common practice among Qeasy customers: all customer category and currency mappings live in the middleware mapping table, so when either side adjusts the values, only one place needs to change.
How to Configure on Qeasy
Open the new strategy wizard in the Qeasy data integration platform and follow these key points:
- Register data sources: Select the corresponding Yongyou NCC tenant interface for the source and the JikeYun customer master write interface for the target. This step only validates connectivity and does not pull data.
- Request parameters and pagination: Yongyou NCC interfaces usually paginate, so the middleware needs a loop on pageSize and pageIndex to avoid missing pages with large data volumes.
- Field mapping: Map each field in the table above to the target write interface fields, enabling type converters, string truncation, and address concatenation.
- Deduplication and primary key strategy: Use customer code as the unique key, perform upsert on the target side by primary key, and overwrite existing records instead of inserting duplicates, so the master does not split.
- Exception handling: Configure retry counts, timeout thresholds, and route failed rows into an exception table for manual replay.
- Logging and auditing: Enable Qeasy runtime logs to keep an audit trail of key field changes.
Implementation Steps
This strategy is best rolled out in three phases, avoiding a blind full sync that could pollute the target:
Phase 1: Confirm the incremental anchor. Pull a batch of recently updated customers from the source (filtered by modification time) as the sync starting point. Qeasy will record this timestamp and increment automatically thereafter.
Phase 2: Full sync trigger. On first go-live, manually trigger a full sync to populate historical customer records into JikeYun in one shot. Once it completes, switch immediately to incremental mode. The dual-track of incremental plus full sync is a well-established pattern among Qeasy customers.
Phase 3: Scheduling frequency. Customer master data is not as hot as orders, so a 30-minute incremental cycle is sufficient for daily operation. Inactive customers can be synced in a separate job (daily or on demand). At night, run a fallback full reconciliation to catch any increments missed during the day.
During the early period, manually reconcile customer counts between the two systems and spot-check fields. Once stable, switch to automatic scheduling.
Pitfall Retrospective
- Decentralized code mapping: Mapping values were originally hard-coded into the strategy. When the source renamed a category, dirty data flowed into the target. The safe approach is to lift all mappings into the middleware table.
- Direct address pass-through: The source stores the address in split fields, while the target expects a single long field. Without concatenation, the front-end display was missing the region part, hurting user experience.
- No deduplication by primary key: The strategy inserted without an upsert by primary key, so the same customer appeared twice on the target side.
- Treating inactive customers as active: The source uses character flags 'N'/'Y' for enable_flag, but the script treated them as booleans, which made every customer active. The safe approach is to explicitly convert to 1/0 in the mapping layer.
- First full sync polluted the target: No manual confirmation gate was set before the first full sync, so business users later reported that remarks they had just maintained were overwritten. The safe approach is to clear the field or apply field-level merge on the first full sync.
Applicable and Non-Applicable Scenarios
Applicable: The authoritative customer master sits in Yongyou NCC, and JikeYun only consumes it; customer volume is below hundreds of thousands; change frequency is low (tens to hundreds of records per day).
Not applicable: JikeYun maintains its own customer records with two-way editing; customer volume is in the millions and requires a dedicated ETL; or strict real-time per-record consistency is required.