Stepwise Stock Transfer-In Query Sync in Practice: MySQL → Kingdee Cloud Cosmos
What This Strategy Solves
Stepwise stock transfer-in documents are multi-stage inventory transfer records in the supply chain. In a real project, a customer needed to pull intermediate process data of transfer-in documents from MySQL into Kingdee Cloud Cosmos on a schedule for archiving and reconciliation. It looks like a simple "query," but because each document goes through multiple status changes, any misstep in scheduling, incremental cursors, or field alignment will cause mismatches between the two systems within three months.
Data Flow and Field Mapping
The overall flow is MySQL (source) → Qeasy Data Integration Platform (middleware) → Kingdee Cloud Cosmos (target). The source side holds the detail and status tables of the stepwise transfer-in document, while the target side pulls the document back through Kingdee's executeBillQuery API and writes the result into an archiving table.
Key field mapping:
| Business Meaning | MySQL Source Field | Middleware Canonical Name | Kingdee Field |
|---|---|---|---|
| Entry primary key | entry_id | entry_id | FSTKTRSINENTRY_FEntryID |
| Document primary key | fid | fid | FID |
| Document number | bill_no | bill_no | FBillNo |
| Document status | doc_status | doc_status | FDocumentStatus |
| Stock-in org | stock_org_code | stock_org_code | FStockOrgID.FNumber |
| Business date | biz_date | biz_date | FDate |
Pay special attention to the status enum mapping: draft Z, created A, approving B, approved C, re-approved D. If the source uses numeric statuses like 0/1/2, you must translate them in the middleware layer; otherwise the target will reject the payload.
How to Configure on Qeasy
On the Qeasy platform, this strategy is a typical "source-pull + target-query" combination. There are four key configuration points:
First, configure a composite incremental cursor on the MySQL source. Use update_time + entry_id rather than a single field. Single-field cursors lose data under concurrent updates. Store the incremental starting point in an environment variable so you can rerun the full volume easily.
Second, use executeBillQuery on the target rather than save. The essence of this strategy is to rhythmically pull existing transfer-in document data from the target system back into the middleware for archiving, not to trigger Kingdee's save logic. Check fields like FEntryID, FID, FBillNo, FDocumentStatus, FStockOrgID.FNumber, and FDate in the request body; the platform auto-fills the response.
Third, centralize code mapping. A common pattern at customer sites is to maintain all cross-system org, warehouse, and account code mappings in Qeasy's "Unified Code Mapping Table" instead of scattering them across each strategy. When codes change, you update one table instead of touching hundreds of strategies.
Fourth, handle headers and line items in phases. For stepwise transfer-in documents, header status changes and line entry changes don't happen at the same time. The safe approach is to stabilize header processing first, then add line items; otherwise debugging becomes very hard.
Implementation Steps
Take a three-step scheduling approach:
Incremental Starting Point: Before the first go-live, record the maximum update_time of historical transfer-in documents in MySQL as the initial value of the incremental cursor. Write this value into an environment variable in the Qeasy source configuration to avoid replaying historical data.
Full-Volume Trigger: Run a full sync on go-live day to align all status, date, and org code data for historical transfer-in documents. Trigger the full sync with a one-shot crontab, then disable it. Don't leave it running long-term.
Scheduling Frequency: Source-side MySQL polling at */5 * * * * is recommended; target-side Kingdee writes should go during off-peak hours, e.g. 23 2 * * *. This is a typical dual-track setup: high-frequency pull on the source, low-frequency write on the target.
Pitfall reminder: don't set high frequency on both sides. The Kingdee query API has QPS limits. A 5-minute poll on the source is fine, but a 5-minute poll on the target will trigger throttling.
Lessons from the Field
Pitfall 1: Passing status values through directly. The source uses 0/1/2 while the target expects A/B/C/D. Passing values through unchanged will cause Kingdee to reject the data as dirty. The safe approach is to add an enum translation layer in the field mapping on Qeasy, shared by all strategies.
Pitfall 2: Losing data with single-field cursors. Using only update_time as the incremental cursor drops records updated in the same second. Switch to a composite update_time + entry_id cursor, which is directly supported on the platform.
Pitfall 3: Forgetting to disable the full-volume job. Running a full sync on go-live day is correct, but if the crontab isn't changed to one-shot, it runs all night and the source database CPU alarms the next morning.
Pitfall 4: Missing dependency declarations. Stepwise transfer-in documents depend on upstream production orders or transfer requests. If depends_on is not configured in Qeasy, downstream strategies run before upstream ones, scrambling the data order.
When to Use and When Not to Use
Use for: stepwise transfer-in documents and similar supply chain documents with frequent status changes that need scheduled archiving; source is a relational database like MySQL, target is Kingdee Cloud Cosmos in a private deployment. Do not use for: documents with one-time status confirmation (such as purchase warehousing), scenarios requiring real-time latency under 5 minutes, or scenarios that need to trigger writes on the target rather than queries.