ABAP-New features

There are many different possibilities to be in trouble with ABAP programs:

Hard errors (Runtime errors, abortion messages …)

Wrong program flow or behaviour– Poor performance.

But the programming language ABAP and the surrounding tools will not let you alone with the error.

But a major problem is to choose the appropriate tool at the right time

Development & Testing

·         Code Inspector

·         ABAP Unit

·         Coverage Analyzer

Tracing

·         Memory Inspector

·         ABAP Runtime Analysis

Debugging

·         The New ABAP Debugger

Tools for ABAP Programs – Development & Testing

Development Testing Production






     style="display:inline-block;width:336px;height:280px"
     data-ad-client="ca-pub-2187275724631596"
     data-ad-slot="1740176261">

Another way of looking at the tools would be to ask “where in the software lifecycle will I use the tools”.

The static checks and some of the runtime checks (ABAP Unit and Coverage Analyser) will be used mainly during development and testing. The other runtime tools are more suitable for analyzing problems in production.

Of course, this is not a strict classification. Generally the debugger is also heavily used during development. But most of the tools are used during development and testing (listed on this slide) are less often used for the analysis of production problems.

Organization of the tools for troubleshooting “production” problems: error category approach.

Which tools is suitable in which error situation?

Most of the runtime tools cover several problem areas.

The ABAP Trace is e.g. a very good tool to search performance lacks, but also for analyzing the program flow.

Sophisticated static program checks should be part of each development process.

Ensure a very high quality of your ABAP programs:

First the program should have no syntax errors.

The next step is to run an Extended Program Check for this program (you can replace this step by running a Code Inspector default inspection which includes the extended Program Check).

This includes more time consuming checks, which are not part of the syntax check like correct function calls w.r.t. the interface or finding unused variables, etc.

Even more tests are provided by the Code Inspector. Here you get, e.g., hints where you may have not entirely perfect select statements (regarding performance!) or where you may encounter security problems.

ABAP Unit tests should be executed in order to make sure that the functions, forms, and methods of your program are working correctly.

Afterwards you must assure the correct runtime behavior of the program.

You may use the Coverage Analyzer to check if all parts of your programs were covered by the test.

The code inspector (Transaction SCI) is a mass test framework which is delivered with WEB AS 6.10.

(For R/3 >=46C a transport is available-> note 543359)

You can define your own:

Program set (which programs shall be checked?),

Test set (which test shall be executed – you can even define your own checks)

From the ABAP editor you can access the code inspector with a default program set (the program which is currently in use of the ABAP editor) and a default test set. This global default test set has the name “default” and can be adapted to your requirements like any other test set.

The default test set contains the following tests:

Performance checks (e.g. tuning of select statements)

Security checks (e.g. client depending INSERT/UPDATE….)

Extended program check.

The code inspector provides an open architecture for ABAP tests.

Create a check variant: Specify which tests shall be executed.

Object set: Which ABAPs (programs, classes,) shall be checked?

Inspection: Define an inspection which contains the relevant check variant (1) and the object set (2).

The inspection can now be executed online or in background. You can even make settings for a parallel run. (on several servers)

Some remarks to the object selection:

You cannot collect SAP repository objects in your object set. Only customer objects are allowed.

There is one exception. If you have changed a SAP program (e.g. because of a note), then you can use single code inspection from SE38 (-> slide 9) during the first week after the change.

Only in a development system code inspections are possible

If you check the flag ‘Save Selections only’ in the program set definition, then the programs will be extracted as soon as the inspection starts. Only the selection, not the programs are stored beforehand. This is a suitable technique if your program set will change before the inspection runs.

Example: searching for a special string (e.g. the use of a special SY field).

The result list contains all found occurrences, and all errors which occurred during searching.

You can navigate from an occurrence to the relevant source line.

If a run didn’t finish successfully, then you can restart the inspection from the point where the error occurred. (No rerun from scratch necessary).

The code inspector can be used to run the extended program check for all your programs to get an overview of the current quality level.

ABAP Unit

What are Unit Tests good for?

There is a gap between static and integration tests.

–    Static checks cannot detect problems that occur only at runtime.

–    Static checks cannot test if a function, form or method “works as designed”.

–    Integration tests are too expensive to use for detecting errors on unit level.

Unit tests allow you to execute a single modularization unit (method, form, function module) of a program under well-defined test conditions and to inspect and verify the behavior.

ABAP Unit is available with Net Weaver 04.

Since unit tests are automatic and can be executed repeatedly from tools like the Code Inspector, they are ideal for regression testing.

Recently, an array of testing methodologies emerged in the community.

Keywords are Test-Driven Design, Mock Objects, eXtreme Programming etc.

Note that Unit Tests are so called white-box tests, i.e. they might exploit assumptions private to the tested module and only known to the programmer of the module. In contrast to that, integration tests only test exposed functionality (black-box tests).

Have a look at the class cl_aunit_assert for the different kinds of methods to check and verify the expected behaviour of your modular units.

Consider inheriting from cl_aunit_assert

Fixtures serve to build up a context in which a test shall be executed.

Fixtures are defined by a naming convention, i.e. the methods setup, teardown and class_setup and class_teardown, respectively.

At the end of an ABAP Unit run, the results are displayed directly (if run from the ABAP Editor via) or collected in the result of a Code Inspector run.

Coverage analyser:

The Coverage Analyzer is a tool for monitoring the system-wide execution of ABAP programs. You can monitor which programs and even which modules of a program were covered by a test find program parts or complete programs which are never used and may be obsolete. find program parts that are executed very often and may benefit from code optimisation Coverage Analyzer is available with WEB AS 6.10 The Coverage Analyzer stores which programs and even modules of programs where executed in a system and if any errors (dumps) occurred. As of Netweaver 7.1, coverage can be measured up to statement level. This allows you to ensure that all programs and even modules were covered by a test. The Coverage Analyzer is divided into the administration and the display part. The administration allows you to: Switch on/off of the collection of coverage data Specify the conditions under which a program shall get the flag “tested”, e.g. at least 1 time executed without any error. Reset the results for special programs to start a new test phase Define test groups and attach users to these groups. You can now display the results for these test groups. Monitor the collection of data – to detect errors or problems (RFC connection …) Check the consistency and repair inconsistencies in the coverage analyser data. E.g between shared memory and the database. Global view: Get the test coverage and number of errors for a development class or an author. This is a good tool for a quality manager who has to ensure professional testing and a good quality of a development project. You see the statistics since the last reset and the accumulated values. The drops in the coverage curve correspond to compilation units that have been regenerated (caused by changes, transports etc). This reflects the fact that once an object has changed, it cannot be considered as tested any more.

                        

For a developer it is more important to see not only the test coverage of e.g. a development class, but to go more into details and display the coverage of a special program or even of one module.

In this example function group WBABAP was covered 76.1% by your test. If you loot at the details, you see that e.g. the form BRANCH_TO_TYPE_ATTR hasn’t been executed – and therefore is not tested (red traffic light).

Memory Inspector:

Motivation Starting the Memory Inspector Analyzing a Memory Snapshot                                        Comparing Two Memory Snapshots

Starting the Memory Inspector Life analysis from inside ABAP Debugger –     Classic Debugger: Goto -> Display Condition -> Memory Consumption –     New Debugger: Use special tool Memory Analysis Stand-alone Memory Inspector, analyzing memory snapshots –     Transaction “S_MEMORY_INSPECTOR” Creating memory snapshots In the ABAP debugger –     Classic Debugger: Development -> Memory Analysis -> Create Memory Snapshot –     New Debugger: Use special tool Memory Analysis, tool service Create Memory Snapshot Command /hmusa in the command field on any screen You can also create memory snapshots from within your ABAP program: Call the

WRITE_MEMORY_CONSUMPTION_FILE method of the

CL_ABAP_MEMORY_UTILITIES class in your code. Use this option carefully to avoid running out of disk space

Memory Inspector: Tips and Tricks

the memory inspector always triggers the garbage collection before a snapshot is created and saved it’s always a good start to have a look at the ranking list to see who is responsible for the memory footprint to investigate memory leakage, keep in mind that event handlers are kept alive by the instance/class that owns the event unless variables have a scope restricted to a modular unit (function module, method) always null out references once are not needed any more. Run Program ZTSTECHED_MI_EXERCISE. Watch how the memory consumption grows each time you press the “Run” button in the application toolbar. Compare two consecutive memory snapshots and try to find the difference – which object(s) cause(s) the higher memory consumption? Analyzing a Memory Snapshot (Appendix)!!! Bound Memory Memory of the object “itself” … … and all exclusively referenced memory Memory that will be freed if object is deleted Referenced Memory Memory of the object “itself” … … and memory of all referenced objects Maximum of memory that could be freed if object is deleted Attention: In releases 6.20 and 6.40, the bound memory does not include any referenced memory (even if it is exclusively referenced). Only the memory used by a reference variable itself (usually 8 or 16 bytes) is added to the bound memory. Allocated memory is almost always higher than the bound memory because –   the kernel needs some memory for administration purposes –   memory is typically allocated in „chunks“ which are filled up later on. Analysing a Memory Snapshot Table bodies (internal tables) and strings Used memory –             Memory of a table body (internal table) or a string that contains data of an application Allocated memory –             Memory of a table body (internal table) or a string that is allocated by the system Used memory <= allocated memory Consequently 4 values: Bound used Bound allocated Referenced used Referenced allocated Concentrate on „Bound used “and „Referenced used “when analyzing memory snapshots. Keep in mind that for the referenced memory, objects may be counted more than once if more than one reference is pointing to them. Therefore the sum of all referenced memory is not a meaningful quantity. The sum of all bound memory will typically be less than the total memory consumption of an application, because it will not contain the memory consumed by objects that have more than one reference pointing to them.  ABAP Runtime Analysis: ABAP Runtime Analysis trace files have the name AT and are stored on the local application server in the directory specified in the profile parameter DIR_ATRA. (In most cases this is identical to the data folder) If ABAP Runtime Analysis has problems to read the file and e.g. you get a runtime error after starting Se30 (even before the first screen comes up), then you may transfer (or delete) the AT… trace files (folder specified in DIR_ATRA -> see above) on this server to another directory for later analysis. With WEB AS release >= 6.20 you can easily create a se30 variant with a new “Create Icon”. This Button will substitute the Button “temporary variant” With aggregation the hierarchy is not available. For memory usage info in the hierarchy check the “With memory use” flag. “Particular units” This option allows you to switch on/off the ABAP trace during the running transaction. Especially, if the you are only interested in a special part of the transaction (e.g. between screen 3 and 4), then you should use “Particular units”. (The flag particular units has no connection to the program parts underneath !) Instruction for tracing “Particular units”: (trace program part between two screens) –  Start SE30 –  Switch on “Particular units” for your variant –  Start the tracing for your transaction. (“Execution” button) –  The trace will be started as soon as you prompt /ron (Trace on) in your transaction. With /roff the trace is stopped. (Or you use the menu: System -> Utilities -> Runtime Analysis -> Switch On / Switch Off) You can even use this technique in combination with the debugger. Set a breakpoint at the beginning of the interesting program part and at the end. If you stop at the first breakpoint, switch the trace on and at the second switch it off. ‘Program (Parts)’ This is a filter where you can specify which programs or even sub elements (like a form, function,…) of a program shall be traced. With the flag ‘Within and below” you can control if only the e.g. specified function module is traced or all subroutines called by this function will be traced as well. Again, the flag particular units has no connection to this functionality and must be unchecked if you use this program (parts) filter. Start the program / transaction via se30 with your variant. Step back to SE30 if the interesting part of the transaction is finished. You now see the new trace, which can be analysed. If the trace file is not available, then please use the button “Other file…” to browse for your trace file. If you got an error message when returning to SE30, which indicates that the measurement failed, then you may use the “File info” button  to get the detailed error code. If you used a variant with active aggregation the please rerun your trace with “Aggregation = NONE”. Access the hierarchy (only available with a “no aggregation” variant) from the overview screen. You get a list which represents the complete path through your application. In the trace variant you specified already which statements and which parts of your application shall be traced. Additionally you can now filter which data you want to display. Please notice that some display filters are switched on per default (e.g. no system programs). Therefore if you miss something, switch off all display filters and check your trace variant. You can step from the trace directly to the relevant source line. The hierarchy list contains the following data: –  Gross/net time (-> performance part of this chapter) –  Level: Stack level –  Call hierarchy: name of the statement / event. –  Program: current program / class –  Memory requirement: the current use of memory. The maximum values are marked with a red background colour. This feature is only available, if you switch on “With memory use” in the area duration/type of your trace variant. (default: switched off). With Basis release >=46B you can use Runtime analysis to trace programs which run in a parallel session. If you used a 46D kernel with patch level >=1413 (or 6.10 kernel patch level >=427), then you can switch on the ABAP trace for idle processes as well (note 586940). You must create your trace variant for the parallel trace as well. (no aggregation to get the hierarchy…) Deactivate the trace after a short tracing time in order to avoid reaching the trace file quota! (profile parameter abap/atrasizequota) Before deactivating the trace refresh the work process display because the work process with activated trace may have changed.  User trace feature list: Switch on an ABAP trace for any user ON THE CURRENT SERVER !! Possibility to restrict the trace according to: –  Client –  External session (should be “Any” , always) –  process type (dialog, batch, RFC, http, ITS,…) –  object type (transaction, report, function, URL,…) –  object (e.g. only transaction se38) Specify the maximum number of traces Specify the time frame when the trace shall be active You can use all your measurement variants for the user traces The traces can be analyzed – as usual – via transaction se30 Please use External session ‚ANY‘ if you are not soure in which session the application will run ! The user trace is only active on one server, but starting from this server you can trace RFCs or updates which run on a second server.