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.

Here is the video on ABAP Debugger Scripting Basics;

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 in NW 7.0 EHP2.)
  • 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.

  

  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:

  1. Load the RSTPDA_SCRIPT_STATEMENT_TRACE as shown above in steps 1 through 4.
  2. Change the Trigger setting from Debugger Single Step to Breakpoint Reached.  Click on the Change button, which has appeared next to Breakpoint Reached.
  3. Create a breakpoint for the SELECT statement, or the AUTHORITY-CHECK statement, or any other statement you would like to trace.
  4. 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.