Practical Tutorial on the Query Kingdee Warehouse Strategy: Pulling Warehouse Master Data from Source to Qeasy

What This Strategy Solves

In a supply chain integration project for a retail enterprise, warehouse master data is the foundation for all downstream documents (purchase receiving, sales shipment, transfers, inventory counts). With Kingdee Cloud Stellar as the ERP backbone and a frontend business system handling daily operations, warehouse information must flow from Kingdee to the frontend first, otherwise downstream documents stall due to missing warehouse records. This "Query Kingdee Warehouse" strategy is essentially a read-only pull action—it pulls warehouse records from Kingdee to the Qeasy middleware layer on a scheduled basis, providing an up-to-date data source for the downstream "Kingdee Warehouse → Frontend Warehouse" write strategy. Since it does not write to the target system, its positioning is a "data supply link" rather than a "sync link."

Data Flow and Field Mapping

The data flow is unidirectional: Source System (Kingdee Cloud Stellar) → Qeasy Middleware Layer (write no-op, only persist) → Awaiting consumption by downstream strategies.

The source API is Kingdee Cloud Stellar's executeBillQuery, POST method, with Qeasy acting as the caller pulling the warehouse list. On the target side, the metadata api is "Write No-Op", which is a common pattern on Qeasy—the upstream only supplies data, while the actual write is left to subsequent strategies. idCheck=true enables primary key validation to prevent duplicate persistence.

How to Configure on Qeasy

Enter the strategy orchestration interface of the Qeasy Data Integration Platform. Select Kingdee Cloud Stellar as the source system and Qeasy middleware (datahub) as the target platform.

Key configuration points: First, select executeBillQuery as the source API, method=POST, effect=QUERY, and choose the warehouse master as the business object. Second, in the field mapping, configure FStockId as the primary key field and FNumber as the business code field, with autoFillResponse=true so Qeasy automatically populates the response into the intermediate table. Third, keep the target metadata as a no-op, only triggering the persist action, with crontab set to a placeholder value like 1 1 1 1 1. The actually effective schedule is the source-side crontab: */5 7-23 * * *—every 5 minutes, only during business hours (7 AM to 11 PM).

For code mapping, a common practice among Qeasy customers is centralized management: maintain a unified warehouse code mapping table in Qeasy's mapping center, rather than hardcoding it in each strategy. This strategy itself does not write to the target, but the downstream "Kingdee Warehouse → Frontend Warehouse" write strategy will directly reuse this mapping.

Implementation Steps

We typically follow three steps at the customer site.

Step One: Initialize Full Sync. When the project first goes live, pull all warehouses from Kingdee at once as baseline data. This step is usually triggered manually. After completion, verify that the record count in the middleware matches the Kingdee source table.

Step Two: Switch to Incremental. After the full sync completes, the strategy enters its normal scheduling cycle—pulling every 5 minutes. There's a detail here: Qeasy's incremental logic is idempotent based on FStockId, so pulling the same warehouse multiple times only updates, never inserts.

Step Three: Link with Downstream Strategies. After this strategy executes, the middleware layer triggers the downstream "Kingdee Warehouse → Frontend Warehouse" strategy to write the latest warehouse records to the frontend system. The entire chain follows the typical header-table phased pattern—supply data first, then consume, decoupling the two phases.

In terms of scheduling frequency, basic master data synchronization usually does not require real-time; 5-minute intervals are sufficient. If the customer is latency-sensitive, it can be compressed to 1 minute; if there are concerns about source system load, it can be relaxed to 15 minutes. The key is to consider the tolerance of downstream documents.

Lessons Learned

First, a common pitfall is business hours configuration. The source crontab is written as */5 7-23 * * *, meaning no pulls during the early morning hours. However, some customers run daily closing or overnight inventory counts, during which data also changes, causing the middleware to be stale when business opens the next day. The safe approach is to confirm the data change window with the business side—either widen the time range or trigger a manual pull after daily closing.

Second, a typical mistake is ignoring the FGroup field. Warehouses in Kingdee may be grouped by region or business line. If everything is pulled without grouping, the downstream strategy will retrieve redundant data when filtering by department. It is recommended to filter by FGroup in the request parameters or configure it in Qeasy's filter component.

Third, idCheck must be enabled. We have seen a real case where a customer disabled idCheck, and once the Kingdee API returned a duplicate FStockId, the middleware persisted two records. When the downstream write reported a primary key conflict, the entire chain was stuck for half an hour.

Fourth, do not take the no-op target for granted. api: Write No-Op is a Qeasy convention indicating that this round does not call an external write API, only persisting to the intermediate database. Newcomers may mistakenly configure the target system of this strategy as Kingdee or the frontend system, causing the strategy to run empty.

Fifth, those placeholder values like describe: "111" in field descriptions look like garbled text, but are actually historical placeholder descriptions that do not affect runtime. However, if the customer has requirements for documentation standards, it is recommended to re-maintain the field labels and descriptions in Qeasy to facilitate subsequent operations handover.

Applicable and Non-Applicable Scenarios

Applicable: Private deployment scenarios where Kingdee serves as the ERP backbone and needs to unidirectionally supply basic master data such as warehouses, suppliers, and materials to the middleware layer for downstream business system consumption.

Not Applicable: Scenarios requiring bidirectional synchronization of warehouse records (Qeasy recommends splitting into two independent strategies); nor for warehouse change pushes requiring extremely high real-time performance with second-level latency—for these, a message queue is recommended instead of scheduled polling.