ABAP Debugger Scripting: Basics

Now that NetWeaver 7.0 EHP2 is available as a Mini-Basis System, we can tell you about some
of its new features.
One of the coolest of these new features for problem analysis is ABAP scripting in the New
ABAP Debugger. In this weblog, we explain what this feature is for, what the script workplace
looks like, and how to run a couple of first scripts to whet your appetite. You’ll see how to do a
complete trace of executed statements from the script overview, and how to see where particular
statements occur in your (executed) code.
What is Debugger Scripting For?
The new scripting capability lets you automate anything that you can do by hand in the New
ABAP Debugger. Debugger Scripts also make some things possible – like all kinds of tracing –
that aren’t possible by hand.
With ABAP Debugger Scripts, you can:
• Analyze and modify the contents of variables and objects in the
program you are debugging.
You can display or change the value of a variable by hand in the debugger, and you can
do the same thing with a script. The classical example: You can skip over failed
AUTHORITY-CHECK statements with a script by stopping at each AUTHORITY-
CHECK, running it, and resetting SY-SUBRC to 0. (This is still recorded in the System
Log….)
• Perform any imaginable tracing that you might want to do.
With scripts, you can
○ Do the first automated absolutely complete trace of executed ABAP
statements possible (SAT – the new ABAP Runtime Analysis - cannot
capture every executed statement.)

○ Trace the call stack in an ABAP application or in any part of an

application – very useful if you want to find out what to include in a
profile for ABAP Layer-Aware Debugging (See Layer-Aware Debugging.)

○ Define your own traces with any trace message content that you can
imagine. You can for example trace the value of a parameter that is
passed up or down the call stack in your application to find out where it
goes bad.

○ Implement your own breakpoints and watchpoints, should the

extended set introduced in EHP2 not meet your needs.
You can combine the powers of the new ABAP breakpoints and watchpoints with
the intelligence of scripts. Some system in your landscape is returning trash in an
RFC data structure? No problem. Have your script run whenever the program in
the debugger does an RFC (breakpoint at RFC), execute the RFC call, check the
 returned data in your script, write a trace or break execution when you find the
bad data return.
○ Analyze and display data from complex data structures (internal tables
with nested objects, for example)
The revised Table tool in the New ABAP Debugger makes it a lot easier to look at
data in a complex data structure (look for the upcoming weblog). But for tracing
data generation or checking data consistency as your debuggee runs, a script is the
better tool. The classical example is an internal table with nested objects whose
attributes you want to check. A script can read those nested attributes row by row,
check or trace them as you wish, and even stop execution if something goes
wrong.
○ Program (interactive) tools for standard tasks, such as checking data
consistency, changing variable values to test error handling, and so on.
A lot of script programming is quick ad hoc work right in the debugger to help
you with some analytical or data collection problem.
But ABAP Debugger Scripting also lets you save scripts for re-use. And
transaction SAS offers a comfortable workplace for developing scripts away from
the pressure of an active debugging session. You can develop tools or utilities for
debugging to suit your special needs, and you can share these scripts with others
on the same or on other ABAP Systems.
An ABAP script is simply a local ABAP Objects program that is run by the New ABAP
Debugger. The script uses the ADI – ABAP Debugger Interface – to automate actions
that you otherwise might perform by hand in the debugger – and to add capabilities that
otherwise would not be available to you. ABAP scripts take advantage of the two-
process debugging infrastructure that SAP introduced in NetWeaver NW04s (7.0).
Of course, what you can do with a debugger script is limited only by your requirements
and imagination. But the point of ABAP Debugger Scripting is to increase your
efficiency in analyzing and solving problems with the New ABAP Debugger.
So the Debugger Script workplace includes a small selection of ready-to-run scripts (the
Script Overview button in Load Script) that you can either use directly or modify for your
own purposes. And there is also a script wizard for writing your own scripts (or
modifying ready-to-run scripts). The wizard lets you insert method calls to debugger
services in your script. See the weblog on advanced scripts for more information.)
The Debugger Script Desktop
Here is what you see when you start a program in the New ABAP Debugger and then
click on the very last Debugger Tool tab: Script.
Here is what you see when you start a program in the New ABAP Debugger and then click on
the very last Debugger Tool tab: Script.
As you can see, the source code editor is open so that you can edit a standard script
template. You can use any standard ABAP OO statements and constructs that you wish.
Plus you can use the method calls from the Script Wizard; these let you make use of the
services of the New ABAP Debugger. (See the weblog on advanced scripts).
You can load a script from the library or from a collection of your own scripts (use a
naming convention, so that you can find them again). You can easily move scripts
between systems by downloading them to file and then uploading them again.
To the left of the editor, you can specify when the ABAP Debugger should run the script
– for example, after every single execution step in the debugger. The Trigger options
have the following meanings:
○ Execute directly: If you mark this option, the script runs only if you
press the Start Script button. The debugger does not run the script
automatically. This is the right option if you are using a script for a
single specific task, like dumping the data from a complex data source
to a trace.

○ After Debugger Events – Debugger Single Step: Once you tell the
debugger to run the script (with Start Script), then the debugger
automatically runs the script after every debugger single step (F5 –
Single Step in manual debugging). After every statement is executed
 by the debugger, the script runs again. This is the Trigger setting for a
full statement-level trace of execution.

○ After Debugger Events - Breakpoint Reached, Watchpoint Reached:

With these options, the debugger runs the script every time a
breakpoint or watchpoint is reached.
Important: The script runs only when the debugger reaches breakpoints and
watchpoints defined here, in the context of the script. If you check one of these
Trigger options, an icon appears that allows you to define breakpoints and/or
watchpoints for triggering the script. The script does not run at breakpoints or
watchpoints that you may have set separately, in the source code editor, for
example. This arrangement lets you separate breakpoints or watchpoints that are
to trigger the script from those that you set for your own use in the debugger.
At the bottom of the screen (not shown in the screen shot) is the Display Last Trace
frame. After your script has stopped running, you can use the buttons in this frame to
display the trace (if any) created by the script.
Your First Script: A Complete Trace of Executed Statements
The ABAP Runtime Analysis (transaction SAT) can trace almost to the level of all
executed statements. But before ABAP scripting, you had to step through a program
yourself in the debugger to see exactly what a program does.
Here’s how to create a complete trace of executed statements using ABAP Debugger
Scripts.
1. Start a program in the New ABAP Debugger. It’s immaterial how you
reach the debugger – by breakpoint, /h ok-code – you can start a
debugger script from any point in a program’s execution.
2. Click on the very last Debugger Tool tab: Script.
3. Click on the Load Script button and then on the Overview of Debugger
Scripts icon.
4. On the list of ready-to-run predefined scripts, open the Traces folder
and double-click on the last script,
RSTPDA_SCRIPT_STATEMENT_TRACE.
The script is inserted into the script editor – it’s ready to run. You’ll notice that
the predefined script has also set the Trigger frame correctly. Trigger tells the
New ABAP Debugger to run the script after each debugger single step (an F5 key
press, in interactive use of the Debugger).
5. Tell the New ABAP Debugger to run the script by clicking on the Start
Script button.
What happens? The New ABAP Debugger runs the program that you are
debugging to the next breakpoint (including a stop required by Layer-Aware
Debugging) or until control returns to the program. It’s as if you had pressed the
F8 Continue button on the debugger tool bar.
At each single-step that the debugger makes, it runs the
RSTPDA_SCRIPT_STATEMENT_TRACE script. The script writes each
debuggee-statement that is to be executed to a log.
If the program is long, you will notice the trace activity in the form of extra
waiting time. For that reason, you may want to run the trace script only between
two breakpoints or in conjunction with layer-aware debugging. Set breakpoints
around the code that especially interests you. Start the script at the first
breakpoint. Stop the script and look at the trace when you reach the second
breakpoint.
6. Tell the New ABAP Debugger to stop running the script so that you can take a
look at the trace.
If you have arrived at the next breakpoint, then the debugger has control. You
can tell the debugger to keep running the script or to stop running the script
directly.
 If control has returned to the program that you are debugging, at screen output for
example, then you need to return control to the debugger so that you can stop the
script.

The debugger returns to the foreground, and you can click on Exit Script or
Continue Script.
7. Display the trace in the debugger session or in an internal session by
clicking on Display or Start Analysis in New Session.
 The trace shows every statement that the debugger executed. A double-click on a
line lets you jump into the source code to see the statement in context.

8. Click on F8 Continue to run the debugger further and return control to

the debuggee.

Bonus: Your Second Script - Finding Out Where Particular Statements

Occur
Perhaps you want to find out where AUTHORITY-CHECK statements are executed, so
that you can ask a customer for the required authorizations for debugging a problem. Or
perhaps you want to see where your program is selecting data from the database.
With the statement trace script, these tasks are easy to accomplish.
Proceed by doing the following:
9. Load the RSTPDA_SCRIPT_STATEMENT_TRACE as shown above in steps
1 through 4.
10.Change the Trigger setting from Debugger Single Step to Breakpoint
Reached. Click on the Change button, which has appeared next to
Breakpoint Reached.
11.Create a breakpoint for the SELECT statement, or the AUTHORITY-
CHECK statement, or any other statement you would like to trace.

12. Run the script and take a look at the result, as shown above as of step 6.

As you can see, you can quickly modify a standard script to perform special tasks
in the debugger.