Enterprise Resource Planning Blogs by SAP
Get insights and updates about cloud ERP and RISE with SAP, SAP S/4HANA and SAP S/4HANA Cloud, and more enterprise management capabilities with SAP blog posts.
Showing results for 
Search instead for 
Did you mean: 
Former Member

Introduction :
This blog describes shortly our experiences of increasing the performance of CO-PA by using HANA. To do so we implemented first a HANA side- by – side scenario. Later on we switched to ERP on HANA.

The way from CO-PA on classical DB over a HANA side – by - side scenario to ERP on HANA:
Because of high data volume that increased more and more in the last years, reporting for CO-PA at SAP AG was only possible on BW system. Furthermore management accounting reallocations that were done for costing based CO-PA could only be done in BW due to poor performance caused by the high data volume.
Therefore SAP AG decided to implement a side – by - side scenario for costing based CO-PA. The reason was to gain experience with the HANA DB and to get an insight how much the performance will be increased by HANA. For the side – by –side scenario the CO-PA accelerator was used.
The following picture shows roughly how the side – by – side scenario looked like.

The CO-PA table CE1XXXX which holds the transactional data of CO-PA was replicated to a HANA box. If CO-PA reads data from this table, the data were selected from the table CE1XXXX of the HANA Box. The rest of CO-PA was not changed or affected, only selects of the standard CO-PA coding were done on the HANA Box to speed up the performance of CO-PA.
The administration of this behavior in detail was customized with transaction KEHC that is part of the CO-PA accelerator.
Every system in the system landscape, development system, quality system and productive system had a HANA box beside. The data replication to the HANA box was done at first by a program that runs in batch, later on it was replicated with SAP LT replication server.
The BW reporting remained unchanged to minimize risk that means the CO-PA data were uploaded to BW as before and the users did their CO-PA reporting in BW.
Some power users in ERP benefited from the fact that transactions KE24 and SE16H increased significantly from a performance point of view.
In addition there was another positive effect too, regarding custom developed programs of CO – PA. At SAP there are management wise postings for some SAP specific processes. These  specific processes that are done to enhance reporting capabilities of CO-PA and to fulfill some specific requirements of the Controlling department. The postings for that processes depend on the standard postings of CO-PA and are a kind of follow up – postings. Because of the high data volume it was not possible before HANA to do these postings in CO-PA. Due to that reason the postings were done in BW. The disadvantage of this was that the postings were not available real-time. The controller had to wait until the data was uploaded and calculated in BW.
With the HANA side-by-side scenario it was possible to bring these processes back to ERP and to realize them as an online scenario. To do so ABAP programs were developed for these scenarios that select the CO-PA data with standard function modules RKE_DATA_READ_CALLBACK. This standard function module makes use of the CO-PA HANA accelerator and selects the data automatically from the HANA database depending on the customizing entries done with transaction KEHC. Because the performance increased rapidly, it was possible to implement the scenarios as online scenarios. That means, every time after a CO-PA document has been created, an asynchronous event is triggered and an event – handler function module reads the newly created document together with some other necessary documents from the HANA database, calculates the values for the follow – up document and saves it immediately to the database.
Now that CO-PA was such fast with the HANA box, it was even possible to post the documents for the last 8 years afterwards too in CO-PA to get also historical data for the scenarios on the ERP side.

Conclusion :
• The experience with the HANA side – by –side scenario was very positive because performance increased rapidly.
• It was possible to bring follow – up postings from BW back to ERP by developing custom programs that are able to read CO-PA data such fast from HANA that the follow-up postings are done real-time now.
• For the custom developed programs it was beneficial to use the standard function modules for selecting and saving CO-PA data so that the standard cares about selecting CO-PA data in an appropriate way.
• In the meantime the side - by – side scenario at SAP has been switched off because SAP switched the whole ERP system to the HANA database.
• Another positive effect was, that the custom developed programs for the follow – up scenario didn’t have to be changed for the switch from HANA side – by – side scenario to ERP on HANA because they use CO-PA standard function modules to read and save data. These function modules now reads the data from the underlying HANA DB of the SAP ERP system. Because of that the switch from the HANA side - by - side scenario to ERP on HANA was relatively uncomplicated for these programs. The performance is at least as good as for the side – by – side scenario, but of course data replication is no longer necessary.