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 [email protected].
Standard Checks That Come with the Code Inspector
In this final installment, I’d like to show you some of the built-in checks that come with Code Inspector. They can be grouped into categories, like the one’s below…
Syntax checks
Program generation
Security checks
Performance checks
To help you get the most out of the Code Inspector right away, we want to introduce you to the most important checks in these categories. Remember that you can display the online documentation for an individual check to learn more about it.
Syntax Checks
This category contains checks that are associated with the ABAP Syntax Check. All checks are standard tests that are also available individually from the ABAP Workbench. The advantage of applying the checks in the Code Inspector is that you can combine them with other checks and perform them on a set of programs at the same time.
The checks in this category are:
Normal ABAP Syntax Check
This check performs the ABAP Syntax Check, which is also available from most workbench transactions. You control its behavior by setting the following parameters:
–One or Several Errors: Normally the syntax check terminates after the first error is detected, but you can also choose to proceed. If a fatal error is detected or the maximum number of 50 errors is exceeded, the check is terminated.
–With or Without Warnings: In addition to error messages, the syntax check also returns warnings for minor syntax problems, such as missing implementations of interface methods. You can turn these warnings on or off.
Extended Program Check
This check uses the same set of checks that is available with the workbench transaction SLIN for single objects. It processes static checks that are too complicated or too time-consuming for the normal syntax check. The first operation of this check is a normal syntax check. If any error is detected, no further checks are performed. You can learn more about the SLIN transaction by clicking HERE.
The checks can be broken down into the following…..
References to program external units:Verifies that the external program units exist and interfaces are used correctly. This would include ABAP statements such as CALL TRANSACTION ‘tcod’, PERFORM form IN PROGRAM program, MESSAGE Ennn, SUBMIT ‘report’, CALL METHOD ‘method’, and of course CALL FUNCTION ‘func’ .
Multi-language enabling: Searches for constructs that hamper the use of a program in different languages — for example, text literals without text IDs. Text literals appear in the language in which they were typed, and are not processed by translation services.
Package check: Detects the illegal use of objects from other packages.
EBCDIC/ASCII portability: Detects whether a program behaves differently in EBCDIC and ASCII (e.g., the comparison of character fields).
Statements in wrong context: Scans for statements that are used in an inappropriate language context. For example, the COMMIT WORK statement within a SELECT … ENDSELECT loop leads to the loss of the database cursor.
Unnecessary items: Searches for form subroutines that are not used in a program, or fields that do not have read access.
Program Generation
Since every program generation starts with a syntax check, this check is very similar to the others in this category. The relevant difference is the fact that this check also generates the load format (byte code) of a program. You might want to use it to pre-compile programs, or during a system upgrade.
Security Checks
Some ABAP statements can endanger stability, data integrity, and overall program security when used carelessly. The Code Inspector security checks inform you of a statement that is critical, or the use of a statement that has database access, or selected statements that don’t handle the system return code.
What are CRITICAL STATEMENTS? These are statements that are considered critical, either for system security reasons or because they could endanger program stability.
Here is a common list to consider…
Lets look at each problem area and expand it a bit…
Internal statements: Some ABAP statements are provided for internal use only in SAP programs. For example, the SYSTEM-CALL statement interacts with the ABAP kernel. SAP may change these statements at any time without notice, leading to incompatibilities in your program. You should know if and when these statements are being used!
Statements where authority checks are necessary: In the SAP system, automatic authority checks protect the invoking of transactions and reports.
Database operations: The EXEC SQL statement accesses database tables bypassing the SAP database interface. The SQL syntax within the statement may be specific to one database system, thereby impeding program portability. Native SQL statements also bypass the SAP table buffers, which can lead to inconsistencies when buffered tables are accessed. You should identify instances where this condition exists to review for possible impacts on data consistency.
In addition, the ROLLBACK WORK statement reverts all database changes that were executed since the last database commit statement. Incorrect use of this statement can lead to serious inconsistencies.
Reading or writing of SAP repository objects: The main repository objects in an SAP system are classes, programs, screens, and global types. The statements that manipulate these objects are intended for use by internal development tools only. Using these statements in application programs can potentially destroy the state of the system.
Remember, you can select statement types individually or in any desired combination by setting the check parameters.
Access to Database Tables
This check searches for accesses to specific database tables. Some database tables contain critical information, such as personal data. Only programs that are protected with authorization objects should access these tables. This check can detect access to specific tables if the table name is used statically. You can specify a list of critical tables as a check parameter.
In addition, this check can detect the use of dynamic table accesses and dynamic WHERE clauses. This might be critical because they can hide an access to critical tables.
Below are a sampling of the statements that you can examine with this check. (In fact, there are two checks, one for SELECT statements and one for changing database accesses.) Again, you can combine one or more different statement types by setting the check parameters.
Handling of the System Return Code SY-SUBRC
In the ABAP language, the system field SY-SUBRC returns the success or failure of a statement.
In some cases, not handling this return code can lead to severe instability and unexpected results. This situation is obvious in the case of the statement AUTHORITY-CHECK, where disregarding the return code means performing no authority check at all! In other statements, the return or export parameters can be undefined if SY-SUBRC is not equal zero, which can lead to application errors when the return code is ignored.
This check examines whether statements handle the system return code. Again, you can select the statement types and freely combine them by setting the check parameters. Additionally, you can specify any other statement in an input list.
Below is a sampling of some of the statements checked…
Performance Checks
One of the goals in using the SAP Code Inspector you can leverage is the ability to perform automated performance checks. These static checks can help evaluate adherence to the practical performance standard.
Some of the checks that can be performed are as follows…
– Database accesses that will lead to high runtimes because the WHERE clause does not use an existing database index
– SELECT statements that will implicitly bypass the SAP table buffers
– CHECK statements inside SELECT …ENDSELECT loops
– Nested loops over internal tables and nested SELECTs
Lets dig deeper into each one of these checks. Lets look closer at how the Code Inspector performs analysis on
A WHERE Clause for SELECT, UPDATE, and DELETE Statements.
These checks identify SELECT statements (or UPDATE/DELETE statements) that cannot use any database index. They compare the database fields specified statically in the WHERE clause with the index definition in the ABAP dictionary. If there is no WHERE clause, or if the WHERE clause does not contain a field of a database table index, the database will perform a full table scan (or, for a client dependent table, a scan of all entries of that client). This is very costly and impacts performance negatively
Below are the options you can specify as check parameters; we recommend activating them all.
.
SELECT Statements That Bypass the SAP Table Buffers
Small tables that only change rarely (especially customizing tables) should be buffered with the SAP table buffers, which notably accelerates read access. Since the SAP table buffers can only handle simple statements, omit more complex statements on buffered tables to avoid posing any risk to the performance advantage.
In addition to the explicit bypassing buffers with SELECT … FOR UPDATE and SELECT … BYPASSING BUFFER, many other statements can bypass the buffer implicitly.
Below are the most important types of SELECT statements that bypass the SAP table buffers. NOTE: Use of Native SQL with EXEC SQL … ENDEXEC will always bypass the buffers, but you can detect Native SQL with the critical statements check explained above.
Nested LOOPs and Nested SELECTs
The Code Inspector can also find nested LOOP and SELECT statements. Nested loops are a frequent source of non-scalable coding, because the runtime for loops over internal tables that are accessed sequentially increases linearly with the number of entries. Nested loops of this type can therefore have exponentially poor (or even worse) runtime behavior, meaning that doubling the number of entries will lead to fourfold (or higher) runtimes.
Normally, only a dynamic check can determine whether the code inside a loop will behave linearly. The same is true for nested SELECT statements; in the end, the developer must decide whether the coding is correct as is, or whether to replace a nested SELECT with a JOIN or a construct with SELECT … FOR ALL ENTRIES.
Summary
You now have a basic understanding of the powerful Code Inspector tool, which allows you to perform static checks on your choice of repository objects. You can…
– Check a single object (such as a program or a class) by simply invoking the Code Inspector from the menu of its ABAP Workbench editor.
– Check many objects at once by creating an object set with the Code Inspector (transaction SCI).
– Combine a set of individual checks into a check variant by using the simple checkbox interface to select them and any available parameters from the check variant tree.
– To fully specify a test, combine an object set and a check variant to an inspection. After running
the inspection you can view the results in a hierarchical tree format.
In addition, you learned about some of the important checks that come with the Code Inspector. These ready-to-use checks make it easy for you to scan your programs for some of the biggest potential problems, including performance and security issues.
Here are links to the prior Blogs in this series:
Evaluating the Quality of Your ABAP with Code Inspector – Part 1
Evaluating the Quality of Your ABAP with Code Inspector – Part 2
