Querying Kingdee YXC Measure Units: A Practical Configuration from Source System to Qeasy Middle Layer

What This Strategy Solves

Measure units are the most overlooked yet error-prone part of product master data. In one real project at a retail enterprise, the front-end sales runs on Jushuitan while the back-end finance and inventory run on Kingdee YXC. Both sides need basic units such as piece, box, and kg to stay aligned. It sounds simple, but as soon as the source system adds a new unit like pallet without pushing it to the target side in time, downstream documents start failing because the unit cannot be resolved. The core value of this strategy is to use the Qeasy Data Integration Platform to periodically pull measure unit master data from Kingdee YXC into a middle layer that serves as the reference for other sync chains, such as product master and inventory.

Data Flow and Field Mapping

The chain is a one-way query-then-write flow: Kingdee YXC V2 → Qeasy Integration Platform (middle layer) → No-op write (target side). The source system calls a WebAPI GET endpoint, and the target side is a no-op write whose purpose is to receive and stage data inside the platform rather than write directly to another business system.

Key field mapping:

The number field on the source side acts as a placeholder for business code, while id is used as the idempotency key (idCheck: true). The target side is an EXECUTE-type node with method POST that represents a no-op write; both request and response are empty, which is by design—the data lands in the platform's internal staging.

How to Configure on Qeasy

When we implemented this strategy, the configuration fell into three blocks.

Source platform configuration: Select Kingdee YXC V2, set the API path to /jdy/v2/bd/measure_unit, method to GET, effect to QUERY. Setting pagesize to 100 is a solid compromise—too large risks hitting rate limits, too small increases request count. Keep idCheck turned on; reconciliation later depends on it.

Target platform configuration: Select the Qeasy Integration Platform (datahub) as the target platform, with the API set to the no-op write. There is a deliberate engineering reason for staging data in the middle layer instead of writing to a business database directly: decoupling. If measure units later need to be distributed to a third system, we only need to add another strategy off the middle layer, leaving the source-side pull logic untouched.

Request and response mapping: On the request side, expose search, pagesize, and page as inputs. On the response side, pass id and name through directly. Keep autoFillResponse enabled so the platform fills the response template automatically, reducing manual configuration errors.

Implementation Steps

We recommend a three-phase rollout.

Phase 1: Initialize the incremental starting point. Manually trigger a full pull to bring over every existing measure unit from Kingdee YXC. On Qeasy, this is just a click on "Run Manually". The goal is to verify connectivity and field mapping.

Phase 2: Set the schedule. The source strategy's crontab is */5 8-20 * * *, meaning every five minutes between 08:00 and 20:00. This rhythm was set on-site based on the client's business tempo—retail orders are dense during opening hours, and unit changes usually accompany new product launches, so a high-frequency daytime pull keeps downstream data fresh. The schedule does not run overnight because the source system may be in its maintenance window. The target-side crontab is 1 1 1 1 1, which translates to firing only once during the initial full load; subsequent increments are driven by the source-side schedule alone.

Phase 3: Stage header and body separately. Measure units themselves do not have header/body semantics, but a common pattern on Qeasy is to let base data (measure units, categories) stabilize first, then run product master, and finally inventory and documents. Code mapping is centralized on the platform's mapping table, so adding a new unit makes the cross-system reference immediately visible.

Lessons Learned

Pitfall 1: Ignoring pagination causes data loss. The Kingdee YXC endpoint is paginated. If pagesize is too small or page iteration is forgotten, the run stops midway under the false impression that there is no more data. The safe practice is to enable the pagination loop on the Qeasy source strategy so the platform increments page automatically until the response is empty.

Pitfall 2: Mixing id and number as unique keys. The source metadata leaves number unset while using id as the idempotency key. If we additionally set number as a unique key, any historical duplicate in the source would cause the entire batch to fail. Recommendation: treat only id as the primary key and use number as a business reference only.

Pitfall 3: Trying to write to a real business system on day one. A typical mistake is to push measure units straight into a business database, only to find later that a schema change forces the whole chain to be rebuilt. This illustrates the dual-track approach of incremental and full loads: stabilize the data flow first with a no-op write target, then consider landing it elsewhere once the data quality is confirmed.

Pitfall 4: Unreasonable crontab intervals. We have seen clients set */5 as */1, which means once per minute and quickly overwhelms the source system. Five minutes is the value born of experience—fresh enough and forgiving enough for the source to recover.

Pitfall 5: Misconfigured fuzzy search input. If the search field is not explicitly cleared, some versions of the API interpret it as "search everything" and return unexpected data. Recommendation: explicitly set search to an empty string in the request template.

When to Use and When Not to Use

Use when: scheduling pull jobs for base master data, aligning reference data across multiple systems, or scenarios that need to land data in a middle layer before distribution. Do not use when: bidirectional sync of measure units is required, writes must target a real business system rather than a middle layer, or sub-second real-time delivery is required instead of minute-level near real-time delivery.