New ABAP Debugger: Advantages of Two-Process Architecture

The classic debugger runs on the same internal mode (role area) of the same main mode (external mode) as the application that is to be analyzed, however the new ABAP Debugger uses an additional main mode and is displayed in a separate SAP GUI window (two-process architecture). The application to be tested (debugee) is controlled by the ABAP Debugger.

The use of a common session has certain handling advantages as well as advantages with regard to resource consumption. However, the advantages that arise through this narrow link between the application and the Debugger clearly outweigh any advantages.

There are certain interactions between the application and the Debugger that enable only very limited options for the layout of the user interface in the classic Debugger. The user interface of the new Debugger, on the other hand, can be configured as required so the user can design the user interface to suit his requirements.
Program units called directly from the ABAP kernel cannot be analyzed with the Classic Debugger. Such calls, for example, take place at each conversion exit.
The classic Debugger analyzes a roll area that, when canceled, itself cancels the classic Debugger. Therefore, all the existing settings, such as the display of variables in the classic Debugger, disappear as soon as the limits of the roll area are exceeded –for example, if the statements SUBMIT or CALL TRANSACTION are called. On the other hand, the new Debugger analyzes an external session. As long as this external session is active, the Debugger will remain open and control this session.

This graphic is explained in the accompanying text.

For this reason, the user will switch - during a Debugger session - from the Debugger to the application window if the application requires a user action. Here, of course, the Debugger window is not ready for input in this state. If input on pages of the application is complete and the program is still running, the Debugger window is ready for input again as soon as the next interruption is reached. If the input focus changes from the Debugger to the application and vice versa, the window that is ready for input is automatically placed in the foreground by the Graphical User Interface (GUI).

In the following graphic, the Debugger is started by entering /h. It remains active until control passes back to the application as a consequence of a user action. The Debugger receives control again when a breakpoint is reached or when the application explicitly activates the Debugger using /h. The application session is then subject to the control of the Debugger session until the application session is closed or the Debugger session is cancelled explicitly using /hx.

This behavior is especially useful when analyzing roll-area-independent programs in debug mode. While a new roll area is opened, the same instance of the Debugger remains open and all settings, such as the arrangement of tools or list of displayed variables, are unchanged.

This behavior could be detrimental if you do not wish to close the Debugger explicitly, but instead want the Debugger to be closed automatically at the end of a roll area, such as after choosing F8 (Continue) as a Debugger command (this is how the Classic Debugger behaves). You can define this behavior in the new ABAP Debugger using the main menu: Settings Debugger Settings Continue to F8 and Roll Area End .

This graphic is explained in the accompanying text.

For more information, see: New and Classic ABAP Debugger: Main Differences