ABAP Test Cockpit and Code Inspector in Context of HANA Migration
See SAP Note: 1912445
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.
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 ATCFigure 2: Selecting the Code Inspector Variant in the Initial Screen of the Code Inspector
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 SQLNote 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) hintsNote 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) UsagesNote 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 tableNote 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 ”
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 ClauseNote 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.
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.
The following content is not part of SAP product documentation. For more information, see the following disclaimer .