ABAP custom code adaption for SAP HANA

The efficient way

Posted by Thomas Fiedler in SAP S/4HANA on Apr 22, 2016 10:29:13 AM
inShare192

Introduction
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 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
informtion.
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.
A very good introduction of the SQL monitor can be found here: http://scn.sap.com/docs/DOC47444
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 nonproductively 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 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 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 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.
Performance optimizations
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 optimizations
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.
Performance optimizations
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 community: ABAP
for SAP HANA
Good starting point for CDS is: Getting Started with ABAP Core Data Services
and for AMDP go for: ABAP Managed Database Procedures - Introduction