Next Generation ABAP Runtime Analysis (SAT) – How to analyze program flow

SAT 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 blog ABAP Runtime Analysis (SE30) – How to analyze ABAP program flow completing 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) – Introduction

Next Generation ABAP Runtime Analysis (SAT) – How to analyze performance

Next 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:

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) via System -> Utilities -> Runtime Analysis -> Execute or call the transaction directly with “/nSAT“.

2. Type a name of a transaction into Transaction field (or a name of a program into Program field)

3. Choose Eval. Immediately to start the analysis right after the measurement

4. Choose Determine Names of Internal Tables to see the names of internal tables in the measurement

5. Create a measurement variant for our user:

• Type a name into Variant field and press Create button
• Set aggregation to None on the Duration/Type tab
• Choose Explicit Switching on and Off of Measurement to turn on/off trace only for the needed program parts to reduce a trace file size
• Choose only all Processing Blocks on the Statements tab to reduce a trace file size
• Choose additionally all operations on Internal Tables since 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 size and 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 option Particular units in 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 only Processing Blocks.

Let’s execute the measurement:

1. Press the Execute button. 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 use System -> Utilities -> Runtime Analysis ->Switch On).

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

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

1. Go to the Evaluate tab, find our measurement and double click to open it.

2. In the results display go to the Call Hierarchy tab. You see a list which represents the complete path through our application

3. Search for “INSERT” in the Call Hierarchy list, since you want toknow 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 press Position in Hierarchy button

5. Double-click on the INSERT entry in the Call Hierarchy list 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 the Set 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 the Display Call Stack button to show the call stack for a selected entry. This feature is available only in the Call Hierarchy.

Now perhaps you wish to understand the program flow which led to this INSERT. And you may perhaps find that the display in the Call Hierarchy is a little large and awkward; it would make sense to restrict this view. You can accomplish these tasks by using the new Processing Blocks Tool of the SAT.

The Processing Blocks Tool displays a call graph of processing blocks in order to present an aggregated view of the call sequence. The Processing Blocks Tool contains the statements that you configured in your measurement variant. Basically these are methods, subroutines and function modules. You can also use the Processing Blocks Tool 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 the Call Hierarchy list, press right mouse button and choose Position in the Processing Blocks Tool in the context menu. Now you can see a call graph which led to the INSERT statement.

7. Press Critical Processing Blocks button, in the popup choose Percentage of Total Runtime (Net) and enter LimitVal. 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 (use Confine to Subarea button)

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 to None again to get the Call Hierarchy.

3. Press the Switch On/Off button to trace processes running in a parallel session. The Runtime Analysis displays a list of the running processes similar to the Process Overview (transaction sm50).

4. Use the Activate measurement/Deactivate measurement buttons 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. Use Call Hierarchy Tool 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) via System -> Utilities -> Runtime Analysis -> Execute or call the transaction directly with “/nSAT“.

2. Create a trace variant and set aggregation to None again to get the Call Hierarchy.

3. Press Schedule button in the For User/Service 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 (“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 the Evaluate tab 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 a Profile Tool and a Hit List. For example by using the Other Hierarchy button of the Profile Tool 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 the Hit List Tool (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 the Times Tool (right mouse button menu, Display Subarea in Times Tool). Of course you can use as usual the Call Hierarchy to 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 the Other Hierarchy button of the Profile Tool 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 aggregation Per Call Position in a measurement variant to get the trace view in the Profile Tool and Hit List Tool for evaluation of measurement results.
• Always perform non-aggregated measurements. Set aggregation to None in your measurement variant
• Reduce trace file size by using variants. Use Explicit Switching on and Off of Measurement option in your variant where possible and then turn on/off the trace with “/ron” and “/roff” commands. Restrict the ABAP statements in the measurement on the Statements tab of your variant.
• Use the Call Hierarchy Tool 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 the Display Call Stack button.
• Use the Processing Blocks Tool to display a call hierarchy in a tree.
• Use the Processing Blocks Tool to find performance and memory hotspots in the call hierarchy. To get memory hotspots you must check Measure Memory Use on the Duration and Type tab in your variant.
• Use the Times Tool and Database Tool to get more detailed runtimes and analyze database accesses
• To compare the differences in the flow logic of your ABAP programs use the Call Hierarchy comparison Tool. You can access it on the Evaluate tab by selecting two compatible measurements on the Evaluate tab and pressing Compare Call Hierarchies button.