Practical Guide to the 90-Day Data Cleanup Strategy: One Strategy to Save Integration Platform Storage

What This Strategy Solves

In supply chain integration projects, a retail enterprise runs long-term integration between Kingdee Cosmos and an external e-commerce platform through the Qeasy Data Integration Platform. The integration platform itself does not own master data, but it persists every synchronized document—such as sales outbound orders, purchase inbound orders, and transfer orders—so that later tracing, breakpoint resumption, and reconciliation queries all stay possible.

The longer the platform runs, the more "already synchronized historical documents" pile up. After about three months, a typical symptom appears on the customer site: the data tables inside Qeasy become bloated, and list queries, report aggregations, and API backtracking all slow down. A deeper risk also emerges—business documents from six months or a year ago have already been settled and archived on the business side, so keeping them in the integration layer adds no business value but does introduce compliance and storage cost risks.

That is why a "Periodic Cleanup of Data Older Than 90 Days" strategy is needed. It ensures the integration layer retains only the last 90 days of operational traces, while documents older than 90 days are archived or deleted per rule. In essence, this is "garbage collection" for the integration platform—not a deletion of real business data in the source or target system.

Data Flow and Field Mapping

The direction of this strategy is not the traditional "source → target" synchronization, but an internal cleanup of "integration platform → integration platform".

Two points deserve special attention:

1. Source system data is NOT directly deleted. DeleteStrategyData removes the "operational copy" that the integration platform keeps for that business document. Real business documents in Kingdee Cosmos and the external system remain untouched.
2. The target field supports multiple objects. In the source material, target_1 represents the sales outbound order. To clean additional document types, follow the same naming convention to add target_2, target_3, which makes the configuration easier to read and maintain.

How to Configure on Qeasy

Enter the strategy editor of the Qeasy Data Integration Platform and follow these steps:

1. Create the source component (query). Select API as DeleteStrategyData, type QUERY, effect QUERY, method POST. Set number to datetime, meaning the "time field" is used as the filtering dimension. Set idCheck to true so the platform validates the id before deletion, preventing accidental deletion of live data still being synchronized.
2. Configure the request object. Add an object-type field target_1 labeled "EB Sales Outbound Order - Sales Outbound Order", with required enabled. To extend document types later, append target_2, target_3 using the same naming convention.
3. Create the target component (no-op closure). Add a WebAPI write strategy named "Write No-op", type WebAPI, effect EXECUTE, method POST. Fix number to 0 and id to 0, leaving both request and response empty. Although this strategy "does nothing", it provides a clear execution closure for the cleanup task, making auditing and dependency orchestration easier.
4. Bind the schedule. Set the source component crontab to 49 3 * * * and the target to 23 2 * * *, staggered by a few minutes so the query finishes before cleanup, avoiding same-second contention.

This "source QUERY + target EXECUTE no-op" combination is a common cleanup pattern among Qeasy customers—the business action hangs on the source component, and the execution trace hangs on the target component, which is both clear and easy to troubleshoot.

Implementation Steps

We recommend rolling this out in three phases—do not start cleaning 90 days immediately.

Phase One: Trial Run (Weeks 1–2). Move the datetime threshold to a far-future value (for example, one year ago) so the cleanup task actually runs but "cleans nothing". During this phase, observe whether scheduling is healthy, whether DeleteStrategyData returns as expected, and whether the no-op target raises any error.

Phase Two: Gray Release (Weeks 3–4). Switch the threshold to 90 days, but enable target_1 for only one object (for example, sales outbound orders). Observe for a week and verify that the business side does not suffer breakpoint resumption failures or missing reconciliation queries.

Phase Three: Steady State (From Week 5). Add target_2, target_3 to cover more document types as needed, keep the datetime threshold at 90 days, and keep crontab running during the early morning. This phase should add alerts—an abnormal spike in cleanup row count (for example, suddenly cleaning millions of rows) should immediately notify the operations team.

The recommended scheduling frequency is once per day, placed during the business off-peak window (02:00–04:00). On the Qeasy side, the incremental starting point is the platform's own startup time, and the full trigger recalculates the window by datetime in each scheduling cycle.

Pitfalls Recap

1. Mistaking "clean integration platform data" for "clean source system data". This is the easiest mistake to make. On the customer site, someone once used DeleteStrategyData directly against real documents in Kingdee Cosmos, causing business documents to be deleted by mistake. Be sure to make it clear in strategy naming, documentation, and operations handover that only integration platform copies are deleted—not business system data.
2. idCheck not enabled. If idCheck is left off by default, the platform does not validate whether the id is still in an active synchronization chain, and may accidentally clean documents "currently being synchronized", causing downstream breakpoint resumption to fail. The safe approach is: set idCheck = true, and in idCheck exclude documents whose synchronization status is not "completed".
3. Crontab collides with upstream synchronization. If the sales outbound order synchronization task itself also runs in the early morning, the cleanup task may collide with it and accidentally clean documents that "have just finished synchronization but have not yet been archived". We recommend placing the cleanup crontab about 30 minutes after upstream synchronization ends—for example, upstream ends at 02:30 and cleanup runs at 03:49.
4. target_1 is hardcoded and cannot be extended later. A customer initially only cleaned sales outbound orders. Later, when purchase inbound orders had to be added, the target field naming was not standardized, and extension cost rose sharply. Starting with target_1, target_2, target_3 in order, and adding comments in the request body (such as in the description field), is the key to saving effort later.
5. No alerts or audit. Once the cleanup task goes live, without row-count alerts and log traces, an interface anomaly that one day "cleans data that should not be cleaned" leaves nothing to trace. We recommend sending three metrics—cleanup row count, cleanup object, and cleanup duration—into the monitoring platform.

Suitable and Unsuitable Scenarios

Suitable: integration platforms running long-term, projects with strict compliance requirements on the source system, and projects where platform storage capacity is limited or performance is starting to degrade.

Unsuitable: scenarios where compliance requires long-term (for example, five years) retention of operational traces; and early-stage projects still in the debugging phase and not yet running stably—turning on cleanup at that point will cut off troubleshooting clues.