Select language:

ABAP Test Cockpit and Code Inspector in Context of HANA Migration

Note This topic does not address the common usage of ABAP Test Cockpit (ATC) and Code Inspector when running static code analysis. In fact, it focuses on the usage of these tools in the context of HANA migration.

See SAP Note: 1912445 Information published on SAP site

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 two tools are available for executing static checks:

  • ABAP Test Cockpit (ATC) - in the case of systems SAP EhP2 and upwards for SAP NetWeaver 7.0 SP 12.
  • Code Inspector - in the case of older systems (< SAP EhP2 for SAP NetWeaver 7.0, SP 12), static checks must be performed using the Code Inspector instead.
    Figure 1: Selecting the Code Inspector Variant when Using the ATC
    Figure 2: Selecting the Code Inspector Variant in the Initial Screen of the Code Inspector
Recommended Code Inspector Variants

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

Currently, the following checks are included in this check variant:

  • 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
Note Since genuine errors are found using these checks, they are of special importance. An explicit sort of the SQL query must be inserted (ORDER BY clause or ABAP SORT) for those ABAP code sections that contain them.
Note We recommend you to use both checks. The focus of the analysis, however, should not be on priority 1 and 2 messages of the check "Search problematic statement…w/o ORDER BY". The messages of the partially redundant check “Depooling/Declustering: Search for…w/o ORDER BY” have a high false-positive rate and can be processed with lesser urgency.

For more details on checks, refer to the documentation of the check in question (in the Code Inspector or the ATC).


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

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.

Note Remember that the selection of static checks within a check variant can become obsolete at any time as a result of new findings, and may possibly need to be amended. The content of the check variants therefore vary between the supported SAP NetWeaver releases because in each release you may have different checks / check parameters at your disposal.
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.