Introduction:

This blog briefly outlines our experiences utilising HANA to improve CO-PA performance. To do this, we first put a HANA side-by-side situation into practise. Later, we shifted to HANA-based ERP.

The path from CO-PA on traditional DB over a side-by-side HANA scenario to ERP on HANA is as follows:
Reporting for CO-PA at SAP AG was only achievable on the BW system because of the huge data volume, which has expanded steadily over the last few years. Furthermore, due to poor performance brought on by the enormous data volume, management accounting reallocations performed for costing-based CO-PA could only be performed in BW. 

In order to implement a side-by-side scenario for costing-based CO-PA, SAP AG made this decision. The goal was to become more familiar with the HANA DB and to learn how much HANA will boost performance. It was decided to use the CO-PA accelerator for the side-by-side scenario.
The side-by-side scenario is broadly depicted in the accompanying image.

The transactional data for CO-PA is stored in the CO-PA database CE1XXXX, which has been duplicated to a HANA box. The data were chosen from the table CE1XXXX of the HANA Box if CO-PA reads data from this table. Only a small portion of the regular CO-PA coding was completed on the HANA Box in order to speed up CO-performance; PA’s the rest of CO-PA was neither altered or negatively impacted.
With transaction KEHC, which is a component of the CO-PA accelerator, this behavior’s administration was specifically tailored.

A HANA box was next to each system in the system landscape, including the development system, quality system, and productive system. Initially, a batch-running software replicated the data to the HANA machine; eventually, the SAP LT replication server copied the data.
To reduce risk, BW reporting stayed the same, which meant that users continued to submit their CO-PA reporting in BW and that CO-PA data were transferred to BW as previously.
The fact that transactions KE24 and SE16H greatly improved in terms of performance helped several power users in ERP.

Another advantageous result related to CO-specially PA’s created programmes was also present. For several SAP-specific processes, there exist posts at the management level. These particular procedures are carried out to improve CO-reporting PA’s capabilities and to satisfy some particular demands of the controlling department. The postings for those procedures are similar to follow-up postings and rely on the regular postings of CO-PA. Prior to HANA, it was impossible to perform these postings in CO-PA due to the huge data volume. The postings were made in BW as a result. The postings were not available in real-time, which was a drawback. The data had to be uploaded and calculated in BW before the controller could act.

These procedures might be returned to ERP and realised as an online scenario using the HANA side-by-side scenario. For these circumstances, ABAP applications were created that use the standard function module RKE DATA READ CALLBACK to select the CO-PA data. Utilizing the CO-PA HANA accelerator, this standard function module automatically chooses data from the HANA database based on the customizations made with transaction KEHC. The situations could be used as online scenarios because of the quick growth in performance. This means that each time a CO-PA document is created, an asynchronous event is triggered. In response, an event-handler function module reads the newly created document and some other necessary documents from the HANA database, calculates the values for the follow-up document, and saves it right away to the database.
It was also possible to publish the papers for the subsequent 8 years in CO-PA to obtain historical data for the scenarios on the ERP side because CO-PA was so quick with the HANA box at this point.

Conclusion:

• Performance increased quickly, which made the HANA side-by-side scenario a really favourable experience.

• By creating customised programmes that can read CO-PA data from HANA so quickly that the follow-up postings are now completed in real-time, it was possible to bring follow-up postings from BW back to ERP.

• It was advantageous to use the standard function modules for picking and saving CO-PA data in the custom generated applications since the standard is concerned with selecting CO-PA data properly.

• As a result of SAP switching its entire ERP system to the HANA database, the side-by-side scenario has been disabled.

• Another beneficial result was, that the specially generated programmes for the follow – up scenario didn’t have to be updated for the changeover from HANA side – by – side scenario to ERP on HANA because they use CO-PA standard function modules to read and write data. These function modules now reads the data from the underlying HANA DB of the SAP ERP system. Because of this, the transition for these programmes from the HANA side-by-side situation to ERP on HANA was comparatively simple. Performance is at least on par with that in the side-by-side scenario, but data replication is obviously no longer required.