The purpose of this blog is to describe ABAP Test Cockpit (ATC) checks. ATC is based on Code Inspector (SCI), it reuses Code Inspector checks and significantly improves the code quality by offering the uniform quality criteria for the whole development landscape and establishing new quality assurance processes (quality gates, exemptions, mass regression tests) to minimize errors in productive systems.

A general overview of ATC can be found in the blog ABAP Test Cockpit – an Introduction to SAP’s new ABAP Quality Assurance Tool. More details about remote code analysis using ATC you can read in the blog series about Remote Code Analysis in ATC.

I focus in this blog on the main ATC checks categories:

Please note: you can find the SAP S/4HANA related checks in the blog SAP S/4HANA System Conversion – Custom code adaptation process

Robust Programming Checks

This category contains:

Append entries to SORTED TABLE in specific position can be done using APPEND or INSERT with INDEX to insert entries into internal tables of type SORTED. If, however, the sort order is not kept, an exception which can´t be handled is raised at runtime.

This check finds the statements specified.

Search DB Operations in Pool/Cluster Tables Check finds all SQL accesses to physical pool or cluster tables.

Direct access to the physical (not logical) pool or cluster is suspicious. After depooling/declustering these accesses are hard errors, because after depooling/declustering the logical table is converted to a transparent table, but the physical pool or cluster is still there but empty.

All accesses with SQL to these tables are senseless after depooling/declustering and shall be corrected.

Empty Unused Procedures Check identifies the procedures in ABAP programs that are empty and have never been called in the current system.

Here, procedures also include ABAP events such as START-OF-SELECTION.

The test returns the different types of procedures in the results list as follows:

  • METH: Methods
  • FORM: Forms
  • FUNC: Function modules
  • MODI: Modules (INPUT)
  • MODO: Modules (OUTPUT)
  • SSEL: START-OF-SELECTION (can also be a REPORT statement)
  • ATPF: AT PFnn
  • GET: GET dbtab.
  • GETL: GET dbtab LATE.

Messages from the test can be hidden using the pseudo comment.

Analyze ABAP source code with the RND parser identifies such source code, either so that you can improve it, or in order to analyze unexpected behavior of such tools.

Many tools that process ABAP source code (such as pretty printer and code completion) do not use the ABAP compiler but a component called RND parser. There are situations where the ABAP compiler accepts source code but the RND parser does not, which means that above mentioned tools might behave unexpectedly.

The test delivers the following result messages:

  • TOKEN – RND parser does not recognize the token: check whether you can replace obsolete with modern syntax or whether you can rename variables so that special characters (punctuation characters except underscore etc.) are avoided
  • TIME_OUT – RND parser could not analyze the code in reasonable time: this is probably a bug, create a ticket for BC-ABA-LA.

Complex WHERE Condition in the SELECT Statement check searches for complex WHERE conditions when SELECT is used. It can search for:

  • OR branches of differing lengths, meaning they have different numbers of comparison fields
  • OR branches containing different fields.
  • WHERE conditions that contain a high number of AND joins
  • ABAP JOINs that join a large number of tables.

Test for support of Field Extension searches for statements where problems occurs during a field extension. The check parameters are:

  • Full-Names of the types which should be extended
  • New Length of the types
  • Comment for the field extension. The comment is included in the check messages.

Test to check handling of type INT8 searches for statements that have to be changed for the introduction of the new type INT8 (8 Byte Integer). The check parameters are:

  • Only local calls: with this parameter, you can specify if external procedure calls should be analyzed too.
  • Non-local analysis depth: with this parameter, you can specify the maximal evaluation depth into external programs.

Search problematic statements for result of SELECT/OPEN CURSOR without ORDER BY searches for SELECT and OPEN CURSOR statements where no ORDER BY clause is specified.

Afterwards problematic statements are searched which use the results of these SELECT or OPEN CURSOR statements. Problematic statements are statements which depend on the order of the entries of an internal table. The problematic statements are listed further below.

If the result of a SELECT or OPEN CURSOR statement is sorted by performing a SORT-Statement or by assigning to a sorted table the searching is aborted.

SELECT SINGLE statements are analyzed independently of problematic statements afterwards. They are problematic if they are ambiguous, i.e. if the WHERE condition does not specify a full key of the database table or if the FROM clause contains a JOIN. If the result of an ambiguous SELECT SINGLE statement is not used no message is thrown.

The check parameters are:

  • Only local calls: with this parameter you can specify if external procedure call should be analyzed too
  • Report access to Pool/Cluster table: Controls whether the messages SEL_POOL/CLUST or OPEN_POOL/CLUST are raised
  • Non-local analysis depth: With this parameter you can specify the maximal evaluation depth into external programs.

Tenuous use of FOR ALL ENTRIES check tries by some heuristics to judge from static code analysis if the program flow ensures content or not. These heuristics are not capable to analyze the full complexity of data flows in ABAP however. The heuristics try to avoid false positives. This also implies there are false negative findings; there constellations where code flaws are not reported.


Programming Convention Checks

This category contains:

ABAP naming convention checks which examine whether the naming conventions specified by the test parameters are met for the various objects (such as types, classes, or fields) defined in an ABAP program.

Extended check on naming conventions in ABAP programs examines whether the naming conventions specified by the test parameters are met for the various objects (such as types, classes, or fields) defined in an ABAP program.

Pretty Print State check in ABAP Programs establishes whether the ABAP code is formatted with respect to the configured Pretty Print variants.

ABAP unit test conventions check helps you to detect flaws in the code of Unit Tests. Unit Tests are special code fragments that execute the domain code in order to detect functional errors within the domain code. The test fragments – typically local classes – underlie some constraints. For example, they must not require interactive user input in order to ensure the capability of fully automated test execution.


User Interface Checks

This category contains:

Web Dynpro Component – Active Components check uses technology, such as Java, Adobe Flash, Microsoft Silverlight or others, to provide enriched functionality to the user.

Due to security constraints and the ongoing improvement of HTML, CSS and JavaScript, some of these technologies are no longer necessary or can be replaced by native functions. Additionally, browser vendors have started to block such plugin technologies.

This check identifies UI elements which are active components to provide an opportunity to analyze the usage of these elements. The rules of the check are:

  • Usage of Adobe Flash based component which requires a Adobe Flash plugin to be available in the Web browser of the user.
  • Usage of Adobe Forms based component which requires the Adobe Reader plugin to be available in the Web browser of the user.
  • Usage of Java applet based component which requires the installation of the JAVA runtime on the user machine. Additionally, a plugin is required in the Web browser of the user
  • Usage of Microsoft ActiveX based component which requires the usage of Microsoft Internet Explorer as Web browser.
  • Usage of Microsoft Office integration component which requires the installation of Microsoft Office and a Microsoft-based Web browser, e.g. Internet Explorer.
  • Usage of Microsoft Silverlight based component which requires the Microsoft Silverlight plugin to be available in the Web browser of the user.

Web Dynpro Component – Standard Check delegates the analysis of Web Dynpro Components to the technical check also used by the IDE. The IDs of findings are mapped generically by the priority used in the IDE. If you compare the information about the findings in the IDE and in the Code Inspector adapter, the IDE contains more information.

Web Dynpro Conventions for Source Text allows you to enhance the declaration of the user interface using code in certain places.

This Code Inspector test enables you to identify these problematic statements and avoid problems before they arise. These checks cover the following areas:

  • Database access
  • File access
  • Lists & Dynpro technology
  • Changes to the program flow
  • Low-level commands
  • Including source code
  • Direct method call
  • Querying the parameter interface

Dynpro Checks are checks on dynpros and resource consumption.

This check contains all usability and accessibility checks for dynpros and the scope of the check is identical to that in the menu function Check -> Layout in Screen Painter (used for dynpro editing in the integrated SAP GUI).

‘SAP Script’ Scanner analyzes SAP Script content (SE61-documentation).

The following issues can be identified by the scanner:

  • Inconsistencies between transport key repository (TADIR) and document repository
  • Inactive document content
  • Inconsistent document content, like malformed tags
  • Invalid meta data, like missing master language.


CDS Checks

This category contains:

Annotation Check for Data Definitions: This check verifies the usage of annotations in Data Definition sources.

The following examples are findings reported by the check:

Annotation &1 does not exist
Diagnosis: annotation does not exist.
Procedure: use an existing annotation suggested by code completion.

Annotation &1 is used at a wrong position
Diagnosis: annotation cannot be used at current position as it is defined for the usage at another position.
Procedure: move the annotation to the correct position or remove it. Only annotations suggested by code completion can be used at this position.

Referenced Objects in CDS: This check reports usages of not existing elements, parameters, associations within annotations values with following types: elementRef, keyElementRef, parameterRef and associationRef.

The following examples are findings reported by the check:

Element &2 for &1 not found
Diagnosis: referenced element doesn’t exist.
Procedure: use an existing select list entry or association.

Key element &2 for &1 not found
Diagnosis: referenced key select list entry doesn’t exist or is not marked as key.
Procedure: use an existing select list entry marked as key.

Syntax Check for CDS Metadata Extensions: This check wraps the syntax check for CDS Metadata Extensions and reports a subset of warnings. These warnings do not prohibit the activation of a Metadata Extension. Under some circumstances, the usage of the affected Metadata Extension may cause runtime abortions.

The following examples are findings reported by the check:

Select list entry ‘&1’ does not exist in ‘&2’
Diagnosis: referenced select list entry doesn’t exist in the annotated view.
Procedure: use an existing select list entry from the annotated view or delete the affected select list entry from the Metadata Extension including all its annotations.

Entity ‘&1’ for ‘&2’ not found
Diagnosis: referenced entity doesn’t exist in the system or is not active.
Procedure: use an active entity.

New NetWeaver Information at

Very Helpfull

User Rating: Be the first one !