Page 1 of 6

ABAP Managed Database Procedures – A beginners guide

Last Updated by Margit Wagner

So what are ABAP Managed Database Procedures? Similar to kernel methods, stored procedures
are encapsulated in special ABAP methods with a regular method interface but the body
implemented in SQLScript instead of ABAP.
The syntax for the implementation of this special ABAP method can be seen in the example below:
METHOD my_meth
BY DATABASE PROCEDURE FOR <db-type> LANGUAGE <db language>
[OPTIONS <options>]
[USING <names>].
-- Here comes native SQLScript now.
-- The SQLscript syntax rules apply,
-- e.g. '--' indicates a comment
-- the ABAP comment symbol >"< would lead to an error

ENDMETHOD.
Let’s talk about the additions seen in the syntax above.
•BY DATABASE PROCEDURE indicates, that this method does not carry ABAP code and will not
be executed in the ABAP Virtual Machine, but instead on the database level
•The obligatory addition FOR <db-type> defines the database type for which this stored procedure
is valid for. Right now, a database procedure can only be assigned for one DB vendor, and only
HANA (value "HDB") is supported.
•The mandatory addition LANGUAGE <db language> defines the implementation language for the
database procedure. Currently only SQLSCRIPT is allowed.
•The optional addition OPTIONS is used to declare database specific options for a database
procedure. The only option allowed at the moment is read-only, (which maps to the "reads sql
data" security privilege).
•USING <names>. All database objects that are used inside the method body, must be declared in
advance. This declaration is required for tables, views and any database procedures called within
the AMDP method.
One ABAP class can have multiple definitions of database procedures. The class can consist of
both ordinary ABAP methods and methods as database procedures.
AMDP methods can be called (from ABAP code) via the CALL METHOD statement, like any other
ABAP method.
Since not all aspects of ABAP class methods can be mapped one-by-one to database procedures,
several restrictions apply to the method definition of AMDP methods:

https://jam2.sapjam.com/wiki/show/rf327FFusTtlCMJEss7AtZ?print=true 06-12-2019
 Page 2 of 6

•AMDP methods can only be created in global ABAP classes

•A special marker interface must be included in the ABAP class, IF_AMDP_MARKER_HDB
This marker interface is not only required for technical reasons, but it simplifies the search for any
ABAP classes which contain AMDP methods.
•Method parameters can have scalar types or (flat) table types - no structures or deep tables can be
used as parameter types.
•Parameters need to be passed by value
Since the data of the parameters is transferred to a different execution engine, similar restrictions as
to RFC enabled function modules are applied here. This means that the method parameters need
to be declared "pass by value" and no data or object references are allowed.
•No returning parameters allowed – only IMPORTING, EXPORTING and CHANGING (changing
parameters are mapped to “inout” procedure parameters)
•Only constant default values for method parameters.
Similar to ordinary ABAP methods, default values can be defined for procedure parameters, but
whereas in ABAP, system-variables such as SY-DATUM for example could be used, they are not
possible for AMDP method parameters.
• Defining optional parameters without a default value is not supported

•Reserved Parameter names CLIENT and CONNECTION.

The parameter names CLIENT and CONNECTION cannot be used as future usages for these
parameter names are planned
So the class definition part might look something like this:

CLASS zcl_amdp_class DEFINITION PUBLIC FINAL CREATE PUBLIC.

PUBLIC SECTION.

INTERFACES if_amdp_marker_hdb. "<-- marker interface is mandatory

TYPES: type2 type standard table of <flat_structure> with default key.
METHODS dbmeth IMPORTING VALUE(i_param1) TYPE type1 "<-- always pass by value
EXPORTING VALUE(e_param2) TYPE type2 "<-- refer to ABAP type
system
CHANGING VALUE(ch_param3) TYPE type3.

ENDCLASS.

https://jam2.sapjam.com/wiki/show/rf327FFusTtlCMJEss7AtZ?print=true 06-12-2019
 Page 3 of 6

As you know, ABAP classes are used to realize the concepts of object orientation in the ABAP
language. SQLScript is not an object oriented language, and so its important to note the following
points:
•Visibility control with PRIVATE/PROTECTED/PUBLIC.
ABAP classes support visibility control for methods, i.e. method X can only be called, if the caller Y
is allowed to do so. If the caller Y is implemented in ABAP, the full ABAP rules apply. Due to the
forward declaration (with the USING clause) of any procedures to be called, the static checks of the
ABAP compiler also apply to methods written in SQLScript, and so the visibility control of ABAP is
brought to the level of database procedures.
•Interfaces.
If a class X implements the interface Y, a method of Y can be realized as database procedure.
•Static and instance methods.
Both static as well as instance methods can be used as database procedures. (Although static
methods better fit to the semantics on the database level).
•Method redefinition.
A method M in class X can be redefined in class Y as a database procedure.
•The methods CONSTRUCTOR and CLASS-CONSTRUCTOR
Neither of these special methods can be defined as a Database Procedure.

Inside the AMDP method body, plain SQLScript syntax is allowed. This has the following
implications:
•The syntax check of the method body (i.e. the actual logic of a database procedure) is done on the
database level. So developing a database procedure for HANA on a system running on MaxDB is
like flying blind J
•There is no full translation of the SQLScript delimiters for statements or comments to the ABAP
environment. So in the method body,
• statements are to be delimited with <;>and not with <.> (as in ABAP)
• a comment to the line end is <-- >and not <"> (as in ABAP)
• There is one exception to this rule. The ABAP comment with<*> in the first column is
translated into a <-->comment on the database level. (However, it is recommended not to use
this kind of comment ).

Modularization
For many purposes it is sensible to split large database procedures into smaller units. ABAP
managed database procedures support modularization in the same way as you know it from the
ABAP language. The method METH of class CL_CLASS has the absolute name
CL_CLASS=>METH, hence this method can be called using
CALL METHOD CL_CLASS=>METH( ) from any other piece of ABAP code.
ABAP managed database procedures reuse the absolute ABAP name for the database procedure,
so if method CL_CLASS=>METH is tagged as a database procedure, a database procedure of

https://jam2.sapjam.com/wiki/show/rf327FFusTtlCMJEss7AtZ?print=true 06-12-2019
 Page 4 of 6

exactly the same name will be created. The SQLScript statement CALL is then used to call the
database procedure with this name.
Example:
class zcl_amdp_example1 implementation.

method abc
by database procedure for hdb language sqlscript options read-only using table1 .

-- SQLScript code here

endmethod.

method xyz
by database procedure for hdb language sqlscript options read-only
using zcl_amdp_example1=>abc.

call "ZCL_AMDP_EXAMPLE1=>ABC"
( iv_parm1 => iv_parm1,
et_parm2 => et_parm2 );

-- More SQLScript code here

endmethod.

endclass.

Editing ABAP managed database procedures

As ABAP managed database procedures are realized as ABAP class methods, the ABAP class
editor is the tool used to create and edit them.
Similar to the development of Database procedure proxies and CDS views, ABAP Development
Tools is the environment of choice. (Viewing of AMDP methods is possible in the ABAP
Workbench, but creation/change should be done in ADT).
One very important feature is the embedded syntax-check for the SQLScript, which goes beyond
the level of native SQL (either ADBC or EXEC SQL). The syntax-check for database procedures is
done by a test creation of the database procedure in a "different namespace". The error result

https://jam2.sapjam.com/wiki/show/rf327FFusTtlCMJEss7AtZ?print=true 06-12-2019
 Page 5 of 6

message of this test creation is mapped back to the origin code position in the ABAP code,
providing the feeling of an integrated development environment.

However, not all features of the ABAP Editor are supported for ABAP managed database
procedures:
•Pretty printer support (Shift+F1)
The pretty printing logic will skip over all code that is marked as a database procedure.
•Forward navigation support (F3):
Currently there isn’t complete support for forward navigation from a caller database procedure to a
called database procedure.
•Where Used List (Crtl+Shift+G):
Not all callers of a called database procedure are found with the where used list functionality
From ABAP code to a Database Procedure - Generation of DB artefacts
Each method marked as a database procedure, will end up as a stored procedure at the database
level.
In addition, some other objects are created as well:
•Global temporary tables to support the transfer of table-like input and output parameters
•A view for database tables to ensure that "SELECT *" will work in SQLScript as expected from the
ABAP perspective
•A helper procedure ("stub") that ensures proper source code management and correct invocation
with named parameters of the actual database procedure
So how exactly is the database procedure created?
Mapping of the Method Definition Parts:

ABAP Syntax Remarks HANA Syntax

USING <used db objects> n/a

METHODS parameter clause is derived from [(<parameter_clause>)]

<method_name> method definition (i.e. statement
<parameters> METHODS)

METHOD <method_name> Name mapping: <proc_name> = CREATE PROCEDURE

BY DATABASE to_upper <proc_name>
PROCEDURE ( <class_name>=><method_name> )

LANGUAGE SQLSCRIPT AMDP: Currently restricted to [LANGUAGE SQLSCRIPT |

SQLSCRIPT LLANG]

ENDMETHOD END
 

https://jam2.sapjam.com/wiki/show/rf327FFusTtlCMJEss7AtZ?print=true 06-12-2019
 Page 6 of 6

[OPTIONS READ-ONLY] [READS SQL DATA

<procedure_body> identically passed through <procedure_body>

Exception: ABAP Comments at line
begin (*) will be translated to HANA
comments (--)

Parameter mapping:
The parameters in the method definition are translated one-by-one to the procedure definition with
the following logic:

ABAP HANA

Importing in

Changing inout

Exporting out

For all table like parameters, a HANA datatype (transfer table) is created and used in the procedure
definition
All ABAP types are mapped to HANA types.
Source code mapping
In general the code between the ABAP statements METHOD and ENDMETHOD is passed mainly
unconverted into the procedure definition.
Transfer Tables
Transfer tables are used whenever table-like parameters are used.
•They act as a data container.
Since the database procedure invocation call from a client (such as HANA studio or the ABAP
server) doesn’t support table-like procedure parameters, a workaround has to be used. The content
of input parameters is pushed into the transfer table and the procedure is called with this content.
•They act as the type definition.
The transfer tables are technically "global temporary tables", which is the most suitable table type
for this operation. The ABAP runtime clears the tables after the procedure call. The handling of the
transfer tables is done in the same DB session as the actual procedure call.
The transfer tables are generated for each table-like parameter with the naming pattern [class
name]=>[method name]=>[parameter name]#tft.

https://jam2.sapjam.com/wiki/show/rf327FFusTtlCMJEss7AtZ?print=true 06-12-2019