MOM Plan Push Report Return Practical Tutorial: Writing Back from Kingdee Cloud Cosmos to MySQL Interface Table

What This Strategy Solves

In a manufacturing MOM (Manufacturing Operations Management) chain, pushing a plan order from MES down to Kingdee Cloud Cosmos is only half the work. After the workshop completes the report in Kingdee Cloud Cosmos, the approval status, document number, and entry ID need to flow back to the MES interface table so that subsequent shopfloor operations, work reporting, and inbound can continue. The typical pain point is: report documents are frequent, but the MES interface table can only be updated idempotently by business key. Once the return link breaks, the workshop dashboard shows an orphan state of "reported but MES did not receive it." This strategy takes on this "write-back" link. We use the Qeasy data integration platform to write the report results from Kingdee Cloud Cosmos back to the MySQL interface table by plan document key, keeping both sides consistent.

Data Flow and Field Mapping

The data flow is relatively simple: the source side is an internal trigger on the Qeasy platform (based on the execution result of the previous "Plan Push Report" strategy), and the target side is two interface tables in MySQL. The key field mapping is as follows:

Note that the status semantics of the two tables are not exactly the same: the report table uses S/A for success/exception, while the inbound interface table uses N/A for not-processed/exception. When writing back, you must land values according to each table's own semantics and cannot simply copy the field values over.

How to Configure on Qeasy

The source metadata uses a "request empty operation" (autoFillResponse=true) WebAPI QUERY. In practice, it does not perform real data retrieval but serves as the execution entry and parameter carrier for the entire strategy. The actual data is already in the context of the preceding strategy.

The target metadata uses WebAPI EXECUTE + SQL to land data into MySQL. Here are several typical configuration points:

1. Header and extension SQL in phases: main_sql handles hme_operation_report_iface, and the extension SQL extend_sql_1 handles hme_prd_instock_iface. This "header-body phased" pattern is very common in Qeasy customer supply chain integrations. Splitting the multiple tables that need to be updated in the same transaction makes failure retry and per-table compensation easier.
2. Idempotency built into the WHERE clause: conditions like status not in ('S','A') and status not in ('N','A') are written directly into SQL, meaning rows already in success or exception terminal state will not be overwritten a second time. This is the third gate beyond the increment-and-full dual-track approach: state-machine idempotency.
3. Business keys parameterized: bind variables such as :fid, :FEntity, :fbillno, :is_success, :result_message, :iface_id, :operation_type, :source_id all come from the source side. Field names must stay consistent with the upstream strategy; otherwise, the value comes in but does not land in the column.
4. idCheck=true: the target side enables ID check to prevent dirty data from being inserted repeatedly.

Implementation Steps

When we deliver this solution for a customer, we usually proceed in three phases:

• Phase 1: Increment starting point. First, define the filter condition for "to be written back" — that is, records in the MySQL interface table whose status falls in the updatable range. It is recommended to pick about 50 historical records from the past week for replay to verify mapping and state machine correctness.
• Phase 2: Full trigger. The source crontab is set to */7 * * * *, meaning polling every 7 minutes. This frequency is sufficient to cover the workshop pace without putting pressure on the Kingdee Cloud Cosmos interface. The target */1 * * * * 1-minute tick only actually executes when the source side produces results; otherwise it is an empty run. This is the common Qeasy "sparse source, compact target" scheduling combination.
• Phase 3: Stable operation. After going live, monitor result_message for one week. Classify the most frequent error codes and maintain them centrally in a code mapping table — this is the "centralized code mapping management" practice commonly used by Qeasy customers.

Lessons Learned from the Field

1. Field names of the empty-operation source are easy to mix up. autoFillResponse=true looks convenient, but the bind variable names in the downstream SQL must exactly match the value of the upstream strategy; otherwise, :fbillno will get an empty string. A safe practice is to bake variable names into a strategy naming convention.
2. Missing terminal status causes repeated write-back. In one on-site case, we found that failed report rows were being written repeatedly because the SQL only checked status not in ('S','A') and did not include the exception terminal state. After completing the terminal state set, the issue disappeared.
3. Inconsistent status semantics between the two interface tables. The report table uses S/A, while the inbound interface table uses N/A. Do not share a single mapping function for convenience, or you will end up with "report success but inbound interface misjudged."
4. NOW() timezone issue. In private deployments, the MySQL server and Kingdee Cloud Cosmos server may have different time zones. last_update_date = NOW() takes the MySQL local time. During troubleshooting, remember to compare against UTC; otherwise, you may misjudge latency.
5. Dependent on prior strategy but depends_on is empty. This strategy is essentially the return link of the previous "Plan Push Report" strategy. Although depends_on in the index is empty, the runtime context dependency is strong. When troubleshooting, always follow the execution log of the preceding strategy rather than viewing this strategy in isolation.

Applicable and Non-Applicable Scenarios

Applicable: scenarios where Kingdee Cloud Cosmos acts as the plan/report core system, MySQL serves as the MES interface table, and the workshop needs state-machine-driven follow-up operations. Not applicable: scenarios where report results need to immediately drive device联动 in hard real-time (1-minute granularity is still not enough), and business chains that are unidirectional push-only and do not require write-back.