Supplier Query Sync from Jushuitan to Kingdee Cloud Cosmos: A Single-Strategy Practical Tutorial

What This Strategy Solves

Pushing supplier master data from Jushuitan into Kingdee Cloud Cosmos looks like a simple "query once, write once" job, but in real projects the failure points all live at the edges: missed pages, misaligned modification-time windows, and missing code mappings that later break the link between purchase documents and suppliers. In this article we isolate one single strategy—Jushuitan Supplier Query ok—and focus only on the first half: incrementally pulling suppliers by modification time on the Qeasy data integration platform. The write side and downstream distribution are handled by other strategies.

Data Flow and Field Mapping

The overall direction is one-way: Jushuitan → Qeasy integration platform → Kingdee Cloud Cosmos. This strategy covers only the front half: the supplier.query interface on the Jushuitan side, which pulls suppliers incrementally by modification time and writes them into the Qeasy middle layer. On the target side, a no-op placeholder (api = 空操作, type = EXECUTE) is configured as a standard landing node, waiting for downstream strategies to consume the result set produced here.

Key field mapping:

Two mapping conventions must be remembered: first, the source uses supplier_id as the business primary key, and the target must adopt the same key—otherwise later documents (materials, purchase orders) suffer from "dual primary-key drift"; second, the modification-time window is injected automatically by the platform variables LAST_SYNC_TIME and CURRENT_TIME. A common pattern among Qeasy customers is to centralize these time variables in a single "variable dictionary" rather than scattering them across strategies.

How to Configure on Qeasy

Source metadata essentials: set api to supplier.query, type and effect to QUERY, method to POST, enable idCheck (used for dedup in incremental scenarios), and enable autoFillResponse so paginated results accumulate into the response array automatically. Keep buildModel as false—this strategy only cares about the supplier object and does not need a nested model.

Target metadata essentials: leave api empty or set it to 空操作, type to EXECUTE, leave request and response empty, and keep only the id field declared. This is a typical "placeholder strategy" pattern on Qeasy: the no-op first lands data into the middle layer, and once a downstream strategy (e.g., "Write Suppliers to Kingdee Cloud Cosmos") is ready, it simply depends on it. There is no need to force read and write into a single strategy.

On scheduling, the source strategy's crontab in the material is */13 7-23 * * *, meaning a run every 13 minutes during business hours. The target no-op's crontab is 15 2 2 2 *, which behaves more like a manual fallback node that is not triggered automatically in normal operation.

Implementation Steps

Step 1: Define the incremental starting point. Create a time variable LAST_SYNC_TIME on Qeasy. Before the first run, manually set it to a timestamp earlier than any business data (e.g., the start of a month) so the first run becomes a "cold-start full pull." Once that succeeds, let the platform automatically take the last successful execution time.

Step 2: Configure pagination and the time window. Use {{PAGINATION_PAGE_SIZE}} for page_size; the platform controls this uniformly (typically between 50 and 100, depending on the source system's rate limit). Strictly use platform time variables for modified_begin and modified_end—never hard-code them. A common customer pattern is to run "incremental" and "full" as two parallel strategies: high-frequency incremental for steady state, low-frequency full as a safety net, with no interference between them.

Step 3: Configure source-side primary key and dedup. Use supplier_id as both number and id, and enable idCheck so the platform enforces idempotency on this key, preventing the same supplier from being written multiple times.

Step 4: Wire the target no-op node. The no-op itself does not write to the target system; it only keeps a result set in the Qeasy middle layer. Downstream strategies such as "Write Suppliers to Kingdee Cloud Cosmos" then reference it via depends_on, forming an A → B strategy chain.

Step 5: Go live and observe. Watch three categories of logs first: whether pagination reaches the last page (no missed pages), whether modified_begin advances on every run, and whether idCheck reports a large number of duplicates. Only when all three behave normally should the frequency be raised.

Lessons Learned

• page_size was hard-coded to 200, and the source system immediately rate-limited. The safe approach is to use a platform placeholder and let ops tune it centrally.
• The modification-time window was hard-coded to a fixed value like 2024-01-01, so the incremental window stayed frozen and new data never came in. You must use platform variables such as {{LAST_SYNC_TIME|datetime}}.
• idCheck was disabled, so the same supplier was pushed again at the incremental window boundary, producing duplicate master records on the Kingdee side.
• Code mapping was scattered across strategies: System A codes, System B codes, and internal codes coexisted, and three months later nobody could tell which set was authoritative. The robust practice on Qeasy is to maintain a single "centralized code-mapping table" that every strategy references.
• Read and write were forced into the same strategy, so a write failure rolled back the read as well, and on retry the window drifted. The typical Qeasy response is to split header and body into phases, and split read and write into separate strategies—this article's scenario is the smallest unit of that pattern.

When It Applies and When It Doesn't

Applicable: source systems that expose only query-style interfaces, require modification-time-based incremental pulls, and benefit from landing results in the middle layer first before distribution—typical for supplier, customer, and material master data. Not applicable: scenarios that require real-time bidirectional sync, strongly consistent transactional writes, or where the source system simply does not support modification-time-based queries (in which case you must fall back to full pulls with strong validation).