Salesforce 到 salesforce 的往返字段更新问题

Question

自从我不得不进行 S2S 集成以来，已经发布了几个版本，但我遇到了一个意想不到的问题，希望有人能更有效地解决这个问题。

我有两个组织，通过 S2S 共享联系人。

每个组织中的联系人都具有相同的架构，即标准字段和自定义字段。我复制了一个只有两个自定义字段的基本案例:复选框字段 A 和 Number(18,0) 字段 B。

组织 1 发布字段 A，并订阅字段 B。

组织 2 订阅字段 A，并发布字段 B。

组织 1 通过通过 S2S 与组织 2 共享联系人来启动所有 S2S 工作流程。组织 2 已启用自动接受。

Org 2 有一个 Contact Before Insert 触发器，它只使用字段 A 来计算字段 B 的值。例如如果选中字段 A，则用 2 填充字段 B，如果未选中，则填充 0。(这当然是对我真正需要做的事情的过度简化，但这是基本的可重现情况。)

在 Org 2 中一切正常 - 联系人在字段 A 中表现良好，我看到字段结果被计算到字段 B 中。

问题是结果 - 字段 B - 在下一次联系人更新之前不会自动共享回 Org 1。它可以像我在组织 2 中编辑同一联系人的非共享字段一样简单，例如“描述”，然后我立即看到先前计算的字段 B 的值被推回组织 1。

我假设这是因为，由于字段 B 的计算发生在插入前，S2S 连接假定当前更新事务仅由其自身执行(我可以看到这种逻辑如何防止无限 S2S 更新循环)。

我首先尝试创建一个工作流字段更新，当字段 B 更改时强制更新一个(新的，虚拟的)共享字段，但这仍然没有导致更新回流，大概是因为它在 Salesforce 认为免于重新的相同执行上下文中-分享。还尝试了一个工作流规则，当字段更改时将 Lead 转发回连接队列，它也不起作用。

然后我在 AfterUpdate 触发器中尝试了重新更新语句 - 如果共享字段已更新，则重新加载并重新更新共享对象。那也没有用。

我确实找到了一个解决方案，这是一个由 AfterUpdate 触发器调用的 Future 方法，它重新加载并接触任何由 BeforeUpdate 触发器更改其共享字段的记录。这确实会导致现场结果近乎实时地显示在原始组织中。

这个解决方案现在对我有用，但我觉得我必须遗漏一些东西。它会导致执行更多的 Future 调用和 DML，而不是必要的。

有没有人对此有更优雅的解决方案？

Answer 1

遇到了同样的问题，一位了不起的 Salesforce 支持代表发现了这个文档，其中涵盖了 Salesforce 的具体指导:https://web.archive.org/web/20210603004222/https://help.salesforce.com/articleView?id=sf.business_network_workflows.htm&type=5

Sometimes it makes sense to use an Apex trigger instead of a workflow. Suppose that you have a workflow rule that updates a secondary field, field B, when field A is updated. Even if your Salesforce to Salesforce partner subscribed to fields A and B, updates to field B that are triggered by your workflow rule aren’t sent to your partner’s organization. This prevents a loop of updates.

If you want such secondary field updates to be sent to your Salesforce to Salesforce partners, replace the workflow with an Apex trigger that uses post-commit logic to update the secondary field.

In bi-directional connections, Salesforce to Salesforce updates are triggered back only on “after” triggers (for example, “after insert” or “after update”), not on “before” triggers.

这就是 OP 最终要做的事情，但 Salesforce 的这份文档至少澄清了此处作为讨论的一部分所做的假设和猜测。它还有助于指出，在这些情况下使用“before”触发器不是最佳实践，以供将来引用。