Query Kingdee Users: A Lightweight Sync Strategy from Kingdee Cloud · Skyline Edition to the Middle Layer

What This Strategy Solves

User master data is the "front-end referrer" for sales orders, delivery notes, and collection notes. If a user code cannot be found in the middle layer, every downstream document with "creator" or "salesperson" fields will stall or write empty values. We used the Qeasy Data Integration Platform to do something that looks small but is critical: pull user records from Kingdee every night into the middle layer as a prerequisite for business document sync.

Data Flow and Field Mapping

The flow of this strategy is special: the source is Kingdee Cloud · Skyline Edition, and the target is not another business system but the Qeasy middle layer (datahub).

• Source system: Kingdee Cloud · Skyline Edition, calling POST /kapi/v2/xkbase/bos_user/queryUserList, with pagination parameters pageNo=1, pageSize=100, the primary key field is id, the code field is name.
• Target system: Qeasy Integration Platform (datahub), writing a no-op (WebAPI POST), used to form a "user snapshot" in the middle layer that downstream strategies can reference.

Key field mapping (Source → Middle Layer):

Note: source-side idCheck=true and autoFillResponse=true are the standard configuration for Qeasy read-type strategies. The former ensures the same user is processed only once, and the latter lets response fields automatically map to the target structure, eliminating manual modeling.

How to Configure on Qeasy

1. Register the source platform: In Qeasy's "System Integration", add "Kingdee Cloud · Skyline Edition", fill in the platform code Kingdee.QJB, and maintain the access credentials for the private deployment environment (intranet domain and account are kept separately at the customer site and do not appear in the strategy).
2. Register the target platform: The target end is Qeasy's own datahub platform, with fixed code datahub, no additional credentials required.
3. Create a read strategy: Select the "Query Kingdee Users" template, and set crontab to 3 2 * * * (pull at 2:03 AM, offset from downstream strategy execution windows).
4. Source-side configuration: Choose the API /kapi/v2/xkbase/bos_user/queryUserList, keep only three fields in the request body: data (object, can be empty), pageNo, pageSize, and set the page size to 100 based on the customer's data volume.
5. Target-side configuration: Choose the "Write No-Op" WebAPI to let the data settle directly into the middle layer as a query source for other strategies.
6. Field mapping: Check idCheck and autoFillResponse, map id to id, and name to number.

Implementation Steps

We break the rollout of this solution into three stages:

• Stage 1: Establish connectivity. At the customer site, run a manual test on Qeasy first to confirm that the first page of 100 user records can be retrieved; otherwise, do not proceed to the next stage.
• Stage 2: Set the incremental starting point and full-volume trigger. User records are pulled in full every day at 2:03 AM (crontab: 3 2 * * *), and written to the middle layer (crontab: 23 2 * * * means the middle layer persistence happens at 2:23). idCheck=true ensures that users that reappear daily are only updated, not duplicated, naturally forming a "full scan + incremental dedup" dual-track.
• Stage 3: Incorporate downstream dependencies. When downstream strategies such as sales orders and delivery notes read "salesperson code", they uniformly query this user snapshot in the middle layer instead of connecting directly to Kingdee. This significantly reduces the failure rate of downstream strategies, because once user records are stably present in the middle layer, downstream only cares about the documents themselves.

Lessons Learned

1. Direct pull without pagination, Kingdee will truncate. A typical mistake is missing the pageSize configuration, resulting in only a few records on the first page being returned. The safe approach here is to let the Qeasy paginator take over pageNo, and fix only one page size of 100 on the source side.
2. Treating user master data as "business documents" and over-modeling. User sync is only a pre-snapshot; there is no need to go through the save interface. Using a "Write No-Op" to land it in the middle layer is sufficient; there is no need to push it into Kingdee.
3. crontab not staggered, downstream gets hammered. If user pulling runs after business document sync, downstream strategies will miss frequently. We recommend pulling users at the earliest hour of the morning (2:03), and persisting them to the middle layer at 2:23, giving downstream a clear "available window".
4. idCheck not enabled, duplicate data accumulates. With a daily full pull, if dedup is not relied on via idCheck, the middle layer will be repeatedly overwritten. This is the place where Qeasy read-type strategies are most likely to fail.
5. Centralized code mapping management. We recommend centrally maintaining the "Kingdee code ↔ business code" mapping in Qeasy's "Code Mapping" module rather than scattering it across each strategy's scripts. This way, when the customer later adds new user types, only one place needs to be modified.

Applicable and Non-Applicable Scenarios

Applicable: Kingdee Cloud · Skyline Edition private deployment, user records are relatively stable (daily change < 5%), and downstream has a large number of business documents that need to reference user codes. Not applicable: scenarios where user changes are extremely frequent and real-time reverse lookup into Kingdee is required; as well as scenarios where the user data volume is very large and a single full pull exceeds 100,000 records (should be changed to incremental batch-by-department).