ABAP TESTING AND TROUBLESHOOTING The Application Server ABAP supports not only development, but the whole

development life cycle with a rich set of integrated ABAP testing and troubleshooting tools. Using the ABAP suite of testing tools, you can verify the formal and functional correctness of your programs. ABAP Unit testing makes enables you to employ test-driven development models. In the case of problems, ABAP offers a state of the art ABAP Debugger and powerful ABAP analysis tools, which ensure high productivity of development and support tasks. ABAP Testing Tools New ABAP Debugger ABAP Analysis Tools ABAP TESTING TOOLS You can avoid expensive troubleshooting by verifying the formal and functional correctness of your programs during development and integration. ABAP provides you with the tools you need to move to a test-driven development paradigm, for even tighter quality control. This section focuses on the comprehensive set of ABAP Testing Tools, which help you to ensure high quality in your ABAP programs. Extendend Program Check Code Inspector ABAP Unit Coverage Analyzer eCATT EXTENDED PROGRAM CHECK Sophisticated static program checks should be part of each development process. The first step is to ensure that your ABAP program is free of syntax errors with the syntax check. The next step is to run an Extended Program Check (SLIN) . SLIN includes more time-consuming checks, which are not part of the syntax check, like validating method calls with respect to called interfaces, finding unused variables, and so on.

Extended Program Check Introduction The extended program check performs a complete check that includes the interfaces of external procedures called from your program, for example, checking whether the number and type of the interface parameters in an external procedure call is correct. The extended program check is also only a static check. It cannot eliminate all of the circumstances that could lead to exception situations or runtime errors. For example, any statements in which you specify arguments dynamically as the contents of fields, or in which you call procedures dynamically, cannot be checked statically. To start the extended program check

Go to transaction SLIN, specify the program name and click on . Select the relevant program in the object list and choose Check -> Extended Program Check from

the Program menu.

It is important to check all boxes (F6) to verify all possible problems, then choose run (F8). It will appear to you a screen like this:

Errors numbers are in red, warnings in yellow and messages in blue. Pay attention to Errors, because there will be potential dump errors. Examples: comparing fields with different type, number of with parameters in a message, obligatory FM parameters not filled or with wrong type. Warnings and messages are important too, but in minor impact, does not affect the performance at all. Example: variables declared but not used, text pool not created. Do you think that you are an exceptional programmer? This screen can be revealing... When we are writing code, is normal to forget some things, like to declare variables and use it, test and remove the code but forget to remove the declaration... Some topics and what they do 1. Test enviroment - verify if the program is active. The Extended Check verify only active programs. 2. Call Function interfaces - verify if the parameters' type is correct, the using of exceptions.

3. Obsolete statements - Verify obsolete statements... 4. Character strings - Verify if the used text pool was created 5. Problematic Semantics - It shows to you better codes, like "WRITE TO can be replaced by more efficient MOVE TO" 6. Syntax check warnings - Pay attention to use conversion functions to compare fields. Or it will be listed in syntax check warnings' topic... and select statements are verified too. 7. Message - verify the number of with fields of message number How to correct the errors/warnings/messages Double click in the topic error, and you will see the full description:

In this example, the form f_validade was declared but not called in the program. Sometimes, in interface programs (BAPIs for example) you need to create forms that the BAPI will call it. This error message will appear, but you will not need to correct it, of course. Double click in the message and you will be redirected to the code. Then, do the needed changes, active your program and do the Extended Check again! Important: Remember to test your program when you finish the extended check. Tip: If your program has a message error that you cant remove, use the "#EC NEEDED to hide the display, and insert a comment in your code to identify why you are using it. CODE INSPECTOR You can test even more intensively with the Code Inspector. This tool also lets you automate mass testing. It offers analysis and tips for improving potentially sub-optimal statements, such as potentially expensive SELECT statements (performance!) or potential security problems. Moreover, it provides sophisticated (mostly static) checks, suitable for mass testing as well as for testing small object sets. This wiki provides useful information about how you can improve the quality of your code by using Code Inspector. ABAP Code Inspector Wiki

Code Inspector

Code Inspector Features The Code Inspector is a tool for checking static ABAP coding and DDIC objects (i.e. generally all objects of the Object Repository) under aspects of functional correctness, performance, security, reliability, and statistical information. It helps developers to adhere to programming standards and guidelines by creating messages on less-than-optimal coding. The Code Inspector offers various possibilities to define object sets and to combine multiple single checks in so-called "check variants". These functions, and the tool's parallel processing framework, make the Code Inspector a flexible and effective development assistant. The Code Inspector can be used in various scenarios with different types of checks, thus providing insights into the code quality from various angles. Usage scenarios 1. Single object checks from the Development Workbench You can check a single object with the Code Inspector from the ABAP Editor (transaction SE38), the Function Builder (transaction SE37), the Class Builder (transaction SE24), or the ABAP Data Dictionary (transaction SE16). To do this, choose<object> > Check > Code Inspector from the menu, where <object> can be a program, function module, class, or table. The respective single objects are then checked with a default check variant. 2. Checks on transport objects from the Transport Organizer You can invoke the Code Inspector from within the Transport Organizer (transaction SE09) to check objects in a transport request. To do this, choose Request/Task > Complete Check > Objects (Syntax Check). 3. Checks on sets of objects from transaction SCI The Code Inspector (transaction SCI) itself enables you to create a wide range of object sets using standard selections via package, software and application component, source system, transport layer, responsible, object type, object name and so on. In addition, special object collectors are available that allow you to read objects from a file, for example. An object set can be combined with a check variant to a so-called "inspection" that can be executed in a single process or in parallel. For a more details see Code Inspector User Manual Types of checks and check variants Below is a short extract of the types of checks and functions that are offered by Code Inspector. New checks can be implemented if required, see for example Code Inspector - How to create a new check. Syntax Syntax check; extended program check Performance Analysis of WHERE clauses for SELECT, UPDATE and DELETE; SELECT statements that bypass the table buffer; Low performance operations on internal tables ; table attributes check Security Usage of critical statements; dynamic and cross-client database accesses; use of ADBCinterface

ABAP UNIT Unit testing is a technique that enables writing and running white box tests during development. Dedicated test classes invoke the tested program and compare the result with the expectation. ABAP Unit is integrated into both the ABAP runtime and the ABAP workbench, and supports you in writing, running, and organizing unit tests in ABAP. Together with the ABAP Coverage Analyzer, ABAP Unit provides you with the tools you need to develop according to a test-driven paradigm. This weblog shows how ABAP Unit facilitates testing in ABAP. You will get a first look at a fairly simple code example that gives you an impression of how easy it is to write a test with ABAP Unit. A Spotlight on ABAP Unit Part 1 By giving a more real-world example, this weblog shows you the benefits of ABAP Unit testing in complex programs. Though unit tests themselves are pretty simple, a comprehensive test coverage enables you to detect side effects of program changes and adaptations. What ABAP Unit is All About So you are an ABAP developer and want to write more tests, if it was not too difficult and took too long. You would like to achieve higher quality of your programs, and are unsure of how to accomplish this. After all, you are looking for a way to improve your code without investing much additional effort.

The solution for these problems is ABAP Unit, which is available with ABAP 6.40. This tool brings the well-known benefits of unit testing into the ABAP world. With ABAP Unit, testing for developers has become comfortable and far less time consuming than testing is supposed to be. This tool is highly integrated both in the programming language and the development environment you are familiar with as an ABAP developer. Above all, it supports individual and mass testing equally well. So ABAP Unit reduces the testing effort during implementation in such a way that once you have understood the way it works you will enjoy testing. Surely, you are primarily interested in going directly into the matter without much ado. So before giving you any further explanations, let us start by giving you an impression of what working with ABAP unit is like. This is part 1 of a weblog series on ABAP Unit. If you are interested, you find the other weblogs of the series here: A Spotlight on ABAP Unit Part 2, A Spotlight on ABAP Unit Part 3, A Spotlight on ABAP Unit Part 4, A Spotlight on ABAP Unit Part 5. Getting Started - a Simplistic Example Program With this tool you test small portions of code and write the test straight into the ABAP program you want to test. Let us start with a very simple program, for those who have always felt uncomfortable with percentages:

Our first ABAP Unit Test Now we write a test which checks whether or not, for a given value, our little form does its job correctly:

The tests are implemented in plain ABAP Objects as methods of local test classes. The test classes are part of the program under test (PUT). This can be an executable program, a module pool, a function group, or class pool. The PUT can contain many test classes, and a test class can contain many test methods. All unit tests belonging to one PUT are organized in a test task.

In our fairly basic example there is only one test class with one test method. Both have FOR TESTING added to the declaration. Never forget this specification. The test method should be declared in the private section, because normally it is only called automatically by the test driver of the framework, when the test is executed, but not explicitly by any other part of your code. In our example the test method class="co">test_minus_ten_percent first calls the form class="co">minus_ten_percent and sets the change parameter to 200. We compare the result of this calculation with the value we expect (180), by passing them as the parameters class="co">act and class="co">exp respectively to the class="co">method assert_equals of the service class class="co">cl_aunit_assert. It is this method supported by the framework which offers a great service. If there is an error, for example: if the value expected and the actual value differs, the error is shown in the ABAP Unit result view, after the test is executed. By pushing just one button, or rather selecting a menu entry (in our case it is the menu path: Program->Test->Unit Test in the ABAP Editor), all the tests belonging to one task are run, and the errors will be presented to you in a clear and concise display. In case of our example, in the result display you are easily lead to the form: FORM minus_ten_percent CHANGING fprice TYPE p. price = fprice * '0.9'. Obviously, we have mistaken the global data field class="co">price for the change parameter class="co">fprice. We change the line to: class="co">fprice = fprice * '0.9', and run the test again. This time, we get the information that the test was successfully processed, which means: There was no error. You see, with ABAP Unit the original error we had in our program was easily detected and tracked down. I will treat the details of the result display in another weblog when your knowledge of the ABAP Unit has increased after reading some of my subsequent weblogs. For the time being, I would like to address an objection that seems pretty natural, looking at the simplistic test we have written.

The Strong Use Cases For ABAP Unit: an Outlook You have now received a first impression of how easy it is to work with ABAP Unit, and you are perhaps convinced that this tool is easy to use. But you might still be a bit undecided and might harbor a slight suspicion: Of course, ABAP Unit is uncomplicated to handle, but what it does is very elementary indeed. Why should I bother to write ten lines of test code to check something I can see at a glance? Does it pay at all to write such simple tests? Regarding our frugal Percentages program with its minimal form, these objections do not seem utterly pointless. But, first you should remember that the Percentages-report containing the faulty form worked properly. It was only detected by the ABAP Unit test that the report yielded a correct output in the end only by accident and that the form itself was programmed incorrectly. As a matter of fact, the real strong use cases for ABAP Unit tests are more complex programs, where you want to run a whole battery of small tests at the touch of one button after each modification. This way, you can easily detect side effects when minor changes in one part of a program affect another part which worked correctly so far. I will give you an example for this in part two of this spotlight on ABAP Unit. A Spotlight on ABAP Unit Part 2 This weblog explains and discusses the principles of unit testing. This way you learn the rules you should adhere to if you want to write good unit tests using ABAP Unit. A Spotlight on ABAP Unit Part 3 This weblog presents basic features of the ABAP Unit result display. You learn how to track down the source of an error in the code. ' A Spotlight on ABAP Unit Part 4 This weblog considers some prejudices which might keep developers from writing ABAP Unit tests and explains that they are mainly based on a misconceptions of what unit tests are, what they are good for and how to differentiate them from integration tests. A Spotlight on ABAP Unit Part 5 This weblog shows how to use the ABAP Code Inspector to automate ABAP Unit testing. Automating ABAP Unit Tests Runs with the Code Inspector This wiki provides additional information on ABAP Unit. ABAP Unit Wiki COVERAGE ANALYZER You can use the Coverage Analyzer to check if all parts of your programs were covered by the test. Coverage Analyzer provides execution statistics for programs and program units. ECATT Extended Computer Aided Test Tool (eCATT) is used to create and execute function and integration tests. Its primary aim is the automatic testing of SAP business processes. Each test generates a detailed log that documents the test process and results. eCATT enables automatic testing in SAP GUI for Windows. For all information on eCATT visit this separate eCatt - Overview page. NEW ABAP DEBUGGER In contrast to other programming language you can run every ABAP program at any time in the debug mode. There is no need to start the server in a particular debug mode, just run a program in

the debug mode and this is all. Using the ABAP debugger, you can display data objects and check the flow logic of programs. The Classic ABAP Debugger is available for SAP NetWeaver release levels up to and including 6.40. As of release 7.0 the New ABAP Debugger is the default tool. The New ABAP Debugger enables analysis of all types of ABAP programs and offers a state of the art user interface together with a set of essential features and tools like the new ABAP Editor with syntax highlighting and a data quick info window, the Diff Tool, which allows to compare for example two nested structures or internal tables or the Data Explorer, which allows you to understand the details of even complicated objects at a glance. GETTING STARTED These recorded demos introduce all essential features of the New ABAP Debugger at a glance and teach you how to use the New ABAP Debugger: New ABAP Debugger for Classic ABAP Debugger Users - Demo (Flash, 10 min) New ABAP Debugger for Newbies - Demo (Flash, 12 min) This presentation introduces the functionality of the New ABAP Debugger. The New ABAP Debugger - An Introduction (PDF 1 MB) This is an audio-visual presentation about the functionality of the New ABAP Debugger. The New ABAP Debugger in SAP NetWeaver 7.0 ABAP ANALYSIS TOOLS The ABAP Workbench offers a suite of analysis tools, which support you in troubleshooting tasks during development and in a production environment. This section introduces tools for runtime analysis and tracing, performance, dump, and memory analysis. No matter what sort of problem you face in ABAP, the analysis tools can usually help you to track down and understand the cause and to find the solution. Runtime Analysis Performance Analysis Dump Analysis Memory Inspector RUNTIME ANALYSIS One tool, the ABAP Runtime Analysis (SE30, also known as ABAP Trace), solves two analysis problems: tracing a program for analyzing the program flow; and performance analysis of your ABAP application. ABAP Trace is the only tool which is able to trace the flow logic of ABAP programs at statement level. You can use ABAP Trace for example to find the location of the statement you are interested in, or to compare the control flow of an ABAP application in different systems or even to trace memory consumption. This weblog explains how to use ABAP Trace to analyze the execution flow of ABAP program. After you have read the blog, you'll be ready not only to find the exact source code line of an ABAP statement, but also to analyze long running batch jobs and even trace HTTP/RFC requests of other users. ABAP Runtime Analysis (SE30) - How to analyze ABAP program flow ABAP Trace can also be used to measure the performance of your ABAP application. You can use the results of the ABAP Trace to identify performance-intensive sections of your ABAP application.

This weblog explains the basics of the ABAP Trace with a focus on performance. After you have read the blog, you'll be ready to find the critical performance bottlenecks in your ABAP program. The ABAP Runtime Analysis (SE30) - Quick and Easy PERFORMANCE ANALYSIS The various trace functions of a SAP system are grouped together in the test tool Performance Trace. You can use it to monitor and analyze system behavior during database calls, lock management calls, remote calls of reports and transactions, and calls of the table buffer administration. This weblog gives you a quick introduction to the SQL Trace. In particular it shows how to execute SQL trace and to interpret its results.

ABAP Runtime Analysis (SE30) How to analyze ABAP program flow

Posted by Olga Dolinskaja in olga.dolinskaja on Dec 11, 2009 5:45:48 PM The ABAP Runtime Analysis (transaction SE30) is the best starting point if you want to execute performance or flow analysis of your ABAP program. Unfortunately many people use ABAP Runtime Analysis only to look for performance bottlenecks and don't know that ABAP Trace is the only tool with which you can trace the execution flow of an ABAP program at the statement level. This blog will show you how to use ABAP Trace of ABAP Runtime Analysis (SE30) to follow the flow logic of your ABAP program.

1. Why analyze the flow of an ABAP program?

The ABAP Runtime Analysis (transaction SE30) gives you one tool for solving two problems. You can measure performance and find bottlenecks. You can also analyze the program flow of your ABAP program. In this blog we will focus on program flow analysis. Why do you need to analyze the flow of ABAP program? Let me give you just a couple examples. First, you may need to find the exact source code location of a particular ABAP statement (a method call, function call...) you are interested in. You would then run the ABAP Trace and afterwards search the required line in the result list of the ABAP statements. Second, you may want to compare the flow of your ABAP program in different systems. Imagine, for example, that your ABAP program runs as expected in the test system but shows a completely differently behavior in the production system, or even worse, aborts with a short dump in the production system. You could then simply run the ABAP Trace in both test and production systems and compare the trace results.

2. How to find exact source code line of an ABAP statement?

Just imagine, you go to the ABAP Editor (transaction SE38), type "XXX" into the "Program" field, press the "Display" button and get the error message on the status bar "Program XXX does not exist". How could you find out the exact source code line of the ABAP statement that produced the message?

You could of course start the ABAP Debugger and try to debug in single step. And then after hours or weeks of intensive debugging you might be lucky enough to find the source code line of the ABAP statement. But why waste time? Here is how to use the ABAP Runtime Analysis to find this error message in a couple of minutes. If you press "?" button or click on the status bar near the error message, you will see the F1 help on the message, in the performance assistant. This tells informs you that the number of the error message is DS017. Therefore you have to look for the "message DS017":

To find the message, first start the ABAP Runtime Analysis and create a measurement variant.

1. Start the ABAP Runtime Analysis (transaction SE30) via System -> Utilities -> Runtime Analysis 2. Type "SE38" into "Transaction" field.
3. -> Execute or call the transaction directly with "/nse30". Create a measurement variant for your user: Type a name into "Variant" field and press "Create" button Set aggregation to "None" on the "Duration/Type" tab

For memory usage info check the "With memory use" flag Switch on "Particular units" on the "Program(Parts)" tab Save your variant

Before we go on, some important notes. Don't use aggregation if you want to trace ABAP in order to follow the program logic (what we are doing here). Aggregation summarizes the trace data for a particular type of event in a single trace record and therefore reduces the number of entries in the trace file. But to see the complete program flow you need all trace data. Try to use "Particular units" where possible in order to reduce trace file size and trace only the code you really need to see. The option "Particular units" allows you to switch on/off the ABAP trace during the running transaction. The trace will be started as soon as you enter "/ron" (trace on) in the OK field in your transaction. With"/roff " the trace is stopped. Alternatively you can also use the menu path: System -> Utilities -> Runtime Analysis -> Switch On / Switch Off. Let's execute the measurement:

1. Press "Execute" button. Transaction SE38, the ABAP Editor, starts. 2. Type "XXX" into the "Program" field and turn on the trace with System -> Utilities -> Runtime 3. Press the "Display" button and turn off the trace with System -> Utilities -> Runtime Analysis
-> Switch Off. Analysis ->Switch On.

Step back to the Runtime Analysis and analyze the trace results:

1. Press the "Evaluate" button. 2. Press the "Call Hierarchy" button and you get a list which represents the complete path 3. 4.

through your program. Search for "message DS017" in the Call Hierarchy list. Double-click on the entry in the Call Hierarchy list to jump to the source code line, which initiated the error message.

3. How to trace a long running batch job?

Now imagine the following situation. You are the administrator of a production system, and you encounter in the Process Overview (transaction sm50) a batch process, which already has been running several days and has been selecting data from a database table. This process is blocking other background jobs and you have to find out what this process is actually doing:

You can find this out very easily with the ABAP Runtime Analysis. You can use the ABAP Runtime Analysis (SE30) to trace programs which are running in a parallel session.

1. Ensure that you run SE30 on the same server as the running process! 2. You must create or adjust a trace variant for tracing the parallel process. Set aggregation to
"None" again to get the Call Hierarchy. Analysis displays a list of the running processes similar to the Process Overview (transaction sm50). 4. Use the "Start measurement/End measurement" buttons to activate and deactivate trace. Caution: Deactivate the trace again after short tracing time so that you do not reach the trace file quota! Before deactivating the trace, refresh the work process display. The dialog step that was active in the work process with the activated trace may have changed, and that deactivates the trace automatically.

3. Press the "Switch On/Off" button to trace processes running in a parallel session. The Runtime

5. Press "Evaluate" button to analyze trace results.

4. How to trace HTTP/RFC requests or processes of other users?

There are also often situations where you need to trace HTTP or RFC requests or processes of other users. Let me give you some examples. Imagine there is an online flight booking system. If a user wants to reserve a flight, his HTTP request arrives in your backend system. And you need to trace the reservation process which is running in your ABAP backend system. In such case you don't know which ABAP backend process handles which HTTP request and have no idea when the HTTP request will reach your ABAP backend system. Therefore it is difficult to capture such a request for debugging in the appropriate ABAP backend process. Another good example would be frequent RFC requests which reach your ABAP system and last only several hundred milliseconds. It is quite hard to trace such short-lived requests. Maybe you also have to deal with a batch job that runs under another user, which always starts at a different time and aborts sporadically with a short dump. How can you trace something like this? The ABAP Runtime Analysis (SE30) provides an answer. It lets you schedule a trace for any user on the current server. 1. Start ABAP Runtime Analysis (SE30).

2. Create your trace variant and set aggregation to "None" again to get the Call Hierarchy. 3. Press "For User/Service" button in the "Schedule" area of the initial screen. 4. Press "Schedule measurement" button on the Overview of Scheduled Measurements screen.
The transaction presents a popup on which you can schedule an asynchronous trace according to these criteria:

User Client

External session (choose "Any" if you are not sure in which session the application will run!) Process Category (dialog, batch, RFC, HTTP, ITS, etc.) Object Type (transaction, report, function module, any, etc.) Object (e.g. only transaction se38) Max. No. of sched. Measurements (specify the maximum number of traces) Expiration Date and Time (specify the time frame when the trace shall be active)

When the trace is scheduled, the ABAP Runtime Analysis automatically starts the trace as soon as session that meets your criteria is started on the system. The user you have specified logs on to the system and executes his task, and the ABAP Runtime Analysis starts to write the trace. The trace results can be analyzed - as usual - in the ABAP Runtime Analysis (using the "Evaluate" button on initial screen).

The ABAP Runtime Trace (SE30) Quick and Easy

Posted by Siegfried Boes in siegfried.boes on Nov 13, 2007 5:32:42 AM Besides the SQL Trace, the ABAP Runtime Analysis or ABAP Trace (transaction SE30) is the most important tool to use, if you want to test the performance of your ABAPprogram. Unfortunately, it can be seen in the forum and other sources that many people have questions about ABAP Trace. This blog will provide you with a quick introduction to ABAP Trace, show you how simple it is to execute, and tell you all you need to know for a basic performance analysis.

1. Using the ABAP Runtime Trace

Using this tool is nearly as straightforward as using the SQL trace (see The SQL Trace (ST05) Quick and Easy): 1. Call the ABAP Runtime Analysis (transaction SE30) 2. Check the measurement restrictions and change them if necessary. See the recommendations below. 3. Make sure you have executed the test program at least once, or even better, a few times, to fill the buffers and caches. You will obtain reproducible trace results only through repeated execution. We will neglect the initial costs in our examination. 4. Execute your test program directly from the ABAP Trace. This is possible for transactions, programs, and function modules. 5. Switch off the trace. 6. If a trace file was written, it will appear under Performance Data File. 7. Evaluate the results file. There are several other ways to execute the ABAP Trace, not described under step 4; but they are beyond the scope of this blog, please go to the ABAP Trace documentation for more information on them.

The measurement restriction has three tabs. First tab: Program (Parts)

Second tab: Statements

Third tab: Duration/Type

It is recommended that you create three measurement variants: PERF_BY_CALL (default): nothing selected on the first tab, on the statement tab everything selected but not the kernel-level runtime administration and not the Internal tables read and change operations; on the third tab set aggregation per call position and set the maximum file size to 20.000 KB and the maximum runtime to 3.000 sec. PERF_BY_CALL_ITAB: as above, but on the second tab the internal table read and change operations are switched on. PERF_NO_AGG: as PERF_BY_CALL, but on the third tab the aggregation is none. After the test program has finished (see step 3), navigate back to the start screen of the ABAP Trace, where you will find the latest trace file.

With Other File you can get a list of all trace files including previous measurements. Note, however, that the SE30 traces are deleted automatically after 8 days. Also remember that the files are stored per application server, so if you want to see traces of prior measurements, then you need to know on which application server the trace was executed. This section shows how to execute the ABAP Trace. Executing the trace is quite straightforward and can be performed with little prior knowledge. Interpreting the results requires some experience and is explained in the next sections.

2. Trace Results Overview

When you evaluate the trace you will first see the overview screen.

The most important information on this screen is the total runtime on the backend, i.e. on application server and the database. This is your total optimization potential. Perhaps you already had some expectations or external limits for the total runtime. In general, dialog applications with small objects should be considerably faster than 2 seconds, in order to obtain a total response time of 2 seconds. Larger batch jobs may need much longer. It is your task to interpret whether a runtime is good or bad. Based on user feedback, we have noticed that the graph seems to attract more attention than the actual figures, and users seem to focus heavily on the percentages and the red or green colors in the diagram. However, the colors carry little information, as the color switches from green to red if the percentage is larger than 50%. And the percentages themselves, of course, always add up to 100%. As a result, if one percentage is larger the other one must be smaller. System and database may be very small, or even zero, but should not be too large. For system, 10% is already too large, and for the database, 50% is quite large. The argument why database should be considerably larger than ABAP is the following: after the data has been read from the database, some kind of processing should occur on the records, so that a ratio of 20 to 40% for database is desirable. Programs with very special tasks can of course have very special percentage distributions. The hit list is the only additional information available for traces of aggregation type per call(ing) position. Fortunately, the hit list offers all you need for a quick and easy performance check. In this section the overview is explained. This is the total runtime and its distribution over the three categories ABAP, Database and System. From the total time you should be able to conclude whether your program is fast or slow, while the percentages tell you where to begin, if you want to optimize performance.

3. Trace Results Hit List

The hit list summarizes the measurements of execution and processing times into one entry per operation. If the aggregation is per calling position, then you will see two separate entries for the same operation if the operation is called from two different programs or if the operation is called from two different positions in the same program. The unique keys fields of the hit list are therefore Call, i.e. operation (col. 7), Program Name (col.8) and Line, i.e. calling position. Unfortunately, the line is not displayed in the default layout of the hit list and can be added by layout change. The important measured values are No. (col. 1), Gross (col. 2), and Net (col. 4). They tell you how often an operation was executed, and how much time it required, either as a total including suboperations (Gross time), or without sub-operations (Net time). Remember that the times are measured in microseconds (ms) and that the shown times are the total times, not the times per execution.

The other columns contain additional, although less important information. These are the equality sign = (col. 3), the percentages Gross (%) (col. 5) and Net (%) (col. 6), and also the Type (col. 9) and the No. Filter (col. 10). Of the 15 function icons

most are standard ALV functions: sorting (icons 1 and 2), horizontal scrolling(icon 5 to 8), details (icon 9), ALV filter (icon 10), sum of numerical columns (icon 11), layout change (icon 12), sending (icon 13), downloading (icon 14), and finally information (icon 15). Not standard ALV functions are the link to the source code (icon 3), and the filter (icon 4), which has ABAP Trace-specific settings. We recommend that you display everything.

This section introduces the hit list, which is the summarized view of the ABAP Trace like the SQL statement summary in the SQL Trace. It is explained what the hit list displays and what additional functions are hidden behind the icons. In the next section the hit list is used for the detailed analysis.

4. Checks in the Hit List

Start the checks in the hit list with the sort order gross time descending, which is also the default sort order. High Gross Time = Expensive Branch For the top 20, or better, for all lines with gross times larger than 10 ms, check whether they are really necessary, i.e. ask yourself if some of the executions can be avoided. It is not uncommon that operations are called too often. In terms of functional correctness this is not a problem, as the result is correct. It just means that the same result is computed several times. Then resort the hit list by net times descending, so that you can see the top consumers:

High Net Time = Expensive Execution Again, check the top 20 or all consumer with net times larger 10 ms. See whether the number of executions are reasonable or whether it could they be lower? Calculate the net time per execution and try to understand, why that amount of time is needed by analyzing the coding. Can the coding be improved to get better performance?

Finally, take a look at the large execution numbers. Do you understand the highest execution numbers? For example, why is an operation executed several thousand times? Is this necessary? Maybe you will realize that some of the executions are not really necessary. The ABAP Trace can provide you with the figures, but it cannot know how much time an operation is allowed to need. This is something only you can determine, either by knowing the functionality or by checking the coding in detail. It makes sense to classify the types of operations into different operations categories:

These

The modularization units, i.e. the methods, functions, and forms, contain the actual coding. Most of your analysis efforts should be focused on these areas. The internal tables are a special part of the ABAP processing. It makes sense to check them separately in a further analysis step. The RFCs (remote function calls) are special modularization units that run in another mode either on the same server or even in a different system. If they claim large fractions of the time, then you should also check the details of the RFCs. The database operations are by default measured separately from the modularization units. This will always represent a considerable part of the total runtime. If individual operations use up a large part of the time, check them in detail with the SQL trace. There are many other types of operations that are traced by the ABAP Trace. Usually, however, they are not critical to performance. Check them if they consume large portions of the net time. type categories will become more prominent in further developments of the SE30.

In this section, the details of the analysis are discussed. Check the top contributions in the hit list in detail and find out whether the coding can be optimized or whether the number of executions can be reduced.

5. Aggregation None
The aggregation None provides much more detailed results, because every individual execution of an operation is traced; it covers a lot more screens than the aggregation by call position.

There are 8 hit lists: Hit list, Group hit list, Database table hit list, Class hit list, Instance hit list, Method hit list, Event hit list and Internal table hit list, Call hierarchy (icon 9)

And Statistics and Display Filter The special hit lists are more or less just filtered views of the hit list and offer little new information. Only the call hierarchy offers something new. It shows all executions in the sequence of execution, with individual gross and net times plus level in the call stack. As you can imagine, a rather simple call hierarchy can already get very long.
As an example, I have reduced the call hierarchy of the simple example program, by selecting only the 4 modularization units on the second tab of measurement restrictions (left top corner), and switching on only the first entry in the display filter, which gives the following call hierarchy:

A standard business application will result in a call hierarchy with thousands of lines, if you use standard settings. Obviously nobody would ever analyze a call hierarchy in total, but only the parts that are of special interest. For a performance overview, the hit list is much more important. This section gives a short overview of the extended functionality of the ABAP Trace for non-aggregated traces. Besides the additional hit lists, the call hierarchy is the most interesting feature. However, about 95% of all performance analysis sessions can be done with the hit list of the trace aggregated by calling position.

This blog explains the basics about the ABAP Trace with focus on performance. You should now be able to find the most critical performance bottlenecks in your system. Together with a similar blog on the SQL Trace (see The SQL Trace (ST05) Quick and Easy), you should be able to get a good overview of the performance in your back-end system.

Further Reading: Performance-Optimierung von ABAP-Programmen (in German!)

More information on performance topics can be found in my new textbook on performance (published Nov 2009). However please note, that it is right now only available in German.

Chapter Overview: 1. Introduction 2. Performance Tools 3. Database Know-How 4. Optimal Database Programming 5. Buffers 6. ABAP - Internal Tables 7. Analysis and Optimization 8. Programs and Processes 9. Further Topics 10. Appendix In the book you will find detailed descriptions of all relevant performance tools. An introduction to database processing, indexes, optimizers etc. is also given. Many database statements are discussed and different alternatives are compared. The resulting recommendations are supported by ABAP test programs which you can download from the publishers webpage (see below). The importance of the buffers in the SAP system are discussed in chaptr five. Of all ABAP statements mainly the usage of internal tables is important for a good performance. With all the presented knowledge you will able to analyse your programs and optimize them. The performance implications of further topics, such as modularisation, workprocesses, remote function calls (RFCs), locks & enqueues, update tasks and prallelization are explained in the eight chapter. Even more information - including the test programs - can be found on the webpage of the publisher. I would recommend you especially the examples for the different database statements. The file with the test program (K4a) and necessary overview with the input numbers (K4b) can even be used, if you do not speak German!

The SQL Trace (ST05) Quick and Easy DUMP ANALYSIS Should the ABAP AS no longer be able to execute a program - because of an unhandled exception, a resource or system problem, or an error in coding - the ABAP runtime environment triggers

an ABAP runtime error. The execution of the program is terminated and a detailed error log (short dump) is created and saved. This pair of weblogs explores the diagnostic aids and information resources that an ABAP short dump offers and how to get the most help out of a dump.

The SQL Trace (ST05) Quick and Easy

Posted by Siegfried Boes in siegfried.boes on Sep 5, 2007 8:30:11 AM The SQL Trace, which is part of the Performance Trace (transaction ST05), is the most important tool to test the performance of the database. Unfortunately, information on how to use the SQL Trace and especially how to interpret its results is not part of the standard ABAP courses. This weblog tries to give you a quick introduction to the SQL Trace. It shows you how to execute a trace, which is very straightforward. And it tells how you can get a very condensed overview of the results--the SQL statements summary--a feature that many are not so familiar with. The usefulness of this list becomes obvious when the results are interpreted. A short discussion of the database explain concludes this introduction to the SQL Trace.

1. Using the SQL Trace

Using the SQL trace is very straightforward: 1. 2. Call the SQL trace in a second mode Make sure that your test program was executed at least once, or even better, a few times, to fill the buffers and caches. Only a repeated execution provides reproducible trace results. Initial costs are neglected in our examination Start the trace Execute your test program in the first mode server, so always switch your trace off immediately after your are finished. Display the trace results Interpretation of the results

3. 4.

5. Switch off the trace. Note, that only one SQL trace can be active on an application
6. 7.

Note, the trace can also be switched on for a different user. => In this section we showed how the SQL trace is executed. The execution is very straightforward and can be performed without any prior knowledge. The interpretation of the results, however, requires some experience. More on the interpretation will come in the next section.

2. Trace Results The Extended Trace List

When the trace result is displayed the extended trace list comes up. This list shows all executed statements in the order of execution (as extended list it includes also the time stamp). One execution of a statement can result in several lines, one REOPEN and one or several FETCHES. Note that you also have PREPARE and OPEN lines, but you should not see them, because you only need to analyze traces of repeated executions. So, if you see a PREPARE line, then it is better to repeat the measurement, because an initial execution has also other effects, which make an analysis difficult. If you want to take the quick and easy approach, the extended trace list is much too detailed. To get a good overview you want to see all executions of the same statement aggregated into one line. Such a list is available, and can be called by the menu Trace List -> Summary by SQL Statements.

=> The extended trace list is the default result of the SQL Trace. It shows a lot of and very detailed information. For an overview it is much more convenient to view an aggregated list of the trace results. This is the Summarized SQL Statements explained in the next section.

3. Trace Results - Summarized SQL Statements

This list contains all the information we need for most performance tuning tasks.

The keys of the list are Obj Name (col. 12), i.e. table name, and SQL Statement (col. 13). When using the summarized list, keep the following points in mind:

Several coding positions can relate to the same statement: The statement shown can differ from its Open SQL formulation in ABAP. The displayed length of the field Statement is restricted, but sometimes the displayed text is identical.

In this case, the statements differ in part that is not displayed. The important measured values are Executions (col. 1), Duration (col. 3) and Records (col. 4). They tell you how often a statement was executed, how much time it needed in total and how many records were selected or changed. For these three columns also the totals are interesting; they are displayed in the last line. The other totals are actually averages, which make them not that interesting.
Three columns are direct problem indicators. These are Identical (col. 2), BfTp (col. 10), i.e. buffer type, and MinTime/R. (col. 8), the minimal time record. Additional, but less important information is given in the columns, Time/exec (col. 5), Rec/exec (col. 6), AvgTime/R. (col. 7), Length (col. 9) and TabType (col. 11).

For each line four functions are possible:

The magnifying glass shows the statement details; these are the actual values that were used in the execution. In the summary the values of the last execution are displayed as an example. The DDIC information provides some useful information about the table and has links to further table details and technical settings. The Explain shows how the statement was processed by the database, particularly which index was used. More information about Explain can be found in the last section.

The link to the source code shows where the statement comes from and how it looks in OPEN SQL. => The Statement summary, which was introduced here, will turn out to be a powerful tool for the performance analysis. It contains all information we need in a very condensed form. The next section explains what checks should be done.

4. Checks on the SQL Statements

For each line the following 5 columns should be checked, as tuning potential can be deduced from the information they contain. Select statements and changing database statements, i.e. inserts, deletes and updates, can behave differently, therefore also the conclusions are different. For select statements please check the following: Entry in BfTy = Why is the buffer not used? The tables which are buffered, i.e. with entries ful for fully buffered, gen for buffered by generic region and sgl for single record buffer, should not appear in the SQL Trace, because they should use the table buffer. Therefore, you must check why the buffer was not used. Reasons are that the statement bypasses the buffer or that the table was in the buffer during the execution of the program. For the tables that are not buffered, but could be buffered, i.e. with entries starting with de for deactivated (deful, degen, desgl or ;deact) or the entry cust for customizing table, check whether the buffering could not be switched on. Entry in Identical = Superfluous identical executions The column shows the identical overhead as a percentage. Identical means that not only the statement, but also the values are identical. Overhead expresses that from 2 identical executions one is necessary, and the other is superfluous and could be saved. Entry in MinTime/R larger than 10.000 = Slow processing of statement An index-supported read from the database should need around 1.000 micro-seconds or even less per record. A value of 10.000 micro-seconds or even more is a good indication that there is problem with the execution of that statement. Such statements should be analyzed in detail using the database explain, which is explained in the last section. Entry in Records equal zero = No record found Although this problem is usually completely ignored, no record found should be examined. First, check whether the table should actually contain the record and whether the customizing and set-up of the system is not correct. Sometimes No record found is expected and used to determine program logic or to check whether keys are still available, etc. In these cases only a few calls should be necessary, and identical executions should absolutely not appear. High entries in Executions or Records = Really necessary? High numbers should be checked. Especially in the case of records, a high number here can mean that too many records are read. For changing statements, errors are fortunately much rarer. However, if they occur then they are often more serious: Entry in BfTy = Why is a buffered table changed? If a changing statement is executed on a buffered statement, then it is questionable whether this table is really suitable for buffering. In the case of buffered tables, i.e entries ful, gen or sgl, it might be better to switch off the buffering. In the case of bufferable tables, the deactivation seems to be correct. Entry in Identical = Identical changes must be avoided Identical executions of changing statements should definitely be avoided. Entry in MinTime/R larger than 20.000 = Changes can take longer Same argument as above just the limit is higher for changing statements. Entry in Records equal zero = A change with no effect Changes should also have an effect on the database, so this is usually a real error which should be checked. However, the ABAP modify statement is realized on the database as an update followed by an insert if the record was not found. In this case one statement out of the group should have an effect. High entries in Executions and Records = Really necessary? Same problems as discussed above, but in this case even more serious. => In this section we explained detailed checks on the statements of the SQL Statement Summary. The checks are slightly different for selecting and changing statements. They address questions such as why a statement does not use the table buffer, why statements are executed identically, whether the processing is slow, why a statement was executed

but no record was selected or changed, and whether a statement is executed too often or selects too many records.

5. Understanding the Database Explain

The database explain should show the SQL statement as it goes to the database, and the execution plan on the database. This view has a different layout for the different database platforms supported by SAP, and it can become quite complicated if the statement is complicated.

In this section we show as an example the Explain for a rather simple index-supported table access, which is one of the most common table accesses: The database starts with step 1, index unique scan DD02L~0, where the three fields of the where-condition are used to find a record on the index DD02L~0 (~0 denotes always the primary key). 2. In step 2, table access by index rowed DD02L, the rowid is taken from the index to access the record in the table directly. Some databases display the execution plan in a graphical layout, where a double-click on the table gives additional information, as shown on the right side. There the date of the last statistics update and the number of records in the table are displayed. Also all indexes are listed with their fields and the number of distinct values for each field, with this information it is possible to calculate the selectivity of an index. From this example you should understand the principle of the Explain, so that you can also understand more complicated execution plans. Some database platforms do not use graphical layouts and are a bit harder to read, but still show all the relevant information. => In this last section we showed an example of a database explain, which is the only way to find out whether a statement uses an index, and if so, which index. Especially in the case of a join, it is the proper index support that determines whether a statement needs fractions of seconds or even minutes to be finished. 1.

Please try the SQL Trace by yourself. If there are any questions or problems, your feedback is always welcome!

Analyzing Problems Using ABAP Short Dumps: Part I Analyzing Problems Using ABAP Short Dumps: Part II

MEMORY INSPECTOR The Memory Inspector is a tool that analyzes memory snapshots and saves them on the application server. You can use it both to display individual memory snapshots and to compare two snapshots. New ABAP Debugger and Memory Inspector A Developer's Guide to Protecting Memory: Detect and Eliminate Damaging Memory Leaks with ABAP Memory Inspector Save Time and Effort with ABAP Memory Inspector