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
Possible adaptations of and corrections to ABAP custom code can generally be divided into two
- 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
Selecting the Code Inspector Variant when Using the ATC
Selecting the Code Inspector Variant in the Initial Screen of the
Recommended Code Inspector Variants
When executing static checks for
custom ABAP code, use the following optimized Code Inspector
Currently, the following checks are included in this check
- 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
- 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
- Finding accesses to technical pools/clusters of a pool/cluster table
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).
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
- 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
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
- 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).
this check variant for performing a static performance check run for ABAP custom
code. The variant contains all the essential static SQL performance
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.
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.
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
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