Debugging is a methodical process of finding and reducing the number of bugs, or defects, in a computer program or a piece of electronic hardware, thus making it behave as expected. Debugging tends to be harder when various subsystems are tightly coupled, as changes in one may cause bugs to emerge in another. Many books have been written about debugging, as it involves numerous aspects, including interactive debugging, control flow, integration testing, log files, monitoring (application, system), memory dumps, profiling, Statistical Process Control and special design tactics to improve detection while simplifying changes. Description by Wikipedia.
Debugging in SAP is a solid bit of control every Abap developer needs to master to work the system. Functional consultants can also benefit from these articles...
Working on something your teamlead doesn't know about ? Produced a dump in the process ? How do you explain a dump on your own hobby coding ? Dump removal.
The debugger may well be the most sophisticated bit of software SAP has ever produced. Like every bit of SAP, the debugger has undergone a lot of upgrades. From version 6.40 there is a Classidc debugger and a New Abap debugger. The main difference is the way the debugger shows: the New Abap debugger presents itself in a new session, which allows more insight with less impact on the program that is being debugged. These articles are all about the New Abap Debugger.
Why debug ? Without the debugger you will be guessing what is happening in your program. The debugger will explain in crystal clear facts what happens and when it happens. Debugging has a very high "Ah, right" factor.
The debugger shows everything there is to show in a running program, which is very dependent on where the current position in the program is. Debugging can also be used to alter the report behavior, without changing it's coding. When an authorization check is done, the outcome could be negative, in the debugger this outcome could be cleared, making the report continue as if the check passed. Hence debugging with change authorization is a bit of a no-no in production systems. Actual changes are logged in system logs, so there are ways to work out what happened - make sure you check this when trying to solve a production issue you can not reproduce.
Break-points and watch-points are the ways to involve the debugger. A break-point can be set in the Abap code of interest, in several ways. In the Abap editor, look up the coding you want to see and select the "Break-point" icon (Stop!) which will show a stop sign left of the line. Only Abap coding which is in fact executable can hold such break-point (don't place your break-point on a comment line or a data definition). Note that this type of break-point is "personal" and client-dependant. It will remain until you remove it (from the debugger or Abap editor) or you log off. You will also note that debugging is a multi session matter. Place the break-point in the editor in a session, run the report in another session to invoke the debugger. You will need to restart the report you are debugging.
When a report or module dumps, the reason is mostly quite obvious. Some runtime errors are "catchable", but when not caught they will stop your report. If you are the user causing the dump, there is a "Debug" button available to you to start the debugger.
Brief summary of (common) runtime errors - in alphabetical order, with an explanation. Could help you get rid of the cause.
Using a select option range variable in a selection has a limitation. It adds to the size of the select option statement, which can cause the DBIF_RSQL_INVALID_RSQL dump. Specifically for "The maximum size of an SQL statement was exceeded" So how could that be done ? Simply put too many lines in a range variabele, by e.g. uploading values from a file or calling the statement with a range variabele that was automatically composed.
Found a problem ? It is not very likely that you are the first person to find that very problem. Whatever it is, we are all covering a lot of SAP topics and there are blogs and OSS notes about many many faults issues and problems. For OSS (Online Service System) you will need an access key on https://service.sap.com/notes. But you will find a lot of useful information in http://scn.sap.com or even sites like this one as well.
The debugger can be invoked from every screen that has a command window. Simply type /H and the debugger will be invoked.
In practice this is only useful if the debugger capabilities to set break-points is utilized. Debugging Abap coding from the PAI (Process After Input) from a screen can be a truly painfull brain breaker. Pressing enter on a screen in a transaction, could involve stepping through thousands of lines of Abap coding.
In some cases the debugging needs to be "picked up" from an external call, such as from a Portal user or an inbound RFC call. When you are using portal functionality or the system is being called through an RFC call, the external debugging is your answer: invoke the debugger triggered from the outside world. Even for a user-ID other than your own. How ? Read on..
If you notice that the things you are debugging behave strangely, values are assigned and the debugger won't tell you where or how, or actions are done and you have debugged the whole thing without a trace of how the action was done, this is one to check out. The system is delivered in many components, and SAP has helped us developers to avoid having to plough through these standard components. So in effect, your debugging session should not be too bothered or influenced with coding that is exected as part of "the system".
Smartforms can also be debugged, or rather: the Abap coding that is backing the Smartform can be debugged. To do this a bit of background on how Smartforms are composed is relevant. When a form is composed, abap logic can be involved in a few ways: the initialization block of the smartform, a routine pool, but also the coding blocks which are set up in the Smartform itself all play along. All of this Abap logic is held in a generated function module, which is available for debugging purpose like any other function module.
If the report you are checking is running for a very long time - where would you put your break-point ? Run transaction SM50 - "Process overview" and find the report that is running (while it is running of course). From this transaction the debugger can be invoked: menu Administration > Program > Debugger. From here it should be quite easy to find out why the report is taking so long. An endless loop ? A while with a condition that is never met ?
To invoke the debugger, you will need to put the /h into the command box, which is only available on main screens (modal windows). So how to invoke the debugger in popup screen (popup window) ? Use a SAPGUI shortcut.
When you are trying to debug a "system program" - which can be identified on the program attributes: status field, the system could be throwing a message at you: "Breakpoints in system programs are only observed in system debugging ". Make sure you don't set this status to your own programs. It makes debugging a bit tricky.
The debugger allows changing values of variables, when you are authorised to do so. This feature ia also available for internal tables. In fact: you can save your internal table to your desktop, have your way with it in Notepad and upload it again. Not entirely smootly though.
Break-points can also be hardcoded, as there is a statement BREAK-POINT in our abap vocabulary. Hardcoded break-points are client independent, which is a feature that makes them useful in systems where the development client and test client are separated. You can set the break-point in the coding you are editing, and the test run in the test client will invoke it.
Debugging and activity logging can also be done using "Dynamic break points". These are break points that are added to ABAP coding ("hardcoded") which can be controlled via the Checkpoint groups tool, transaction SAAB
If you're working an area that sometimes requires special debugging attention, you will (like me) find that not all issues are easily reproduced in a test/development environment. This article will take debugging to another level - closer to using it in a production environment.
Breakpoints van also be added as valid only when a condition is checked: conditional breakpoint. First place a breakpoint and get your report to stop. From the debugger the context menu has the option "Create breakpoint condition".
In a development environment the debugger is a great tool, but it has it's limits: when the debugging needs to be done in a background process the actual debugging session cannot address an end-user (the developer in this case). Or when it's performance info the needs to be "logged". Debug information to a logging file...
As a blue-print description: A simple program that can be called from other programs via a perform call. It logs a message and allows viewing of the log, as well as removing the log.
If you are doing a debug session on standard SAP coding, you should be aware of a few things: if it is an error you are looking for, check the web first - as you are not likely the first person to encounter the error. And what will you do when you find the error? Fix it ? Apply a SAP modification ? You have to understand where your coding is in the grand scheme of things, before ploughing through SAP's thousands of lines of coding just to find out there is nothing you can do about it. So how can the call stack help ? What is a call stack ?
Macro's can be a great help in making your coding more readable and I'm very much in favor of using them. Their use should be warranted, by the repetitive nature of the logic you want to capture in the macro. Defining a macro with DEFINE my_macro. and END-OF-DEFINITION. is in fact an abap editor prepration step. When the abap program is executed, macro's are resolved and the coding that is eventually executed no longer contains macro's. Thus a macro is not a languange element, it is an editing/editor feature.