SAP Cloud for Customer – ERP Business Partner Integration – Performance Improvement
SAP Cloud for Customer
ERP Business Partner Integration
available in test systems since February 2020 (productive with 2005)
As of the February 2020 release in SAP Cloud for Customer, we added a performance improvement to test deployments regarding the replication of business partners from SAP Cloud for Customer to SAP ERP. This improvement in performance is especially noticeable if you have a very high number of contacts. This feature is applicable if you have activated the ‘Replicate Business Partners to SAP ERP’ communication arrangement.
We plan to set this into productive use with the SAP Cloud for Customer May 2020 release.
Replication still stays how it has been before: any change to an account or any of its contacts triggers a replication of the entire network of contacts to SAP ERP, regardless of whether all of them require an update.
We’ve made some changes to the framework which improves the response time of the user interface. Before, the user interface remained unresponsive until outbound replication of all object had been completed. With this change outbound SAP ERP replication messages will be sent after the user interface returns to an interactive state.
Furthermore, sending of outbound SAP ERP business partner replication messages has been decoupled from invalidating the business objects in Cloud for Customer with this change.
Before, the entire network of contact business objects of an account needed to be invalidated (“touched”) in Cloud for Customer in order to trigger sending of required replication messages to SAP ERP.
Removing the invalidation of these additional business objects in SAP Cloud for Customer reduces the computational load: data validation and computation of dependent data as well as calls to custom PDI extensions will not be performed anymore for these unmodified objects with this code change.
If your ERP Business Partner Replication Scenario is extended via SAP Cloud Applications Studio (PDI), then there might be implications to be considered.
Your extension code needs to be checked and may require an update.
Let’s understand what needs to be done with an example:
Let’s assume we have the following business objects of type BusinessPartner:
- An Account A
with two Contacts:
- Contact C1
- Contact C2
Technically these contacts are connected by two additional business objects of type BusinessPartnerRelationship:
- Contact relationship R1 from account A to contact C1
- Contact relationship R2 from account A to contact C2
With the previous logic, any change to the business objects A, C1, C2, R1 or R1 additionally triggered an internal update (“touch”) in SAP CLoud for Customer to the following business objects:
- Account A
- Contact Relationships R1 and R2
With this feature, there is no longer an an internal update trigger to these business objects in Cloud for Customer.
Consequences for custom SAP Cloud Application Studio extensions
Therefore, if your custom extension relies on the trigger of AfterModify/BeforeSave events of related objects, then your extension may not work as expected.
To check whether your extensions are affected, you need to look at the following PDI extension events:
- Either BeforeSave or AfterModify on
Check the logic of these events considering the following questions:
- Does your logic assumes to be executed on Account A and accesses data from a related contact (C1 or C2 in the above example)? Does the logic requires to be re-executed if this data changes?
- Does your logic assumes to be executed on BusinessPartnerRelationship (R1 or R2 in above example) and accesses data from account A or a related contact (C1 or C2)? Does the logic requires to be executed if this data changes?
If your answer to anyone of these questions is a Yes, then this feature can affect your extensions. See the Solution section.
Solution if your extension is affected
If your PDI code is affected, then you have two options how to adjust your tenant:
- The recommended approach is:
Adjust your PDI solution logic to remove dependency on another object as described above.
- Alternatively, you can implement a PDI logic which re-implements the previous functionality.
Note: In this case your tenant will only partially benefit from the performance improvement gained by the underlying framework improvements.
How do you have to adjust your PDI logic to remove this dependency (recommended option 1)?
- Executed on account A, your logic accesses data from a contact C1 or C2:
=> then you need to adjust the logic as follows:
- Events on Customer.xbo:
Extract the dependent logic and move it to the respective BusinessPartner.xbo event such that the calculation is performed on the contact BusinessPartner event and not the account A1.
- Events on BusinessPartner.xbo:
Extract the dependent logic.
Use an appropriate IF-condition to detect whether the event is called for account A or contact C1/C2.
Place the extracted logic in the branch called for the modified contact.
- Events on Customer.xbo:
- Executed on contact BusinesParterRelationship R1 or R2, your logic accesses data from account A or contact C1 or C2:
=> then you need to adjust the logic as follows:
- Extract the dependent logic and move it to the respective BusinessPartner.xbo event such that the calculation is performed on the account A1′ or contact C1/C2 BusinessPartner events and not of the relationship R1/R2.
Basic guide line is: processing of data changes need to be handled on the business objects events where the data change occurs and not on events of dependent objects.
How to add a PDI logic re-implementing the previous functionality (option 2)?
- Download the compatibility solution template file for SAP Cloud Application Studio from this link.
I have already described how to upload and active a PDI solution template at the end of this blog (steps one to eight only).
Hi Ludger Buenger,
Thanks for the detailed explanation. You mentioned that the change is applicable if we use arrangement Replicate Business Partners to SAP ERP. However considering the fact that the change is preventing additional update ("touch") on all BPs involved into a relation with updated BP I was wondering if this is influencing exclusively arrangement Replicate Business Partners to SAP ERP or also arrangement Business Partner Replication to SAP Business Suite?
Thanks in advance for your feedback.
I see, you understood the implication well.
The important point is:
The "previous behavior" I am describing was tied to the existence of an active instance of the communication arrangement Replicate Business Partners to SAP ERP.
This means: the specific behavior that relations and contacts were "touched" applied only if an active instance of this communication arrangement existed. Deactivating this communication arrangement removed.
Even before, if no communication arrangement with Replicate Business Partners to SAP ERP was active, the relationships were not touched.
Now you point out this influences Business Partner Replication to SAP Business Suite as well.
You are correct: if there is the ERP communication arrangement, the additional touches also caused replication messages to other destinations which now are not sent anymore.
Does this clarifies the dependency you asked about?
I need the PDI logic package to re-implement the previous logic, however it is no longer available. Could you please provide me with the compatibility solution package that was available in this link?
could you please elaborate a little bit about the use case for your requirement to have this compatibility solution being updated?
The change in behavior to which this is related happened three years ago, so I currently do not see the need to provide an update to a compatibility solution to support such aged behavior.
Maybe you can contact me and elaborate on the business requirement requiring this?
Thank you and best regards,