Assembly Production Date Backwrite Sync: A Practical Guide from MySQL to Kingdee Cloud Cosmos

What This Strategy Solves

For a manufacturing enterprise running assembly lines with Kingdee Cloud Cosmos as the production order system, a recurring but easily overlooked issue appears: when the MES side updates an assembly production date on a document, MES needs to write back a "synced" flag so that the next sync cycle does not treat the same record as new data. It looks like a simple flag update, but without a dedicated strategy, after three months the "synced" versus "unsynced" counts in the MES report will drift apart.

This strategy is essentially a one-way backwrite: the source side issues an empty query, the Kingdee Cloud Cosmos side executes a flag-write call, and the platform writes the result into a state table on the MES side. The schedule runs every two minutes. It carries no business fields, only a status bit, acting as the closing step of the production sync chain.

Data Flow and Field Mapping

The full chain is: MySQL (MES side) → Qeasy Data Integration Platform (middle layer) → Kingdee Cloud Cosmos (target system) → writeback to the MES state database.

There are only three key fields, all transparently passed from the source through the middle layer to the target:

The source API is effectively a POST "no-op request" interface that returns only these three fields. The target API is Kingdee Cloud Cosmos's ZZdate2 WebAPI, method POST, effect EXECUTE. The request body uses _function CONCAT to assemble the three variables into the JSON that Kingdee requires. The mapping table is intentionally thin. A common practice on the Qeasy platform is to centralize such thin mappings into a "light mapping table" so that every strategy does not redeclare the same fields.

How to Configure on Qeasy

On the Qeasy Data Integration Platform, this strategy is implemented as a pair: a source strategy plus a target strategy.

Source configuration notes

• Platform type: the MySQL adapter.
• API: select the no-op or custom query interface, method POST, effect QUERY.
• Response fields: only tick formId, fid, and rowsid; ignore the rest.
• Enable autoFillResponse so the platform builds the response automatically, avoiding manual data shaping.
• Turn on idCheck for deduplication.

Target configuration notes

• Platform type: the Kingdee Cloud Cosmos adapter.
• API: select ZZdate2, method POST, effect EXECUTE.
• The request body uses _function CONCAT to assemble the three variables into the JSON that Kingdee expects, with the FormId field wrapped in _function.
• Leave response fields empty since the execute-style API does not consume a response body.
• Also turn on idCheck.

Some practices we often see on customer sites: keep thin field mappings in a centralized mapping table, put all schedules in the strategy's crontab field rather than scattered across executors, and use the sequence field to control the execution order of multiple strategies on the same business object. This strategy can sit near the end of the sequence.

Implementation Steps

Step 1: Define the incremental start point. This strategy does not move business master data, so "incremental" must be reinterpreted. It moves "records whose flag has not yet been written back." Add sync_flag = 0 AND update_time > last_sync_time to the source SQL or query conditions, so only unflagged records are picked up.

Step 2: Trigger one full run to validate the chain. On the go-live day, manually trigger a full run. Observe whether Kingdee's ZZdate2 returns correctly and whether the MES state database is updated. Persist Kingdee's error codes to a log table for easier troubleshooting.

Step 3: Switch to high-frequency scheduling. Configure crontab as */2 * * * *, running every two minutes. A common pattern among Qeasy customers is the "incremental plus full dual-track": the scheduler runs incremental during the day, and a nightly window runs a full reconciliation. Since this strategy only writes flags, the nightly full run can be once per day.

Step 4: Exception handling and retries. Configure retries three times with exponential backoff; alert the ops chat when consecutive failures exceed a threshold.

Step 5: Reconcile daily during the first week after go-live, focusing on whether the count of "unsynced records on the source" converges toward zero over time.

Lessons Learned

Pitfall 1: Treating the no-op as a business query. The source API only returns three identifier fields. A junior engineer initially configured it like a normal query, pulling in unrelated fields and bloating the mapping table by three times. The safe approach: only tick the three fields you need, and enable autoFillResponse.

Pitfall 2: Variable case mistakes inside _function CONCAT. The request body on the Kingdee side is case-sensitive. Writing {{Formid}} instead of {{formId}} will trigger a null pointer error on the Kingdee side. Always run a "debug execution" once after setup and visually inspect the assembled JSON.

Pitfall 3: Forgetting to enable idCheck. Without it, the platform does not deduplicate by document primary key, so the same record gets flagged repeatedly. Source logs may show the same formId appearing several times within one minute.

Pitfall 4: Setting the schedule too aggressively. Some teams initially set it to every 30 seconds, which tripped Kingdee's rate limiter and got the source IP blocked. Every two minutes is the safe value learned the hard way. You can tune it for heavier business volumes, but only after confirming Kingdee's QPS limit.

Pitfall 5: Backwriting header and body in one shot. If the production date lives on the header and the status field lives on the body, split them into two phases: first write back the header flag, then the body flag. Otherwise a single record can end up half-updated.

When It Applies, and When It Does Not

Applies: backwriting lightweight fields on production orders or assembly documents such as sync flags and last-modified timestamps; indirect sync where the source cannot directly write to the target; high-frequency but low-load polling scenarios.

Does not apply: full sync of business master data (items, BOMs, routings); cross-organization bulk data migration; scenarios that demand millisecond-level real-time reconciliation — those should be event-driven rather than polled.