Custom ABAP Code Migrating to SAP HANA and

S4 HANA

By
Muralikrishna Dabbugudi
 Agenda
•1 What is HANA and how do we differentiate with other
databases?
•2 Path for HANA Migration
•3 Let’s see ABAP Code in HANA
•4 Tools for facts-based code migration planning
•5 Best Practice & Recommendations for code migration to HANA
•6 S/4 HANA and ABAP Code
•7 What are the Available tools and Options
•8 Q&A
What is HANA and how is it different from other databases?
SAP HANA is an in-memory database and application platform, which is for many
operations 10-1000x faster than a regular database like Oracle on the same hardware

SAP HANA database is different by design. It stores all data in-memory, in columnar format
and compressed. Everything is calculated on-demand, on the fly, in main memory. HANA is
the solutions to all the problems of columnar databases, like concurrency (HANA uses
MVCC) and row-level insert and update performance (HANA uses various mechanisms like a
delta store).

For ABAP code, it means that most of the

calculations / analytical operations can be
performed at database level, thus reducing the
data flow and time taken for massive data sets.
Options for Hana upgrade
ABAP Code on HANA

Current Context: ABAP Runs

on HANA
Migration of the ABAP custom code to HANA
Even though HANA is fully compatible based on the Open SQL support in the SAP NetWeaver
Application Server ABAP. Existing database specific ABAP coding needs to be revisited and
possibly adapted. Furthermore, there are some additional recommendations related to the
nature of the In-Memory columnar storage in SAP HANA.
The migration of the ABAP custom code to HANA can be split into two/Three main areas:
1. Functional modifications of the custom code
• The main task is to locate ABAP code that potentially relies on specific properties of
the predecessor data base and that might need to be modified. One example of this
is the use of native SQL in ABAP custom code.

2. SQL performance optimization of the custom code

• New tools are available for effective optimization: The new ABAP SQL monitor, static
Code Inspector performance checks, and the SQL Performance Tuning Worklist.

3. SAP HANA only supports Unicode installations, So code has to be Unicode enabled.
5 Golden Rules for Database Programming

All 5 golden rules apply for HANA but

with differed priorities
Functional (Mandatory) code Adaptions
1. Adaptions to any database migration.
• Native SQL and database (DB) hints.
For native SQL you must check whether the SQL code can also run on SAP
HANA or whether it should be adjusted.
• ADBC (ABAP Database Connectivity) usages (should be treated in a similar
way to native SQL).
2. Adaptions specific to the migration to SAP HANA
• Usages of special ABAP Dictionary function modules that check/provide the
existence or technical properties of certain database indexes. On SAP Hana,
most of the database indexes are not in use, and these checks are therefore
usually obsolete.
• Accesses to technical (!) pools/clusters of a pooled/cluster table. As part of
an SAP HANA migration, most pooled and cluster tables are converted to
transparent tables of the same name. After this step, access to these
technical pools/clusters that are no longer used does not make sense.
• Non-robust ABAP code that relies on a non-guaranteed/implicit sorting of
certain SQL queries, even though no ORDER BY clause is used.
For these incorrect ABAP source code sections, an explicit sorting of the SQL
query must be inserted (ORDER BY clause or ABAP SORT).
Optimization (optional) code Adaptions
• SQL operation without WHERE clause. The semantics of this statement should be
checked for changing operations, in particular.
• SQL operation with the supplement FOR ALL ENTRIES IN <intab>, where the code does
not ensure that the internal table <intab> is always filled. (For an empty internal table
<intab> the complete WHERE clause of the SQL operation disappears, according to the
ABAP documentation.)
• Check ABAP Dictionary table settings for consistency. In particular, this checks whether
table buffer settings have been maintained consistently (performance).
• Supplementary runtime checks
• SQL operation with the supplement FOR ALL ENTRIES IN <intab>, where the code
does not ensure that the internal table <intab> is always filled.
• Location of non-robust ABAP code that relies on a non-guaranteed/implicit sorting
of certain SQL queries, even though no ORDER BY clause is used.
 Runtime and Static Analysis Tools for Planning
• If no SQL Monitor data is
available, data from the Usage
Procedure Logging (UPL) can be
used to distinguish used code
from unused code.
• If the ABAP Test Cockpit is not
available (or specific improved
code checks are not available),
the ABAP Code Inspector with the
existing checks can still assist in
finding some issues.
• If the SQL Performance Tuning
Worklist is not available, then the
runtime data and check results
need to be analyzed
independently.
• SQL Monitor data can be collected
(using the ST/PI Add-On) in a
productive SAP NetWeaver 7.00
system, and afterwards analyzed
in the SQL Performance Tuning
Worklist in an SAP NetWeaver
7.31 system together with the
Existing tools (STAD, the ABAP Trace Tool SAT and the SQL Trace ST05) are complemented by findings of a code analysis
some new utilities which can ease the transition to SAP HANA performed in the same system.
ABAP Test Cockpit/Code inspector (transaction ATC/SCI)

Most of the functional check have been introduced in NetWeaver release 7.02 SP14 and above,
Some of the check have lot of False positives as the tool does Static code analysis. So this data has
to be combined with runtime statistics to get the correct list of Adaptions for Migration.
Usage scenarios for ABAP Test Cockpit/Code inspector
 SQL monitor (transaction SQLM)
Default setting is to switch
off the SQL monitor after 7
days, but one should aim
for a month covering the
month end if possible year
end runtime data.

The Potential candidates for

performance optimization are
the ones with DB time high (
>70% ) and change time low (
<= 1% )

Available statistics
Collected data is aggregated by
• Number of executions
• Process type (e.g. transaction, report ,RFC module, HTTP request)
• Entry point (e. g. transaction VA01) • Execution time (maximum, minimum, average,
• ABAP source code location of the statement (i.e. program, include, line) standard deviation)
• Database table names (e.g. MARA). • Fetched/changed rows (maximum, minimum,
The data quality decreases whenever processes are modified. average, standard deviation)
• Number of internal sessions that triggered the
respective SQL statement
Usage scenario for SQL Monitor
Usage scenario for SQL Monitor
SQL Performance Tuning Worklist (transaction code SWLT)
SQL Performance Tuning Worklist is a tool for combining the result of a code analysis with
relevant runtime data coming from a productive system. This combination of data makes it
easy to generate a ranked work list for SQL performance tuning by analyzing and filtering
the data set
Why SQL Performance Tuning Worklist ?
SQL Worklist effectively combines runtime and static time analysis of abap code in a single
report for a complete analysis.

We can set:
• Object set filter: we can select the object set (e.g. limit to Z*, Y*, etc.) for limiting the
number of the retrieved check results / SQL monitor data.
• Runtime data: SQL monitor data snapshot can be imported via RFC or a local file into
SWLT
• [Optional] Coverage Analyzer: If no SQL monitor data is available, you can use code
coverage data (obtained e.g. via the Usage and Procedure Logging; UPL) from a
remote system to get at least the number of executions on the level of
modularization units. In particular, this allows ruling out coding which is never
invoked at all.
• Code analysis: we can Choose a Code Inspector or ATC result by providing the Code
Inspector inspection or the ATC run series. SWLT will always choose the latest version of
the available results.
Usage Scenarios for SQL Performance Tuning Worklist
HANA Migration process model
Planning phase
Check list for planning code migration:

1. Check whether all installed components (including e.g. SAP or partner Add-Ons are supported on SAP HANA). Please consult SAP Notes 1812713
(NetWeaver), 1760306 (ERP), 1855666 (3rd party) for compatibility information. As SAP HANA supports only Unicode installations, a Unicode
Conversion might be a part of the transitioning project

2. Install and configure the SQL Monitor tool in all relevant systems.

3. Run SQL Monitor in productive system(s) to collect SQL runtime data. Usually a timeframe of 1-4 weeks is recommended. Capture the
data as a snapshot.

4. Schedule ATC check-runs for source code analysis

a. Check existing custom ABAP code for mandatory adaptation
b. Check existing custom ABAP code for optimization candidates

5. Analyze the ATC findings with mandatory adaptation

a. The number of findings may serve as a first indicator for the required effort.
b. As a rule of thumb, findings related to existing database specific implementations (primarily native SQL) are significantly more
expensive to adapt compared to findings related to the sorting behavior.

6. Correlate the SQL Monitor results with ATC check results in the Performance Tuning Worklist
a. Pre-Analyze the SQL Monitor results (plausibility checks)
b. Import the SQL Monitor snapshot and ATC result data into the SWLT
c. Rank the findings by different criteria and select candidates.

7. Estimate and plan adaptations

a. Estimate the impact of optimizations (e.g. determine theoretical lower boundaries or create dedicated prototypes in a sandbox environment),
b. Choose findings with best cost/benefit ratio.
Reference:
http://scn.sap.com/docs/DOC-59923
Thank You

Muralikrishna Dabbugudi
Sr. SAP Solution Architect