This action might not be possible to undo. Are you sure you want to continue?
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 AUTHORITYCHECK, 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
check or trace them as you wish. a script is the better tool. But the point of ABAP Debugger Scripting is to increase your efficiency in analyzing and solving problems with the New ABAP Debugger. But for tracing data generation or checking data consistency as your debuggee runs. ABAP scripts take advantage of the twoprocess debugging infrastructure that SAP introduced in NetWeaver NW04s (7. But ABAP Debugger Scripting also lets you save scripts for re-use. 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. ○ Analyze and display data from complex data structures (internal tables with nested objects. what you can do with a debugger script is limited only by your requirements and imagination.) 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. such as checking data consistency. And transaction SAS offers a comfortable workplace for developing scripts away from the pressure of an active debugging session. and you can share these scripts with others on the same or on other ABAP Systems. write a trace or break execution when you find the bad data return. . The wizard lets you insert method calls to debugger services in your script. The classical example is an internal table with nested objects whose attributes you want to check. ○ Program (interactive) tools for standard tasks. A script can read those nested attributes row by row. And there is also a script wizard for writing your own scripts (or modifying ready-to-run scripts). You can develop tools or utilities for debugging to suit your special needs. See the weblog on advanced scripts for more information. 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.0). 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. Of course. and even stop execution if something goes wrong. 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). 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. changing variable values to test error handling.returned data in your script. An ABAP script is simply a local ABAP Objects program that is run by the New ABAP Debugger.
like dumping the data from a complex data source to a trace. Plus you can use the method calls from the Script Wizard. 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. After every statement is executed ○ . the script runs only if you press the Start Script button. To the left of the editor.As you can see. You can easily move scripts between systems by downloading them to file and then uploading them again. This is the right option if you are using a script for a single specific task. (See the weblog on advanced scripts). The Trigger options have the following meanings: ○ Execute directly: If you mark this option. The debugger does not run the script automatically. then the debugger automatically runs the script after every debugger single step (F5 – Single Step in manual debugging). these let you make use of the services of the New ABAP Debugger. so that you can find them again). you can specify when the ABAP Debugger should run the script – for example. After Debugger Events – Debugger Single Step: Once you tell the debugger to run the script (with Start Script). after every single execution step in the debugger. You can load a script from the library or from a collection of your own scripts (use a naming convention.
in interactive use of the Debugger). the debugger runs the script every time a breakpoint or watchpoint is reached. 3. Here’s how to create a complete trace of executed statements using ABAP Debugger Scripts. Start a program in the New ABAP Debugger. After your script has stopped running. /h ok-code – you can start a debugger script from any point in a program’s execution.Breakpoint Reached. Watchpoint Reached: With these options. On the list of ready-to-run predefined scripts. in the context of the script. 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. for example. ○ After Debugger Events . Important: The script runs only when the debugger reaches breakpoints and watchpoints defined here. Click on the very last Debugger Tool tab: Script. an icon appears that allows you to define breakpoints and/or watchpoints for triggering the script. It’s immaterial how you reach the debugger – by breakpoint. in the source code editor. Click on the Load Script button and then on the Overview of Debugger Scripts icon. . you can use the buttons in this frame to display the trace (if any) created by the script. If you check one of these Trigger options. you had to step through a program yourself in the debugger to see exactly what a program does. 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. 2. 1.by the debugger. open the Traces folder and double-click on the last script. At the bottom of the screen (not shown in the screen shot) is the Display Last Trace frame. The script is inserted into the script editor – it’s ready to run. This is the Trigger setting for a full statement-level trace of execution. the script runs again. But before ABAP scripting. 4. RSTPDA_SCRIPT_STATEMENT_TRACE. The script does not run at breakpoints or watchpoints that you may have set separately. 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.
Tell the New ABAP Debugger to stop running the script so that you can take a look at the trace. The script writes each debuggee-statement that is to be executed to a log. It’s as if you had pressed the F8 Continue button on the debugger tool bar. If you have arrived at the next breakpoint. If the program is long. At each single-step that the debugger makes. Set breakpoints around the code that especially interests you. you will notice the trace activity in the form of extra waiting time. then the debugger has control.5. 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. Tell the New ABAP Debugger to run the script by clicking on the Start Script button. . you may want to run the trace script only between two breakpoints or in conjunction with layer-aware debugging. 6. Stop the script and look at the trace when you reach the second breakpoint. You can tell the debugger to keep running the script or to stop running the script directly. For that reason. Start the script at the first breakpoint. it runs the RSTPDA_SCRIPT_STATEMENT_TRACE script.
Display the trace in the debugger session or in an internal session by clicking on Display or Start Analysis in New Session. and you can click on Exit Script or Continue 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. The debugger returns to the foreground. 7.
these tasks are easy to accomplish. Proceed by doing the following: 9. Click on the Change button. which has appeared next to Breakpoint Reached.Change the Trigger setting from Debugger Single Step to Breakpoint Reached.The trace shows every statement that the debugger executed.Finding Out Where Particular Statements Occur Perhaps you want to find out where AUTHORITY-CHECK statements are executed. 8. Or perhaps you want to see where your program is selecting data from the database. A double-click on a line lets you jump into the source code to see the statement in context. With the statement trace script. Load the RSTPDA_SCRIPT_STATEMENT_TRACE as shown above in steps 1 through 4. . Click on F8 Continue to run the debugger further and return control to the debuggee. Bonus: Your Second Script . so that you can ask a customer for the required authorizations for debugging a problem. 10.
As you can see. 12.11. as shown above as of step 6. you can quickly modify a standard script to perform special tasks in the debugger. . Run the script and take a look at the result.Create a breakpoint for the SELECT statement. or the AUTHORITYCHECK statement. or any other statement you would like to trace.
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue reading from where you left off, or restart the preview.