[Query Only] Kingdee Organization Info: A Lightweight Probe Strategy from WDT to Kingdee Cloud
What This Strategy Solves
In supply-chain integration projects, "query-only, no-write" strategies are often underestimated. In one retail enterprise's integration blueprint, there are 40+ sync strategies, among them a deceptively lightweight one: [Query Only] Kingdee Organization Info. It writes nothing anywhere, but plays a critical role—it pulls Kingdee Cloud's organization master data (code, name, org ID) back into Qeasy Data Integration Platform on a schedule, so downstream write strategies can validate code mappings in real time.
We use Qeasy (Qeasy Data Integration Platform) for this. The goal is not to move data, but to act as a "probe + cache." Once organization info changes, downstream strategies for items, customers, and warehouses won't fail because of stale codes.
Data Flow and Field Mapping
The data flow is clear: Kingdee Cloud is the sole source system. Through its query API, organization master data is pulled into Qeasy. The target is a "write no-op," meaning data lands in the platform's own storage and is not pushed to any downstream business system.
Key field mapping:
| Source Field (Kingdee Cloud) | Meaning | Middleware Field (Qeasy) | Required | Notes |
|---|---|---|---|---|
| FNumber | Org code | FNumber | Yes | Primary key, anchor for downstream mapping |
| FName | Org name | FName | Yes | Used for manual verification |
| FOrgID | Internal org ID | FOrgID | No | Auxiliary field for anomaly locating |
| Limit | Max rows per page | PAGINATION_PAGE_SIZE | Yes | Kingdee pagination parameter |
| StartRow | Starting row index | PAGINATION_START_ROW | Yes | Kingdee pagination parameter |
A subtle but important design point: number is explicitly set to FNumber, id is set to FOrgID, and idCheck=true. This means Qeasy uses FOrgID as the idempotency key during pull, preventing the same org from being duplicated across pagination boundaries.
How to Configure in Qeasy
On the source side, choose "Kingdee Cloud · executeBillQuery" WebAPI, POST method, effect type QUERY. On the target side, choose "Qeasy Data Integration Platform · Write No-op," effect type EXECUTE. Data only lands in the platform's own org cache table—no business DB is touched.
Three configuration highlights:
- Request body construction: Use Kingdee's
executeBillQueryinterface. Inject the pagination parameters Limit and StartRow intootherRequest. Qeasy's built-in paginator auto-pages until exhausted. - Response mapping: Since the target is write-no-op,
autoFillResponse=truemust be enabled so the platform auto-fills query results into the middle table according to the request field order. - Scheduling: Source crontab is
0 0 * * *(daily midnight). Target crontab is1 1 1 1 1(placeholder, never actually fires). This "real schedule on one side, placeholder on the other" is a typical pattern for read-only probe strategies.
Implementation Steps
We recommend a phased rollout:
Step 1: Launch in "Full Pull" mode. On first run, let Qeasy pull all organization records from Kingdee Cloud as a baseline snapshot. Verify that the middle-table row count matches the source org total.
Step 2: Switch to "Incremental + Scheduled" mode. Once the full pull is clean, attach the strategy to a daily midnight schedule. Since it's query-only, the incremental cursor naturally is "last successful pull timestamp"—no complex watermark management needed.
Step 3: Wire downstream strategy dependencies. In Qeasy's strategy orchestration, set the depends_on of item, customer, and warehouse write strategies to point to this strategy. If org info sync fails, downstream strategies auto-pause, preventing invalid codes from being written into Kingdee.
Step 4: Periodic reconciliation. Monthly spot-check that FNumber in the middle table matches Kingdee Cloud's inventory orgs and admin orgs.
Pitfalls and Lessons Learned
Pitfall 1: Treating "query-only" as "no idempotency needed." A typical mistake is disabling idCheck, which causes the same org to be pulled twice at pagination boundaries, creating one-to-many mapping downstream. Safe practice: always keep idCheck=true, use FOrgID as the dedup anchor.
Pitfall 2: Misplacing pagination parameters. Kingdee's Limit and StartRow belong in otherRequest, not request. Some engineers put them in the main request body, and Kingdee's API directly rejects them.
Pitfall 3: Setting a real schedule on the target side. If both sides run on 0 0 * * *, the platform misinterprets it as a full "sync" and triggers an unnecessary no-op write chain. The target side must use a placeholder expression to disable real scheduling.
Pitfall 4: Downstream strategies don't notice org master changes. One manufacturing enterprise hit this: Kingdee renamed an org, but downstream item strategies kept using the old code. The fix is to enable downstream dependencies on this strategy and centrally manage the "code → name" mapping in Qeasy's code-mapping module.
When to Use and When Not
Use when: As a master-data probe for multi-strategy dependencies; when you need real-time org-code validation without business writes; for cross-system org master consistency audits.
Don't use when: You need to write org info back to any business system (use a standard SYNC strategy instead); org master changes frequently and sub-minute freshness is required (use real-time event triggers instead of scheduled queries).