Code Inspector

Purpose
The Code Inspector is a generic tool that you use to check SAP repository objects.
You use it to define inspections which examine object sets with the help of check
variants. It checks the performance, security, syntax, and adherence to naming
conventions of individual or sets of repository objects. You also use it to retrieve
statistical information or to search for certain ABAP tokens. As a result of an
inspection, you receive information, warning, and error messages about the
different properties of the examined objects.
To start the Code Inspector, perform one of the following:
Choose SAP Menu Tools ABAP Workbench Test Code
Inspector.
From the SAP Easy Access, enter transaction code SCI.
Features
The Code Inspector comprises the following elements:
Inspection, where you can perform checks on an object.
You can display, create, change, copy, create a new version of, delete, and see
the results of an inspection.
Object set, where you can determine the objects to be checked.
You can display, create, change, copy, and delete an object set.
Check variant, where you can define the individual checks that are performed
on the objects.
You can display, create, change, copy, and delete a check variant.
Constraints
The range of functions of the Code Inspector is limited to checking static object
definitions and can only point out certain problems. For example, it cannot give a
precise prediction of the overall program performance. To do this, you need to
analyze the program execution at runtime, using the Runtime Analysis (transaction
code SAT), the Performance Analysis (transaction code ST05), the Global
Performance Analysis (transaction code ST30), or another relevant tool.
ABAP Unit
Purpose
Automated tests could help to recognize such changes which break the existing
code. Unit testing is a technique that enables testing during development.
Dedicated test classes invoke the tested program and compare the result with the
expectation. ABAP Unit implements this technique. ABAP Unit is integrated both in
the ABAP runtime and in the ABAP Workbench, which facilitates the writing of tests.
Page 1 of 74

ABAP Code Inspector

Features
The key features of ABAP Unit are the following:
Tests are written in ABAP itself. You do not have to use additional tools or
scripting languages.
The program being developed can be checked from within the editor.
The integrated coverage analysis helps to identify code which is not tested.
An adapter that is embedded in the Code Inspector allows you to execute
multiple tests.
To write a unit test is to write a dedicated local test class within the main program.
An integral part of the program the test class and the code being tested is one
transport object. This ensures that test coding and tested coding always have the
same version.
ABAP Unit identifies all test classes and invokes them to check the code being
tested. A service class allows the test classes to analyze the state and raise
assertions if necessary.
If you have all the code tested, the integrated coverage analysis help you to identify
which code was actually invoked from the test classes. The source which was not
executed can be highlighted in the edit control.
The adapter to the test framework Code Inspector offers the power to run multiple
tests such as all unit tests within one development package.

Performance Trace Overview

Use
The Performance Trace allows you to record database access, locking activities,
remote calls of reports and transactions, and table buffer calls from the SAP system
in a trace file and to display the performance log as a list. The Performance Trace
additionally offers wide support when analyzing individual trace records in detail.
Integration
The Performance Trace is fully integrated in the ABAP Workbench, and can be called
from the ABAP Workbench initial screen.
Prerequisites
To use the Performance Trace, you need authorization to start Transaction ST05 and
the system authorizations "Change trace switches" (authorization STOM for
Page 2 of 74

ABAP Code Inspector

authorization object S_ADMI_FCD) and "Analyze traces" (authorization STOR, also

for authorization object S_ADMI_FCD).
Features
The following traces are available:
1. SQL Trace: This allows you to monitor the database access of reports and
transactions.
See also SQL Trace Analysis.
2. Enqueue Trace: This allows you to monitor the locking system.
See also Enqueue Trace Analysis.
3. RFC Trace: This provides information about Remote Function Calls between
instances.
See also RFC Trace Analysis.
4. Table buffer trace: You can use this to monitor database calls of reports
and transactions made via the table buffer. See also, Table Buffer Trace Analysis.
Activities
You access the initial screen of the Performance Trace via:
Transaction code ST05
From ABAP Workbench using the menu path Test Performance Trace.

Architecture and Navigation

The following graphic shows the architecture with the main components and
navigation options within the test tool:

Page 3 of 74

ABAP Code Inspector

Navigation
On the initial screen, you can start and stop trace recording. The measurement
results are saved in a trace file after execution of the program to be analyzed.
You can restrict the quantity of performance data displayed using a display filter and
by defining selection criteria.
The performance data can then be displayed, either in the form of a basic trace list,
an extended trace list, or atime-sorted trace list.
You can manipulate the display of data even further:
With Edit SQL Statement, you call up the appropriate editor.
You call up a description of Dictionary objects through the display DDIC
Info. From here you can easily branch to the definition in the DDIC.
Using Detailed Info, you can call up a detailed display for the statement to be
analyzed.
You can determine identical Select statements easily through the
display Identical Selects.
Using the Summary function, you can summarize a trace list by statements or
tables.
In addition, you can display an execution plan for a selected SQL statement
using Explain SQL.
Using the function List Sort, you can sort the trace records according to different
properties for example, transaction name, process ID, process type, or even
stored sequence.
Using the function Display Long Name, you can display the extended names for
the objects or program.
Page 4 of 74

ABAP Code Inspector

You can branch from the display of performance data for a statement to the
appropriate source code in the ABAP Editor.

Initial Screen
Calling
You can call the initial screen of the test tool using transaction code ST05 or by
choosing Test Performance Trace in the ABAP Workbench.

Functions
The following functions are available on the initial screen:
Select trace:
Select the trace mode SQL Trace, Enqueue Trace, RFC Trace, or Table Buffer
Trace. You can select mutliple trace modes simultaneously.
Select trace function:
Start the trace recording.
Stop the trace recording.
Page 5 of 74

ABAP Code Inspector

 Branch to trace list, detailed list, or time-sorted list.

Branch to Explain SQL to analyze an SQL statement without an explicit trace file.

Trace files are managed by the system. Thus they can be saved,
like any other object; saved trace files can be displayed and deleted.
Trace Status
A trace can only be activated once on any application server. The Trace
Status display informs you whether another user in the system has already
activated a particular trace.

Recording Performance Data

Preparation
By default and for performance reasons, the performance trace is switched off in
SAP systems. If you want to analyze a report or transaction using the performance
trace, you must first establish whether you want to analyze the interaction of
reports and transactions, their effects on one another, the behavior of one or more
individual reports and transactions, or only program sections.
As trace records are stored in up to ten circular memory files, trace
records can be overwritten. If the memory space of a file is insufficient,
the recording continues at the start of the next file. It is therefore a
good idea to log important procedures separately. To avoid data being
overwritten, you can also reduce the trace interval or extend the
circular memory. You can see any errors by choosing Overview of Trace
Kernel Errors under Goto. In the following, the term trace file is used in
the context of a trace recording, regardless of how many physical files
the recording actually covers.
Essential Information
Before you can record trace records, you must switch on the performance trace for
an instance of the SAP system.
Here, you can specify which trace functions (SQL trace, enqueue trace, RFC trace,
table buffer trace) you want to switch on, and for which user or users they should be
activated.
You can then run the reports or transactions that you want to analyze, before
switching the trace off again.
This process generates a trace file, containing all logged trace records, which you
can then analyze, either immediately or later on. If you decide to repeat the trace or
Page 6 of 74

ABAP Code Inspector

analyze the results later on, remember that the data in the trace file can be
overwritten (see above).

Starting the Trace

Prerequisites
You can only switch on the Performance Trace for a single instance. You should
already have decided the scope and targets of your performance analysis.
Procedure
To analyze a trace file, do the following:
1.

1. Choose the menu path Test Performance Trace in the ABAP Workbench.
The initial screen of the test tool appears. In the lower part of the screen, the
status of the Performance Trace is displayed. This provides you with information
as to whether any of the Performance Traces are switched on and the users for
which they are enabled. It also tells you which user has switched the trace on.
2. 2. Using the selection buttons provided, set which trace functions you wish to
have switched on (SWL trace, enqueue trace, RFC trace, table buffer trace).
3. 3. If you want to switch on the trace under your user name, choose Trace on.
If you want to pass on values for one or several filter criteria, choose Trace with
Filter.
Typical filter criteria are: the name of the user, transaction name, process name,
and program name.
4. 4. Now run the program to be analyzed.

You will normally analyze the performance trace file immediately. In

this case, it is a good idea to use a separate session to start, stop, and
analyze the Performance Trace

If you are shown trace kernel errors on the initial screen (for example,
not enough storage space available), you must first remove the errors
or have them removed by your system administrator.

Page 7 of 74

ABAP Code Inspector

The selected trace types can be changed as required during a

performance trace interval (time between switching on and off the
trace). The user (user group) must remain unchanged.
Result
The results of the trace recording are written to a trace file. If trace records are
overwritten during the trace interval, the system displays a message to inform you
when you analyze the trace file.

The results of the trace recording are stored to ten trace files.
Overwriting trace records, however, cannot be entirely excluded in this
case either.
The Performance Trace records all database access calls, table buffer
calls, remote calls, or calls for user lock activity. These measurements
can affect the performance of the application server where the trace is
running. To preserve system performance, you should therefore turn off
the traceas soon as you finish recording your application.

Stopping the Trace

Prerequisites
You have started the trace and finished running the program that you want to
analyze.

For performance reasons, you should switch off the traces as soon as
you have finished recording.
Procedure
To deactivate the trace:
Page 8 of 74

ABAP Code Inspector

5.

1. Choose Test Performance Trace in the ABAP Workbench.

The initial screen of the test tool appears. It contains a status line displaying the
traces that are active, the users for whom they are active, and the user who
activated them.
6. 2. Select the trace functions that you want to switch off.
7. 3. Choose Deactivate Trace.
If you started the trace yourself, you can now switch it off immediately. If the
performance trace was started by a different user, a confirmation prompt
appears before deactivationResult
The results of the trace are stored in one or more trace files. You can then analyze
the performance data stored in the trace file. See also, Analyzing Performance Data.

Analyzing Performance Data

Prerequisites
Once you have switched off the performance trace, you can analyze the data The
data is analyzed, even repeatedly, until its trace records are overwritten in the trace
file. The trace files are managed by the SAP system. You can therefore keep a trace
file for editing and delete it later through the menu Performance Trace->Save
Trace, Display Saved Trace, and Delete Saved Trace.
Procedure: Overview
Before you start analyzing the trace records, you must first switch off the
Performance Trace. (It is also possible to display a trace without switching it off
beforehand. In this case, however, the display procedure is also recorded in the
trace file, in accordance with the set filter criteria for the trace.
For more information, refer to:
Stopping the Trace Recording.
Before displaying the trace records, you can use a display filter to specify the
records to be edited and the information that you want to look at.
For more information, refer to:
Display Filters.
Page 9 of 74

ABAP Code Inspector

When you display the trace records, you can choose between a basic list and an
extended list. Both lists display an overview of the logged actions and performance
data. In addition, you can display a trace list sorted by time.
For more information, refer to:
Displaying Lists of Trace Records.
In both lists the simple trace list and the extended list you have the same range
of functions for analyzing the listed statements and other performance data.
The time-sorted trace lists is only slightly different from the trace lists mentioned
above. For more information on the transaction, process type, client, and user, call
up the function Display->User, Transaction and so on in the Goto menu.

For more information, refer to:

Analyzing Trace Records
Other analysis options depend on the trace types that you are using. See also:
SQL Trace or
Enqueue Trace or
RFC Trace.

Display Filter
Prerequisites
You have switched off the performance trace and have opened the display filter
after choosing Display Trace or the corresponding menu entry from the initial screen
of the performance trace.
Use
You can use the display filter (Set Restrictions for Displaying Trace) to restrict the
number of logged trace records that are displayed on the basic list (Trace List),
detailed list, or time-sorted list.

Page 10 of 74

ABAP Code Inspector

Features

If you do not enter any selections, all of the trace records are selected.
Specifying the Trace Type to Display
The SAP system also initializes this parameter from the system environment. The
default trace type is SQL trace. If you start the display filter directly after the
recording, the trace type appears as it was last configured.
Specifying the Trace Interval
The system initializes the trace interval from 00:00:00 to the current system time on
todays date. However, if you start the display filter directly after the recording, the
trace interval is set from the start time to the end time of the recording.

Note that if you are working on a distributed system, where the clocks
on the database server and the application servers are not
synchronized, any times determined automatically by the system may
be inaccurate, which in turn may mean that not all trace records are
displayed.
Page 11 of 74

ABAP Code Inspector

Enter Further Selections

For further information refer to:
Other Filters
Update Selection Criteria
With this button, your display filter entries are updated. You can also use the
ENTER key for this.
Select Operator for Selection Conditions
With this button, you can change the default option and select and operator. To
do so, place the cursor on the relevant parameter.
Initialize the Selection Criteria
If you repeat the performance trace during a session, the default filter
parameters are set to your last selections. Use the Initialize All Selection
Criteria function (right mouse button) to restore the original defaults.
Delete Selected Selection Criterion
Choose this button to reset restrictions for individual parameters (see also Other
Selection Options).
See also Displaying Lists of Trace Records.

Other Filters
You can also filter the trace record display using the following parameters:
User
Objects

SQL trace: Table name that the SQL statement refers to

Enqueue trace: Lock object that the statement refers to
RFC trace: Instance on which a function is executed
Table buffer trace: Name of the table that the access is limited too
Page 12 of 74

ABAP Code Inspector

 Duration
Operations

SQL trace: Database operations

Enqueue trace: Operation for the lock object
RFC trace: Characteristics of the execution (client/server)
Table buffer trace: Name of the buffer operation

The default filters are:

- For User, the current user
- For Objects, the display of the system tables is suppressed. Currently, these are
the tables D010*, REPOLOAD, REPOSRC, REPOTEXT, DYNPSOURCE, DYNPLOAD,
DYNPTXTLD, DDLOG.
The Duration and Operations parameters are not initialized
You can specify a numeric value for the Duration. This is measured in microseconds.
For all other parameters, you can enter a pattern or name. In addition to
alphanumeric characters, you can also use the wildcard characters * and '+ in
patterns.
You can also change the operator in a specification for further filtering. To do this,
position the cursor on the relevant parameter and choose Selection Options. A
dialog box then appears in which you can specify whether trace records satisfying
the condition should be included (green traffic light) or excluded (red traffic light)
from the selection.

Page 13 of 74

ABAP Code Inspector

For the duration, restricting to an interval of 1000 to 5000 seconds

may be of use.

Displaying Lists of Trace Records

Prerequisites
You have chosen the Display Trace function and specified the value range for the
display in the Display Filter, where you have also displayed the trace liste, detailed
list, or time-sorted list.
Lists
The detailed list contains the complete trace list. The detailed list merely contains
three additional columns for the display.
In the time-sorted list, you can display information about the transaction, process
type, client, and user by choosingDisplay -> User, Transaktion, and so on, in
the Goto menu.
There is a range of analysis functions that you can use both on the trace list and on
the detailed list. All lists have the same functions. You can switch between the trace
and detailed lists via a button.

Page 14 of 74

ABAP Code Inspector

The first line of the list contains a subheader, which remains unchanged for all trace
records of a program to be analyzed. It contains the following information:
- Name of the transaction, process identification number, process type, client, and
user name.
The next line contains the following headers:
Duration Execution time of the statement. The time is displayed in the format
milliseconds.microseconds.
Object name
SQL trace record: Name of the database table
Enqueue trace record: Name of the lock object
RFC trace record: Shortened name of the instance on which the function
module was executed
Buffer trace record: Name of the buffered table
Oper
SQL trace record: Name of the operation to be performed on the database.
See also: Measured Database Operations
Enqueue trace record: Name of the lock operation
RFC trace record: Client | Server. (If a function is specified as the Client, this
means that it wass calledremotely. If it is specified as the Server, this
means that the function was made available and executed.)
Buffer trace record: Buffer operation

Rec Number of records

SQL Trace: Number of records retrieved or processed and passed between the
SAP System and the database.
Enqueue trace: Number of granules
RFC Trace: Not used
Buffer trace: Number of processed records
RC - Return code of the logged statement
Statement - Short form of the logged statement
Depends on the trace type

Page 15 of 74

ABAP Code Inspector

The runtime (duration) is highlighted in the list if it exceeds a given

threshold value (100000 microseconds). This is declared in the type
group SQLT as the constant SQLT_DURATION_NEG. You can change
this value by changing the constant accordingly.

Note that the duration can only be as precise as clock of your

hardware platform. The duration cannot be less than the time required
by the hardware. If the execution time of the statement is less than
this time, the duration will be zero.
Detailed List
To switch from the basic list to the extended list, choose Detailed List. The extended
list contains three extra display columns:
hh:mm:ss.ms - The time at which the record was executed (in the form hours:
minutes: seconds: milliseconds).
Program - Name of the program that executed the logged statement.
Curs
SQL trace record: Number of the cursor (link to cursor cache) used to find the
database entries.
Enqueue and RFC trace records: Not used.
Additional Functions
Analyzing Trace Records
Sort list
Display formatted logged statements
Definition of the corresponding ABAP Dictionary object for SQL and Enqueue
trace
Display the logged statement in the source code
Display the access plan for a logged SQL statement
Page 16 of 74

ABAP Code Inspector

 Format identical select statements in the trace list

Summarizing the Trace List
Switch between the two lists
For more information, refer to Analyzing Trace Records
Different Trace Types
The system displays different trace types in different colors.
Standard Functions
A range of standard SAP list functions is also available to help you print the list,
navigate and search in the list, or save the list to an operating system file. These
functions can be called via the corresponding menu entries, buttons, or function
keys.

Analyzing Trace Records

Prerequisites
You have displayed the trace records that you want to analyze in a basic or
extended list.
Functions
Sorting the Trace List and the Extended Trace List
You can sort the list by any of the parameters in the list heading, that is, transaction
name, process identification number, process type, client, and user name. To sort
the list, position the cursor on the relevant column and choose the pushbutton
Sort or the appropriate menu option.
Switching from the Trace List to the Extended Trace List
To switch from the basic simple list to the extended list, choose the pushbutton
Extended List or choose the appropriate menu option.
Detailed Display and Replacing Placeholders
When the logged statement is formatted, you can specify whether to replace the
placeholders in the statement by the current variables or leave them in the
Page 17 of 74

ABAP Code Inspector

statement and list the variables separately. If there are no variables, the two display
forms are identical. To display the statement, double-click its short form or the menu
option Detail, or click the magnifying glass icon.

To replace the placeholders with the current variables, choose the pushbutton
Replace Placeholder in the SQL Statement, or choose the appropriate menu option.
Displaying Information about DDIC Objects
If you wish to look at the Dictionary description for the object (table or lock object)
to which the statement refers, position the cursor on the object and choose DDIC
info. Alternatively, you can choose the same function from the menu. If the current
statement contains several DDIC object (for example, a join), the Object Name row
contains the first object to appear in the statement.
If the log entry is an RFC entry, the column contains a shortened version of the
name of the instance on which the function module is executed. In this case, you
cannot display a Dictionary definition.
You can display further DDIC Dictionary information by opening the actual definition
of the object in the DDIC. For more information, refer to Finding Dictionary
Information.
Execution Plan for SQL Statements
To display the execution plan of a selected SQL statement, place the cursor on the
statement and choose the pushbutton

Explain SQL Statement. The SQL

Page 18 of 74

ABAP Code Inspector

statements for which an execution plan can be displayed depends on the database
system that you are using. The execution plan for a SELECT statement under
the Oracle database system looks like this:

Displaying the Source Code

To switch to the ABAP source code containing the current statement in the log,
position the cursor on the short form display of the statement and choose the
pushbutton
same name.

Display Call Positions in the ABAP Program or the menu option of the

Note that the source code cannot always be displayed. For example, if
the call comes from the SAP kernel, you cannot branch to the program
code.
Identical Selects
When you are analyzing a trace log, it can be particularly useful to find out if there
are any identical select statements. You can do this by choosing the menu
option Identical selects in the menu Trace List. The system compiles a list of any
SQL statements that are executed more than once. You can then eliminate any SQL
statements that are repeated or superfluous.

Page 19 of 74

ABAP Code Inspector

Summarizing the Trace List

You can summarize the select statements in order to get an overview of the total
execution time and the total number of records found. To do this, use the menu
option Trace List->Summarize Trace by SQL Statement. You can also group the trace
records by table access using the menu option Trace List->Combined Table
Accesses.

SQL Trace Analysis

The SQL Trace part of the Performance Trace tool allows you to see how the OPEN
SQL statements that you use in ABAP programs are converted to standard SQL
statements (see Embedded SQL) and the parameters with which the embedded SQL
statements are passed to the database system.
Overview
From the time you turn on the trace function to the time you turn it off again, all
database activity occurring either for a specific user or for an entire system is
recorded. The SAP System takes OPEN SQL statements and converts them in to
embedded SQL statements that it passes to the database and makes the results
available. The embedded SQL statement and its parameters are recorded in the SQL
Trace file. The results of the SQL statement, like return code, number of entries
retrieved, inserted, or deleted by the database are recorded in the SQL Trace file as
well. The log file also contains the runtime of the statement and the place in the
application program, respectively transaction, from which it was called which
enables additional analyses (supported by the SQL Trace function).
From the recorded SQL trace you can deduce:
which SQL statements your application carries out
which values the system uses for specific database accesses and changes
how the system translates ABAP OPEN SQL commands (such as SELECT) into
standard SQL commands
where your application positions COMMIT statements
where your application makes repeated database accesses
what database accesses or changes occur in the update section of your
application

Page 20 of 74

ABAP Code Inspector

Embedded SQL
One of the difficulties of connecting a programming language with an SQL interface
is the transfer of retrieved data records. When the system processes an SQL
statement, it does not know how big the result will be until it has made the
selection. The result consists of table entries, which all have the same structure.
The system has to transfer these records to the calling program in the form of a
data structure, for example an array, that is known to the calling program.
The disadvantage of an array is its static definition. You have to specify the size of
an array before runtime. However, because you cannot know the size of the dataset
the system will return, you must define a very large array to avoid an overflow.
To circumvent this problem, the SAP System translates ABAP Open SQL statements
into Embedded SQL. To do this, the system defines a cursor. The cursor is the
logical connection to the selected datasets in the database and is used to regulate
the data transfer between ABAP programs and the database. See also Database
Operations.
During every FETCH operation, the database passes one or more data records to the
database interface.

Measured Database Operations

Each SQL statement is broken down into database operations by the SAP System
The SQL Trace allows you to measure the runtime of each of these operations:
DECLA
RE

Defines a new cursor within an SAP work process and assigns the SQL
statement to this. The short form of this statement is displayed in the list of the
trace records underStatement. The cursor is given a unique number, the cursor
ID. The cursor ID is used for communication between the SAP System and the
database system.

PREPA
RE

Converts the SQL statement and defines the execution plan.

OPEN

Opens a cursor for a prepared (converted) SELECT statement. OPEN passes the
parameters for the database access. OPEN is used only for SELECT statements.

FETCH

Passes one or several records selected from the database through the SELECT
statement to the DB interface of the SAP System. The selected data is identified
Page 21 of 74

ABAP Code Inspector

through the cursor.

REOPE
N

Opens again a cursor that the system has prepared for a SELECT statement and
passes the new parameters to the database.

EXEC

Transfer of the parameters for the statement from the database and execution
of the statement that change data in the database (for example, using UPDATE,
DELETE, or INSERT).

REEXEC Opens again a cursor that the system has already prepared for a previous EXEC
statement.

Logical Sequence of Database Operations

Database requests are interconnected and always occur in the same logical
sequence.
The DECLARE function defines and numbers the cursor. DECLARE precedes the
PREPARE function.
Use PREPARE to prepare a specific SQL statement, such as:
select * from sflight where carrid eq 'LH'.
and define the access method before the system can transfer the request to the
database. During this preparation, the system is concerned only with the structure
of the SQL statement and not with the values it contains.
The OPEN function takes the prepared SELECT statement and completes it with the
correct values. In the above example, OPEN would issue the field carrid the value
LH.
FETCH passes the entries from the database to the database interface of the SAP
System All of the database operations required to execute an SQL statement are
linked by the same cursor ID.
If the SQL statement makes changes in the database (INSERT, UPDATE,
DELETE), PREPARE is followed byEXEC, which executes the statement
If the system can refer back to an SQL statement that has already been prepared,
there is no PREPARE operation, and the statement is executed
using REOPEN or REEXEC as appropriate

Buffering
The SAP System ensures that data transfer between the SAP System and the
database system is as efficient as possible. To do this, it uses the following
techniques:

Page 22 of 74

ABAP Code Inspector

 Table buffering. The program accesses data from the buffer of the application
server.
Database request buffering. Individual database entries are not read or passed
to the database until required by an OPEN SQL statement.
When you analyze trace records, you should also examine the system's buffering
mechanisms.
Table Buffering
For tables can be either partially or fully buffered (refer to Buffering Database
Tables.), an OPEN SQL statement only accesses the database if the results of the
statement are not already in the buffer Consequently, the SQL Trace does not
contain a command or command sequence for every OPEN SQL statement. On the
other hand, every SQL statement in the trace file has been sent to the database and
executed.
Buffering of Database Requests
To keep the number of runtime-consuming PREPARE calls small, each an
application's work processes hold a certain number of already translated SQL
statements in a special buffer. By default, a process holds up to 250 statements.
If the system must execute a specific OPEN SQL, the system first checks whether
this statement is stored in the "Statement cache". If the statement is in the cache,
the system executes it immediately using a REOPEN (SELECT) or a REEXEC (INSERT,
UPDATE, DELETE).
If the statement is not buffered, a PREPARE operation prepares it for the subsequent
OPEN/EXEC. The system administers the buffer according to the LRU algorithm
("least recently used"). When space is needed for new statements, the statements
that are rarely used are deleted. As a result of the LRU algorithm, the statement
must prepare frequently used statements usually only once.
An application server buffers the DECLARE, PREPARE, OPEN, and EXEC requests
within the cursor cache of one work process. As a result, once the system opens a
cursor for a DECLARE operation, it can use this cursor over and over again within
the same work process.

Analyzing a Sample SQL Data File

When you create an SQL trace file for an application, you can see exactly how the
system handles database operations. In a sample application, a report reads, and
later changes, records on the ABAP Dictionary table SFLIGHT using ABAP Open SQL
statements. Since the table SFLIGHT is not buffered, the system first needs to
access the database to retrieve the records. In the sections below, the data file from
the sample application is analyzed.

Page 23 of 74

ABAP Code Inspector

Read Access
The first screen of the SQL trace file displays each measured database request the
application made. The trace file records when the request occurred and its duration.
The ABAP Dictionary table involved in the request is also listed.
A trace file for a read access of the table SFLIGHT might look like this:

The system measured several database operations involved in retrieving records

from SFLIGHT:
Operati Function
on
PREPARE Prepares the OPEN statement for use and determines the access method. Since
an active cursor with the number 18 is available in the work process's cursor
cache, the system does not perform a DECLARE operation. However, the
system must prepare the SELECT statement that is used to read the table
SFLIGHT.
The system does enter any value into the fields 'MANDT' and 'CARRID' in the
SELECT statement at this point, but instead gives them a database-specific
marker.
OPEN

Opens the cursor and specifies the selection result by filling the selection fields
with concrete values. In this example, the field 'MANDT' receives the value
'000' and the field 'CARRID' receives the value 'LH'. The OPEN operation then
creates a set of retrieved records.

FETCH

Moves the cursor through the dataset created by the OPEN operation. The
array size displayed beside the fetch data means that the system can transfer
a maximum package size of 392 records at one time into the buffered area.
The system allocates this space on the application server for the SFLIGHT
table.
In the above example, the first FETCH retrieves the maximum number of
records from the dataset. Then, the these records are transferred to the
program interface.

Page 24 of 74

ABAP Code Inspector

Write Access
An sample SQL file analyzing a request that changes data in the Table D010SINF
might look like this:

The example shows the system inserting new records into the table (INSERT). As in
the first example, where the system carried out a read-only access, the system
needs to prepare the database operations (PREPARE) that change the database
records. The PREPARE operation precedes the other operations.

Example Explanation of an Oracle Statement

You can use the SQL Trace facility to view explanations of specific Oracle
statements. From within a trace file display, you use the Explain SQL function to
display more information about a specific database request. TheExplain function is
available only for PREPARE and REOPEN operations. To explain a request:
1.
Place the cursor on a line containing the database request you want
explained.
2.
Choose Explain..
The Explain screen shows you the database's strategy for carrying out the
selected operation.
For example, if you are working with an ORACLE database, you can show the
explanation for the following statement:
select * from fllog where flcode = '00000123'.
The system provides the following explanation:
Operation

Options:

Object Name

SELECT STATEMENT

ID

PAID

POS

TABLE ACCESS BY ROWID

FLLOG

INDEX UNIQUE SCAN

FLLOG___0

QUERY PLAN
SELECT STATEMENT
Page 25 of 74

ABAP Code Inspector

TABLE ACCESS BY ROWID

FLLOG

INDEX UNIQUE SCAN

FLLOG___0(UNIQUE)

The fields in the explanation have the following meanings:

OPERATIO Identifies the operation name.
N
OPTIONS

Operation attributes.

OBJECT
NAME

Identifies the object involved in the operation.

ID

Specifies the operation's ID number.

PAID

Specifies the ID number that the current operation transfers its results to.
This is important if nested accesses on various hierarchy levels are involved.

Position

Identifies the next number for operations working on the same hierarchy
level.

In the example above, the key is fully qualified. The database can use the primary
key index FLLOG__0 to access the table records. Every transparent table in the ABAP
Dictionary has a primary key. The system automatically creates an index for this
key. The primary key index is also unique, meaning that there is only one index
entry for every line in the table. As a result, the system uses the UNIQUE SCAN
operation.
The UNIQUE SCAN has the ID 2 and parent ID 1. This means that the operation
passes its results to the operation with ID 1. ID 1 belongs to the TABLE ACCESS
operation. TABLE ACCESS can directly access one record because of the uniqueness
of the BY ROWID index. Once the system chooses an access strategy, it sends the
SELECT statement with ID 0 to the database.
If the SELECT statement does not specify a fully qualified key, the database could
be forced to read the records using a FULL TABLE SCAN. In this case, no index is
available and the database reads the entire table in packages.
If the index is ambiguous, the database uses a RANGE SCAN. The RANGE SCAN
scans over an index area that might contain several sets of retrieved data.
The NESTED LOOP operation exists for nested reads where several indexes are
joined together within one database access.

Example Explanation of an Informix Statement

You can use the SQL Trace facility to view explanations of specific Informix
statements. From within a trace file display, you use the Explain SQL function to
display more information about a specific database request. TheExplain function is
available only for PREPARE and REOPEN operations. To analyze a statement:
Page 26 of 74

ABAP Code Inspector

1.

Place the cursor on a line containing the database request you want
explained.
2.
Choose Explain..
The Explain screen shows you the database's strategy for carrying out the
selected operation.
If you are working with an Informix database and you display the explanation for the
following statement:
select owner from systables where tabname = 'atab'
The system provides the following explanation:
Execution plan of a select statement (Online Optimizer)
QUERY:
SELECT OWNER
FROM SYSTABLES
WHERE TABNAME = ATAB
Estimated Cost: 1
Estimated # of Rows Returned: 1
1) informix.systables: INDEX PATH
(1) Index Keys: tabname owner (Key-Only)
Lower Index Filter: informix.systables.tabname = ATAB
The fields in the explanation have the following meanings:
QUERY

Identifies the SQL statement that was traced.

Estimated Cost Estimates the database expenditure required to execute the statement.
The cost-based optimizer estimates this value in terms of the I/O and
CPU required by the statement. The larger the
Estimated Cost the greater the expenditure.
Estimated # of Estimates the number of table rows that the SQL statement will return.
Rows
Returned:
Immediately below the number of rows returned is the selected execution plan. In
the above example, the execution plan is as follows:
1) informix.systables: INDEX PATH
The
1) indicates that the system processes the systables table as the first step of the
execution plan. For queries that span several tables (views and joins), the
numbering sequence indicates the order the system processes the tables. In this
example, only a single step was needed.
The execution plan specifies the type of table access. In the above example, the
access was the
INDEX PATH . Access to the required data row is made using the index of
the systables table. Normally, the execution plan uses the primary key as an index.
Every transparent table in the ABAP Dictionary has a primary key and the system
automatically creates an index for this key.
Page 27 of 74

ABAP Code Inspector

When the system must read a large proportion of a table, the system
does not use the primary key as an index.
For this example, the system did not need to read the row that corresponds to the
index key. The information that was required was present in the key itself. The
explanation indicates this using the phrase
Key-Only as follows:
(1) Index Keys: tabname owner (Key-Only)
If a SELECT statement is specified without a fully-qualified key, the database may
need to read the relevant rows with a FULL TABLE SCAN. In this case, you will not
see an index in the SQL-Explain output but instead you will see something like the
following:
1) informix.systables: SEQUENTIAL SCAN
This indicates that a read of the entire table is necessary (FULL TABLE SCAN).
With more complex operations, where the combination of results from several
SELECTS on different tables is required, you will see further strategies mentioned
(such as MERGE JOIN, DYNAMIC HASH JOIN). These refer to the join strategy chosen
by the optimizer.

Ensuring Up-to-Date Information

The optimizer can compute an accurate value for each explanation field only if the
statistical information for each table is up to date. To enable the optimizer to
compute accurate values for the above fields, you must ensure that up-to-date
statistical information about the contents of relevant tables is available.
To update your information, use the Update Statistics function. Since the execution
plan selected by the optimizer (for example, the use of a table scan versus an
index) depends crucially on this information, you should always ensure that it is
kept as up to date as possible by regularly running Update Statistics.

Enqueue Trace Analysis

Use
The enqueue trace allows you to track the locking and unlocking statements that
your application or the SAP system uses, and the locking objects and parameters to
which they apply. You can display and analyze the logged trace entries in the trace
file.

Page 28 of 74

ABAP Code Inspector

Features
While the enqueue trace is switched on, the system records all of the locking and
unlocking statements that occur for a user or group of users.
The trace recording contains the following information:
Lock statements executed
Table names of the lock event
Name of the program that set the lock
Type of lock
Lock owner
Total time required for the lock
Time required by the enqueue server to release the lock
For further information refer to:
Enqueue Trace Records
Detailed Display of Enqueue Trace Records

Enqueue Trace Records

The following list columns are particularly relevant to enqueue trace records:
In the Trace List
Duration Runtime for the lock operation in the form milliseconds.microseconds.
Object Name The name of the lock object.
Oper The lock operation. For further information, refer to Lock Objects.
RC Return code.
If the value in this column is zero, the enqueue operation was successful. If it is
"1", the operation was unsuccessful because the lock object or parts of it were
already locked.
Page 29 of 74

ABAP Code Inspector

 Rec Number of granules in the lock object.

Statement This column lists the granules for the lock request. If there is more
than one, they are separated by the "|" character. The lock mode, lock table,
and lock argument of each granule are listed.
See also: Lock objects.
In the Extended List
hh:mm:ss.ms The time at which the lock operation was performed, in the form
hours : minutes : seconds. milliseconds.
Program Name of the ABAP program that requested the lock operation.
Curs not used.
For a more detailed analysis, use the Detailed Display of Enqueue Trace Records.

Detailed Display of Enqueue Trace Records

To display an enqueue trace record in more detail, choose the magnifying glass icon
or the corresponding menu entry on the trace list.
The detailed display contains the following information, which is also explained in
the online heklp:
Lock Operation
Execution Mode
Lock Object
Owner Lock owner.
Owner_UPT Owner of the lock in the logical processing unit.
Scope Parameter Indicates who owns the lock.
Collision Owner If this field is filled, the user whose name appears is the owner
of the lock that was requested.
Collision Object The lock object that already possesses the lock requested (or
parts of it).
Collision User Name The logon user of the lock owner.
Time Total time in milliseconds required for the lock (in client). This is made up
of the request time and the time required for the communication. If the request
is local, the local execution time is entered.

Page 30 of 74

ABAP Code Inspector

 Time Time required by the enqueue server to execute the lock (server time, in
milliseconds). If the). In the case of an asynchronous call, or no server being
requested, the time is zero.
ABAP-Programname Name of the ABAP program that requested the lock.
Number of granules.
Lock-Mode Type of lock.
Table Name Table name of the lock object.
Granularity Argument Lock argument.

RFC Trace Analysis

Use
Using the RFC trace, you can track which remote calls your application or the SAP
System triggers and on which instance these calls are executed. You can display
and further analyze the trace records logged in the trace file.
Features
From the time you turn on the RFC trace function to the time you turn it off again,
all RFC calls occurring either for a specific user or for an user group are recorded.
From the recorded trace you can deduce:
Which function modules have been called remotely by the program to be
analyzed.
Whether the RFC was executed successfully.
The total time used to process the remote call.
The marking of the RFC communication (RFC client or RFC server).
On which instance the remote call was executed.
With which technical parameters this instance is characterized.
The number of bytes sent and received during the RFC.
For more information, see:
RFC Trace Records
Page 31 of 74

ABAP Code Inspector

Detailed Display of RFC Trace Records

RFC Trace Records

For an RFC trace record, the following columns are particularly significant:
In the Trace List
Duration Execution time of RFC call. The time is displayed in the format
milliseconds.microseconds.
Object Name Shortened name of the instance (system) on which the remotely
call of the function module was executed.
Oper ID of the cross-instance RFC communication. We differentiate between
the RFC client and the RFC server. The client is the instance that calls a
function remotely. The instance specified as the server makes the requested
function available and executes it.
Records Not used.
RC Return code of the logged remote call. A value of 0 in the RC column
indicates a successful completion of the remote call. Values other than 0
indicate an error.
Statement This column contains the name of the local instance, the name of
the remote instance, the name of the function module called, and the number of
bytes sent and received.
In the Detailed List
hh:mm:ss.ms The time at which the remote call was executed, in the format
hours: minutes: seconds. milliseconds.
Program Name of the ABAP program that triggered the remote call of a
function module.
Curs Not used.
For further analysis, use the Detailed Display of RFC Trace Records.

Page 32 of 74

ABAP Code Inspector

Detailed Display of RFC Trace Records

To display detailed information about an RFC trace record, choose the magnifying
glass icon or the corresponding menu option from the trace list.
The detailed display contains the following information:
Function Module Name of the function module that was called.
Source IP Address: IP address of the server on which the RFC was triggered.
Source Server: Name of the servers from which thee RFC was triggered.
Destination IP Address: IP address of the server on which the function
module was executed.
Destination Server: Name of the server on which the function module called
using RFC was executed.
Client/Server: Classification of the RFC communication as RFC client or RFC
server when the function module is called remotely.
Conversation ID of the RFC record.
RFC Trace Set: Type of RFC trace record.
Bytes Sent: Number of bytes sent to the target system.
Bytes Received: Number of bytes received from the target system.
Total of Sent Files: Total number of sent bytes with the conversation ID,
excluding the current call.
Total of Received Files Total number of received bytes with the conversation
ID, excluding the current call
ABAP Program: Name of the ABAP program that triggered the remote call. If
there is no name explicitly specified ("space"), the call came from the kernel of
the SAP System.
RFC Time: Total runtime for execution of the Remote Function Call in
microseconds.

Table Buffer Trace Analysis

With the table buffer trace, you can monitor accesses made to the table buffer and
how it is loaded or invalidated. You can display and further analyze the trace records
logged in the trace file.
By default, the table buffer trace records are displayed summarized that is, a
sequence of fetch statements on the same table is grouped into one line. If you
choose Trace List -> Expand Table Buffer Trace, each fetch is displayed in a separate
line.

Page 33 of 74

ABAP Code Inspector

Features
While the buffer trace is switched on, the system records all buffer accesses of a
user or user group.
The table buffer trace tells you:
Which buffer accesses your statement executes
Which buffer operations are used
How the buffer is managed

Additional information is available under:

Table Buffer Trace Records
Detailed Display of Table Buffer Trace Records

Additional Functions

Saving Lists Locally

The Explain SQL Function
Finding Dictionary Information
Summarizing Trace Lists

Saving Lists Locally

The results of the trace recording are written to a trace file and you can display
them in the form of a list. You can also save all the trace records of a list in local
files on your front end. This allows you to keep performance data for a longer period
of time.

Page 34 of 74

ABAP Code Inspector

Procedure
To save a list locally:
8.
9.

1. Start the Initial screen of the performance trace.

2. Choose the pushbutton Display Trace.
The display filter appears.
10. 3. In the display filter, specify the value range for the trace record display.
11. 4. Choose Display Trace List.
Depending on your selection in 3, you will see the trace list, the extended trace
list, or the time-sorted trace list.
12. 5. Choose the menu path Trace-List Save as Local File or the appropriate
pushbutton. The dialog boxSave List in File appears.
13. 6. Choose the format for saving the list in the local file and confirm by
pressing Continue.
14. 7. In the following dialog box, enter the local path name.
15. 8. Choose Transfer.
Result
The trace records have now been saved locally in a file on your front end. You can
display this file in the selected format.

Alternatively, you can download the file into the buffer if you
choose unconverted in item 6 above.

The Function Execute Explain for SQL Statements

The function Execute Explain for SQL Statements allows you to analyze the
database strategy used to access any given table or view defined in the ABAP
Dictionary or in the database itself. You can use this analysis to identify the indexes
used for database access. You can explain a specific SQL statement in two different
ways.
From the initial screen of the performance trace, you can check a statement
without creating a trace file.
Page 35 of 74

ABAP Code Inspector

 From the list display of a trace file, you can select a Dictionary table and get
details on the access method.
See also Analyzing Trace Records

Note that the result of the Explain for SQL Statement function
are database-specific. This concerns both the SQL statement and the
operation. With some DB systems, Explain for SQL Statement can only
be executed for the SELECT statement. To be able to understand the
results, you require sound knowledge of the relevant database
system. You should refer to the manuals provided by the manufacturer
of the database system you are using.
Analyzing an SQL Statement without a Trace File
To retrieve an analysis of an SQL trace without creating a trace file, proceed as
follows:
16. 1. On the Performance Trace initial screen, choose Enter SQL Statement.
The system starts an editor with which you can enter an SQL statement. You can
also load an SQL statement from an internal table or local file or save it in one.
17. 2. Enter an SQL statement.

18. 3. Choose Explain.

The system examines the statement and displays information about the
database's access strategy.

Page 36 of 74

ABAP Code Inspector

Using the Dictionary Information Function

From the list of trace records, you can display further information about Dictionary
objects, and also branch to the definition of the object in the ABAP Dictionary.
Prerequisites
The relevant trace records of the trace file must not have been overwritten.
Procedure
19. 1. Call the Initial screen of the performance trace.
20. 2. Choose Display Trace.
The Display Filter appears.
21. 3. Specify the value range for the trace record display.
22. 4. Choose Display Trace List.
The trace records of the trace file are displayed in the trace list, detailed list, or
time-sorted list.
23. 5. Place the cursor on the line containing a Dictionary table you want to
analyze.
24. 6. Choose Dicitonary Information.
The first part of the ABAP Dictionary information screen displays administrative
data for the chosen tables, such as classes, required memory space, and so on.
The second part of the screen contains information about the indexes created
for the table. Dictionary tables always have at least one index formed by the
Page 37 of 74

ABAP Code Inspector

table's primary key. If other indices were created within the ABAP Dictionary, the
system lists these also.
25. 7. Choose Table/View fields.
This function branches from the trace list to the table definition in the ABAP
Dictionary.

Summarizing Trace Lists

For further performance analysis, the following functions are available:
Summarize trace by SQL statements
Identical selects
Summarized table accesses
These functions provide an overview of accesses and, in the case of the
function Summarized Table Accesses, table buffer accesses.

Procedure
To access the summarized lists from the trace list, the detailed trace list, or the
time-sorted list, choose Trace List Summarization Function (summarize trace by
SQL statements, display identical selects, Summarized table accesses).
You can use the F1 help to obtain information about the column contents of the
individual lists.

Results
Function Summarize Trace by SQL Statements
The following columns are displayed in this list:
Executions: Total number of executions of the statement.
Identical: Percentage of "value-identical" select statements of the "statementidentical" select statements.

Page 38 of 74

ABAP Code Inspector

 Duration: Total execution duration for all "statement-identical" SQL statements in

microseconds. For the individual statements, the total is made up via the
operations prepare, open, or reopen, fetch, close.
Records: Total number of rows (records) returned to the ABAP program(s) for
these "statement-identical" SQL statements.
Time/exec: Average execution time of one of the executed statements in
microseconds.
Rec/exec: Average number of rows (records) processed in the execution of a
statement.
Avg. Time/r: Average processing time (in microseconds) required for a row
(record).
Min. Time/r: Minimum processing time (in microseconds) required for a row
(record).
Length: Length of the row (record) of a table.
Btype: Characteristic for the table buffer (see also F1 help)
Tabtype: Table type
Object Name: Name of the table
SQL Statement: SQL statement
On this summarized list, a number of functions are available for further analysis;
you will already be familiar with these functions (such as Explain, Dictionary
Information, Display Call Positions in ABAP Program) from the initial trace lists.

Identical Selects function

For identical selects, the following columns are displayed:
Executions: Number of calls of a select statement with the specified where
clause.
Object Name: Table name

Page 39 of 74

ABAP Code Inspector

 Where Clause: The where clause of the SQL statement. If the clause ends with
the character string ..., it was truncated.

Function Summarized Table Accesses

This summarized list provides the following information for the SQL and the buffer
trace:
Work Proc. No.: ID (see transaction sm50, for example) of the process by which
the trace records were written.
Ptype: Work process type (see also F1 help)
Client: Client in which the user was working and in which the trace records were
written.
hh:mm:ss.ms. Time at which the logical trace record was created. Displayed in
the format hours:minutes:seconds.milliseconds
Transaction: Name of the transaction or program from which the specified table
was accessed.
Table Name: Name of the table that was accessed within the specified
transaction or program.
Statement: Name of the statement executed on the specified table.
Total Records. Total number of read, deleted, or updated records, depending on
the statement executed.
Total Access Time: Total time required for executing the statements on the table.
Displayed in the format milliseconds.microseconds.
DB Connection: Logical name of a database connection.

For further analysis of this summarized list, a range of functions is available such as
sorting by column, selecting rows or parts of rows with subsequent summarization.
******************************************************************************

Page 40 of 74

ABAP Code Inspector

Code Inspector
Use
The ABAP Workbench offers a variety of tools for doing static and dynamic checks of
the correctness of your programs and other objects.
The Code Inspector resolves the question of how to use these separate tools
comfortably and efficiently.
With the Code Inspector, you can run all of ABAP's checking tools at one time. You
can also choose which tools you want to run.
Uses: If you are a Developer, you can use the Code Inspector for the following
tasks:

Run a fast ad hoc code inspection from the ABAP Workbench.

Run a fast ad hoc inspection from the Code Inspector itself.

Define personal (private) re-usable code inspections.

Ad hoc inspection definitions and results are not saved - you use them to check
objects on which you are currently working. The definitions and results of re-usable
inspections are saved. You can define re-usable inspections to check larger sets of
objects or track your errors over time.
If you are a Quality Manager, you can do the following with the Code Inspector:

Define public re-usable code inspections. Other users - for example, other
QMs - can use these inspection definitions and their results.

Approve or reject exceptions. Exceptions let developers mask check errors

without correcting them.

Change the priority of check messages and get an overview of the available
checks, documentation, and handling of check messages.
For these functions, choose Goto Management of Message Priorities . Table
entry in theException column means that an exception can be requested. Where
a pseudo comment is shown, a message can be masked.

Do special checking tasks, such as these:

Page 41 of 74

ABAP Code Inspector

Automate regular runs of ABAP Unit tests

Review saved results

Search for particular ABAP statements or words in program texts

Have the Code Inspector automatically check objects when a transport

request is released

Sending lists of messages by e-mail.

Starting the Code Inspector

Start the Code Inspector by entering transaction code SCI.
You can run ad hoc code inspections from most of the tools of the ABAP Workbench.
Authorizations

To run ad hoc inspections as a Developer, you need an authorization for

authorization object S_TCODE with value SCI for field TCD.

To define and run re-usable, system-global inspections, approve exceptions,

and do other Quality Manager tasks, you need an authorization for
object S_COV_ADM with value * for field ACTVT

Doing a Fast Ad Hoc Code Inspection

Procedure
You are editing a repository object in one of these transactions:
The Object Navigator (transaction SE80)
The Class Builder (transaction SE24)
The ABAP Editor (transaction SE38)
The ABAP Function Builder (transaction SE37)
The ABAP Dictionary (transaction SE11).
And you want to check your program or other object for errors.
Do the following to run an ad hoc check with the Code Inspector:
1.
Start the Code Inspector. Open the left-most 'object' menu of the screen you
are on and choose this menu function:
Check Code Inspector .

Page 42 of 74

ABAP Code Inspector

Or mark the program or other entity and use the context menu. The path is the
same.
2.
The Code Inspector presents the results of the checks. Here, the display is
opened to show an error and two warnings. These are in the categories Analysis
of WHERE Condition for SELECT and Low Performance Operations on Internal
Tables.

Figure 1: Useful Functions in the Code Inspector Results Display

Unlike the results of reusable inspections, these results aren't saved. They are
deleted when you leave the program. Also, the Code Inspector will object if you
try to check more than 50 objects in an ad hoc inspection.
3.
Respond to a result message. You can:

Correct the problem. Double-click on the error message to open the

editor.

Mask the problem if it cannot or should not be corrected. In your

code, enter the pseudo comment- if there is one - that cancels the Code
Inspector check.
Click on
or the
in the results table to see if there is a pseudo comment.

Mask the problem with an exception if it cannot be corrected or

masked with a pseudo comment. An exception has to be approved by a
Quality Manager.

Page 43 of 74

ABAP Code Inspector

Not all problems can be masked with a pseudo comment. In these cases,
choosing
instead lets you request an exception. (Where you don't see
an Exceptions icon, the check message cannot be masked at all.)
To request an exception, you need to specify the name of a user authorized to
grant it, the scope of the exception, and optionally a comment. Once you save
the exception, you can see it from the entry screen of transaction SCI.
Choose Goto Exceptions Requested .
Note: For a complete list of messages with documentation and exception
handling, choose Goto Management of Message Priorities . Table entry in
the Exception column means that an exception can be requested. Where a
pseudo comment is shown, the message can be masked.
Useful Ways to Go On
Here are some useful things you can do from the Results screen of the Code
Inspector.
Define Your Own Check Variant
In an ad hoc check, the Code Inspector uses the system-wide DEFAULT check variant
to decide what to check.
For future checks, you can create your own personal DEFAULT check variant. The
Code Inspector will then use your check variant instead of the system default.
1.
On the Code Inspector: Results screen, choose .
2.
You will see the checks selected for the system DEFAULT check variant. Mark
or unmark the checks to put together the code inspection that you wish to have.
You may need to specify check parameters for some tests before you can
activate them.
Note: Marking Dynamic Checks tells the Code Inspector to run your ABAP Unit
tests. To this extent, the Code Inspector can do dynamic runtime checks as well
as static checks.
3.
Save your personal DEFAULT check variant. The Code Inspector will use it in
ad hoc runs from now on.
To use the system DEFAULT check variant again, just use transaction SCI to delete
your DEFAULT check variant.
Use a Compact Results Display
For a more compact Results display, try the table display. Click on the
button.
Mail Check Results
Some or all of the problems don't really belong to you? Then you can mail them to
the real offender:
1.
Choose the
function to switch to the list display.
2.
Choose the
function to enter e-mail addresses and a cover note.
3.
Choose
to dispatch your results mail.

Page 44 of 74

ABAP Code Inspector

Starting an Ad Hoc Inspection from the Code Inspector

Procedure
You can run a fast ad hoc inspection from the Code Inspector (transaction SCI), not
just from the tools of the ABAP Workbench. The definition and results of the
inspection are not saved for reuse.
Do the following:
1.

Start transaction SCI to start the Code Inspector.

2.

Leave the Name field in the Inspection frame empty. Click on

3.

or

On the screen which follows, you define the ad hoc inspection. Just as in a
reusable inspection, you can choose from existing object sets and check
variants or define new ones.
You can also inspect the entities in a transport request or specify single programs
or other entities. And you can define a temporary check variant by marking and
unmarking the checks you would like to run.

4.

Run the inspection. The Code Inspector presents the results screen
automatically.
Here, the display is opened to show an error and two warnings. These are in the
categories Analysis of WHERE Condition for SELECT and Low Performance
Operations on Internal Tables.

Page 45 of 74

ABAP Code Inspector

Figure 1: Useful Functions in the Code Inspector Results Display

5.

Respond to a result message. You can:

Correct the problem. Double-click on the error message to open the

editor.

Mask the problem if it cannot or should not be corrected. In your

code, enter the pseudo comment- if there is one - that cancels the Code
Inspector check.
Click on

or the

in the results table to see if there is a pseudo comment.

Mask the problem with an exception if it cannot be corrected or

masked with a pseudo comment. An exception has to be approved by
a Quality Manager.
Not all problems can be masked with a pseudo comment. In these cases,
choosing
instead lets you request an exception.
To request an exception, you need to specify the name of a user authorized to
grant it, the scope of the exception, and optionally a comment. Once you save
the exception, you can see it from the entry screen of transaction SCI.
Choose Goto Exceptions Requested .
Page 46 of 74

ABAP Code Inspector

Note: For a complete list of messages with documentation and exception

handling, choose Goto Management of Message Priorities . Table entry in
the Exception column means that an exception can be requested. Where a
pseudo comment is shown, the message can be masked.

Defining and Running Reusable Code Inspections

Procedure
This section explains how to create reusable inspections. The definition
(name, object set, check variant) of a reusable code inspection is saved. You can run
it repeatedly or schedule it for automatic execution as a background job.
Likewise, the results of a reusable inspection are saved. You can compare or track
the results over time.
To inspect a large number of objects (more than 50), you must use a reusable code
inspection.
To define and run a reusable code inspection, do the following:
1.
2.

Start the Code Inspector with transaction SCI.

Enter a name for your inspection in the Name field in the Inspection frame
and choose
or .
Click on the toggle
for a private inspection, visible only to you. Or choose
to
create or choose from an inspection visible to everyone in the system. You have
the same choice for object sets and check variants.
You can also create a new version - - of an existing inspection and run it right
away, without changing the object set or variant. .
For more details, click here.

3.

Define the object set - the programs and objects to inspect.

You can choose an existing object set. Or you can define a new object set by
entering a new name in theObject Set field and double-clicking for forward
navigation.
Page 47 of 74

ABAP Code Inspector

You can also inspect the objects in a transport request, or specify programs or
other components by name.
4.

Define the check variant - the checks to be done in the inspection.

You can choose an existing an existing variant or define a new variant by
entering a new name in the field inCheck Variant frame.

5.

Run the inspection.

Choose

to run the inspection while you wait in your current session.

Choose
... (Execute) to run the inspection asynchronously. The most
interesting option is to run the inspection as a background job. For this, enter a
server group (click on
and mark the In Background (Periodically also) field.
With this option, you can run the inspection periodically. This is a good way to run
ABAP Unit tests automatically.
6.

Wait for the results. The screen shows when the inspection has finished (you
may need to refresh the screen with Display <-> Change). You will see one of
these icons next to the Inspection field.

The inspection has not yet run or has not yet been completed.

The inspection finished successfully.

The inspection aborted (the background job or asynchronous

execution failed). There are no results.

You can also pick up the results later. Just use the F4 Possible Entries function of
the inspection Name field to access inspections that have already run.
7.

As soon as the Executed icon shows, click

to see the results screen.

Here, the display is opened to show an error and two warnings. These are in the
categories Analysis of WHERE Condition for SELECT and Low Performance
Operations on Internal Tables.

Page 48 of 74

ABAP Code Inspector

Figure 1: Useful Functions in the Code Inspector Results Display

8.

If you would like to re-check the objects after making corrections, just click on
the
button.
The Code Inspector creates a new version of your inspection, and you can run it
again.

Managing Code Inspector Exceptions

Procedure
Some check messages of the Code Inspector can be masked with exceptions.
This section explains how to use exceptions.
Note

Page 49 of 74

ABAP Code Inspector

To see which messages may be masked with exceptions, choose Goto

Management of Message Priorities . Table entry in the Exception column means
that an exception can be requested.
Where a pseudo comment is shown, a message can be masked by inserting the
comment in the source code.
No entry in the Exception column means that a message cannot be hidden or
cancelled.
Prerequisites and Limitations

You must designate one or more users with full Code Inspector
authorizations to review and approve exceptions. You must tell your developers
which users are responsible for their exceptions.
Developers apply for exceptions from the results of code inspections. To complete
an exception request, a developer must enter the name of the user who should
review the request.

You should use the Code Inspector in your consolidation or Quality Assurance
test system only. Do not let developers apply for exceptions in their development
systems.
The reason: Exceptions are system-local entities. They cannot be transported.
You should use and manage exceptions only in a stable, long-lived Quality
Assurance system. Otherwise, the exceptions can get lost, so that hidden errors
are reported once again.
In practice, this limitation means that developers should use the Code Inspector
in the QA system. Only there will check messages be hidden by exceptions.

Reviewing and Approving Exceptions

1.
2.

Start the Code Inspector with transaction SCI.

Choose Goto Exceptions Approve to see if any developers have sent
you requests for exceptions. You will only see exceptions that specify your user
name as the approver.
( Exceptions
asked for.)

Requested

shows a developer which exceptions he or she has

Page 50 of 74

ABAP Code Inspector

3.

If you need more information, double-click on a requested exception to see

the original check message.
From the check message, you can jump to the source code or use the other
resources of the results display.

4.

Approve or reject an exception.

If you approve, the problem is masked or hidden in this system as long as the
exception stays in effect.
If you reject the exception, then the request disappears from the exception
display. The Code Inspector will report the problem again when it next runs.

Special Checking Tasks in the Code Inspector

Procedure
This section shows how to do several useful quality checking tasks with the Code
Inspector.
Reviewing Saved Results
The Code Inspector saves the status (successful, aborted) and results of inspections
up until their Deleted ondates.
To review saved results, do the following:
1.

Click on the toggle

to review results of private inspections, visible only to
you. Or choose
to see the results visible to everyone in the system.

2.

Click on the F4 icon at the Name field in the Inspection frame on the start
screen of the Code Inspector (transaction SCI).

3.

The Code Inspector displays a window with the available inspections. The
highest version number is of course the newest instance of an inspection.
Click on an entry in the list to fetch the inspection. You can then select
the saved results.

to see

Automating ABAP Unit Tests

Page 51 of 74

ABAP Code Inspector

The Code Inspector provides a convenient way to automate ABAP Unit testing. You
can, for example, run ABAP Unit tests automatically every week after transports
arrive, in order to do regression testing and verify new functions.
Note
You will find a weblog in SDN with detailed instructions for setting up automated
ABAP Unit testing with the Code Inspector (English
only): http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/16420
To set up automated ABAP Unit testing, do the following:
1.

Define an inspection and select the programs whose ABAP Unit tests should
run.

2.

Define a check variant in which you mark only Dynamic Tests in the List of
Checks.

3.

Choose
shown here:

... (Execute) to run the inspection. Fill out the execution options as

Figure 1: Batch Execution Options

4.

Confirm your choices. On the next screen, you can enter the start time and
repeat interval of the Code Inspector job. The job will automatically repeat the
ABAP Unit tests that you have selected.

Searching for Particular Words in ABAP Entities

Do you want to look for use of obsolete ABAP statements? Or do you need to
enforce a change in terminology in coding? The Code Inspector can help you with
these tasks.
1.

In a check variant, mark the section Search Functs.

Page 52 of 74

ABAP Code Inspector

With the check Search of ABAP Tokens, you can look for text strings in literals,
comments, and in active coding. Enter the search string by clicking on the
button.
SAP recommends for best results that you start and end the search string with
the wild card character:*string to search for*. The search is case-insensitive.
With the check Find Unwanted Language Elements, you can search for ABAP
statements that are obsolete in modern ABAP OO programming. The check is
delivered with a pre-selection of statements.
2.

Save the check variant and use it to search for texts and statements that you
wish to change.

Sending Lists of Messages by E-Mail

The Code Inspector e-mail function (
active in customer systems.

Utilities

SAP Internal

Send Mail ) is not

But you can still send lists of messages to users. This is a good way to report results
from a consolidation system to developers who work in other systems.
1.

Generate a results list that is suitable for a user or group of users.

For example, you can inspect development packages and send the results to the
developers who work on the package.

2.

3.

On the Code Inspector: Results screen, choose the

messages in ABAP list format.
Choose the

function to display the

to open the mail window.

For R-Mail within the SAP System, you can specify a user ID as
the Recipient and B SAP Logon Name as the Recip. Type.
For external Internet mail, you can enter an Internet e-mail address
(user.name@domain) and U Internet address as the Recip. Type. For external
mail, SAP Connect (transaction SCOT) must be set up.
4.

Press

dispatch the mail.

Automatically Checking Transport Requests on Release

Page 53 of 74

ABAP Code Inspector

You can have the Code Inspector automatically check the objects in a transport
request when the request is released.
To activate this feature, do the following:
1.

Start the Transport Organizer Tools by entering transaction SE03.

2.

Choose Transport Organizer Tools

(Transport Organizer) .

Administration

Global Customizing

3.

In the Check Objects when Request Released frame, mark the Globally
Activated option.

The Code Inspector will automatically start when a user releases a transport
request. (The Code Inspector does not run if a user releases a task within a
transport request.)
The user will see a status message reporting that the Code Inspector is checking the
objects in the transport request. The system DEFAULT check variant is used for the
check.
If no check messages are reported, then the release of the transport request is
completed, as usual.
If there are check messages, then the user has the option to review and correct
them before the release of the request is completed. The user can also override the
checks and complete the release of the transport request despite the presence of
check messages.

*************************************************************************************
******

Insights of code inspector

By Mohammed Zuber, John Deere India
Most of the time we do developments and when it comes to checking or doing the
review of the code we generally use Code Inspector and EPC i.e. Extended Program
Check.
But have you ever wondered what these tools are doing behind the scene?

Page 54 of 74

ABAP Code Inspector

You can call the Code Inspector for the relevant single objects directly from the
ABAP Editor (SE38), the Function Builder (SE37), or the Class Builder (SE24) (Object>Check->Code Inspector). The system then checks using a default check variant
which is provided by SAP.
SE38

SE37

Page 55 of 74

ABAP Code Inspector

So in this post I will give an overview of how we can use the potentials of code
inspector and how we can pin point the errors and deliver the best quality code with
adherence to ABAP coding guidelines.
What is Code Inspector?
The Code Inspector is a tool for checking Repository objects regarding
performance, security, syntax, and adherence to name conventions.
Using the Code Inspector (transaction code SCI), you can check individual objects
or sets of objects for performance, security, syntax, and adherence to naming
conventions. You can also determine statistical information or search for certain
ABAP words (tokens). In the Code Inspector, you can define inspectionsthat, with
the help of check variants, examine certain sets of objects. As the result of an
inspection, you receive information messages, warning messages, or error
messages on different properties of the examined objects.
Limitations:
The range of functions in the Code Inspector is limited to checking static object
definitions and can therefore only point out certain problems.
It cannot, for example, give a precise statement as to how the overall performance
of a program is. To be able to do this, you need to analyze program execution
yourself at runtime for example, using the Runtime Analysis Tool (transaction code
SE30), the Performance Trace (ST05), or the Global Performance Analysis Function
(ST30).

*******************How to start Code Inspector? ********

You can call the Code Inspector using transaction code SCI or through the menu
path SAP Menu Tools ABAP Workbench Test Code Inspector.
You can call the Code Inspector using transaction code SCI or through the menu
path SAP Menu Tools ABAP Workbench Test Code Inspector.
Below is the screen when you start Code Inspector.

Page 56 of 74

ABAP Code Inspector

We have three Blocks as below:

1.

Inspection

2.

Object Set

3.

Check Variant
What is Inspection?
Inspection is the process of checking individual objects or set of objects as to
whether certain programming guidelines have been adhered to. The result of an
inspection run is a list of the individual checks made with errors, warnings, or
information messages. There are two types of inspections. They differ with respect
to whether the results are made persistent or not.

Persistent
inspections
with
results
storage
For execution on the local server or parallel execution on the server group. You can
plan persistent inspections as background jobs and use them for any size of object
set.

Anonymous
or
ad-hoc
inspections
without
results
storage
For execution on the local server and for fewer than 50 objects. You can execute adhoc inspections in online mode only.
Page 57 of 74

ABAP Code Inspector

When you give a name in inspection box and click create icon following is the
screen you get.

In the screen above you can see we can do inspection of an Object set (we will see
shortly what that mean) which can be thought of as a collection of objects, Or we
can do inspection of objects captured under any transport request by selecting the
Request/Task radio button.
We can also do inspection of individual objects by selecting the Single radio button
and giving the type of object and giving the name in the input box.
The next thing is Check Variant which is kind of collection of check rules that we
have to follow while inspecting any object.
What are Object Sets?
They are collection of several single objects together in a group/set. Sets of objects
include, for example, programs, function groups, classes, or DDIC objects. In
general, any Repository objects can be included in a set of objects.
There are global and local sets of objects.Global sets of objects are visible for all
users while local objects are only visible for a single user. You can create global sets
of objects only if you have the appropriate authorizations.

Page 58 of 74

ABAP Code Inspector

Below is the screen you will get when you give the Object Set name and click the
create icon.
There are lots of filters that you can use to group objects into an object set.

What are Check Variants?

This is the most important and most crucial component in Code Inspector. The
Check Variants are nothing but the rules to be checked when we do the inspection.
The system checks the individual objects of a defined set of objects for certain
attributes using the check variant.

Page 59 of 74

ABAP Code Inspector

SAP supplies the global DEFAULT variant, which you can use to check objects from
within the workbench i.e. when you do from SE24, SE37, SE38 or SE80. You can
anytime enhance the predefined list of check categories and individual checks
supplied by SAP but with restriction that you have proper authorizations to change
or create check variants.
The individual checks are assigned to different check categories. The following list
shows examples of check categories and individual checks.

General checks contain formatting elements, such as listing table names from
SELECT statements.

Performance checks contain checks for performance and for resource use,
such as:
1.

Analysis of the WHERE condition for SELECT / UPDATE and DELETE

2.

SELECT statements that read past the table buffer

3.

Low-performing accesses to internal tables

Security checks contain checks for critical statements, cross-client queries,

inadequate authority checks.

Syntax check / generation contains ABAP syntax check, an enhanced program

check, and generation:

Programming conventions contain checks for name conventions.

Search functions contain searches in ABAP coding for tokens (words) and
statements.
These are just to mention the most important but there are lot more you can
explore.
Give an appropriate name for the check variant based on the checks it will perform
and click the create icon. It will take you to the following screen:

Page 60 of 74

ABAP Code Inspector

If we select the check box for a category all sub items will be checked, you can
manually select multiple items from the tree structure and enable the checks.
There is an arrow shown in attributes column where you can again do a pinpoint
check. Clicking on the attributes arrow will open more options to be checked.
Page 61 of 74

ABAP Code Inspector

For every check there is documentation provided where you can see how this check
will work and what results you can expect after the inspection.
So go and dig down into the options provided and do not just rely on the results of
Workbench Code checks. Create a custom check variant where it will check for all
the possible errors that one can expect to be rectified in static review of the code.

*************************************************************************************
*************
Evaluating the Quality of Your ABAP with Code Inspector Part 2
by admin on June 15th, 2014

Recommend This Post!

Anthony Cecchini is the President of Information Technology Partners

(ITP), an SAP consulting company headquartered in Pennsylvania. ITP offers comprehensive
planning, resource allocation, implementation, upgrade, and training assistance to companies.
Anthony has over 17 years of experience in SAP R/3 business process analysis and SAP
systems integration. His areas of expertise include SAP NetWeaver integration; ALE
development; RFC, BAPI, IDoc, Dialog, and Web Dynpro development; and customized
Workflow development. You can reach him at ajcecchini@itpsap.com.

Calling the Code Inspector

Last month we examined the Code Inspector Framework, which should have given you a good
foundation on the components of a Code Inspector inspection process. Lets look then this
month on using the Code Inspector day to day to help us write better code.

Page 62 of 74

ABAP Code Inspector

This blog will focus on the code inspector prior to EhP2 for SAP NetWeaver 7.0
support package stack 12 (SAP Basis 7.02, SAP Kernel 7.20) and EhP3 for SAP NetWeaver 7.0
support package stack 5 (SAP Basis 7.31, SAP Kernel 7.20). The reason I bring this to your
attention is because after the above, we now have a NEW solution for quality management
called the ABAP TEST COCKPIT. The ABAP Test Cockpit is a new ABAP check toolset which
allows you to run static checks and unit tests for your ABAP programs. In order to ensure a
smooth migration and comparable check results throughout your company, the ABAP Test
Cockpit is compatible with SAPs Code Inspector. This means you can reuse your custom Code
Inspector checks and variants in the ABAP Test Cockpit.
Back to our Blog..
When you are working on a program, function module, or class, you typically call the ABAP
Syntax Check directly from the editor iteratively as we code. But wouldnt it also be nice to
have the performance or security checks of the Code Inspector at your disposal while coding?
As of Web AS 6.10, you can call the Code Inspector for the object you are working on from the
menu of the ABAP Workbench (SE80), the ABAP Editor (SE38), the Function Builder (SE37), or
the Class Builder (SE24). When called from these workbench transactions, the Code Inspector
automatically applies the DEFAULT check variant to the examined objects and the inspection
results are not persisted.
Select <Object>=>Check =>Code Inspector where <Object> represents aProgram, Function
module, or Class.

Page 63 of 74

ABAP Code Inspector

Check Variants That Come with the Code Inspector

The Code Inspector comes with a variety of individual checks that you can combine into check
variants. You can transport global check variants through the system landscape like any other
transportable SAP object.
The Code Inspector comes with a few global check variants, the two most important of which
are:
DEFAULT: Every inspection started from the ABAP Workbench uses the DEFAULT check
variant, which is very extensive. This check variant contains the normal and extended ABAP
Syntax Checks, as well as additional performance checks and security checks. You can also
check workbench objects with a different combination of checks by defining your own local
DEFAULT check variant, which will then override the global one. You create a local DEFAULT
check variant either with transaction SCI or from the result screen of a workbench inspection.
PERFORMANCE_CHECKLIST_XL: This check variant includes a basic set of checks for
performance analysis, such as Analysis of the WHERE clause for SELECT, UPDATE, and
DELETE. It comprises the most important performance checks to help you identify poorly
coded SQL WHERE clauses or statements.

Page 64 of 74

ABAP Code Inspector

Calling the Code Inspector for Several Objects

To check many objects at the same time, you use the Code Inspector to create object sets, add
individual checks to check variants, and combine an object set and a check variant to an
inspection. Each instance of these elements can be either global or local.
Creating an Object Set
In order to check more than one object, you define an object set. For example, suppose you
want to check all ABAP object classes for user HA92974. You could follow these steps:
1) Call the Code Inspector using transaction SCI.
2) On the initial screen, enter a name for the object set and click the Create button, which takes
you to the Object Set selection screen.

3) In the Object Assignment area of the Select Object Set tab, enter the SAP user name
HA92974 in the Person responsible field not to be confused with the Person
Page 65 of 74

ABAP Code Inspector

Responsible field at the top of the screen, which is the name of the person responsible for the
object set itself which is E71800017 in the screen below.
4) In the Object Selection area in the lower area of the screen, enter an asterisk (*) in the
Class/Interface field. The asterisk ensures that all classes assigned to the user HA92974 will
be included. If you enter ZCL_SV* instead, only classes that start with ZCL_SV are selected.

5) Save the object set by clicking the Save button in the standard toolbar.
Once you have created and saved an object set, you can then tailor your object selections
further. For instance in the Object Assignment section you could use the additional Package,
or SAP Component options to include or exclude single packages or components. Note that
these options are linked by AND operations. Be careful NOT to choose entries that define a set
Page 66 of 74

ABAP Code Inspector

without an intersection. For example, if I choose user HA92974 and SAP Component FIN and
this user has no objects in that component, then the resulting Object Set will be empty.
Creating an object set from scratch is typically the first method you learn. Once you become
familiar with using the Code Inspector, other methods of creating object sets offer added power
and flexibility. You access these additional methods via the following tabs on the object set
screen:
Edit Object Set: You can combine object sets and filter them based on the attributes Object
Type, Object Name, Package, and Responsible. Use this option when you want to create
an object set that consists of some combination of two other object sets.
Object Set from Result: You can create a new object set containing objects that triggered
messages in aprevious inspection. Again, you can filter the set based on the attributes Object
Type, Object Name, Package, and Responsible, and also by a single check, its message
codes, and message priority (Error, Warning, or Information). Use this option if you want to
determine your result set in several steps in other words, use any objects that raise issues in
a first inspection as the object set for a subsequent inspection.
Object Set from Request: You can also extract object sets from transport requests/tasks and
filter them based on the attributes Object Type, Object Name, Package, and Responsible.
If there are program like objects in the request, the new object set will contain only their
associated main programs (programs, classes, or function groups instead of includes, methods,
or function modules). Use this option when you want to check the objects in a transport request.
For example, you might want to ensure that only objects adhering to your security rules are
transported into your production system.
Obj. Collectors: You can use generic collectors to create an object set. You can do this by
loading the objects from files or from object lists of programs, such as Where-Used List,
Coverage Analyzer, or Runtime Analysis. Then in the Set Filter screen area you can filter them.

WARNING A daily background job prevents the Code Inspector from accumulating too much
data. Inspections and object sets have an automatically generated deletion date of 50 days
ahead, which means that the inspection or object set will be deleted after 50 days. Inspections
that have not yet been executed, as well as object sets included in those inspections, are
Page 67 of 74

ABAP Code Inspector

excluded. To keep your object sets or inspections for a longer time, simply change the deletion
date. You can change the deletion date individually for individual inspections and object sets.

Creating a Check Variant

After creating an object set, the next step is to decide which checks you want to execute on
those objects. The Code Inspector always uses check variants, which are compilations of
individual checks, instead of single checks only. The standard check variants we examined
earlier (DEFAULT, PERFORMANCE_CHECKLIST_XL), that come with the Code Inspector may
be sufficient at first, but if your like me, sooner or later you will want to create your own check
variants for more flexibility. Creating a check variant is easy. You select checks from a tree that
contains all active check categories with their respective active individual checks.
Follow these steps to create a new check variant:
1) In transaction SCI, enter a suitable name for the check variant and click the Create button.

Page 68 of 74

ABAP Code Inspector

2) To add a check to your check variant, select the checkbox next to the check. To see
information about a check, click the Information button next to the checkbox.

3) Some checks require USER Parameters. You can see this by the
icon next to the check.
You can set one or more parameters to further define the check attributes. These attributes can
be input parameters or can activate a sub-check (a component of a single check that can
generate a message). Click the arrow to display a popup where you can set the parameters.

Page 69 of 74

ABAP Code Inspector

4) To save the check variant, click the Save button on the standard toolbar.

Creating and Executing an Inspection

OK, so finally we get to the crux of what this has been leading up too. I hope you are still with
me, cause all of the prior work has lead us here. If you are still here. You now understand how
to create an object set and a check variant. Next, you want to apply the individual checks of the
check variant to the objects in the object set. This process happens during the inspection run.
So you will need to combine a single object or an object set with a check variant to define the
test task that performs the inspection.
Remember that inspections can be anonymous or named. Anonymous inspections are useful
for ad-hoc queries with only a few objects where you do not need the results to be persisted. A
named inspection is stored persistently with its results. It can handle object sets containing any
number of objects. You can also run a named inspection outside working hours by scheduling it
in a background job. For our purpose here, we will create a NAMED inspection.
Follow these steps to create and run a named inspection:

Page 70 of 74

ABAP Code Inspector

1) In the Code Inspector (transaction SCI), enter a name for the inspection and click the
Create button.

2) Combine an object set, a single object, or objects from a request with an existing check
variant.

Page 71 of 74

ABAP Code Inspector

3) You can run the named inspection in one of two ways. You just click the execute
button

to start the inspection immediately or you can click the other execute button with 3

. after it
to display the Execution Options pop-up screen.Here you can further control
how and when the inspection is run. This includes selecting a server group for large object sets,
so they can be run in parallel across the app servers for performance. This would be done as a
Batch job and to schedule the inspection in a background job, click the In Background radio
button.

Page 72 of 74

ABAP Code Inspector

4) Execute the inspection!!

The Inspection Results
When an inspection run completes successfully, the inspection screen displays a status
message across the bottom of the screen. Press the Results button on the Inspection screen
to display the results. The Code Inspector displays the results of the inspection in an easy-toread hierarchical tree format. See the example below and make note that we have 3 colors to
consider. An entry in the red column (the left column) indicates an error message. An entry in
the yellow column (the middle column) indicates a warning message. An entry in the green
column (the right column) indicates an information message.

Page 73 of 74

ABAP Code Inspector

Each message contains the name of the examined object and a short explanation of why the
message was raised. If the examined object is a Report, Include, Function Module, Classetc.,
you also see the source code position of the statement that caused the message. Doubleclicking the message text takes you to the ABAP Workbench, where you can display and edit
the object. For further explanation, press the Information button next to the message.
You now have created and object set to be examined, the Check variant that has all the relevant
CODE checks you would like to employ and ran a NAMED inspection and examined the results.
Not bad for a days work!
The Code Inspector comes with a set of built-in checks that are organized into functional
categories. In the final installment of this Blog series I will you introduce you to the
most important checks in these categories To help you get the most out of the Code
Inspector right away!

Page 74 of 74

ABAP Code Inspector