使用Salesforce Bulk API 2.0同步时Lead记录丢失问题排查

可能的原因及排查步骤 #

1. 时区不一致导致过滤逻辑错误

   • Salesforce的SystemModStamp和CreatedDate均为UTC时区，若数据仓库存储的last_sync_date使用了本地时区，转换为UTC时会出现偏差，导致本该被包含的记录被过滤。
   • 排查方法：
     • 执行SELECT Id, SystemModStamp, CreatedDate FROM Lead WHERE Id = '<lead_id>'，获取缺失记录的两个时间字段值（确保统一为UTC时区）。
     • 对比last_sync_date的UTC值，确认是否存在SystemModStamp <= last_sync_date的情况，若存在则说明时区转换有误。

2. SystemModStamp字段存在异常值

   • 部分场景下，SystemModStamp可能被设置为早于CreatedDate的时间（比如通过Data Loader等工具导入记录时手动指定了该字段值），导致即使过滤时间早于CreatedDate，SystemModStamp仍不满足> last_sync_date的条件。
   • 排查方法：
     • 查看缺失记录的字段历史追踪（Object Manager -> Lead -> Field History Tracking），确认是否有数据导入、批量更新操作修改过SystemModStamp。
     • 检查导入工具的配置，是否允许覆盖SystemModStamp字段。

3. Bulk API 2.0查询引擎的特殊限制

   • Bulk API 2.0依赖Salesforce的批量处理引擎，存在部分场景下的查询偏差：
     • 排查方法：
       • 使用普通REST API执行相同的SOQL过滤语句（SELECT id,... FROM Lead WHERE systemModStamp > <last_sync_date>），看是否能返回缺失记录，排除Bulk API本身的问题。
       • 查看Bulk Job的执行日志（Setup -> Bulk Data Load Jobs），检查是否有警告、超时或部分数据未处理的提示。

4. 记录操作未触发SystemModStamp更新

   • Salesforce中，仅修改记录字段的操作会更新SystemModStamp，若记录的可见性变化（如从回收站恢复、共享权限调整）未涉及字段修改，SystemModStamp不会更新；若这些记录的SystemModStamp早于last_sync_date，则不会被同步。
   • 排查方法：
     • 检查缺失记录的回收站恢复历史、共享权限变更记录，确认是否存在未触发字段修改的操作。

临时解决方案 #

• 若确认是SystemModStamp异常导致，可临时改用CreatedDate或LastModifiedDate作为过滤条件（注意：LastModifiedDate包含所有者变更，SystemModStamp仅包含字段修改）。
• 对缺失记录执行批量更新（如更新一个无关字段），触发SystemModStamp更新后重新同步。

内容的提问来源于stack exchange，提问作者YuvalDr