Inside the Qeasy Integration Platform: Visual Assembly of Integration Flows
The Four Layers
The Qeasy data integration platform is organized into four layers, bottom-up:
- Connector layer — encapsulates the API differences of each system. Kingdee Cloud's session authentication, WDT's MD5 signing, and Jushuitan Qimen's envelope format are all absorbed inside connectors, which expose uniform semantics upward: read bills, write bills, query master data.
- Flow assembly layer — a visual canvas. A "flow" consists of source, transform, and target nodes linked by data streams, with field mapping configured as a table.
- Scheduling runtime — executes flows: scheduled triggers, paged extraction, resumable checkpoints, failure retry, idempotent writes, and rate limiting.
- Observability layer — run logs, per-record execution detail, exception alerting, and data replay.
Three Core Concepts in Flow Assembly
A source node defines where data comes from: the authorized connector instance, the API (e.g. "sales order query"), the incremental condition (by modified time or bill number range), and the pagination strategy. A transform node carries field mapping and data shaping: renaming, type conversion, value mapping (enum translation), constant filling, and scripted extensions — with the principle that mapping is configuration, and only genuinely complex logic requires scripts. A target node defines where and how data is written: idempotent upsert by bill number, batch size, and failure behavior (skip, abort, or route to manual handling).
Lifecycle of a Flow
| Stage | Key actions | Outcome |
|---|---|---|
| Assembly | Connect nodes on the canvas, configure mappings | Flow draft |
| Debugging | Single-record trial run, inspect node I/O | Runnable flow |
| Go-live | Set schedule, enable monitoring | Production task |
| Operation | Read logs, handle exceptions, replay as needed | Stable data pipeline |
Deliberate Trade-offs
Qeasy makes explicit architectural choices: configuration over code to lower maintenance cost; idempotency over distributed transactions (which are impractical across vendors), achieving eventual consistency via idempotent writes plus compensating retries; and record-level detail over aggregates, so troubleshooting starts from "which record, which step" rather than from arguing about whose fault it is.