Query Kingdee Employees Strategy in Practice: Configuring Employee Master Data Sync from Kingdee Cloud via Qeasy

What This Strategy Solves (Scenario & Value)

During an MES rollout at a manufacturing enterprise, we kept running into the same problem: shop-floor dashboards, work reporting, and shift-lead dispatch all need a single, authoritative source of employee master data. The source of truth lives in Kingdee Cloud, but the downstream Four-Industrialization MES (a shop-floor execution system) does not want to call Kingdee directly. It wants to read a clean, code-indexable employee table from a local intermediate layer.

We used the Qeasy data integration platform to handle this. The "Query Kingdee Employees" strategy becomes a source-to-intermediate-layer pull. The intermediate layer is declared as a "write no-op" placeholder, and every downstream strategy that needs employees reads from it. This avoids direct connections from downstream systems to Kingdee, and gives us one place to investigate anomalies such as "this employee is gone".

Data Flow and Field Mapping (Source → Intermediate → Target)

The flow is one-way: Kingdee Cloud → Qeasy intermediate layer, and the intermediate layer exposes employee fields to consumers. The source side calls the standard Kingdee executeBillQuery API against the employee form. The key field mapping is:

The target metadata uses "Write No-Op". This is a typical placeholder pattern: the Kingdee side is only queried, never written back. Qeasy takes the result and writes it to the intermediate table, and the actual consumers are downstream MES strategies such as dispatch and work reporting.

How to Configure in Qeasy

Open the Qeasy strategy editor. Set the source system to Kingdee Cloud and the target to the Qeasy integration platform (the intermediate layer). Choose strategy type QUERY.

Source-side configuration:

• API: executeBillQuery, method POST, effect QUERY.
• Set number to FName and id to FID. Turn off idCheck, because this query is by name and does not depend on a primary-key write-back.
• In the request array, select FNumber, FID, FName, FMobile, FEmail, FPostDept as the columns to return.
• Since this is a filtered query, add a FilterString in the Qeasy request parameters, for example by FUseOrgId or by modification date, to avoid pulling the entire table at once.

Target-side configuration:

• API: "Write No-Op", method POST.
• Keep idCheck true, because the downstream MES uses FID for idempotency.
• Leave response and otherResponse empty, since no return value is consumed; the actual persistence is handled by the Qeasy intermediate layer.

A common pattern here on Qeasy is centralized code mapping: the mapping between Kingdee FID and the intermediate layer's own surrogate key is maintained in a single Qeasy mapping table. Any downstream strategy that needs "Kingdee employee code ↔ MES personnel code" looks it up there, instead of scattering the logic across strategies.

Implementation Steps

On real projects we run three phases:

1. Phase 1: Incremental baseline sync. Trigger once manually to pull employees modified in the last 30 days, forming the initial intermediate-layer dataset. The source uses FilterString with FModifyDate >= 'YYYY-MM-DD'. This is a one-time step to establish a baseline.

2. Phase 2: Full-load reconciliation. Run without a filter, then compare the full result against the baseline. Check that headcount and department distribution match. If the gap is large, investigate first: did Kingdee switch organizations, are disabled employees included, and so on. Only after this passes do we proceed.

3. Phase 3: Schedule production. The source strategy crontab is set to * 7-22 * * * (every hour from 07:00 to 22:00), covering working hours so the latest employees are available before each shift. The intermediate layer "Write No-Op" crontab is left as 1 1 1 1 1, a template placeholder that does not actually execute.

This is the Qeasy-style incremental and full-load dual track: full-load for reconciliation, incremental for production. When something breaks, fall back to the full-load comparison and you usually find the cause quickly.

Lessons Learned

A few things that burned us in the field:

1. A typical mistake is treating the full-load result as production data. executeBillQuery returns employees who have left but were not deleted. If you do not filter them, the intermediate layer contains "ghost employees" that MES dispatch can still select. The safe approach is to add a filter such as FStatus = 1 in the request, or to drop them in a Qeasy cleansing script.

2. Using FID as the primary key can mislead you when Kingdee re-issues IDs. In rare cross-organization transfer scenarios Kingdee generates a new FID. Downstream that has already joined on FID will silently miss the change. We recommend a stable business key (FNumber) as the real primary key in the intermediate layer, with FID as auxiliary.

3. Null in mobile or email breaks strict-JSON consumers. These fields can be null in Kingdee's response and a strict schema downstream will throw. In Qeasy field mapping, set the default value to '' for these two columns so null becomes an empty string, and the issue goes away.

4. Do not copy crontab expressions blindly. The source side * 7-22 * * * is meant for a frequently queried source during working hours. The intermediate placeholder 1 1 1 1 1 is template-default and should not be changed. Always re-read the expression when duplicating a strategy.

5. In private deployments the Kingdee API host must be on the internal network. Qeasy runs on the internal network, so the source platform host must resolve to the internal Kingdee API gateway; otherwise the integration job will keep timing out. This is easy to miss in the system prompts.

When It Applies and When It Does Not

Applies: Kingdee Cloud is the HR/organization source of truth, downstream systems such as MES, WMS, and SRM need stable employee/department/position master data, and the project is private-deployment with an intermediate layer (Qeasy) that can host it.

Does not apply: scenarios where employee data is written back to Kingdee at high frequency and demands sub-second latency, or where downstream systems must call Kingdee directly without an intermediate layer. In those cases the source-to-intermediate pattern becomes a bottleneck, and a CDC or event-driven design is more appropriate.