Tools in Release 6.20
1 Code Inspector
2 Run Time Monitor
3 Debugger
4 Runtime Analysis
ABAP_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 the 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 .
ABAP_MODIFICATION_2 Runtime Monitor
The Runtime 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 ABAP 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 that the Runtime Monitor can be used
at any time, even in a production operation.
ABAP_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 can
now display memory consumption by choosing
Goto -> Status Display ->
Memory Usage .
Breakpoints are defined according to whether they take effect in a
http session or in a standar session. http debugging is
activated in the Editor by choosing Utilities -
Settings - HTTP Debugging . 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 and
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 g
enerated for the key is now displayed as a tooltip . 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
tooltip , 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 save breakpoints
and the settings "System Debugging" and "Always Create Exception Object"
persistently 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.
ABAP_MODIFICATION_4 Runtime Analysis
In Runtime Analysis , you can no longer create
temporary variants. Instead, you can create a separate standard variant,
which is automatically assigned the user name by the system. You can
also create other variants with your own name or that of other users, as
long as a master record exists for them. When you first start the
runtime analysis, the system always display your own standard variant.
If it does not exist, the system displays the SAP standard variant. If
you call the runtime analysis again, the system always displays the last
used variant.
Additionally, the create, delete, and copy functions are again
included in the measurement restrictions block on the initial screen.
While create and copy can only be executed as single functions, you can
use the F4 key to delete multiple variants.
Documentation extract taken from SAP system, � Copyright SAP AG. All rights reserved