Professional Documents
Culture Documents
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.
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.
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 -> Execute or call the transaction directly with “/nse30“.
2. Type “SE38” into “Transaction” field.
3. 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
Step back to the Runtime Analysis and analyze the trace results:
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.
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 “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.
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).