SAP Cloud for Customer
ERP Business Partner Integration
Performance Improvement
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.
The improvement
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.
Implications
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:
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
- Customer.xbo
- BusinessPartner.xbo
- BusinessPartnerRelationship.xbo
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.
- 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).
Please enjoy,
Ludger
