使用 Bulk API 2.0 时 Salesforce 丢失记录

Question

我们正在使用 Salesforce Bulk API 2.0 查询作业来复制 SF 实例中的更改 (https://developer.salesforce.com/docs/atlas.en-us.api_asynch.meta/api_asynch/query_create_job.htm)将记录上传到我们的仓库。 我们使用以下查询来提取数据：

SELECT id,... FROM Lead WHERE systemModStamp > <last_sync_date>

其中last_sync_date是我们仓库中存在的最大systemModStamp时间戳 - 基本上提取自上次同步以来已修改/更新的所有记录。

最近我们注意到 Lead 对象中的一些记录丢失了 - 我们可以使用 SF Web 应用程序查看它们，但在基于 systemModStamp 字段进行过滤时它们丢失了，即使我们过滤的时间戳是在创建记录之前也是如此。 使用查询显式过滤该记录时：

SELECT id,... FROM Lead WHERE id = <lead_id>

其中 Lead_id 是我们丢失的记录 ID，我们确实得到了结果中丢失的记录，这可能解决了我们的权限问题 - 这也可以使用

createddate

字段。

我们丢失的记录看起来与任何其他记录没有任何不同，也没有任何可能导致此行为的标志。

我们尝试更改 API 版本，但似乎没有任何影响。

Answer 1

我们此刻也看到了类似的情况。虽然我不知道根本问题，但我确实有一个理论。是否会出现以下情况：

• 发生记录的插入或更新； id已设置，systemModStamp已设置；交易尚未提交
• 发生了一个或多个其他行动 - 已承诺
• 我们调用API根据之前的最后一个id或systemModStamp值检索记录；我们会找到所有满足这个条件并且已经提交的记录。我们得到一个新的（高水位线）和/或 systemModStamp。
• 仍待处理的第一个更改现已提交，并且更改或新记录对 API 可见
• 下次我们使用新的或新的高水位线 systemModStamp 值调用 API 进行过滤时，我们不会检索该记录 - 因为它的 ID 低于（较早分配）和/或其 systemModStamp 早于之前的 API 调用时间或 systemModStamp 的高水位线值。

所以我的理论是，DML 语句（设置 Id 和 systemModStamp ）和实际提交（使记录可见）（可能与稍后开始并较早完成的其他事务结合使用）之间的短暂时间可能会导致此记录检索逻辑不滴水不漏。

我们将进一步研究这个理论。我们现在的解决方法是使用早于我们希望的值的 systemModStamp 值进行查询，检索潜在的重复项（我们之前处理过的记录），同时也获取我们现在错过的记录。我们需要照顾重复项。

如果您有任何更新，我会非常感兴趣。

亲切的问候， 卢卡斯