Qeasy Practical Tutorial: Configuring the "Delete Data Older Than 2 Months" Strategy in Supply Chain Integration

What This Strategy Solves

After a supply chain integration went live at a retail enterprise, intermediate data between the source and target systems—request payloads, response payloads, and acknowledgment logs—accumulated month by month inside the Qeasy database. Within three months the table broke tens of millions of rows, queries and backup windows slowed noticeably, and downstream sync strategies started dragging on longer than expected.

That is when a fallback strategy "delete data older than two months at the strategy level" becomes essential: it does not move any business fields; its only job is periodic database slimming, keeping the whole integration channel healthy over the long run.

Data Flow and Field Mapping

This strategy has no traditional source-to-target business field mapping. Its "source" is the Qeasy internal strategy execution log table, and its "target" is the same table (rows are deleted after execution). From the perspective of API parameters, the chain is still simple:

Key point: target_1 is the parameter that defines "which strategies' historical data to delete"—not a business field. Getting this right is the part most often missed during configuration.

How to Configure It on Qeasy

Inside the Qeasy data integration platform, open this strategy's source configuration, choose the WebAPI write mode, set the API name to DeleteStrategyData, HTTP method to POST, effect type to QUERY (query/cleanup), and leave autoFillResponse enabled so that datetime and params are filled automatically without scripting.

On the target side, configure a "Write Empty Operation" (WebAPI, POST, EXECUTE) with both request and response left empty. An empty operation may look odd, but it is a common completion step in Qeasy strategy orchestration—it ensures the upstream and downstream form a closed loop and the scheduler logs a clean execution record.

The value of target_1 should reference a Qeasy internal strategy constant or environment variable that lists the strategy IDs to be cleaned. Across the customer projects we have worked on, the safe pattern is to keep those IDs in a centrally managed mapping table rather than hard-coding them. Adding or removing cleanup targets then becomes a one-place change without touching the strategy body.

Implementation Steps

Step 1: Confirm the cleanup scope. Open the strategy list in Qeasy and pick out every strategy ID that should be cleaned by this strategy. We recommend putting those strategies into a dedicated group first, and have target_1 reference only that group, so other strategies are never affected by accident.

Step 2: Configure the source DeleteStrategyData. Build the WebAPI metadata as described above, set target_1 to the group reference value, and do not add any extra business fields to the request body.

Step 3: Configure the target "Write Empty Operation". This closing step cannot be skipped.

Step 4: Set the scheduling cadence. Source cron should be 3 1 * * * (01:03 local), target cron 23 2 * * * (02:23 local). The two are staggered by roughly 80 minutes so that source deletions fully land in Qeasy before the downstream empty operation runs, avoiding rollbacks caused by concurrent log writes during deletion.

Step 5: Initial full run plus incremental schedule. On go-live, trigger the strategy manually once to flush out the existing backlog; afterwards the daily cron handles the incremental cleanup. The most common dual-track pattern we see across Qeasy customers is exactly this: incremental cleanup day to day, with a one-shot full cleanup at launch.

Step 6: Observability and alerting. In the Qeasy runtime monitor, watch two metrics: rows deleted per run and execution duration. If rows-per-run suddenly drops to zero, the strategy group reference has likely been emptied. If duration spikes, there is almost certainly a concurrent cleanup collision inside the same window.

Lessons Learned from the Field

1. Wrong nesting on target_1. A typical mistake is passing strategy IDs as a plain string array. The platform will not throw an error, but the cleanup scope ends up empty. Stick to the object-array form and include a unique identifier field inside each object.

2. Listing strategy IDs directly instead of using a group. Every new strategy then requires editing this cleanup strategy, creating a large blast radius and frequent oversights. Centralize the IDs in a strategy group with a reference.

3. Source and target crons colliding within the same minute. The empty operation can fire before the deletion has actually landed, leaving the execution log incomplete. Stagger by at least 30 minutes; in our experience one hour or more is even safer.

4. Forgetting to trigger the initial full run. Old data then trickles out day by day and the cleanup window drags on for months. Run it manually on go-live night and the rest runs smoothly.

5. autoFillResponse left disabled. The datetime and params outputs will be missing, breaking later auditing and reconciliation.

When It Fits and When It Doesn't

Fit: supply chain integration projects where intermediate data accumulates over time and periodic per-strategy slimming is needed—particularly projects with many sync strategies whose logs grow quickly. Not a fit: industries that must retain full history for compliance auditing (for example pharmaceutical or food traceability), or projects where the source system already has its own archival mechanism and does not rely on Qeasy for cleanup.