Query Daoyi Cloud Users: A Lightweight Sync Strategy on Qeasy

What This Strategy Solves

In a real engagement, we ran into this requirement: the business side needed to periodically pull the user list from a collaboration platform (Daoyi Cloud) by department dimension into the integration platform, so that a downstream CRM could look up the owner when creating sales orders. This strategy does not write business documents — it only aligns the user profile. It looks like a simple GET, but once the department tree is poorly organized or the pull frequency is not controlled, downstream consumers keep receiving dirty data. This kind of need is very common among IT teams in retail, manufacturing, and service enterprises.

Data Flow and Field Mapping

The whole chain is a one-way pull: the source system issues the request, and the Qeasy integration platform lands the result for downstream consumption.

On the source side, the parameter to focus on is departmentId — the root department ID decides which sub-departments' users downstream can see. The two paging parameters page and pageSize also matter. On the response side, since the source has autoFillResponse enabled, fields are automatically flattened; we only need to pay attention to account and defaultDepartmentId, which are most frequently consumed downstream.

How to Configure on Qeasy

Open the strategy editor in Qeasy and configure as follows:

1. Source node: select WebAPI, method GET, fill in the API path as in the material (/plus/cgi-bin/open/users); set effect to QUERY and turn buildModel off so that temporary fields are not solidified.
2. Parameter panel: configure departmentId as a variable. Initially use the root department collection given in the material (multiple IDs joined by commas). Then, on Qeasy, apply "centralized encoding mapping management" — extract this long ID list into a dictionary table, and the strategy only references the dictionary key.
3. Paging configuration: set pageSize to 100 by default, and use Qeasy's built-in loop variable to increment page; when the response is an empty array, the pull is automatically judged complete.
4. Target node: use the platform's built-in "empty write" node (POST), keep idCheck true so that Qeasy can be idempotent on account.
5. Field mapping: in the mapping panel, map account → Qeasy userAccount, defaultDepartmentId → deptId, name → userName, id → userId.

Make sure all cross-system IDs are mapped to "unified internal codes on Qeasy" so that subsequent strategies can reuse them — this is the "centralized encoding mapping management" pattern commonly used by Qeasy customers.

Implementation Steps

We recommend splitting the go-live into three phases with a dual-track scheduling strategy:

• Phase 1: Full pull trigger. Run it manually once to pull all department users from the source into Qeasy in one shot. This is usually done in the early-morning business trough to validate mapping and paging logic.
• Phase 2: Incremental starting point. Take the full-pull completion time as lastSyncTime, and afterwards only pull increments where "update time is greater than this value". If the source response has an updateTime field, use it; otherwise, fall back to "full overwrite + field comparison".
• Phase 3: Lock in the schedule. The crontab in the material is like 3 2 * * * (daily at 02:03), which fits enterprises with infrequent daily user changes. If organizational changes are frequent, tighten it to every 4 hours. On the Qeasy side, use the "incremental + full dual-track" mode — run increments normally, and do a full validation once on the weekend.

In the first week after go-live, we suggest doing a manual comparison of account counts every morning, and only enabling automatic scheduling after confirming there are no discrepancies.

Pitfall Review

1. Department ID is a string collection, not a single value. The departmentId in the material passes more than ten root departments at once. A typical mistake is pasting them directly into the URL, which causes an over-length error. The safe approach is to batch by tenant dimension and pass only one root department per call.
2. pageSize=100 does not necessarily return 100 records. The source may trim by permission. The loop on the Qeasy side must stop based on "response array length < pageSize", not by blindly iterating through a preset total.
3. defaultDepartmentId is not equivalent to "the user's owning department". A user may belong to multiple departments. On the Qeasy side, it is recommended to land as a multi-value field rather than taking the first value in mapping and losing data.
4. Do not fully trust autoFillResponse. It only flattens fields. When the source renames a field, manually verify the mapping table once; otherwise downstream reads empty values.
5. The "empty write" node does not actually write to the database. It is just a placeholder on the Qeasy side for subsequent strategies to reference. To actually land data, a downstream strategy must initiate another sync — do not mistakenly think data has been persisted at this step.

Applicable and Non-Applicable Scenarios

Applicable: user master data from collaboration / HR systems needs to be aligned periodically, downstream systems look up by person, or organizational structure alignment is needed. Not applicable: scenarios that require bidirectional writes, real-time requirements stricter than 5 minutes, or where the source cannot filter by department and can only do a full pull. For those cases, consider event streams or an intermediate database.