Step-by-Step Transfer-In Order Approval Result Feedback: Closed-Loop Sync from Kingdee Cloud Cosmos to MySQL

What This Strategy Solves

In a typical MES/WMS-to-ERP integration, pushing the document over is only half the story. Whether ERP approved it and what transfer-in number ERP generated must be written back to the MES staging table, otherwise the loop is not closed. This tutorial dissects the approval result feedback leg of a step-by-step transfer-in order — running after the Kingdee Cloud Cosmos approval action, writing three key fields (is_success, message, ERP document number Number) back to a MySQL interface table.

Data Flow and Field Mapping

The end-to-end direction is "Kingdee Cloud Cosmos → Qeasy → MySQL". Qeasy itself plays two roles here: it acts as the polling trigger source and as the carrier — a no-op WebAPI (effect=QUERY) acts as the polling trigger that collects approval fields from ERP, and a SQL execution WebAPI (effect=EXECUTE) writes them back to the interface table.

Three mapping pitfalls to watch: is_sucess keeps that spelling at the source (verbatim from the source material, not a typo of mine), but maps to STATUS on the target; SuccessEntitys.0.Number is the first element's ERP document number and lands in erp_warehouse_num; sourceid must be carried in from the upstream strategy, otherwise the UPDATE cannot locate the row.

How to Configure It in Qeasy

Source (trigger) configuration highlights: choose API "Request No-Op", set effect to QUERY, method to POST, leave the request body empty, pre-declare is_sucess / result_message / SuccessEntitys in the response template with autoFillResponse enabled. This "no-op" pattern is commonly used as a heartbeat trigger — after an ERP approval event occurs, a status bit is written somewhere; Qeasy polls it at */3 * * * *, and once a value appears, the feedback leg fires.

Target (SQL writeback) configuration highlights: choose API update, method SQL. In request, place a single main_params object whose field value uses dot-path syntax like {{SuccessEntitys.0.Number}}. The actual SQL lives in otherRequest.main_sql and uses named parameter placeholders :message, :is_success, :time, :Id, :Number, :sourceid. Qeasy automatically binds same-name keys from main_params. Note the UPDATE condition where t1.instruction_doc_num = :sourceid — :sourceid flows in from the upstream chain and must not be hardcoded.

Dependencies and scheduling: place this strategy's sequence after the strategy it depends on, and have depends_on point to the upstream push strategy. The source uses */3 * * * * (three-minute cadence), the target uses */2 * * * * (two-minute cadence), forming a narrow "fast polling trigger, fast polling writeback" window.

Implementation Steps

1. Incremental starting point: at go-live, flag existing "pending feedback" rows in the MySQL interface table (e.g. attribute14 is NULL). The first polling cycle will pick them all up; afterwards it converges by status. Recommended: dry-run on 3 sample rows in a test environment before touching production.
2. Bring up the no-op trigger: configure the source "Request No-Op" in Qeasy, then use the log panel to verify that SuccessEntitys can be retrieved stably — if this step fails, do nothing further.
3. Configure the SQL writeback: fill in main_sql and main_params completely. Strongly recommend running the same parameters manually in Navicat/DBeaver first to confirm affected-row count.
4. Full-volume trigger: temporarily change the target scheduling to */1 * * * * to drain the historical backlog as quickly as possible. Once STATUS and erp_warehouse_num are correctly populated, switch back to */2 * * * *.
5. Converge scheduling frequency: after 24 hours of stable operation, observe the latency distribution of ERP approval callbacks, then tune both source and target intervals to values that neither waste resources nor miss business tolerance windows.

Pitfalls Revisited

• When SuccessEntitys is empty, the whole chain goes silent: Kingdee Cloud Cosmos may omit this array when approval fails. Without null-value guarding, {{SuccessEntitys.0.Number}} on the SQL side becomes null written into erp_warehouse_num. The safe approach is to add a null-value check at the source: on failure set is_success='N' and fill message with the error so the UPDATE still lands.
• Missing named parameter turns UPDATE into a table-wide update: when main_sql has a placeholder but main_params lacks the same-name key, some drivers bind the parameter as NULL, causing the UPDATE to hit far more rows than intended. Always inspect EXPLAIN and affected-row count in a test database before going live.
• sourceid not passed in, UPDATE degrades to full-table scan: this is the most common crash on real customer sites — the upstream strategy never propagates the MES document number into this strategy's context. Recommend explicitly declaring sourceid as an input parameter in Qeasy, and grepping the upstream strategy logs to confirm it actually arrives.
• Source field spelling is_sucess is not corrected: the source material spells it that way verbatim. Recommend adding an alias at the mapping layer to normalize it to is_success, so the typo does not leak into downstream SQL named parameters.
• Polling frequency too high kills MySQL: an UPDATE every two minutes is light on its own, but without an index on instruction_doc_num, accumulated IO can still climb.

When This Fits — and When It Doesn't

Fits: ERP approval results need to be written back to a MES/WMS staging table, and the business tolerates minute-level latency; the caller can already receive the approval callback fields and only needs to persist them in its own database. Does not fit: sub-second writeback requirements; ERP has no stable approval event to listen on, and the only option is timed full-table comparison; or the feedback must be re-broadcast to multiple heterogeneous downstream systems — in that case, write back to MySQL first and let each downstream pull separately, rather than overloading this strategy as a broadcaster.