Material Master Query Sync: Pulling from Kingdee Cloud into Qeasy Integration Platform

What This Strategy Solves (Scenario & Value)

Syncing material master data from Kingdee Cloud into a CRM looks like a simple data move, but the most fragile part in real projects is how to reliably pull the source data out. Kingdee's material master is large, field-rich, and encoding rules often differ across organizations. Querying on-demand right before every CRM write puts heavy pressure on the source API, and if the target write fails, the source side has no clean rollback. The standard pattern is to first pull materials into the Qeasy data integration platform's intermediate layer on a schedule, and then distribute from there. This article focuses on that single "source query" strategy—getting Kingdee materials into the intermediate layer in a stable, rerunnable way is the starting point of the whole sync chain.

Data Flow & Field Mapping

The data flow is straightforward: Kingdee Cloud (source) → Qeasy data integration platform (intermediate layer) → CRM system (downstream target).

The source calls Kingdee Cloud's executeBillQuery (POST, type QUERY). The key fields are:

The target side of this strategy uses a "write no-op" WebAPI node, whose purpose is to persist the data into Qeasy's internal database so downstream strategies can consume it. This avoids tight coupling across systems.

How to Configure in Qeasy

When configuring this strategy in the Qeasy data integration platform, there are a few points the on-site engineer should pay close attention to:

1. Source selection: Pick the Kingdee.Cloud adapter on the source side. Authentication follows the customer's actual deployment (in private environments, this is typically account set + user + secret, with encrypted storage on the platform side).
2. API configuration: Select executeBillQuery as the API, method POST, effect QUERY, and enable autoFillResponse so the platform automatically fills the response into the target schema.
3. Primary key and number: Map FMasterId to the id field and FNumber to the number field, which makes idempotency and code mapping easier later.
4. idCheck and buildModel: Set idCheck to false and buildModel to false on the source side. Because this is a pure query strategy, we neither validate the primary key nor build a return model here—the platform writes source fields straight into the intermediate store.
5. Target node: Select Qeasy's own datahub platform as the target, with API "write no-op", which persists the data into the intermediate table for downstream strategies to read.

Implementation Steps

We typically proceed in the following rhythm on the customer site:

• Step 1: Confirm the incremental starting point. Before go-live, capture the latest material modification timestamp in Kingdee Cloud as the initial incremental anchor. Qeasy's source query node supports time-window filtering, so the first round does a full backfill with FModifyDate >= anchor.
• Step 2: Trigger one full pull. Manually trigger a full sync to pull all historical materials into the intermediate layer. Qeasy's full-task resumability is quite forgiving—engineers only need to watch for pagination and timeouts.
• Step 3: Switch daily schedule to incremental. Configure the source cron as 3 2 * * * (02:03) and the target cron as 23 2 * * * (02:23). The 20-minute offset ensures the source side lands data first, and downstream strategies consume afterwards, avoiding same-window contention.
• Step 4: Run dual tracks for observation. After go-live, keep a 1-2 week dual-track period—run the new chain while keeping the old sync window open, comparing material counts and sampling fields on both sides.

Pitfalls & Lessons Learned

Here are some real issues we've hit on customer sites:

• Pitfall 1: No pagination cap, Kingdee times out. Kingdee's executeBillQuery has a per-call row limit; without explicit pagination, it gives the illusion that "not all data was returned". The safe approach is to declare a page size explicitly on the source and implement looping on the Qeasy side.
• Pitfall 2: Material codes get renamed during pre-sync. Some customers run a "code mapping" strategy upstream that converts FOldNumber to a new code, but forget to add uniqueness on FNumber, producing duplicates in the intermediate store. The safe approach is to use FNumber + Organization ID as the composite unique key.
• Pitfall 3: Empty FName causes the whole record to be discarded. Because FName is required, poorly governed source data produces materials with blank names. Once Qeasy added a "required validation" rule, batches of blank-name materials were bounced back to the business team for rework.
• Pitfall 4: Schedules collide with peak windows. Both source and downstream target were set to 02:00, and Kingdee's monthly close job running that night made queries painfully slow. The 20-minute offset we use today is the result of several on-site tuning sessions.
• Pitfall 5: Network policy in private environments. The source sits in the customer's intranet and the target sits in Qeasy's intermediate layer. Cross-segment calls need a reverse proxy or whitelist; otherwise you get intermittent 502s.

When to Use and When Not to Use

Use when: Kingdee Cloud is the source of truth for material master, and you need to pull materials on a schedule into an intermediate layer before distributing to CRM, MES, WMS, etc.; the customer has multi-org or cross-set materials that must be centralized before mapping.

Don't use when: Material master is maintained on the CRM side and Kingdee is only a consumer; or the customer requires real-time point-to-point writes and rejects any intermediate layer.