MOM Plan Push Transfer Result Echo: A Lightweight Closed-Loop Practice from Kingdee Cosmos to MySQL
What This Strategy Solves
On the shop floor of a discrete manufacturing enterprise, after a planner presses "push transfer" on the MES side, they need to know whether the ERP actually generated that transfer document, what the document number is, and whether it succeeded.
If we only push the request without echoing the result back to MES, a common embarrassment occurs: "MES shows submitted, but ERP cannot find this document." Production schedulers then have to dig through ERP logs.
MOM-GXJH-Plan Push Transfer-Out (Universal)-Return solves this closed-loop problem. After the transfer document is generated in Kingdee Cosmos, it writes back the success flag, document number FBillNo, document internal ID FID, and result message to the MES-side MySQL interface table, allowing MES to directly see the ERP's final result.
Data Flow and Field Mapping
The overall direction is Kingdee Cosmos (via the Qeasy Data Integration Platform) → MySQL. In essence, this is a "result echo" rather than a master data push.
The source comes from intermediate results inside the Qeasy platform (callback messages triggered by the upstream strategy), and the target is the interface table in MySQL. Key fields are mapped as follows:
| Source Field (Qeasy Side) | Target Field (MySQL) | Meaning |
|---|---|---|
is_sucess | status | Processing success flag |
GXZYWYJS_FBillNo | erp_operation_handover_num | Transfer document number |
GXZYWYJS_FID | erp_operation_handover_id | Transfer document internal ID |
result_message | message | Processing message returned by ERP |
sourceid | batch_id + iface_sequence | Batch ID + row sequence (locator) |
Note an important detail: iface_sequence = 1 triggers the main update, while iface_sequence = 3 only updates FID and FBillNo without changing the status. This is a common practice of splitting "header info echo" and "status echo" into two SQL statements, often called "header and body phased" by Qeasy customers in the field.
How to Configure on Qeasy
The source metadata is a WebAPI-type "empty operation request" (QUERY). Its job is to "wait for the result" without actively calling external interfaces. What truly triggers the echo is the upstream strategy pushing messages into this strategy's queue. When configuring, set autoFillResponse to true; response fields (the left column in the table above) are auto-injected by the upstream with no manual assembly.
The target is MySQL's SQL execution (EXECUTE), which requires two SQL statements:
- Main SQL (
main_sql): with the conditionbatch_id = :sourceid and iface_sequence = 1 and status not in ('S','A'), only updating non-terminal records to avoid overwriting already-successful rows; - Extended SQL (
extend_sql_1): conditioniface_sequence = 3, only echoingFIDandFBillNo, not changingstatus, leaving it for subsequent status-echo strategies.
Another configuration note: the value of "centralized encoding mapping management" on Qeasy here is that the enum values of status (success/failure/abnormal) are uniformly defined by the mapping table. If we later need to adapt another ERP, we only swap the mapping, not the SQL structure.
Implementation Steps
We recommend going live in three stages: incremental starting point, full trigger, scheduling frequency.
- Incremental Starting Point: First, do a cold start with a batch of historically generated but un-echoed data. Run the full SQL once to fill in
FID/FBillNo, avoiding the difficulty of troubleshooting when old and new data are mixed together. - Full Trigger: On the first day of go-live, manually trigger all
iface_sequence = 1records that are not yet successful on the Qeasy platform. After confirming the echo result is correct, then enable scheduled polling. - Scheduling Frequency: Source
*/7 * * * *, target*/1 * * * *. That is, the platform pulls result caches every 7 minutes, and SQL lands every minute. This frequency difference of "sparser upstream, denser downstream" keeps up with upstream callback rhythm while avoiding missed records.
Pitfall Recap
1. Missing status not in ('S','A') causes repeated overwrites. This is the most typical pitfall: successful records get echoed multiple times. Although the value stays the same, logs make it look like ongoing updates, misleading engineers during troubleshooting. The safe practice is to always carry this filter in the main SQL.
2. Stuffing FID echo and status echo into one SQL. Doing it all at once seems convenient, but it will also flip intermediate-state records on iface_sequence = 3 to terminal status, breaking subsequent status strategies. Stick to header and body phased.
3. Keeping upstream's original field name with typos (is_sucess). This is not Qeasy's fault; the source ERP returns it misspelled. We recommend renaming is_sucess to is_success in the mapping to prevent contamination to all downstream tables.
4. Setting the same frequency on both ends causing backlogs. When both source and target use */1 * * * *, the target will run empty when the source has no new data. Set the source sparser and the target denser — it's stable and resource-efficient.
Applicable and Non-Applicable Scenarios
Applicable: After MES submits a plan, scenarios where the ERP document number is needed to continue subsequent processes, such as shop-floor work reporting and cost aggregation.
Not applicable: Master data (item, BOM) sync, and scenarios requiring real-time push (second-level) such as workstation material calling — this strategy runs on a minute-level cadence and lacks real-time capability. Additionally, if Kingdee Cosmos is not enabled, there is no result to echo, and the strategy will idle.