ABAP custom code adaption for SAP HANA – The efficient way

Posted by Thomas Fiedler on SCN

Currently many SAP customers plan and are evaluating the migration from their classic ERP system running on any DB to Business Suite on SAP HANA or S/4HANA. For both scenarios custom ABAP code needs to be adapted for SAP HANA. This paper shares best practices in order to minimise the adaption effort. The recommended procedure has already been applied successfully in many different SAP Hana migration projects.

Basic facts about the adaption of ABAP code for SAP HANA
In general all ABAP code runs on SAP HANA as on any other supported database. Some SQLs are faster on HANA , e.g. when selecting columns without an index. Only ABAP code which relies on specific features or capabilities of the predecessor database must be analyzed and corrected. There are three main aspects for custom ABAP code adaption for SAP HANA:

Mandatory corrections of your code to avoid functional regression
Target: ABAP code, SQL code or database calls which build on specific features of the predecessor database

(e.g. native SQL, ABAP code relying on certain sort order of a SQL result set)

Recommended SQL performance optimizations in order to avoid performance degradations
Target: “Bad” SQLs in custom code playing a dominant role in the runtime profile of productive business processes. Special focus is on SQLs which are executed very frequently (e.g. SELECT in loop).

Exploit SAP HANA Code pushdown techniques
by using Core Data Services and SQL script procedures to speed up custom code processes significantly

This papers focuses on the first two aspects which are part of the SAP HANA migration. The third step normally happens after the migration and is addressed in custom development projects driven by business requirements.

Recommended tools

For functional corrections the ABAP platform provides static code check tools like Code Inspector and the ABAP Test Cockpit. In addition, ABAP developers and test engineers can build unit tests and scenario tests in order to ensure functional correctness. For the SAP HANA migration SAP provides new static checks integrated in the code inspector. These checks are bundled in the code inspector variant FUNCTIONAL_DB and FUNCTIONAL_DB_ADDITION.

Please check the SAP note: http://service.sap.com/sap/support/notes/1935918 in case the variant does not exist in your system.
In addition to the static checks SAP also provides a new runtime check monitor, transaction SRCTM.

Please check the SAP Note: http://service.sap.com/sap/support/notes/1931870 for more information.
For performance optimisations the ABAP platform provides runtime tools for tracing and monitoring the performance of the business processes. The main tools are Runtime Analysis, SQL Trace and the workload monitor for runtime monitoring. With NetWeaver 7.40, the new SQL monitor was introduced to analyze SQL statements in your productive system. The SQL Monitor is the recommended tool for optimizing SQLs in custom code during the migration to SAP HANA.

A very good introduction of the SQL monitor can be found here: http://scn.sap.com/docs/DOC-47444

Please check the SAP Note http://service.sap.com/sap/support/notes/1885926 to find information how you can get the SQL monitor in lower releases.
Additionally, the developer can use static checks integrated in the code inspector to find and avoid performance bugs in the code. For the SAP HANA migration, some additional static performance checks are available to find performance hints. The static checks are bundled in the code inspector variant PERFORMANCE_DB. But please be aware that these checks should only be used as additonal hints when fixing the issues detected by the SQL monitor analysis. Never fix the static findings without looking in the SQL monitor before.

For condensing the custom code work package during the SAP HANA migration it is recommended to use the Usage Procedure Logging (UPL) in order to focus the functional corrections on the productively used code. Cleaning up of non-productively used code before the migration is therefore strongly recommended. A good overview about the UPL can be found here: http://scn.sap.com/docs/DOC-54826

Recommended step by step process for the custom code adaption:

Project planning phase

Before you start the journey towards SAP HANA you should first reflect the current situation of your custom code in your landscape to get an impression about the efforts needed for the migration. Topics like custom code retirement, custom code quality optimisation, custom code process optimisation and the custom code impact analysis are helpful offerings to refine the custom code strategy in your company. SAP is offering various services to help customers here. You can find more information about these options in the custom code management community: Custom Code Management

Preparation phase before the migration (old system landscape)

Before you start with the migration of the database you have to do some preparation steps in your old landscape in order to be successful with the project. The following steps are recommended:

Limit work package (optional)

A very important step in such a migration project is to do some housekeeping before the project starts. Get an overview about your custom code and analyze which code is really necessary for your business. Ideally eliminate code that is not used anymore before the migration starts. Use the Usage Procedure Log (UPL) to create a custom code directory containing only the productively used code.

Performance optimisations

Switch on SQL Monitor in the old productive system for ~ 2 weeks to monitor the performance of your productive business processes. Sort the SQL Monitor results in transaction SQLM by “number of execution” and optimize the 10-20 Top most executed SQLs in your custom code which affect relevant business processes (e.g. SELECT in Loop can be transformed in FOR ALL ENTRIES).

During the migration (new system landscape)

Correct functional issues via static checks

In the upgraded development system, run the code inspector with the static checks from the variant FUNCTIONAL_DB for your custom code.

Correct the priority one and two findings

Correct functional issues via runtime checks
Switch on the runtime check monitor SRTCM in the upgraded test system in order to monitor the tests of your business processes. Correct the additional findings found by runtime check.

After these corrections are done you should now start your standard tests for functional corrections via standard unit tests and scenario tests.

Performance optimisations

Switch on SQL Monitor in the upgraded test system in order to monitor the tests of your business processes.

Sort the SQL Monitor results by “execution time” and optimise the first Top 10 SQLs in in your custom code which affect relevant business processes.

After the migration (productive system is live on SAP HANA)

Functional corrections – runtime checks

Switch on the runtime check monitor again in the new productive system and correct the additional findings found by the runtime check.

Performance optimisations

Switch on SQL Monitor in the productive system. Sort the SQL Monitor results by “execution time” and optimise the 10-20 Top SQLs in your custom code which affect relevant business processes. After performance optimisations reached the productive system, this process needs to be repeated 2-3 times in order to achieve the best results.

Optimise your code for SAP HANA

After the successful migration you can now start to think about optimising your business processes by using code push down techniques of SAP HANA like the Core Data Servcies (CDS) and ABAP managed database procedures (AMDP) implemented with the native HANA language SQL script.

Find more information about these capabilities in the ABAP for SAP HANA community: ABAP for SAP HANA