Returning Production Material Issue Results: A Practical Incremental Writeback Guide with Qeasy

What This Strategy Solves

After a production material issue document enters the business system, warehouse or production staff need timely confirmation of whether processing succeeded before continuing downstream work. The challenge is that the result remains in the source system while the task detail is still awaiting confirmation. A typical flow is: MySQL initiates a production material issue task, the source system processes it and returns a production order number, a success flag, and a result message, and the Qeasy Data Integration Platform updates the task detail in MySQL. The strategy addresses delayed result return, continued processing of failed tasks, and insufficient traceability.

Data Flow and Field Mapping (Source → Middle Layer → Target)

This is a writeback flow rather than a one-way creation flow. The source is the return interface from Kingdee or the result dataset handled by Qeasy. The middle layer identifies the task and prepares parameters, while the target is the task-detail table in MySQL.

Source or Middle-Layer Field	Target Field	Handling
sourceid	id	Must be passed unchanged and cannot be empty; it identifies the target detail
Production order number	Middle-layer business field	Records the business number generated or confirmed by the source system
is_sucess	is_success	Convert the source spelling to the normalized target field
result_message	Middle-layer message field	Used for logs, alerts, or future expansion; not written by the sample SQL
Combined condition	Update condition	Use `id = :sourceid` to locate the task detail
Business result set	main_params	Assemble the parameter object passed to the SQL action
Fixed update statement	main_sql	Updates the success status of the task detail

The core update semantics are: update task_detail set is_success = :is_success where id = :sourceid. Use named parameters or platform parameter binding instead of concatenating external input, which prevents SQL injection and quoting problems. The return interface includes a production order number and result message, but the sample SQL only updates the success status and matching identifier. If they must be persisted, add target fields explicitly and use a separate update statement.

How to Configure It in Qeasy

We use the Qeasy Data Integration Platform for this return flow, deployed in a private environment. First, create a result-query or no-op action that obtains the Kingdee return dataset through POST. Preserve sourceid, the production order number, is_sucess, and result_message.

Next, create a MySQL execution action. Name the input object main_params and map the success flag to is_success. Configure main_sql with the following parameterized template:

update wms_instock_confirm_task_detail set is_success=:is_success where id=:sourceid

A common mistake is writing the source field is_sucess directly into the target column. A safer approach is to add a field alias or conversion rule in the middle layer, separating source naming from target conventions. Code mappings, status mappings, and error-message rules should be centrally managed rather than scattered in SQL statements.

Enable target-side validation for matched records, affected row counts, and exceptions. If zero rows are updated, route the record to retry or manual investigation instead of treating the run as successful. Production material issues may involve headers and details, but this strategy only writes back a result status. For complex multi-step document returns, handle headers and bodies in separate phases rather than placing unconfirmed multi-table actions into one strategy.

Implementation Steps

Establish the incremental starting point. Use sourceid as the task cursor and retrieve only new or pending results. Persist the latest successful position, checkpoint time, or processed-ID set to prevent duplicate updates. During initial rollout, scan all existing tasks, but only supplement statuses and do not invent business numbers without evidence.
Transform and pre-validate. Convert is_sucess to is_success, verify that sourceid is non-empty, validate status values, and ensure each record is unique within the batch. Keep the production order number and result message in intermediate logs for investigation.
Run full and incremental tracks. During initialization, perform one full writeback to confirm the target table structure and field semantics. In daily operation, use incremental processing. A common customer pattern is a dual-track approach: incremental processing for timeliness and periodic full processing for verification and gap repair.
Configure scheduling frequency. The source polls every seven minutes and the target SQL polls every two minutes in the supplied configuration. Actual frequency should be determined by business timeliness and source-system load rather than copied mechanically. Offset the schedules and configure bounded retries and alerts in the private environment.
Reconcile and compensate. Record source record count, successful update count, unmatched count, and exceptions in every run. When unmatched records, duplicate updates, or database unavailability continue, pause the batch and resume from the last unprocessed position after remediation. This prevents false success where the strategy reports completion but the business data was not updated.

Lessons from Production Issues

Field-name inconsistency. The source field is is_sucess, while the target field is is_success. Manual configuration based on memory is bound to fail. Use centralized mapping and add assertions.
Mistaking a query for a writeback. A no-op or query action only retrieves the result; it does not prove that MySQL was updated. Validate the affected row count of the execution action and retain batch logs.
Repeated full-table updates. Without an incremental cursor, the job repeatedly scans historical tasks and increases database load. Use a full and incremental dual track, but reserve full processing for initialization or periodic recovery.
Direct SQL concatenation. Placing external values such as statuses or task IDs into SQL strings causes errors and security risks. Bind named parameters and keep field mapping centralized.
Ignoring zero matches. where id=:sourceid may not raise an error when no row is found, making the issue easy to miss. Treat zero affected rows as an alert and compensation condition.

Suitable and Unsuitable Scenarios

This approach is suitable for lightweight result writeback in production material issue and material-supplied outsourcing scenarios where a source system returns a processing result by task ID and MySQL needs timely confirmation. It is not suitable when header, detail, inventory, reversal, and other multi-table transactions require strong consistency, cross-database commits, or bidirectional concurrency control. In those cases, split the interfaces, introduce idempotency keys and compensation, and evaluate a transactional or service-oriented integration design.