Single Transaction Analysis (ST12) getting startedThe Single Transaction Analysis was developedto promote the usage of ABAP trace inside SAP Support. It integrates the ABAP- (SE30) and the Performance (ST05) Trace into one transaction. This blog will show how to take a trace with ST12 in the so called "Current Mode" scenario. Further options for performning traces and analysis will bepresented in future blogs.Before you start:ST12 is delivered as a part of the Service tools for Applications (ST-A/PI). SAP note 69455 describes how to get the latest version of the ST-A/PI. Note that the ST12 transaction is not officially documented / supported and only available in the English language. Although it is mainly intended for use by SAP or certified service consultants during SAP Service Sessions, you can use it for you own performance analysis. A description of ST12 is given in SAP note 755977 (ST12 "ABAP Trace for SAP EarlyWatch/GoingLive").

ST12 main Screen:The main screen of ST12 has three main parts as shown on figure 1.

Figure 1: main screen

Using ST12 with Current Mode:In the "Current Mode" Scenario you are going to trace the execution of a program or transaction. Before you trace, it is recommended to execute your program or transaction several times to fill the buffer and caches, as filling the buffers and caches is something that can't be optimized with ABAP or SQL tuning. Before you can start the trace you have to define the measurement scope. In ST12 this is done "on the fly", no measurement variants are saved. After starting ST12 and clicking on "Current Mode" (see nr. 1 in figure 1) you will see a screen like figure 2.

Figure 2: Current Mode

You can enter a comment to give a meaningful description for the trace. Enter your program or transaction in the corresponding field and set the appropriate radio button, see nr. 2 in figure 2. In the lower part of the screen you define the measurement scope. The left part is for the ABAP trace (SE30) and the right part for the Performance Trace (ST05), see nr. 3 in figure 2.

Note: Since ST12 uses the functionality of both transactions (SE30 and ST05) the options are similar or the same. ST12 hides some details to make the traces more easy to use.

For the ABAP trace the most important decision is if you want to trace "with internal tables". It is recommended to switch this setting on. Other options like Particular units, Filters or "Further opt." are only needed in exceptional cases and beyond the scope of this "getting started" blog.

If you click on "Further opt." (see nr. 4 in figure 2) the following screen pops up:

Figure 3: further Options

Increase the "Max. size of file" to 20 MB (see nr. 5 in figure 3) and the "Max. trace runtime" to 3600 seconds (see nr. 6 in figure 3) if you have long running programs. The aggregation is set to "by calling position" by default which is the recommended option. All other options only have to be changed in exceptional cases. For example, if you get strange or negative times in the ABAP traces, you should use the low resolution clock.

For the performance trace you can decide whether you want to take the SQL-, Enqueue- and / or RFC trace. In the above scenario only the SQL Trace is switched on. The SQL Trace is the most important performance trace.

This is all you have to do. You can start your program or transaction now by clicking "Execute / start trace" (see nr. 7 in figure 2). After your program or transaction has finished and you have returned to ST12 you will see your trace in the lower part of the screen.

The status column (see nr. 8 in figure 4) shows you whether your trace is ready for evaluation. There might be a red and white circle which means the ABAP trace is still being imported into the database. The yellow flash indicates a measurement error (e.g. time limit exceeded, file size to small, ...). The green tick shows that the ABAP trace has been successfully imported to the database.

Note that ST12 imports the ABAP trace files into the database, in order to make them available in the whole system and keeps them for later analysis. In SE30 the trace files are application server specific and deleted after a certain number of days. The performance trace is not imported by ST12 and therefore is only available until the trace files are overwritten.

To evaluate the trace you can click on ABAP trace (see left arrow in figure 4) in order to display the imported ABAP trace. The list on figure 3 has been sorted descending by the Net column. This means the total times for each calling position is displayed in descending order.

In order to evaluate the performance traces just click the button Performance traces, see right arrow in figure 4. This will display the basic list of the performance trace. For the SQL trace it is recommended to start with the statement summary. Therefore in the basic list click menu Trace List -> Summary by SQL Statements. In figure 3 on the right bottom you can see an example of the SQL Trace Summary.

Note: Please refer to The SQL Trace (ST05) - Quick and Easy Blog (The SQL Trace (ST05) Quick and Easy) for further details on ST05 analysis.

Figure 4: Trace Analysis

Summary:In order to take an ABAP and SQL Trace at the same time for a program you are going to execute the following steps:

1.) Call ST12, click on CURRENT MODE (Nr. 1 in figure 1)

2.) Fill in the program or transaction and a meaningful comment (Nr. 2 in figure 2)

3.) Define the measurement variant:

a. switch on ABAP and SQL Trace and use internal tables (Nr. 3 in figure 3)

b. increase the file size and the duration (Nr. 4 in figure 2 and Nr. 5 and 6 in figure 3)

4.) Execute your program (Nr. 7 in figure 2)

5.) Evaluate the trace (figure 5)

This blogdemonstrated how ST12 combines the ABAP and Performance trace and how easy it is to trace a program and measure both ABAP and SQL execution. Future blogs will show advanced topics for trace taking and analysis.

More information on ST12 can be foundhere:

ST12 WIKI:

http://wiki.sdn.sap.com/wiki/display/ABAP/Single+Transaction+AnalysisBlogs:

ST12 - The workprocess traceBooks:

http://www.sap-press.com/product.cfm?account=&product=H3060http://www.sap-press.de/1821The Single Transaction Analysis was developed to promote the usage of ABAP trace inside SAP Support.It integrates the ABAP- (SE30) and the Performance (ST05) Trace into one transaction.Before you start:ST12 is delivered as a part of the Service tools for Applications (ST-A/PI).SAP note 69455describes how to get the latest versionof the ST-A/PI. Note that the ST12 transaction is not officially documented / supported and only available in the English language.

Although it is mainly intended for use by SAP or certified service consultants during SAP Service Sessions, you can use it for yourown performance analysis. A description of ST12 is given inSAP note 755977(ST12 "ABAP Trace for SAP EarlyWatch/GoingLive").

ABAP trace view (SE30):

Performance traces view (ST05):

SQL summary view (ST05 statement summary):

Stat. records view (STAD):

Next Generation ABAP Runtime Analysis (SAT) How to analyze program flowPosted byOlga DolinskajainABAP Testing and Troubleshootingon Jan 18, 2011 1:45:44 AMinShare1SAT is the transaction name of the new ABAP Runtime Analysis Tool, which is one of the most significant improvements in ABAP in the NetWeaver 7.0 EhP2.For those of you who are already familiar with the transaction SE30, the former ABAP Runtime Analysis Tool, transaction SAT is the successor of SE30. In SAT, ABAP's Runtime Analysis has been reworked by SAP's R&D department and has been enhanced with effective new analysis tools and features.

SAT offers benefits such as a modern state-of-the art UI, new analysis tools, easy navigation between tools and so on. As successor of the transaction SE30 SAT should be used for a program flow analysis. If you use SE30, you would be pleased to know, that the SE30 functionality for a program flow analysis is still the same in SAT and was just enhanced by the new program flow analysis tools.

The fourth part of these series of blogs about SAT devotes itself to the execution logic of an ABAP program and demonstrates how the new tools of the SAT help you to execute effective program flow analysis of any ABAP application.

This blog also fully complies to the SE30 blogABAP Runtime Analysis (SE30) - How to analyze ABAP program flowcompleting it by all new program flow analysis features, which were released with SAT.

You can find other blogs about SAT from these series here:

Next Generation ABAP Runtime Analysis (SAT) IntroductionNext Generation ABAP Runtime Analysis (SAT) How to analyze performanceNext Generation ABAP Runtime Analysis (SAT) How to analyze memory consumption

If you want to see a live demonstration of SAT, take a look at this short video:

SAT - Next Generation ABAP Runtime Analysis(Flash)

1. Why analyze the flow of an ABAP program?

Why do you need to analyze the flow of ABAP program? Let me give you just a couple of 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. To do this, you can run the ABAP Trace and then search for the required line in the result list of the 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 for this program in both test and production systems and compare the trace results to find out the differences in the program flow in both systems.

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

We will start directly with a sample usage scenario. Just imagine a car rental application, which makes it possible to reserve cars for the customers of a car rental company. When a car reservation for a customer is created, it is added to the car reservation table of the customer. Imagine that our task is to add some changes to the car reservation record before it gets written into the car reservation table. We therefore need to find out which ABAP program, (or method, function module...) writes the car reservation record into the car reservation table and where exactly in the ABAP source code this operation occurs.

Now let's see how to find this information with SAT within a couple of minutes.

First we must start the ABAP Runtime Analysis (SAT) and create a measurement variant.

1. Start the ABAP Runtime Analysis (SAT) viaSystem -> Utilities -> Runtime Analysis -> Executeor call the transaction directly with"/nSAT".2. Type a name of a transaction intoTransactionfield (or a name of a program intoProgramfield)

3. ChooseEval. Immediatelyto start the analysis right after the measurement

4. ChooseDetermine Names of Internal Tablesto see the names of internal tables in the measurement

5. Create a measurement variant for our user:

Type a name intoVariantfield and pressCreatebutton

Set aggregation toNoneon theDuration/Typetab

ChooseExplicit Switching on and Off of Measurementto turn on/off trace only for the needed program parts to reduce a trace file size

Choose only allProcessing Blockson theStatementstab to reduce a trace file size

Choose additionally all operations onInternal Tablessince we want to trace where a car reservation record is written into the reservation table

Save the 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 "Explicit Switching on and Off of Measurement" where possible in order to reduce a trace file sizeand trace only the code you really need to see. This option allows you to switch on/off the ABAP trace during the running transaction (if you know transaction SE30, it corresponds to the optionParticular unitsin the SE30).The trace will be started as soon as you enter"/ron"(trace on) in the OK field in your transaction. With"/roff "(trace off)the trace is stopped. Alternatively you can also use the menu path:System -> Utilities -> Runtime Analysis -> Switch On / Switch Off. Restrict the measurement only to the really required ABAP statements in order to reduce the trace file size.For most measurements it would be enough to trace onlyProcessing Blocks.

Let's execute the measurement:

1. Press theExecutebutton. The car rental application starts.

2. Shortly before we create a car reservation for a selected customer, turn on the trace with"/ron"in the OK code field (or useSystem -> Utilities -> Runtime Analysis ->Switch On).

3. Create a car reservation and turn off the trace"/roff"in the OK code field(or useSystem -> Utilities -> Runtime Analysis ->Switch Off).

Now it's time to go back to the SAT and analyze trace results.

1. Go to theEvaluatetab, find our measurement and double click to open it.

2. In the results display go to theCall Hierarchytab. You see a list which represents the complete path through our application

3. Search for "INSERT" in theCall Hierarchylist, since you want to know where a car reservation data record gets inserted into the reservation table

4. On the search result list choose the appropriate line with the INSERT statement and pressPosition in Hierarchybutton

5. Double-click on the INSERT entry in theCall Hierarchylist to jump to the source code line in which it was initiated.

Here you are. You have found the exact source code line in which a car reservation record was written into the reservation table.

Before we go on, some notes for you.

Use theSet Filter...button to choose the data you want to display. In the trace variant you already specified which statements and which parts of your application are to be traced. Additionally you can now filter the data you want to display. Please notice that some display filters are switched on by default (e.g. no system programs). Therefore if you miss something, switch off all display filters and check your trace variant.

Use theDisplay Call Stackbutton to show the call stack for a selected entry.This feature is available only in theCall Hierarchy.

Now perhaps you wish to understand the program flow which led to this INSERT. And you may perhaps find that the display in theCall Hierarchyis a little large and awkward; it would make sense to restrict this view. You can accomplish these tasks by using the newProcessing BlocksTool of the SAT.

TheProcessing BlocksTool displays a call graph of processing blocks in order to present an aggregated view of the call sequence. TheProcessing BlocksTool contains the statements that you configured in your measurement variant. Basically these are methods, subroutines and function modules. You can also use theProcessing BlocksTool to display critical processing blocks in terms of runtime (gross or net) or memory consumption. The SAT marks the appropriate nodes in red and opens them in a tree view.

6. Mark the INSERT entry in theCall Hierarchylist, press right mouse button and choosePosition in the Processing Blocks Toolin the context menu. Now you can see a call graph which led to the INSERT statement.

7. PressCritical Processing Blocksbutton, in the popup choosePercentage of Total Runtime (Net)and enterLimitVal.of 15,00%. The SAT will mark in red the processing blocks, which net runtime exceeds 15%.

8. You can then jump to one of these places and restrict the view to this subarea to analyze it more deeply(useConfine to Subareabutton)

That is basically everything you can get with a non-aggregated measurement.

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 new ABAP Runtime Analysis (SAT). You can use SAT to trace programs which are running in a parallel session.

1.Ensure that you run SAT on the same server as the running process!2. You must create or adjust a trace variant for tracing the parallel process. Set aggregation toNoneagain to get theCall Hierarchy.

3. Press theSwitch On/Offbutton to trace processes running in a parallel session. The Runtime Analysis displays a list of the running processes similar to theProcess Overview(transaction sm50).

4. Use theActivate measurement/Deactivate measurementbuttons to start and stop the 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.

5. Go to "Evaluate" tab, find your measurement and double click it.

6. UseCall HierarchyTool to analyze 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 (SAT) provides an answer. It lets you schedule a trace for any user on the current server.

We will demonstrate it by using our car rental application, which makes it possible to execute car reservations for the customers of the car rental company. After a car reservation for a customer takes place it will be added to the car reservation table of this customer. We will run it this time as a Web Dynpro for ABAP application in an external browser:

Let's schedule a measurement.

1. Start the ABAP Runtime Analysis (SAT) viaSystem -> Utilities -> Runtime Analysis -> Executeor call the transaction directly with"/nSAT".2. Create a trace variant and set aggregation toNoneagain to get theCall Hierarchy.

3. PressSchedulebutton in theFor User/Servicearea of the initial screen.

4. PressSchedule measurementbutton on theOverview of Scheduled Measurementsscreen.

The transaction presents a popup on which you can schedule an asynchronous trace according to these criteria:

User("ABCD" in our case)

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)

The ABAP Runtime Analysis automatically starts the trace as soon as a 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 SAT starts to write the trace. In our demo example SAT starts to write the trace as soon as the user "ABCD" executes the car rental application in the external browser. After the user "ABCD" made a car reservation for a customer, he closes the browser and the trace results can be accessed - as usual - in SAT (by double clicking on the corresponding measurement result on theEvaluatetab of the SAT initial screen).

Finally let us take a brief look at the measurement results in SAT. It is the same as we just have seen in the other two examples with the only difference being that here we are dealing with a Web Dynpro application. On the Desktop 1 we can see aProfileTool and aHit List. For example by using theOther Hierarchybutton of theProfileTool we can group the runtimes by packages and find out how much runtime gets consumed by our car rental application and how much runtime belongs to the Web Dynpro ABAP. If we then display the subarea of our car rental application in theHit ListTool (right mouse button menu,Display Subarea in Hit List Tool) we could pick up some runtime consuming trace entries and analyze them more deeply by using theTimesTool (right mouse button menu,Display Subarea in Times Tool). Of course you can use as usual theCall Hierarchyto follow the execution logic of the car rental application and for example find out where a car reservation took place.

Please note: SAT offers a possibility to group runtimes by SLAD (Software Layer Aware Debugging) layers.By using theOther Hierarchybutton of theProfileTool you can also group runtimes according to the SLAD (Software Layer Aware Debugging) object sets and profiles. By using the new transaction SLAD you can define specific object sets or layers which should be accessed by debugger and hide the rest of the code. Furthermore you can define whole layers and then jump from layer to layer instead of debugging through the application with single step'. This new debugging mode becomes especially important if you want to analyze a Web Dynpro for ABAP application and need to debug only its code instead of spending hours on intensive debugging of Web Dynpro for ABAP framework code, HTTP handlers, system stuff and so on. For more information on how to use SLAD please consult this weblog:Layer-Aware Debugging in NW 7.0 EHP2

5. Best Practices for a program flow analysis

When you measure a program flow of your application remember the following:

Use aggregationPer Call Positionin a measurement variantto get the trace view in theProfileTool andHit ListTool for evaluation of measurement results.

Always perform non-aggregated measurements.Set aggregation toNonein your measurement variant

Reduce trace file size by using variants.UseExplicit Switching on and Off of Measurementoptionin your variantwhere possible and then turn on/off the trace with"/ron"and"/roff"commands.Restrict the ABAP statements in the measurement on theStatementstab of your variant.

Use theCall HierarchyTool to analyze the call hierarchy of your application and find the ABAP statements you are interested in.You can also display the immediate call stack of a measurement event by using theDisplay Call Stackbutton.

Use theProcessing BlocksToolto display a call hierarchy in a tree.

Use theProcessing BlocksTool to find performance and memory hotspots in the call hierarchy.To get memory hotspotsyou must checkMeasure Memory Useon theDuration and Typetab in your variant.

Use theTimesTool andDatabaseTool to get more detailed runtimes and analyze database accesses To compare the differences in the flow logic of your ABAP programs use theCall Hierarchy comparisonTool.You can access it on theEvaluatetab by selecting two compatible measurements on theEvaluatetab and pressingCompare Call Hierarchiesbutton.

News in ABAP Debugger Breakpoints and Watchpoints , Statement DebuggingPosted byOlga DolinskajainABAP Testing and Troubleshootingon Jul 14, 2011 5:17:00 AMinShareSAPNetWeaver 7.0 EHP2 brings an expanded set of breakpoint and watchpoint capabilities as well as a new higher-resolution statement debugging capability (of course in the New ABAP Debugger!).This blog shows how to use these new features: The new types of breakpoint (on ABAP command, on Web Dynpro entities, on method of a class, on Simple Transformations...) The new types of watchpoints (on internal table, on ABAP objects and object attributes...) The new conditional breakpoints and watchpointsThis blog also explains the new statement debugging in ABAP - how you can separately debug multiple ABAP statements or expressions in one line.If you are interested in a live demonstration of the new features in ABAP breakpoints and watchpoints, just take a look at this short video:Advanced ABAP Breakpoints and Watchpoints in SAP NetWeaver 7.0 EHP2

1. New Breakpoint Types

If you are in the New ABAP Debugger and press theBreakpointbutton, you will find a whole series of new tabs in the breakpoint popup. Each of these tabs introduces a special new breakpoint type, which you can choose accordingly to your special needs, when setting a breakpoint in your code. Let's take a closer look at some of them.

ABAP Command Breakpoints

With theABAP Cmndstab, you can set a breakpoint on any of a variety of ABAP statements, shown to you in the F4 Help. The possibilities include setting a breakpoint at CALL FUNCTION, CALL FUNCTION DESTINATION, CALL FUNCTION IN REMOTE TASK, CALL FUNCTION IN UPDATE TASK, .... Many people didn't know that there are also different DELETE variants: DELETE ITAB (delete from an internal table) is different from DELETE DBTAB (delete from a database table).

Method Breakpoints

With theMethodtab, you can set a breakpoint at the invocation of a method of a class.

Simple Transformation and Web Dynpro Breakpoints

On theST Templatetab, you can set a row breakpoint at the call to a Simple Transformation template.

With theWeb Dynprotab you can set a breakpoint on Web Dynpro entities. When entering components, controllers and methods, the name of the generated class is determined and the breakpoint is set there. You can also tell the debugger to stop at each ABAP stack and screen change (Misctab) or set a breakpoint on a message (Messagetab).

2. Conditional Breakpoints

Imagine you need to debug an ABAP application in which an internal table is gradually filled with a large number of data records. Somewhere during the execution an error takes place and an incorrect data record gets inserted into the table. To analyze this behavior you can tell the debugger to stop as soon as this incorrect data record gets inserted into the table. You can do this by setting a breakpoint and adding a condition to it.

To add a condition to a breakpoint, click on your breakpoint with a right mouse button and chooseCreate Conditionfrom the context menu.An additional popup is displayed, in which you can enter the test condition.You can use variables in the condition, as well as debugger symbols and functions. Use the F1 Help on theBreakpoint Conditionpopup to see the possible condition operands and syntax.

3. New Features in Watchpoints

Now it is possible to set a watchpoint for an internal table (this wasn't possible in the classic debugger). Just pressWatchpointbutton and enter the internal table name in theCreate Watchpointpopup. The debugger stops when the internal table is changed. You can further refine the watchpoint by specifying a condition (for example stop only if internal table contains more then 200 rows). Enter a condition in theFree Condition Entryfield. Use the F1 help to learn which functions you can use in your conditions. The debugger will stop only if the internal table has changed and your specified condition is fulfilled.

In addition, theBreak./Watchpointstab shows which watchpoint has a hit, and you can for example view and compare a variables in its current (after stopping at a watchpoint) and previous state.

A further new feature is the ability to set watchpoints on objects. Just enter the object name in theCreate Watchpointpopup. In this way you can monitor the object during execution of your program. The debugger will stop as soon as the object changes. You can also set a watchpoint at object attribute (chooseWatchpoint at Object Attribute radio button) and select any desired types of instance and static attributes. The debugger then stops if an attribute has changed. Afterwards you can take a look at this attribute change on theBreak./Watchpointstab by selecting your watchpoint there and clicking on its details magnifier (in our example the Expander' attribute has changed from X' to a space').

4. Statement Debugging

Now imagine you are stepping through your code in the debugger and execute a long IF... statement, consisting of many different subcondtions. You expect a positive result, but unfortunately the IF... statement delivers you the negative answer. To analyze this behavior you need to understand which subcondition of this long IF...statement failed.

You can easily evaluate the conditions in the IF by changing the step size in the debugger. By pressing theStep Sizebutton you activate the statement debugging, and the debugger will execute the subconditions of for example your long IF... statement separately one after another. You can then analyze return values of single subconditions on theAutotab of the variable fast display window. By pressing theStep Sizebutton again you return to a normal line stepping in the debugger.

The ABAP Runtime Trace (SE30) - Quick and EasyPosted bySiegfried BoesinABAP Testing and Troubleshootingon Nov 13, 2007 5:32:42 AMinShareBesides 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 (seeThe 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 thenext 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 overviewisexplained. 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 sub-operations (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 BranchFor 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 ExecutionAgain, 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:

Themodularization units, i.e. the methods, functions, and forms, contain the actual coding. Most of your analysis efforts should be focused on these areas.

Theinternal tablesare a special part of the ABAP processing. It makes sense to check them separately in a further analysis step.

TheRFCs (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.

Thedatabase operationsare 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 manyother typesof 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.

These 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 (seeThe SQL Trace (ST05) Quick and Easy), you should be able to get a good overview of the performance in your back-end system.

New ABAP Debugger Tips and TricksPosted byOlga DolinskajainABAP Testing and Troubleshootingon Nov 10, 2010 12:51:37 AMinShare2The New ABAP Debugger was first released by SAP with NetWeaver04. As of release NetWeaver 7.0 it fully replaces in the scope of its functionality the "old-fashioned" Classic ABAP Debugger. During the last SAP TechEds I learned that more and more people use the New ABAP Debugger (that is a great news!) but still many are not aware of some of its useful features. The purpose of this blog is to point you to these features so that you can make the most of the New ABAP Debugger.

Some useful debugger settings How to handover a debugger problem - Use Debugger Variants How to display all loaded programs and global variables - Use the Loaded Programs Tool How to test a function module in the debugger and pass parameters Helpful hints for analyzing variables How to debug a program which is running in an endless loop How to debug a background job which is running in an endless loop How to debug a finished or crashed background job How to compare ABAP variables - Use the Diff Tool How to debug HTTP requests Helpful debugger ok-codes

Some useful debugger settings

The New ABAP Debugger settings dialog lets you activate special debugging modes and comfort options that can speed up your troubleshooting scenarios. Here you will find some helpful debugger settings with instructions on when and how to use them. You can access debugger settings in the debugger by usingSettings->Display/Change Debugger Settings:

System Debugging:if you have problems that involve system programs (such as a function that can't be accessed in the debugger), turn on this setting (or use menuSettings->System debugging On/Off" or the command/hsin the debugger command field). You can declare a program as a system program by settingStatusto "System Program" in its attributes in the ABAP Editor (SE38) (check the radiobuttonAttributesand pressChangebutton).

Update Debugging:turn on this settingif you need to analyze asynchronous updates, which are functions that are called as follows: CALL FUNCTION ...' IN UPDATE TASK. These functions are executed asynchronously in a special update work process (after the next COMMIT WORK statement). The debugger can't follow them since it is attached to a single process. Set a breakpoint in the function that is called IN UPDATE TASK, start debugging, turn on this setting, and the debugger will reach the breakpoint in your update function.

TRFC (In Background Task): Block Sending:turn on this settingif you need to analyze transactional Remote Function Calls (TRFC), which are called as follows: CALL FUNCTION ...' IN BACKGROUND TASK. These functions are called asynchronously, along with other TRFC functions of this logical unit of work (LUW), after the next COMMIT WORK statement. The debugger can't follow them since it is attached to a single process. When you turn on this setting, these TRFC functions are stored in the system for debugging instead of being sent. Use the TRFC Monitor (transaction SM58) to analyze the unprocessed LUWs and selectEdit->Debug LUWto debug them.

Close debugger After Continue' (F8) and Roll Area End:usually after you pressContinue (F8)in the debugger session, the debugger session remains available but inactive when the program is finished. If you switch on this setting, then the debugger will be closed automatically after pressingContinue (F8), when the roll area (internal session) is ended.

Always Create Exception Obj.:turn on this setting if you need to analyze exception objects (if you catch ABAP exceptions in your program via the CATCH CX_MY_EXCEPTION without specifying a reference variable to which the exception object can be assigned). You can then examine the created exception objects in the debugger viaDisplay Exception Obj.magnifier button.

How to handover a debugger problem - Use Debugger Variants

Imagine that you have had to reproduce and troubleshoot a problem in a rather complicated environment. You have finally found the function module which doesn't work properly under certain conditions. You may need to hand over this debugging session for further analysis to a colleague who has expert knowledge of this function module.

In order to ensure that your colleague can reproduce the problem, you must create a very detailed description: the source lines at which to set breakpoints, the debugger settings that must be active, and so on. This is time consuming and there is still a chance that you might forget critical information. In such situations, use a debugger variant (menuDebugger->Debugger Session->Save) to store your debugger session. You can choose which parts to store: current layout (customized desktops), debugger settings, options and breakpoints. Then you can save the variant either in the database or in a local file and send it per email to your colleague.

Afterwards your colleague can load the saved variant from a file or the database after starting a debugging session (menuDebugger->Debugger Session->Load). All settings and breakpoints will become active immediately. Of course he can choose which components of the variant to load: layout, settings, options, breakpoints, or all of them.

How to display all loaded programs and global variables - Use the Loaded Programs Tool

A double-click on the variable name in the source code leads to theVariable Fast DisplayTool where you get information about variable: type, value, etc. On theLocalstab you get all parameters (including parameter kind) and local variables of the current function module, on theGlobalstab, you can display all global variables of the current program. But sometimes this local and global information is not enough; you maybe need to display all currently loaded programs and their global variables as well. For this purpose, use theLoaded ProgramsTool (buttonNew Tool, Special Tools->Loaded Programs).

Loaded Programsshows you two tabs. On theLoaded Programstab you see the attributes of all loaded programs and their program groups. On theGlobal Datatab you get global variables of each global program just by double-clicking the program in the navigation tree.

How to test a function module in the debugger and pass parameters

Imagine you want to test a function module in the test framework of the Function Builder (transaction SE37) in the debugger, and you need to pass as a parameter a big internal table with many entries. It would be very time consuming to enter the input data for such a table manually in SE37. But you don't have to do this. If you access the function module from the debugger, then you can download its parameters to the SE37 test framework. Select the parameter and use the right mouse button context menuSave Parameters as Test Data (SE37). Please consider that this download is restricted to the data types which are allowed in the SE37 test framework: you cannot download objects, nested internal tables or data references. After that just open the function module in a separate SE37 window and run it in the test framework. You can access your downloaded data in SE37 viaTest Data Directorybutton.

Helpful hints for analyzing variables

Use theData Explorerto view deep nested objectsWith theObjectsTool (Objectsdesktop) you can examine object properties including visibility, inheritance, references to the object (where-used list ). You can double-click on attributes in order to navigate to the subcomponents of a class. But if you have to analyze deep nested objects, then theData ExplorerTool is the better choice. TheData Explorerlets you drill down into nested objects, structures, and references without losing context of the upper levels.

UseText Translationto display large hex strings and the XML Browser to display XML data.It is very time consuming to analyze the content of a variable that contains 2000 bytes of hex code. Therefore, the detail view (Detail Displaydesktop) for simple types and strings allows you to translate hex strings into readable text using the appropriate code page (fieldView, chooseText Translation). For binary XML data, there is the XML viewer (fieldView, chooseXML Browser).

How to debug a program which is running in an endless loop

Imagine your program is running in an endless loop and you need to analyze its behavior. In such situations you can force the running program into the debugger simply by setting a session breakpoint in a second ABAP Editor. InUtilities->Settings...->Debugging just choose theSession breakpoint active immed.option. When you activate this option, all (running and waiting) sessions of your logon session immediately inherit all session breakpoints set in any of those sessions. It is recommended that you activate this option in development environments.

How to debug a background job which is running in an endless loop

Now imagine that you have a background job that is running and running, and you want to analyze its behavior. Just use theProcess Overview(transaction SM50), select the running process, and choose from the transaction menuProgram->Debugging.

How to debug a finished or crashed background job

Now just imagine that your background job finishes its execution so quickly, that you don't have a chance to attach a debugger to it in theProcess Overview(SM50), or even worse: it crashed with a dump and you need to analyze what caused the dump. Just choose your job in theJob Overview(transaction SM37) and type "jdbg" into the command field. The debugger will start, and you just would need to press a couple of times Return (F7) to get out of the spool functions checks and you can debug your finished or crashed background job online in dialog.

How to compare ABAP variables - Use the Diff Tool

Just imagine you are in the debugger and need to compare two strings which are 2000 bytes long, or you need to compare two nested objects to look for differences in deeply nested attributes. With theDiffTool (Diff Desktop) you can compare two compatible ABAP variables, e.g. two tables, objects, structures or strings. TheDifftool provides differences concerning type and value. If you double click on a hit in the diff result list, the variables are displayed in parallel, and the debugger navigates to the difference.

In order to assure good performance of the diff tool, even for deeply nested variables no "deep diff" is executed.

This means that if you have for example an internal table as the attribute of an object, then you can at first only check if the tables of both objects are equal. You will not get details about where they differ. To get the details of differences, you can run a diff for the unequal subcomponents (Diffbutton in the corresponding result line). You can use theHistorytab to get back to the first result list.

How to debug HTTP requests

Nowadays, distributed HTTP based applications (like BSP, Web Dynpro for ABAP applications) are the reality in many IT scenarios. To troubleshoot such applications, you must be able to debug HTTP requests.

Use transaction SICF to activate the debugger for a specific web service and a specific user (menuEdit->Debugging->Acivate Debugging). Please keep in mind that your web application must run on the server where you set user breakpoints and/or where you activate HTTP debugging via SICF. Please refer to SAP note 668256 for the details on HTTP debugging.

After activating debugging, you will stop in the system code of the http requests in the debugger.

You can set new user breakpoints

or watchpoints to reach the point of interest. Don't forget to save them before continuing.

Helpful debugger ok-codes

/hactivate debugging

/hsactivate system debugging

/haskip dynpro (PAI, PBO) and directly debug ABAP code

/hxdetach debugger

/hmusacreate memory snapshot (can be used in the transaction S_MEMORY_INSPECTOR for memory consumption analysis)

jdbg in SM37restart of a finished or crashed background job for debugging

/ronstart ABAP Runtime Analysis measurement (transaction SE30)

/roffstop ABAP Runtime Analysis measurement (transaction SE30)