ABAP help

Tools in Release 6.20


1. Code Inspector

2. Run Time Monitor

3. Debugger


Modification 1

Code Inspector

The Code Inspector is a tool that allows you statically check ABAP programs, function modules, classes, interfaces, and Dictionary objects for errors, performance, security, and reliability. The development of these Repository objects is supported by simple search and check functions. The check results are available in form of a tree hierarchy

The Code Inspector is called for a single object from the ABAP Editor by choosing Program → Check → Code Inspector, from the Function Builder by choosing Function Module → Code Inspector , or from the Class Builder by choosing Object Type → Check → Code Inspector. If you wish to check several Repository objects, for example all development classes in a package, then these can be grouped together in an object set. You also have the possibility of defining check variants with individual checks. A check of all objects in an object set using a specified check variant is called an inspection.

The Code Inspector executes purely static checks that only return hints and clues for an object. The actual runtime behavior can be ascertained using Runtime Analysis or SQL Trace.

Modification 2

Run Time Monitor

The Run Time Monitor is a framework that supports the recording of ABAP program information at runtime. This information can come from tests that are fixed in the SAP kernel. ABAP programmers can also query and log specific program conditions at runtime.

With Test Create ABAP Test, the Runtime Monitor creates a class, which can be called to record data in the source code. The data is first compressed in the main memory and periodically transferred to the database in a background job. The tests can be individually activated and deactivated for different servers. Compressing and saving the data hardly affects the application server, which means the Runtime Monitor can be used at any time, even in a production operation.

Modification 3

Debugger

The display of the memory consumption of dynamic objects has been divided into an overview of the total memory consumption and ranked lists for individual objects. You can compile the ranked lists according to specific criteria by choosing the function Change Settings. You now display the memory consumption by choosing Goto-> Status Displays -> Memory Consumption.

Breakpoints are then differentiated by whether they are effective in an HTTP or standard session. HTTP debugging is activated in the Editor by choosing Utilities → Settings → HTTPDebugging. Depending on the setting, the system then displays either the HTTP or standard breakpoints in the Editor.

If, under Settings, you selected the function Check Sorting Before READ BINARY SEARCH, the system checks, before every execution of this statement, whether the internal table is sorted. If the table is not sorted, a Runtime Error occurs. You should only activate this setting shortly before reaching a relevant point in the source code, because there can be a significant loss in performance, depending on the table size.

If you checked the "Check Sorting Before PROVIDE" function under settings, the system checks all of the relevant tables - and not just the area specified with extlim1 und extlim2 - for sorting and overlapping intervals when the long form of the PROVIDE statement is executed.

When displaying exception objects, the system only displayed the key itself in the field display for the TEXTID attribute that contains the OTR key of the text description assigned to the exception. Because this key is generated automatically and is nothing more than a sequence of numbers, assigning the corresponding text to the exception was difficult. The reason for this is that the displayed value had to be compared with the values of all constants generated for the exception. To simplify the assignment, the name of the constant generated for the key is now displayed as a Quickinfo. For example, in the case of an exception of the type CX_SY_FILE_IO for the TEXTID attribute the system displays READ_ERROR or WRITE_ERROR as a Quickinfo, depending on whether the exception was raised while reading or writing. The actual value of the attribute is the OTR key of the corresponding text description.

By choosing Debugging -> Session, you can now persistently save breakpoints and the settings System Debugging and Always Create Exception Object and reload them later. You can save the session, entering a name and expiry date for it. It is then available to other users and sessions, with the selected settings.