Skip to Content

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.

    Debugger Script Desktop

    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).Selecting a pre-defined script
    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.

      Restart or stop the script

      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.

      Returning control to the debugger

      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.Display the statement traceThe 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.

      A statement trace

    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.Executing a script at breakpoints
    3. Create a breakpoint for the SELECT statement, or the AUTHORITY-CHECK statement, or any other statement you would like to trace.Setting a breakpoint for running scripts
    4. Run the script and take a look at the result, as shown above as of step 6.Trace of statements by type

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

To report this post you need to login first.

18 Comments

You must be Logged on to comment or reply to a post.

  1. Former Member
    Stephen:

    This is so great…I was wondering how the Script debugger was supposed to work since the first time I heard about it…this blog is really great and useful…can’t wait to create my own script -;)

    Greetings,
    Blag.

    (0) 
  2. Former Member
    Stephan ,

    This blog is very useful for pinpointing where the error is .

    But I have one basic requirement in Debugger ( which I am amazed that  the new debugger is not having ).

    Suppose there is an ITAB with 67 lines , I want to delete all except two lines . Currently I dont see any Select all, Deselect all buttons inside data display .

    Am I missing something or Is it not available in the debugger?

    (0) 
    1. Former Member
      Post author
      Hello! 

      You could of course delete lines from an internal table in a script. But the new Table Tool (Tab tables in the new ABAP Debugger) offers a comfortable way to delete selected lines from a table, among other functions.  Just mark the lines you want to delete and select change table from the context menu. There’s docu on the table viewer in help.sap.com EHP2, and there’ll be a blog on this soon too.

      Cheers, Stephen 

      (0) 
      1. Former Member
        Ya thats what I wanted to convey .
        You have to mark 65 lines of the internal table manually  for deletion. But there is no select all/ Deselect all button in the debugger.

        Imagine a case where I need just first two entries of an Internal table which is having 1000 entries . Do I need to mark 998 times ?

        (0) 
        1. Former Member
          Post author
          Hi!

          Ah, I understand. While you can’t do a SELECT ALL, you can do mass deletes by line number. From the context menu, choose Change Table Content and then Complete Table / Delete Line Break.  The table tool opens a dialog box in which you can specify a range of lines to delete.

          Regards, Stephen

          (0) 
    1. Former Member
      Post author

      Hi!

      I had to poke around to find out what NetWeaver Release is under ECC6. I’m afraid that it may not necessarily be the NetWeaver 702 EHP2 release that you need for the new debugger and for scripting. Under one consolidation system for ECC6 I found 700, under another NW 701. So, first check that you have an adequate NW release. Choose System -> Status from any SAPGUI screen and double-click on the component version field to open the table of installed components. Look for the SAP_BASIS component and check whether 702 or higher is shown in the Release field. If yes, you’re golden. Then, make sure that you have the new debugger switched on. In SE80, open Menu Utility > Settings and switch to the ABAP Editor tab, and within that, to the debugging tab. There, you can choose between the classic and the new debugger. You need the new debugger, of course. Finally, with the debugger running, make sure that you scroll the tab strip all the way to the right. The Script tab is the very last of the tabs…  Hope that this will help!

      Cheers, Stephen

      (0) 
      1. Former Member

        Hi Stephen,

        Thanks a lot for your reply. I check our system and too bad, the component SAP_BASIS has only 701 Release. 🙁 … That’s the main reason then why I dont have the “Script” tab in my debugger mode. 🙁

        Do you have any idea on how to upgrade to 702 Release for this component?

        Thanks in advance…

        (0) 
        1. Former Member
          Post author

          Hi!

          The component that needs to be updated is NetWeaver itself, the kernel executables and the SAP_BASIS component that you can see in System > Status. I’m afraid I don’t know if the upgrade from 701 to 702 EhP2 is allowed for ECC6. If it’s possible to do the upgrade, then there is a lot to speak for it from the NW side – it’s the most significant ABAP release in years – with the new debugger, a great many advances in the ABAP language itself, and a lot of progress is SE80 and the ABAP editor. BTW, you can download a trial NW 7.31 from SCN if you want to take a look at 702 and the progress since then. I have one running on my laptop.

          Cheers, Stephen

          (0) 
          1. Former Member

            Hi Stephen,

            Thank you so much for this information and for your kind help to enlighten me with my concern.

            god bless you always.

            truly yours,

            levi palmer

            (0) 
          2. Former Member

            Hi Stephen,

            Thank you so much for this information and for your kind help to enlighten me with my concern.

            god bless you always.

            truly yours,

            levi palmer

            (0) 
    1. Former Member
      Post author

      Hi!

      I had to poke around to find out what NetWeaver Release is under ECC6. I’m afraid that it may not necessarily be the NetWeaver 702 EHP2 release that you need for the new debugger and for scripting. Under one consolidation system for ECC6 I found 700, under another NW 701. So, first check that you have an adequate NW release. Choose System -> Status from any SAPGUI screen and double-click on the component version field to open the table of installed components. Look for the SAP_BASIS component and check whether 702 or higher is shown in the Release field. If yes, you’re golden. Then, make sure that you have the new debugger switched on. In SE80, open Menu Utility > Settings and switch to the ABAP Editor tab, and within that, to the debugging tab. There, you can choose between the classic and the new debugger. You need the new debugger, of course. Finally, with the debugger running, make sure that you scroll the tab strip all the way to the right. The Script tab is the very last of the tabs…  Hope that this will help!

      Cheers, Stephen

      (0) 
  3. Joachim Rees

    I know this is from 2010, still I think it helped me starting to get an Idea of how powerful debugger scripting is.

    One take away for me is that there are lots of ready-to-use scripts, which seem to be a good starting point.

    (Last time I tried to look into debugger scripting, I think I tried starting with writing a script from scratch, which might no be the best way).


    Thanks a lot!

    Joachim

    (0) 
  4. praveen kumar mannala

    Nice Post Stephen.

    i am able to work on it only in development client. in the testing client, script wizard button is disabled. Is there any setting we need to do in quality to activate the scripting. may be i am asking a simple question ? i could not find any answer when I googled. Thanks for your time.

    (0) 
    1. Michael Bennett

      Hi,

      My understanding / experience is system has to be open for coding changes allowable. So via SCC4 you have to allow changes to repository objects. It could also be you have to set modify options for namespaces and components. At least I had to do this if wanted to edit a script in “test” or “production” system. If you think about it I guess it is risk to allow any code to be created in a debug script if it is not controlled similar to other ABAP objects. So of course you can always create a script in development system and transport it like other objects.

      Regards,

      Michael

       

      (0) 

Leave a Reply