ABAP Test Cockpit and Code Inspector in Context of HANA Migration

Possible adaptations of and corrections to ABAP custom code can generally be divided into two main areas:

Functional adaptations
SQL performance optimizations

Analysis of the custom code is supported in both areas through static Code Inspector checks in order to find the affected ABAP code parts.

In the case of functional adaptations of custom code, the primary goal is to detect, using checks, ABAP code that relies on specific features of a database and thus definitely needs to be analyzed and, if necessary, adapted. An example of this is native SQL usage in ABAP custom code. Such functional adaptations require, for the most part, clear, local corrections in program code that do not demand a deep knowledge of the application.

In the case of SQL performance optimizations, the interaction of various tools and checks is vital for performing the optimization effectively. Here, the new SQL Monitor is used, in addition to the new static Code Inspector performance checks and also the SQL Performance Tuning Work List.

Keep in mind that the static performance checks can generate a large number of messages. However, this is not particularly worrying because these performance checks are merely of an indicative nature (for example: a “nested SELECT” exists). Only in combination with the relevant performance data can these results from static checks be used effectively. By combination with the performance data (from the SQL Monitor) the number of recommended performance corrections is generally reduced quite considerably.

Executing Static Checks with ATC or Code Inspector

These tools are available for executing static checks:

ABAP Test Cockpit (ATC): SAP NetWeaver 7.0 EHP2 SP 12 and higher

Selecting the Code Inspector Variant when Using the ATC
Remote code analysis in ATC: For earlier releases in SAP_BASIS>=7.00
For more information, see .
Code Inspector: For older systems below SAP NetWeaver 7.0 EHP2 SP 12

Selecting the Code Inspector Variant in the Initial Screen of the Code Inspector

Further Information

Code Inspector

Quality Checking with the ABAP Test Cockpit

Recommended Code Inspector Variants

When executing static checks for custom ABAP code, use the following optimized Code Inspector variants.

FUNCTIONAL_DB

Finding Native SQL

Note

For native SQL, you have to check whether the SQL code can be run on SAP HANA and whether it needs to be adapted.
Database (DB) hints

Note

Messages on DB hints are to be viewed solely as indications; although DB hints are declared for specific databases, generally they do not need to be adapted.
Finding ADBC (ABAP Database Connectivity) Usages

Note

These usages are to be treated similarly to native SQL.
Finding usages of special DDIC function modules that check or return the existence or technical properties of certain DB indexes.

Note

On SAP HANA, most DB indexes are not in use and therefore these checks are generally obsolete.
Finding accesses to technical pools/clusters of a pool/cluster table

Note

In the course of an SAP HANA migration, most pool and cluster tables are converted into transparent tables of the same name. After this step, access to these technical pools/clusters that are no longer used does not serve any purpose.
Finding non-robust ABAP code that relies on non-ensured/implicit sorting of certain SQL queries, although no ORDER BY clause is used. There are two different checks available for finding non-robust ABAP code:
- “Search problematic statement…w/o ORDER BY”
- “Depooling/Declustering: Search for…w/o ORDER BY ”

FUNCTIONAL_DB_ADDITION

This check variant contains additional checks that are not directly linked with the SAP HANA migration. However, they can detect - as experience has shown - important, potential functional errors and low-performance SQL statements. Therefore, the checks of this check variant are not mandatory for the SAP HANA migration, but they are recommended.

This check variant currently includes the following checks:

Checking SQL Operations without a WHERE Clause

Note

In particular for operations that perform a change, like UPDATE and DELETE, the semantics of this statement should be checked.
Checking SQL operations with the addition FOR ALL ENTRIES IN <itab>, whereby in the code itself it is not ensured that the internal table < itab> is always filled.

Note

Keep in mind that in accordance with the ABAP documentation for an empty internal table <itab> the entire WHERE clause of the SQL operation is suppressed. This can, in certain circumstances, result in reduced performance levels.
Checking settings in DDIC tables for consistency. In particular, this checks whether table buffer settings have been maintained in a consistent manner (influence on performance).

PERFORMANCE_DB

We recommend this check variant for performing a static performance check run for ABAP custom code. The variant contains all the essential static SQL performance checks.

However, we do not recommend an isolated view of these static performance checks for the entire custom code because processing the results would be ineffective. Pure static checks also include ABAP code that is not used at runtime at all or is not critical for performance.

The essential tool for an overall view of the custom code with regard to performance optimization is the new SQL Monitor. It returns aggregated performance data from the productive system for the executed SQL commands. This runtime data of the SQL Monitor often provides immediate work lists with potential performance improvements for custom code.

In addition, however, this runtime data can be merged with results of the static performance checks. This linking of both data sources is performed in the SQL Performance Tuning Worklist tool. In this way, you get indications or even solution suggestions from the static performance checks for SQL statements that stand out negatively in the SQL Monitor.

Supplementary Runtime Checks

In addition to the static checks, there are supplementary runtime checks that are executed using the Runtime Check Monitor tool.

The runtime checks thus complement the static checks with aspects that could not be checked statically (for example, dynamic code) and they show only suspicious code parts that were also executed at runtime.