查询钉钉员工策略实战：从钉钉拉员工档案到轻易云的端到端配置

这个策略解决什么问题(场景与价值)

在金蝶云星空与钉钉的供应链集成里，员工主数据并不是从 ERP 推给钉钉，而是反向的：业务单据里经常要带「发起人」「审批人」「部门对接人」这些人头字段，而钉钉的通讯录才是组织架构的事实来源。

我们的做法是单独建一个「查询钉钉员工」策略，按 userid 把员工档案（含 unionid、部门归属等）落到轻易云数据集成平台的中间层，供后续采购、审批事件、单据回写等策略共用。看起来只有一次接口调用，但它的稳定与否直接决定后面十几条策略的人员字段准不准。

数据流向与字段映射(源 → 中间层 → 目标)

源端调用钉钉开放接口 topapi/v2/user/get，按 userid 单点查询员工档案，返回 userid、unionid 等字段。中间层是轻易云集成平台本身，目标策略配置为「写入空操作」（api: 写入空操作、effect: EXECUTE），仅作为落点承载数据，并不外发。

关键字段对照（已脱敏）：

注意 dep_strategy 不是普通参数，它指向另一条「部门同步」策略的 ID，是跨策略引用的关键。

在轻易云上如何配置

源端策略（钉钉侧）：接口选 topapi/v2/user/get，类型 QUERY，方法 POST，主键取 name，业务键取 userid，关闭 idCheck 与 buildModel，打开 autoFillResponse，让响应自动落到平台。

目标端策略（轻易云侧）：选 WebAPI 写入空操作，request 与 response 都为空，idCheck 打开即可。它的作用不是推送，而是提供一个稳定的落点，让其他策略能按 userid 反查员工档案。

调度方面，源策略 crontab 写为 1 1 1 * *（按月触发），目标策略 crontab 写为 23 2 * * *（每日凌晨），两者用 depends_on 串起来，目标等源跑完再触发。

实施步骤

第一阶段：建源策略。 在轻易云数据集成平台里新建「查询钉钉员工」策略，平台选钉钉，接口填 topapi/v2/user/get，把 userid、language、dep_strategy 三个入参配置好，dep_strategy 这一项直接粘部门同步策略的 ID。

第二阶段：建落点策略。 新建目标策略，平台选轻易云集成平台，类型 WebAPI，api 写「写入空操作」，request、otherRequest、response、otherResponse 全部留空，idCheck 打开。

第三阶段：串依赖、设调度。 在目标策略的 depends_on 里挂上源策略 ID；源端按月跑（1 1 1 * *），目标端按天跑（23 2 * * *），形成「月增量拉取、日落点刷新」的双轨节奏。

第四阶段：联调验证。 先在测试租户跑一次，看 autoFillResponse 是否把 unionid、userid 都落到了中间层；再让采购申请单等下游策略引用这个落点，验证人员字段能否正常取到。

踩坑复盘

坑一：dep_strategy 写成字面量。 客户现场见过把部门策略 ID 硬编码进请求体的情况，结果部门策略一重建就失联。稳妥的做法是把它配置成引用变量，轻易云里通过策略 ID 解析，避免硬编码。

坑二：autoFillResponse 忘开。 这个开关默认是开的，但复制策略时偶尔会被重置。一旦关掉，响应字段不会自动落到中间层，后续策略按 userid 反查就拿不到 unionid。

坑三：idCheck 在源端打开。 源端是单点查询，不存在主键冲突，把 idCheck 打开反而会因为 userid 重复而误判为空。源端关、目标端开，是这条策略的标准做法。

坑四：调度时区没对齐。 源策略 1 1 1 * * 与目标策略 23 2 * * * 看似不冲突，但跨时区部署时容易出现「目标先跑、源还没跑完」的情况。建议在轻易云调度面板里统一以平台时区为准，并在依赖图里确认 depends_on 真的生效。

坑五：unionid 与 userid 混用。 钉钉租户内 userid 唯一，但跨租户会重复；unionid 才是跨系统稳定标识。在编码映射集中管理里，把 userid → unionid 的对应关系维护好，下游策略统一取 unionid。

适用场景与不适用场景

适用： 需要把钉钉通讯录作为人员档案事实源，供 ERP、审批、单据等多条下游策略引用；组织变动不频繁、按月拉取即可覆盖；私有化部署、对延迟不敏感的场景。

不适用： 员工高频变动、要近实时同步；跨多家钉钉租户聚合（unionid 不足以去重）；需要把档案再回写到钉钉以外的第三方系统的场景，建议另建落点策略。