Currently many SAP customers plan and evaluate 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 minimize the adaptation effort. The recommended procedure has already been applied successfully in many different SAP Hana migration projects.
Basic facts about the adaptation 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 adaptation 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.
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 SRTCM.
Please check the SAP Note: http://service.sap.com/sap/support/notes/1931870 for more information.
For performance optimizations 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. The tool runs in the productive system and monitors the business processes without harming your system performance as the overhead of the tool is neglectable (<3%).
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. Do 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 adaptation
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 optimization, custom code process optimization 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 ABAP Testing and Analysis community.
Preparation phase before the migration (old system landscape)
Before you start with the migration of the database you have to do some prepartion steps in your old landscape in order to be succuessful 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.
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. Findings of all priorities are relevant for the analysis.
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.
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 optimize 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.
Switch on SQL Monitor in the productive system. Sort the SQL Monitor results by “execution time” and optimize the 10-20 Top SQLs in your custom code which affect relevant business processes. After performance optimizations reached the productive system, this process needs to be repeated 2-3 times in order to achieve the best results.
Optimize your code for SAP HANA
After the successful migration you can now start to think about optimizing 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 document: ABAP for SAP HANA Reference Scenario.