If you are an ABAP developer and the terms ABAP for HANA, code push down or database procedures sound interesting for you, then you may have already heard about ABAP Managed Database Procedures (AMDP). This article shortly repeats what AMDP is and explains how to debug AMDP procedures using the new AMDP Debugger – which is now part of the ABAP Development Tools (ADT).
What is AMDP?
The goal of ABAP Managed Database Procedures is to make the world of database procedures available for ABAP Developers. In order to achieve this, AMDP offers a way to create, edit and transport database procedures nearly like standard ABAP classes. With the new AMDP Debugger there is now also debugging support directly integrated in the ABAP tool environment.
Example for an AMDP procedure:
A single AMDP procedure is implemented as an AMDP method and its content is written in a database-specific language like SQLScript. One or more AMDP methods are part of an AMDP class that looks almost like a usual ABAP class. The AMDP methods can be directly called from ABAP in the same way as normal ABAP methods.
During activation of such an AMDP class for every AMDP method one DB procedure is generated on the DB layer. During runtime (when an AMDP method is called from ABAP) the corresponding generated database procedure is executed. For the importing and exporting parameters there is an implicit automatic type mapping.
For more information about AMDP see also:
- The AMDP introduction by Jens Weiler
- The recap of the last AMDP news by Horst Keller
- The official ABAP documentation
- The SQLScript Reference
About the AMDP Debugger
Technical Prerequisites for the AMDP Debugger
- HANA DB SPS9, or higher (SPS 8 with restricted functionality only)
- SAP NetWeaver 7.50, or higher
- ABAP Development Tools 2.51, or higher
To go along with the AMDP concept there is no need for a database user or additional authorizations. You only need your ABAP user with the standard ABAP debug authorization to be able to use the AMDP Debugger.
AMDP Debugger and ABAP Debugger are not identical
ABAP programs and database procedures are executed in different environments during runtime:
- ABAP programs are executed in the ABAP runtime environment on the application server layer (AS ABAP).
- Database procedures – also those generated from AMDP – are executed in the procedure runtime environment on the database layer (e.g. HANA DB).
Therefore the ABAP Debugger, which is also part of the application server layer, cannot simply reach out for the database layer to control the procedure execution in a foreign runtime environment. Instead that is the task of the AMDP Debugger which is in fact a standalone debugger, independent from the ABAP Debugger and technically rooted on the database layer itself.
Since AMDP procedures are directly called from ABAP it was one of the main goals of the AMDP Debugger to offer a smooth transition from ABAP debugging to AMDP debugging and vice versa. Nevertheless it’s still good to keep in mind that there are two different runtime environments / debuggers involved when working with AMDP.
One difference between AMDP Debugger and ABAP Debugger is the fact that the AMDP Debugger has to be started before you can do anything else. If the debugger has not been started your DB procedures will not stop at breakpoints. To deal with this we implemented an automatism within ADT to start the debugger implicitly when a user creates a breakpoint for an AMDP.
Stopping the AMDP Debugger after usage is also important because it is rather resource intensive for the ABAP Server and it’s not affordable to have an active debugger instance for every user in the system all the time. For this reason there are two automatisms to stop the debugger implicitly:
- When a user closes the IDE
- When a user is idle for 10 minutes (timeout)
Besides this the user always has the possibility to start or stop the AMDP Debugger manually. This is for example necessary when you re-open your IDE after closing it and try to start a debug session with your old breakpoints instead of creating new ones.
Since the current activation state of the AMDP Debugger is quite important it is also reflected by the color of the breakpoints:
- Gray – debugger is inactive
- Green – debugger is active, BP is confirmed
- Blue – debugger is active, BP confirmation is pending
Breakpoints are usually only for a very short time blue / pending, often you won’t recognize that state at all.
How to use the AMDP Debugger – Demo
The following video shows how to activate and deactivate the AMDP Debugger, how to perform stepping and variable inspection and how the AMDP Debugger cooperates with the ABAP Debugger.
In order to keep the demo simple I used strongly simplified example code, so don’t be irritated by the fact that the result of the AMDP could also be retrieved by a single line of Open SQL.
Features and Restrictions
As last part of this article you can find here the lists of currently supported features and restrictions (10/2015):
- Change comfortably between ABAP debugging and AMDP debugging
- Create and manage breakpoints in the embedded code of AMDP classes
- Step through procedures using Resume (F8) and Step Over (F6)
- Inspect scalar variable values
- Analyse table variables including sorting and filtering
- The languages SQLScript and Llang can be debugged
- Native DB procedures – that are not generated via AMDP – cannot be debugged
- CDS table functions are not yet supported
- No Step Into (F5) and Step Out (F7) available
- No support for changing variable values
- Variable inspection only for top of stack
- With HDB SPS8 the AMDP Debugger must be restarted after every debug session (not with SPS9+)
Further details and tips
The second part of this article 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 should be sufficient.