Skip to Content
Author's profile photo Former Member

Setting up and using the SAP Code Inspector

If we are looking to review development from a quality or standards point of view, either our own code or a peer review, SAP provides the Code Inspector tool.  The Code Inspector is a configurable tool that can be used to check the quality and consistency of development from a single program up to an entire Package.

There are two main transactions used to access the Code Inspector, SCI and SCII.  Transaction SCI can be used to configure the Code Inspector and perform inspections.  Transaction SCII has less functionality than SCI and is limited to performing inspections.  This blog focuses entirely on transaction SCI, but the concepts are relevant for SCII.

The Code Inspector can also be called from the ABAP editor.  This runs the inspection on the current program with the Variant DEFAULT.

The first thing to understand is the concept of Local and Global in the Code Inspector.  Local elements are associated directly with a specific user id and whilst available to all users can only be found if the responsible user id is known.  Global elements are available to all users.



The icon on the push button to the left of the entry field indicates the type, and can be used to switch between the two.  While creating elements as local is beneficial for prototyping, all elements for general use or for use across multiple systems should be created as global.  Remember whenever the transaction is called the default setting is Local.

The three elements of the code inspector are the Check Variant, the Object Set and the Inspection, defined as follows;

Check Variant – This defines the rules to be applied, which checks are to be made and the settings of those checks.

Object Set – This defines the development objects that will be included.

Inspection – This defines a combination of Check Variant and Object Set, in other words what checks are to be applied to which development objects.

Creating a Check Variant

Create a new variant or copy an existing one.



The checks can be activated or deactivated as required


The checks are well documented, so it’s usually clear what each one is for.  My preferred approach is to start with a large set of checks and review the results of the inspection.  Then reduce the number of checks or change the parameters depending on how useful the results were.  The Variant can be transported if it is Global and the ‘Transportable’ checkbox is selected.

Create an Object set


The Object set defines the scope of development objects included in the Inspection.  The options available on the main tab strip are;

Select Object Set – This is the most flexible definition of the Object Set, essentially enabling selection from high level attributes such as Package or Software component down to the lowest level of individual development objects.

Edit Object Set – Object Set definition based on other existing Object Sets, combing based on either the entire Objects Sets or just the objects common to both.

Object Set fr. Result – Object Set definition based on the results of an existing Inspection result.

Obj. Set from Request – Object Set definition based on the contents of a transport request.

Obj. Collectors – Object set definition based on complex criteria, such as the where-used list for a table or program.

An additional filter can then be applied to the criteria based on Object Type, Name, Package and Person Responsible.

Consider the potential volume of results from the inspection when defining the Object Set.  If the Object Set includes many objects and the Variant many checks the results from the inspection could become unmanageable.  Depending on the stage of the development different Object Sets will be required.  During build a high-level set covering a larger number of objects is suitable whereas during testing and defect fix or productive operation a transport level set could be more appropriate.

Create an Inspection


The Inspection combines the Check Variant and the Object set; the checks specified in the Variant are applied to the development objects defined in the Object set.  The Inspection can also be defined against an individual transport or development object, rather than an Object set.

Note that a new Inspection will be created with a default ‘Deleted on’ date of two months into the future.  If the Inspection results are to be retained beyond this date it can be changed.

Once the inspection has been defined you need to run it.  If the Object Set is fairly small you could just run the Inspection in the foreground (the regular Execute icon), or otherwise in the background (the Execute icon with some dots after it).

Reviewing the Inspection

The results of the inspection are displayed in the same hierarchy structure as the Variant. 



Each message is grouped by Type (Error/Warning/Information) and message.  Each message is repeated once for each instance where it occurs.  The meaning of each message (as well as the tag needed to switch off the check) is available by clicking the blue i icon. Double-clicking on the message navigates to the development object requiring attention.

Assigned Tags

      Be the first to leave a comment
      You must be Logged on to comment or reply to a post.