By

Muralikrishna Dabbugudi

Custom ABAP Code Migrating to SAP HANA and S4 HANA

• 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

Agenda

What is HANA and how is it different from other databases?

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).

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

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

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.

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.

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 findings of a code analysis performed in the same system.

Existing tools (STAD, the ABAP Trace Tool SAT and the SQL Trace ST05) are complemented by some new utilities which can ease the transition to SAP HANA

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.

Collected data is aggregated by • Process type (e.g. transaction, report ,RFC module, HTTP request) • Entry point (e. g. transaction VA01) • ABAP source code location of the statement (i.e. program, include, line) • Database table names (e.g. MARA).

The data quality decreases whenever processes are modified.

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

Available statistics• Number of executions • Execution time (maximum, minimum, average,

standard deviation) • Fetched/changed rows (maximum, minimum,

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 phaseCheck 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 DabbugudiSr. SAP Solution Architect