Analyzing Program Flow with the Call Sequence

Prerequisites

You have created an ABAP trace of your ABAP program. The ABAP trace has the state Finished.
The trace in question has aggregation set to No, as in this sample from the ABAP Trace Requests view.

If a trace is aggregated, then the trace does not record individual trace events. The Call Sequence function is not offered in the context menu if a trace was recorded with aggregation active.

Context

Use the Call Sequence view to analyze the execution path of a program. You can use the Call Sequence to do the following, for example:

Analyze the flow of a program as part of the analysis of an error. You can see which ABAP programs are involved in the error and easily find useful places to set breakpoints.
Understand how an unfamiliar program works and which ABAP programs play a role in its execution.

Here is how to use the Call Sequence to analyze the flow of program execution.

Procedure

Open the Call Sequence by selecting a trace in the ABAP Traces view and choosing Show in Call Sequence from the context menu or from the Overview page.

The Call Sequence opens in a new view of its own. It starts with a display of the top-most branches of the call hierarchy. The main runtime consumers are highlighted with boldface. The Show/Hide toggle link lets you display or hide non-procedural trace events in each procedure, such as database activity or use of internal tables.
Drill down to the section of the trace that particularly interests you. There you can see which programs participated in processing and analyze the flow of processing at the level of procedure calls.
Use the information resources of the Call Sequence to understand the program flow and analyze the runtime behavior of the program.
In this sample, we want to understand the most expensive call to the method GET_DOCUMENT_FROM_DOCU_SYSTEM, which had a runtime of around 17 milliseconds (Total Time). In this first view, the structure of the method is clear:
- It calls a function module from SAPLSDOC to fetch a document.
- It then calls a series of methods that perform operations on the document, such as resolving text symbols.
As you take a closer look at the trace excerpt, there are some interesting features to look at. First, the DOCU_GET function module uses almost as much 'own' (net) runtime as total runtime. What is it doing? Click Show to see what used the time in DOCU_GET. In fact, the Own runtime is accounted for by database operations on the three ABAP documentation tables.

Then, the calls to the native methods of class CL_DOCU_ADT_ITF_DOCU_READER have very low Own Time values. What are these methods calling? Expanding the methods shows that they call function modules from various function groups. A check of these function groups shows that they all belong to the ABAP documentation system. So, class CL_DOCU_ADT_ITF_DOCU_READER essentially encapsulates an older function-module-based API.

Results

We now understand basically how the class works and what runtime resources it consumes.

Tip

Should you wish to take a closer look at the code or set a break point in the code, just double-click on an entry. The ABAP editor opens in a separate window, positioned where the aggregated trace event occurred.
To take a look at the aggregated impact of the trace event on runtime, choose Show in Hit List from the context menu of an entry. You can see how the aggregated trace event ranks among the runtime consumers in the trace.
To Displaying the Call Stack that lead to a trace event, choose Show Call Stack in the context menu.