Finding Messages and Other Statements with the ABAP Runtime Analysis

If a short dump occurs in a program, you know exactly where in the ABAP code the problem occurred.

But what do you do if an unexpected error message occurs in one of your programs, perhaps because the program has encountered unforeseen conditions? How can you find out where in the code the message was issued? That's the first bit of information you need for analyzing the problem.

The ABAP Runtime Analysis provides a fast and easy way to find out where an error message was issued in the code. You can also use the Runtime Analysis just as easily to find other important statements, such as SQL statements or calls to methods, function modules, or form routines.

Here is the procedure for doing a program flow analysis to do the following:

• Find a particular statement, such as an error message

• Display the call stack that lead to the statement

Finding an Error Message and Displaying the Call Stack with a Program Flow Analysis

Assume that you need to analyze an unexpected error message that has been issued by an ABAP program. Follow this procedure to find the location at which the error message was issued and the call stack that lead to the message.

1. Use the message F1 help to find out the message ID and message number.

   The message ID and number are shown at the top of the help. For example the string BT005 in the help window means message ID ' BT' number 005 (in transaction SE91).

   Click a message in the status line to start the F1 help. Or choose the Help button on messages in dialog boxes.

   The message ID and number let you find the message faster in a runtime analysis measurement. You can also be sure that you have found the right message, if more than one was measured.

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

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

   The resulting 'ABAP trace' measurement records trace events individually, so that you can search for particular ABAP statements.

   Optionally, you can turn the trace on and off on your own. Do this if you know the part of an interactively started program or transaction that you want to trace. You can then limit the trace to the relevant part of a program or transaction.

4. Start the non-aggregated measurement (ABAP trace) using any of the three Runtime Analysis start methods.

5. Display the trace when it is done, if it is not displayed automatically.

   You find yourself on the tab Desktop 1, which is set up by default for analyzing performance.

   Switch to the tab Desktop 2, where you find tools for analyzing program flow, the Call Hierarchy and the Processing Blocks view.

6. Find the MESSAGE statement in the Call Hierarchy. In the Call Hierarchy tool bar, click .

   In the search dialog box, enter the name of the statement or event that you want to find. To find a message, enter MESSAGE. If you know the message number and type, you can make the search more precise: MESSAGE E005, for example.

   The trace events in the Call Hierarchy represent ABAP statements schematically, not exactly as they appear in the source code. Browse through a trace to find examples if you are not sure how to search for a particular trace event.

   The Call Hierarchy responds by showing the trace entries found by your search in a dialog box.

7. In the dialog box of trace entries that were found, double-click an entry to jump to the exact location of the entry in the source code.

   In response, the ABAP Runtime Analysis opens the ABAP editor to show the MESSAGE statement or other event for which you have searched. You have found where the message or other event occurred.

   In the editor, you can analyze the code. You can set a breakpoint or watchpoint so that you can stop in the debugger when you reproduce the problem.

   Continue to the next step to see how to display the call stack that lead to this trace event.

8. Leave the ABAP Editor to return to the list of trace entries that were found.

9. Find the location of the MESSAGE entry in the list of trace entries in the Call Hierarchy.

   Mark the message entry or other entry that you found. In the tool bar of the search window, choose .

   In the main screen of the Call Hierarchy, the Runtime Analysis marks the position of the entry in the list of trace events. Leave the Find dialog box to return to the main screen of the Call Hierarchy.

10. Display the call stack in the Processing Blocks tool.

    Open the context menu of the marked entry in the Call Hierarchy display. Select Position in the Processing Blocks Tool.

    The Processing Blocks tool is the other tool on the standard Desktop 2 tab. It opens automatically to show the processing block in which the trace event in the Call Hierarchy occurred.

    The Processing Blocks tool gives you a clear display of the call stack that lead to your trace event. The processing block (a dialog module, method, function module, or other modularization unit) in which the event occurred is highlighted in green.

    You can use the call stack to understand how the program reached the location at which the error occurred. Of course, you can jump into the code from any entry in the Processing Blocks tool to analyze the code or set additional breakpoints.