Practical Tutorial: Deleting Data Older Than 60 Days in Jushuitan-to-Kingdee Integration

What This Strategy Solves (Scenario and Value)

In a supply chain integration between Jushuitan and Kingdee Cloud Skylin for a retail enterprise, the main pipeline continuously pushes sales outbound orders, transfer orders, and return orders to the downstream ERP. Over time, large volumes of completed and archived historical documents accumulate in the middleware and target systems, hurting query performance and burying operations engineers in old data when troubleshooting.

The Delete Data Older Than 60 Days strategy serves as the historical-data recycling mechanism for this main pipeline: it automatically cleans expired records from the intermediate data generated by the sales outbound order synchronization. While it looks like a simple cleanup action, it actually handles three responsibilities: controlling middleware bloat, reducing the historical burden on the target system, and bringing anomaly investigation back into the manageable scope of recent data. In our on-site delivery work, we typically position it as the closing strategy of the entire supply chain integration, running in parallel with the main pipeline.

Data Flow and Field Mapping

The data flow of this strategy is somewhat unique: the source side is the synchronization output produced by the Qeasy platform itself (targeting the Sales Outbound Order Sync object), while the target side is an internal no-op write action (Write Empty Operation), with the final effect being deletion after filtering by a 60-day time window.

Key field mapping:

One detail worth emphasizing: target_1 is of object type and supports multi-object extension. In other words, if the customer also needs to clean transfer orders, return orders, etc., simply add another target_2 object in the same API call to complete cleanup for multiple business objects in a single call—no need to build a separate strategy for each.

How to Configure on the Qeasy Platform

On the Qeasy data integration platform, this strategy is configured in three parts.

Part 1: Source interface definition. Select the built-in DeleteStrategyData WebAPI on the platform, with POST as the request method. It is a QUERY-type interface that returns the record set to be deleted based on the passed target object and time threshold. Pay attention to two switches, autoFillResponse and buildModel: with auto-fill enabled, the datetime and params fields in the response are generated automatically, requiring no manual construction. This is very friendly for cleanup-type strategies—you don't need to maintain a separate field for "when did this cleanup run."

Part 2: Target interface definition. Select Write Empty Operation, also POST, but with effect EXECUTE. This is a placeholder-style target whose real meaning is to close the strategy chain at the scheduling level: the source side filters records to delete by threshold, and the target side uses an empty write to complete the chain. The platform uses this to count strategy execution results.

Part 3: Objects and time threshold. In the request body, configure target_1 = Sales Outbound Order Sync, and clearly specify the comparison field (sync time or document date) and the threshold (60 days). If the business side requests that transfer orders also be cleaned, simply append target_2 = Transfer Order Sync to the same request, and the platform will filter and clean by object separately.

Implementation Steps

In our on-site delivery work, we typically roll out this strategy in four phases.

Phase 1: Confirm the incremental starting point. First confirm what the sync time field is called in the main pipeline, which object it belongs to, and whether the format is ISO. The starting point of the cleanup strategy must align strictly with the main pipeline's write time; otherwise you will face the awkward situation of "we clearly cleaned it, but it still shows up in the target system."

Phase 2: Trigger a full-volume trial run. Manually trigger a full cleanup on the night of go-live, and observe the datetime and params returned by the platform to confirm the deletion count matches the expected magnitude. A prudent approach is to first run with a conservative threshold (e.g., 90 days) to confirm the chain works smoothly, then dial it back to 60 days.

Phase 3: Set the scheduling frequency. The source DeleteStrategyData is set to 20 8 * * * (every morning at 8:20), and the target Write Empty Operation is set to 23 2 * * * (2:23 AM). The two times are intentionally staggered, ensuring the cleanup action runs during business off-peak hours and avoiding resource contention with the main pipeline's sync window.

Phase 4: Observe and recycle. Within the first week after go-live, check the cleanup count daily to confirm there are no abnormal spikes such as "tens of thousands of records deleted in a single day." After that, switch to weekly spot checks, and set the anomaly alert threshold at "single-day cleanup volume exceeds 3x the 7-day average."

Pitfall Review

Pitfall 1: Wrong field used for the threshold. A typical mistake is to use the business document date for comparison—but historical documents may have very old business dates, and new documents may have business dates earlier than their sync dates due to backfilling. The prudent approach is to use sync time (sync_time / datetime), which truly reflects when the record entered the middleware, giving the most accurate cleanup semantics.

Pitfall 2: Merging multiple objects into one target. Some engineers squeeze sales outbound orders, transfer orders, and others into a single object expression, resulting in overly broad delete conditions that wipe out records that should not be cleaned. Each business object should have its own target slot (target_1, target_2, …), letting the platform handle them separately.

Pitfall 3: Cleanup strategy sharing the same window as the main pipeline. Scheduling cleanup and sync at the same time creates a race condition where "sync writes halfway, cleanup deletes halfway." Staggered scheduling is a basic discipline. Arrangements like "source at 8:20, target at 2:23" are our default recommendation in customer-side operations specifications.

Pitfall 4: No audit trail after deletion. Cleanup-type strategies fear most the situation where "once deleted, you cannot find it back." Even though the target side is a no-op, it is recommended to retain the two auto-filled fields datetime and params in the platform's execution log so that there is evidence to check when something goes wrong.

Pitfall 5: One-size-fits-all threshold. Some customers want 30 days, others 180 days, but none consider downstream audit requirements. The prudent approach is to first align with finance and audit on how many days the data must be retained at minimum, then set the cleanup threshold, rather than having IT decide unilaterally.

Applicable and Non-Applicable Scenarios

Applicable: scenarios where middleware data keeps growing, the downstream ERP carries a heavy historical burden, and operations need a recent-data view for troubleshooting, as well as any sync chain managed by time-window lifecycle rules. Not applicable: data subject to long-term retention by regulation or audit (such as financial vouchers in certain industries), the early stage when the main pipeline is not yet stable, and business objects whose document status requires strict state machine control and cannot be physically deleted.