Analyzing a Long-Running Process with the ABAP Runtime Analysis

You can use the ABAP Runtime Analysis to trace program execution in other work processes in your system.

For example, you can trace the execution of a long-running background job. The trace lets you see what the job is doing - whether it is looping or is doing the work it should be doing.

Tracing a 'parallel session', as the function is called on the transaction SAT measurement screen, is faster and safer than trying to capture a long-runner in the debugger:

• Faster, because although you can capture a running process in the debugger from transaction SM50, the Process Overview, you cannot control where the program stops in the debugger. The chances are that you will land somewhere in infrastructure code. It can take a long time for you to orient yourself and understand what the program is doing.

• Safer, because you run the risk in the debugger of inadvertently affecting the program's execution. The ABAP Runtime Analysis traces a program without interfering with it.

Tracing an External Process

Assume that there is a background job running in your system. The runtime is in excess of what you would expect for the job. Perhaps it is also showing unexpected activity in the Process Overview, transaction SM50, such as reading persistently from a single table.

Here is how to trace the background job without interfering with it. From the trace, you can find out what the job is doing and whether it is doing what it should be doing.

You can use this procedure to trace activity in any type of work process.

1. Start the ABAP Runtime Analysis by entering transaction SAT or choosing  System  Utilities  Runtime Analysis  Execute. 

2. Specify a variant that has Aggregation set to None.

   The resulting 'ABAP trace' measurement records trace events individually, so that you track the program flow and understand what the program is doing.

3. Start the non-aggregated measurement (ABAP trace) using the Switch On/Off button in the In Parallel Session frame on the Measure tab.

   The ABAP Runtime Analysis shows you a list-based variant of the SM50 Process Overview.

4. Activate the trace. Click the work process that you wish to trace.

   The Runtime Analysis displays a status message to show that the measurement has been activated.

   • An icon shows that the measurement still has not yet started.

   • When the icon shows, the trace is running. You can click the process again to deactivate the trace for display.

   If the Runtime Analysis shows the message Trace file not yet written. Do you want to wait?, then choose the Cancel button to terminate and display the trace.

   Initially, the process-list display shows only active work processes in the local ABAP application server.

   • You can show all work processes in the server by choosing All Processes.

   • You can trace one or more work processes in other servers or all servers by choosing Server Selection.

5. In the measurement display, switch to the Desktop 2 tab to analyze the measurement.

   Desktop 1, where the display starts, is set up for analyzing performance.

   You need Desktop 2, for analyzing program execution.

6. Analyze the call stack to see what the program is doing.

   On Desktop 2, open the Processing Blocks tool to get a clearer view of the program's call stack. If you see repetition in the sequence of processing blocks, then double-click on the entries to look at the code.

   You will not be able to examine the value of variables, as you could in the Debugger. But you can probably judge whether the repetition is for doing proper work, like processing a sequence of customer records.

7. Get more detail on program activity by jumping to the Call Hierarchy.

   Do you need to see the program flow in more detail? Then use the context menu of Processing Blocks entries to jump over to the Call Hierarchy tool. Choose Position in the Hierarchy Tool.

   There, you can see the individual trace entries related to each processing block. You can also filter the Call Hierarchy to show only the trace entries related to individual processing blocks.

The clear call stack trace offered by the Processing Blocks tool and the detailed tracing offered by the Call Hierarchy tool may be enough to let you judge whether the long-running program is doing what it should be doing.

If you feel that you need to examine the variables in the debugger to see what the long-runner is doing, then you can leave breakpoints in the source code so that you can stop in the debugger.