In this second part of the AMDP debugging article I would like to provide some additional details and tips for the work with AMDP procedures and ADT. This is probably only relevant for you if you actually work with AMDP or plan to do so in the near future. If you only want to get an overview the first part of the article should be sufficient.
More Details about AMDP Debugging
During the execution of AMDP procedures every procedure of the call hierarchy runs either in debug mode or in optimized mode:
- Optimized mode improves performance by using mechanisms like parallelization, inlining and others. These optimizations can potentially interfere with debugging. One unusual but simple example would be a read-only procedure without any exporting parameters. Since such a procedure can never have any effect it’s not executed at all in optimized mode and therefore breakpoints within this procedure cannot be reached.
- Debug mode will prevent such optimizations. Additionally only procedures in debug mode will recognize breakpoints that are newly created during an active debug session. Its drawback is that the procedure must be recompiled in debug mode during breakpoint creation or debugger start and this can become time consuming for large procedure hierarchies.
The decision regarding which procedures run in debug mode and which in optimized mode can be influenced by the Compile in Debug Mode setting. It can be changed in the properties of your ADT project under ABAP Development -> Debug:
- Only procedures containing breakpoints: Breakpoint creation and debugger start is faster but can have optimization side-effects. (Default, necessary for very large procedures / call hierarchies)
- All called procedures: No side-effects but can cause long waiting time for breakpoint creation or debugger start up. (Recommended for small procedures / call hierarchies)
Breakpoints get the status pending (blue) when they are valid but the procedure is not yet ready to be debugged because it must be recompiled in debug mode. Once procedure compilation has finished the associated breakpoints will get the status confirmed (green).
Procedures that are running in optimized mode are gray colored in the call stack. If you select an optimized procedure in the call stack the exact code position of the call cannot be determined, therefore it will navigate to the start of the procedure.
Differences to other DB procedure debuggers
This section originates from my personal knowledge of a rather wide and complex domain, so please do not fully count on its correctness or completeness.
Currently there are three different development environments that you can use to develop database procedures, depending on your requirements and use cases:
- As you know ADT is an eclipse based IDE and offers DB procedure development via the described AMDP concept
- HANA Studio is also an eclipse based IDE for the development of HANA native applications and it enables you to create database procedures directly as HANA artifacts
- HANA Web-based Development Workbench is a lightweight web-based alternative for HANA Studio
ADT and its AMDP Debugger are tailored for the ABAP context and therefore cannot be used to debug native DB procedures (procedures that are not generated from AMDP). To debug native DB procedures you have to use one of the other two alternatives.
HANA Studio and HANA Web-based Development Workbench however can be used to debug AMDP indirectly via debugging the generated DB procedures. Sometimes this can be a bit confusing, especially since ADT and HANA Studio are both eclipse based tools and can run side by side within the same eclipse installation.
The used debugger then depends on the position of the breakpoint:
- Creating a breakpoint in the AMDP class itself, that means the ABAP class that contains the embedded code, addresses the AMDP Debugger
- Creating a breakpoint in the generated DB procedure addresses the HANA Studio Procedure Debugger
Although every environment comes with its own procedure debugging front end they all use the same core functionality on the DB layer.
Terminate vs. Disconnect
To cancel an active debug session you can use the functions terminate or disconnect:
- Disconnect: Stops only the debugger itself, the debuggee (= the procedure that you are currently debugging) is released and continues its execution. That means the code after your current position will be executed.
- Terminate: Stops the debugger and the debuggee. The processing of the database procedure will be canceled and no further code will be executed.
Please note that your current selection in the debug view is relevant. In Eclipse these kind of actions always refer to the debug entity that is currently selected in the debug view.
Debug for a different user
If you have to debug the process of a different user then you can use the same setting as for the ABAP Debugger (It’s shared). You can find it in the properties of your ADT project under ABAP Development -> Debug.
Further tips for working with AMDP
The following features can potentially make the work with AMDP procedures in ADT more comfortable.
Background color for embedded languages
To highlight the parts of your class that contain embedded code like SQLScript choose the ADT menu “Window” -> “Preferences”. In the preferences popup choose “General” -> “Appearance” -> “Colors and Fonts”. Within the Colors and Fonts preference page choose “ABAP” -> “Syntax Coloring” -> “Embedded Language”.
Group breakpoints by type
In the breakpoints view you can group your breakpoints by type using the pulldown menu (small white triangle).
Use the AMDP Preview
If you want to quickly check the results of a certain AMDP procedure or just execute it (e.g. to trigger the debugger) you can use a tool called AMDP Preview. To open it expand the relevant AMDP class in the project explorer, open the context menu for the relevant procedure and choose “Run As” -> “Data Preview” (see first screenshot). Once opened you can enter own ABAP code in the area between “begin custom code” and “end custom code” in order to provide importing parameters for the procedure. Since custom ABAP code is executed here you need to have developer authorization. When you ensured that the importing parameters will be supplied correctly you can finally press the run button to execute the procedure and see the results on the right half of the tool.
Data Preview Pin
Once you have opened a table variable in the data preview during debugging an AMDP you can pin the current variable to this view using the pin button (see screenshot). When you now double click another table variable you can see that another instance of the data preview will be opened. You can use this to compare table values or to keep an eye on multiple table variables during stepping.