SQL Server 与旗开得胜考勤系统集成方案：出差申请数据双向同步实践

场景与价值

在某制造企业的实际项目中,HR 经常发现一个尴尬的局面:员工上午填完出差申请,下午到了客户现场才发现考勤系统里没有这次外勤记录,月底算工资时只能在群里反复对单据号。问题的根源不是哪个系统抄错了表,而是从出差审批到外勤考勤之间没有自动闭环——数据停留在 OA/费用系统的视图里,没有人把它推到考勤侧。

本方案解决的就是这条断点:把 SQL Server 中的出差申请视图(vw_cus_ExpenseRequest),按区域和操作类型拆分,稳定地同步到旗开得胜考勤系统的外勤/出差接口,使外勤考勤、工时核算、薪酬结算有一致的源。

集成架构与数据流

整体链路是单向的「拉取-转换-写入」三段式:

┌─────────────────────┐    拉取    ┌──────────────────┐    写入    ┌─────────────────────────┐
│   SQL Server        │  ──────►  │  集成中间层/ETL   │  ──────►  │  旗开得胜考勤系统       │
│  (vw_cus_ExpenseReq)│           │  (调度/转换/映射) │           │  (外勤/出差 API)       │
└─────────────────────┘           └──────────────────┘           └─────────────────────────┘
        │                                  │                              │
        │ 增量:fcreatedate/fmodifydate      │ 工号区域过滤 S%/W%             │ RESTful API
        │ 新增/修改类型过滤                  │ 日期格式转换                   │ /api/attendance/open/batch/att-out-work
        │ 全量/增量切换                      │ leaveHourAmount 计算           │
        ▼                                  │ 异常重试                       ▼

我们在轻易云数据集成平台(Qeasy)上落地这条链路时,把它分成了 4 个相互独立的策略,按「区域 × 新增/修改」正交切分:深圳新增、深圳修改、温江新增、温江修改。两条线之间没有任何强依赖,理论上可以并行跑;为了规避考勤接口的限流,实操中通常错开 1–2 分钟调度。

数据流分四步:

抽取:按区域前缀(S%、W%)与操作类型(新增/修改)在源视图中做行级过滤;
增量游标:新增走 fcreatedate,修改走 fmodifydate,各自维护独立的水位;
字段转换:做日期格式归一、出差起止时间差换算成 leaveHourAmount(算不出时默认 0.1 小时),并完成工号区域编码到目标字段的映射;
写入:调旗开得胜外勤批量 API,以源端 FBillNO 作为目标端 approvalSerialNum,天然幂等。

接口清单

策略编号	数据对象	同步方向	备注
策略 1	深圳出差申请(新增)	SQL Server → 旗开得胜	`FAccompany like 'S%'`,`ftype='新增'`,增量字段 `fcreatedate`
策略 2	深圳出差申请(修改)	SQL Server → 旗开得胜	`FAccompany like 'S%'`,`ftype='修改'`,增量字段 `fmodifydate`
策略 3	温江出差申请(新增)	SQL Server → 旗开得胜	`FAccompany like 'W%'`,`ftype='新增'`,增量字段 `fcreatedate`
策略 4	温江出差申请(修改)	SQL Server → 旗开得胜	`FAccompany like 'W%'`,`ftype='修改'`,增量字段 `fmodifydate`

实施要点

分阶段调度。4 个策略独立调度,推荐每 5 分钟一轮,起步延迟 2 分钟;若考勤接口有 QPS 限制,深圳、温江之间再错开 1–2 分钟,实测比纯并行更稳。

增量字段与全量兜底。新增与修改必须拆开走两条增量水位,混用 fcreatedate 会漏掉修改记录;同时保留手动或定时全量触发(常见做法是每周日凌晨跑一次全量核对),用于增量漏数后的修复。

编码映射集中管理。工号前缀 S/W、审批单号 FBillNO→approvalSerialNum 这些映射规则,在轻易云里通常集中放到一张映射表,而不是散落在各个策略里,后续区域或字段口径调整只动配置不动脚本。

异常重试与幂等。源端 FBillNO 写入目标 approvalSerialNum,配合目标端的去重逻辑,保证重复推送不会产生脏数据;网络抖动或限流时的失败重试,建议退避策略 30s→2min→10min,最多 3 轮。

隐私与凭证。数据库连接串、考勤 API 的认证凭证全部放在平台的环境变量里,不进任何方案文档或脚本正文,这是我们做私有化交付的硬性约束。

最佳实践与踩坑复盘

不要在源端混用 fcreatedate 和 fmodifydate。典型错误是用 fcreatedate > :t 一把抓新增和修改,结果修改单永远追不上,考勤侧漏算外勤。稳妥的做法是新增/修改各走一条策略、各自一张水位表。
leaveHourAmount 算不出时不要直接抛错。出差起止时间若跨多天或带跨日,时间差换算偶尔会拿到 0 或异常值。我们统一约定拿不到就默认 0.1 小时,目标端会按其规则修正,而不是让整批失败。
批量上限要摸清。旗开得胜 /api/attendance/open/batch/att-out-work 单次批量有上限,超过会被截断。我们在轻易云的策略里默认按 200 条/批拆分,大表分批写,避免单批失败导致整段重跑。
表头表体分阶段写入。这类「申请单 + 同行人明细」的双层结构,稳妥的做法是先写表头拿到返回的 approvalSerialNum,再带着这个 ID 去写同行人明细,轻易云的编排画布里直接串两个节点就能落地。
奇门/非奇门双通道分流。如果考勤侧同时接了奇门通道与直连开放平台,需要按门店编码前缀预先分流到不同适配器,这条规则放在映射表里比写死在脚本里好维护得多。

何时使用轻易云

当数据要从 SQL Server 这样的传统关系库,持续推到旗开得胜这类带 RESTful 开放接口的业务系统,且涉及多区域、多操作类型的拆分调度时,轻易云数据集成平台提供可视化的策略管理、集中的编码映射、内置的增量水位与异常重试,可以把交付从「写脚本+盯日志」压缩到「配策略+看看板」,私有化环境下也能完整落地。

SQL Server 出差申请与旗开得胜考勤系统集成方案总览