自2020年2月SAP Cloud for Customer发布以来，我们增加了一项性能改进，以测试有关业务合作伙伴从SAP Cloud for Customer复制到SAP ERP的部署。如果您的联系人数量非常多，则性能的这种改进尤其明显。如果您已激活"将业务伙伴复制到SAP ERP"通信安排，则此功能适用。我们计划在SAP Cloud for Customer 2020年5月发布时将其投入生产性使用。

改进

复制仍然保持以前的状态：对帐户或其任何联系人的任何更改都会触发将整个联系人网络复制到SAP ERP，美国云服务器，淘客大联盟，不管它们是否都需要更新。

我们对框架做了一些修改，提高了用户界面的响应时间。以前，农业物联网，用户界面一直没有响应，直到所有对象的出站复制完成。此更改将在用户界面返回交互状态后发送出站SAP ERP复制消息。

此外，发送出站SAP ERP业务合作伙伴复制消息与使用此更改使客户在云中的业务对象无效已分离。之前，一个账户的联系人业务对象的整个网络需要在云计算中为客户失效（"触摸"），以便触发向SAP ERP发送所需的复制消息。

在SAP云计算中为客户消除这些额外业务对象的失效减少了计算负载：数据验证和计算如果您的ERP业务伙伴复制方案是通过SAP Cloud Applications Studio（PDI）扩展的，则此代码更改后，将不再对这些未修改的对象执行依赖数据的复制以及对自定义PDI扩展的调用。

影响

如果您的ERP业务伙伴复制方案是通过SAP Cloud Applications Studio（PDI）扩展的，然后可能会有一些影响需要考虑。

您的扩展代码需要检查，大数据概念，智慧农业物联网系统，可能需要更新。

让我们用一个例子来了解需要做什么：

让我们假设我们有以下类型BusinessPartner的业务对象：

帐户A有两个联系人：触点C1联系人C2

从技术上讲，这些联系人由BusinessPartnerRelationship类型的两个附加业务对象连接：

从帐户A到联系人C1的联系人关系R1联系关系R2从账户A到联系C2

根据之前的逻辑，对业务对象A、C1、C2、R1或R1的任何更改都会额外触发SAP CLoud中对以下业务对象的内部更新（"touch"）：

账户A联系关系R1和R2

使用此功能，客户云中的这些业务对象不再有内部更新触发器。

因此，如果您的自定义扩展依赖于相关对象的AfterModify/BeforeSave事件的触发器，则您的扩展可能无法按预期工作。

检查您的扩展是否正常受影响，您需要查看以下PDI扩展事件：

保存前或修改后开启客户.xbo业务伙伴.xbo业务sPartnerRelationship.xbo公司

考虑到以下问题，检查这些事件的逻辑：

您的逻辑是否假定在帐户A上执行并访问相关联系人（上例中的C1或C2）的数据？如果数据发生变化，是否需要重新执行逻辑？

您的逻辑是否假定在BusinessPartnerRelationship（上述示例中的R1或R2）上执行，并从帐户A或相关联系人（C1或C2）访问数据？如果数据发生变化，是否需要执行逻辑？

如果您对其中任何一个问题的回答都是"是"，则此功能可能会影响您的扩展。请参阅解决方案部分。

如果您的PDI代码受到影响，那么您有两个选项如何调整租户：

您必须如何调整PDI逻辑以删除此依赖关系（建议选项1）？

在帐户A上执行，您的逻辑从触点C1或C2访问数据：=>然后你需要调整逻辑如下：上的事件客户.xbo:提取相关逻辑并将其移动到相应的业务伙伴.xbo事件，以便对联系人业务伙伴事件而不是帐户A1执行计算。上的事件业务伙伴.xbo:提取依赖逻辑。使用适当的IF条件来检测是为帐户A调用事件还是为联系人C1/C2调用事件。将提取的逻辑放在为修改的触点调用的分支中。在联系人业务伙伴关系R1或R2上执行，您的逻辑从帐户A或联系人C1或C2访问数据：=>然后你需要调整逻辑如下：提取相关逻辑并将其移动到相应的业务伙伴.xbo事件，以便对账户A1′或联系人C1/C2业务伙伴事件执行计算，而不是对关系R1/R2执行计算。

基本准则是：需要对发生数据更改的业务对象事件处理数据更改而不是依赖对象的事件。

如何添加PDI逻辑来重新实现以前的功能（选项2）？

我已经在这个博客的末尾描述了如何上传和激活PDI解决方案模板（仅步骤一到八）。