SCI — Code Inspector for Static ABAP Checks

SCI opens the Code Inspector, the ABAP Workbench tool for running static checks against a defined set of repository objects - programs, classes, function groups, or entire packages - using a named check variant that bundles individual checks (extended syntax check, performance checks, security checks, naming conventions, and so on) with severity thresholds. The result is an inspection: a saved combination of object set plus variant that can be re-run at will. The structural fact that explains most confusion: SCI does not check code live as it is edited. It runs the selected checks in a batch pass and displays a snapshot list of findings tied to that specific run; nothing in the tool re-validates automatically when the underlying code changes afterward.

Reached for before transporting custom development, as part of a quality gate in a development or change process, or when a downstream problem (dump, performance complaint, security finding) needs a broader sweep across a package rather than a single-object check. It sits earlier than transport release: a disciplined process runs SCI against the whole request before release, not after. It is not a substitute for functional testing or for a single-object extended syntax check during active editing, which is faster for one object mid-edit. SCI is for a scoped or scheduled batch pass across many objects, packages, or an entire transport request, often run unattended as a background job feeding a quality report to the development lead.

There is no dedicated results table to query with SE16. To confirm a finding, re-run the same inspection with the same object set and same variant and compare the result list line for line against the earlier one. For background runs, open the job in SM37 and read the spool, which lists every finding with its message text and object and line reference. To confirm scope before trusting any result, check TADIR for the object type and package to be sure the object set actually included the object in question; a typo in a package name silently produces an empty or partial object set with no error raised.

SCI still exists unchanged on S/4HANA as the underlying Code Inspector engine; nothing about the transaction itself changed. What changed is how it gets used: the ABAP Test Cockpit, which runs on top of the same Code Inspector checks, became the standard tool for custom-code adjustment during an S/4HANA conversion, remote analysis of a system's whole custom namespace, and release-relevant quality gates. Consultants doing S/4HANA readiness work are usually pointed at that cockpit rather than at SCI directly, even though the checks executing underneath are the same ones configured here.

Development and ABAP team problem, not functional or Basis, except when a scheduled inspection needs a background job or authorizations Basis controls. A clean handover names the inspection and variant used, states the object set scope (single object, package, or transport), lists open findings by severity with any exemptions already applied, and states whether the run being discussed was interactive or the latest scheduled job, so the receiving developer does not have to guess which result is current.

SLIN is worth knowing first since several Code Inspector checks are the same extended syntax check wrapped into a batch pass; understanding SLIN's messages makes SCI's output easier to read. SE80 or the equivalent editor is where every finding actually gets fixed, since SCI only reports and does not edit. SE09 and SE10 matter because the object set is frequently defined by a transport request, and the inspection is usually run as a gate before release. SAT is the natural next stop when a performance-category finding needs empirical proof rather than a static warning.