Practical Configuration Tutorial: Syncing Employee Users from Panwei to Ctrip Business Travel HR Profile

What This Strategy Solves

When a retail enterprise rolled out a unified business travel platform, they ran into a very common pain point: employee master data living in the Panwei OA system—name, employee number, department, position, mobile, email—had to land in the Ctrip Business Travel platform to serve as the foundation for booking, approval, and reimbursement. Once the two systems drifted out of sync, problems showed up immediately: "an employee placed an order but no approver could be found," or "a resigned employee still had a travel budget." The essence of this strategy is treating the OA as the Single Source of Truth for employee master data, extracting through an intermediate SQL Server database, and writing into Ctrip Business Travel's HR profile API.

Data Flow and Field Mapping

The overall flow is unidirectional: SQL Server (Panwei intermediate view) → Qeasy Data Integration Platform → Ctrip Business Travel HR profile.

Key field mapping (desensitized):

The two most error-prone points in this strategy are "department path parsing" and "position code mapping," which we will expand on in the pitfalls section.

How to Configure on Qeasy

Configuring this strategy on the Qeasy Data Integration Platform is not complicated, but several essentials must be thought through in advance:

1. Source data source: Register the SQL Server intermediate database connection and locate the Panwei employee view. Make sure the view contains a "last update timestamp" field; otherwise, incremental sync is impossible.

2. Target data source: Register the Ctrip Business Travel HR profile write API, and confirm the authentication method and rate-limit threshold (typically a per-minute QPS limit).

3. Centralized mapping table management: In Qeasy's "Mapping Table" module, centrally maintain two tables: "position name → Ctrip position code" and "department leaf-level path → Ctrip department ID." When HR adjusts the position system, only one table needs updating, not every strategy. This is the most easily overlooked yet most labor-saving step at client sites.

4. Phase header and extended fields separately: This strategy only handles the "employee HR profile" main body; sensitive fields like salary and contracts are excluded. We recommend placing extended attributes in Qeasy's "custom field zone" temporarily, waiting until business departments finalize the definition before pushing downstream.

Implementation Steps

At the client site, we typically follow these four steps:

Step 1: Full initialization. Run a one-time full sync to land all current OA employees into Ctrip Business Travel. Qeasy's full-load tasks support resume-from-breakpoint, so even if it fails midway, restarting will not re-write employees that have already succeeded.

Step 2: Define the incremental starting point. Use the full-load completion time as the anchor and record the maximum last_update_time value in the SQL Server view as the incremental starting point. After that, only records updated after this value are pulled.

Step 3: Set the scheduling frequency. The client ultimately adopted a "every 15 minutes incremental + daily early-morning full-load safety net" dual-track rhythm: the incremental ensures timeliness, the daily full-load catches "stragglers" (such as manual database edits).

Step 4: Observe for one week after go-live. Focus on three things: the success rate returned by Ctrip Business Travel, the average duration of incremental tasks, and the reconciliation discrepancy between employee counts on both sides. Once the numbers stabilize, consider tightening the scheduling frequency.

Pitfall Review

Pitfall 1: Passing the entire department path string directly causes hundreds of empty departments to be created on the target. The safe approach is to parse by separator in the intermediate layer and only use the leaf-level code for mapping.

Pitfall 2: Position names are inconsistent between the two systems. For example, the OA calls it "Senior Sales Manager," while Ctrip calls it "Sales Senior Manager." Without a mapping table, you either cannot match at all, or you have to hardcode in scripts. The most common pattern at client sites is hosting the mapping table in Qeasy, so that business changes only require updating one table.

Pitfall 3: Resigned employees are not pushed downstream in time. A typical mistake is treating emp_status='resigned' as "skip," resulting in the employee still being active in Ctrip. The safe approach is: when the status is resigned, actively write isLeave=1 rather than skipping the record.

Pitfall 4: Incremental starting point drift. If the incremental task updates the last_update_time watermark during a failed retry, data loss can occur. The recommendation is to update the watermark only after the target write succeeds.

Pitfall 5: Ctrip API rate limiting kicks in. Business travel APIs usually have per-minute QPS limits, which can be triggered during large full-load runs. You can configure per-minute request caps in Qeasy's "flow control," leaving a safety margin.

Applicable and Non-applicable Scenarios

Applicable: Enterprises where OA is the master data source, the target system is a business travel / expense control platform, and employee profiles require near-real-time synchronization. Not applicable: Enterprises where employee profiles are centrally managed by a dedicated HRIS, or where Ctrip Business Travel is just one of many travel entry points (in this case, it is recommended to first aggregate into the HRIS, then have the HRIS distribute in a single direction).