Fund Account Sync Strategy in Practice: An Incremental Loop from Source to Workflow Engine

What This Strategy Solves

In a supply-chain middle platform project for a retail enterprise, "fund accounts" are high-frequency business documents—every receipt, payment, or internal transfer leaves a record in the source system, and both financial reconciliation and business reviews depend on this data. Our job is to push the new and changed fund records from the source system into the target system within an incremental time window, building a unified fund view. The strategy looks like an ordinary document sync, but it is far more sensitive to time windows, idempotency, and code alignment than master-data sync.

Data Flow and Field Mapping

The chain is: source system (fund flow) → Qeasy integration platform → target system (workflow document).

Source side: a RESTful query API pulls the fund list; the primary key is fundCode, with startdate and enddate used as the time-window filter.
Target side: a POST call to the standard open API writes the fund document; the operation is /fund/save, and the idempotency field is biReferenceId (mapped to the source fundCode).

Key field mapping:

Meaning	Source field	Target field	Notes
Flow primary key	fundCode	biReferenceId	Idempotency anchor; pass through unchanged
List row ID	listId	listId	Identifies one sync row
Transaction type	transTypeName	Inside formData	Written after code mapping
Counterparty	handlerEntityName	Inside formData	Usually reconciled in the middle layer
Sync time window	startdate / enddate	—	Injected by Qeasy scheduling context

fundCode is the field to watch most closely in this strategy—it is the deduplication key on the source side and the idempotency key on the target side; almost every troubleshooting session will end up relying on it.

How to Configure It on Qeasy

In the Qeasy integration platform, this strategy is split into three parts: source API + target API + scheduling.

Source API: choose RESTful, set effect to QUERY, set the primary key to fundCode, and enable autoFillResponse so the response structure unfolds automatically and manual modeling is minimized.
Target API: also RESTful, but effect is EXECUTE, operation is hard-coded as /fund/save, and idCheck stays on; biReferenceId directly references the source field via {{fundCode}} to guarantee idempotency.
Code mapping: keep the source system's transaction type and counterparty enum values in a centralized mapping table on Qeasy—this is the "centralized code mapping" pattern we most often recommend to customers; if the source dictionary later changes, only one table needs updating.
Header/body staged write: the formData payload usually contains detail rows; on customer sites we typically use a "header first, body in batches" two-stage write so a single request body does not exceed the target system's limit.

Implementation Steps

Initialize the incremental starting point: in Qeasy, set LAST_SYNC_TIME to a historical point (for example, 00:00 of the day before go-live), and run a full sync first to fill in the historical fund records; this stage is best triggered manually during off-peak hours.
Full reconciliation: after the full sync completes, reconcile the source fundCode values against the target biReferenceId values to confirm the counts match before switching to incremental.
Scheduling: the source cron is set to 1-59/10 7-23 * * * (every 10 minutes during business hours); the target cron is offset by 7 minutes to 8-59/10 7-23 * * *, giving the source pull and the middle-layer processing enough buffer. This is the "incremental + full dual-track" pattern we often use—only when the full sync is stable can the incremental sync run densely.
Gray release and rollout: open it up for 1–2 stores or business lines first, observe for 3 days to confirm there are no duplicate or missing records, then expand to the full scope.
Monitoring and alerts: set threshold alerts on Qeasy for the fundCode duplication rate and the target-side 4xx/5xx ratio.

Pitfalls and Lessons Learned

Do not transform fundCode in any way: a typical mistake is to casually uppercase or trim the code, which breaks the idempotency key and produces duplicate documents on the target side. The safe approach is to write whatever the source sends, unchanged.
Do not use "calendar days" for the time window: startdate and enddate should be millisecond timestamps, not strings like 2024-01-01 00:00:00, otherwise the record that crosses midnight is easily missed.
transTypeName dictionary drift: the source system occasionally adds new transaction types; if the mapping table is not updated in time, the fund document fails to write. The safest approach we have seen on customer sites is "alert on unmapped values" rather than silently dropping them.
Do not turn off idCheck on the target side: if it is off, replaying the same flow creates duplicates, and this strategy is extremely hard to clean up once it duplicates.
Do not skip the scheduling offset: if the source and target use the same cron, a network hiccup easily produces "pulled but not written" situations; the 7-minute offset is a battle-tested value.

Applicable and Non-applicable Scenarios

Applicable: business documents such as fund flows and payment orders that need incremental time-window sync and have high requirements on idempotency and code consistency. Not applicable: scenarios requiring second-level real-time push (Qeasy is essentially a near-real-time scheduler, not a message queue), or scenarios that need bidirectional reconciliation (a single strategy is one-way only; bidirectional reconciliation should be handled by a separate reconciliation strategy).