Get Example source ABAP code based on a different SAP table
ABAP_AMDP - Procedure Implementations An AMDP procedure implementation is an AMDP method for implementing a database procedure. It is declared in an AMDP class like a regular static method or instance method in any visibility section. An AMDP procedure implementation cannot be identified as an AMDP method in the declaration part of the class. An AMDP procedure implementation is indicated as an AMDP method in the implementation part of the class using the addition BY DATABASE PROCEDURE of the statement METHOD. At the same time, the database system where the method is to be used and the programming language of the database system used to implement the method are also defined. The database objects of the current database schema accessed in the AMDP method must be declared using an addition USING. If possible, the syntax check is performed on the basis of this information. When database tables defined in the ABAP Dictionary are accessed, and the access is known statically, the AMDP framework ensures that the order of the fields defined in the dictionary is respected, which can differ from the order on the database. The following restrictions apply with respect to the parameter interface of an AMDP procedure implementation:
The typing of the parameters must not be generic.
Only elementary data types and table types with a structured row type can be used.
The row type of a tabular type can only contain elementary data types as components.
A parameter must not have an enumerated type and must not have a component with an enumerated type.
A parameter must not be typed with a data type that references one of the obsolete built-in DDIC data types DF16_SCL or DF34_SCL.
The parameters must be declared for pass by value using VALUE. Pass by reference is not allowed.
Return values must not be declared using RETURNING.
Only input parameters can be flagged as optional parameters.
Each elementary optional input parameter must have a replacement parameter declared using DEFAULT. Only literals or constants can be specified as replacement parameters.
Unlike in regular methods, a literal specified as a replacement parameter must be convertible to the data type of the input parameter. If not, a syntax error occurs.
Input parameters of the types string, xstring, decfloat16, and decfloat34 cannot have replacement parameters and hence cannot be optional.
An optional tabular input parameter cannot have any replacement parameters and must be made optional instead using OPTIONAL.
Parameter names:
Parameter names cannot start with the characters %_.
The parameter name connection can only be used for an input parameter of type DBCON_NAME, if the name of the database connection can be passed to the input parameter.
The parameter name client is reserved for future enhancements.
The parameter name endmethod is not allowed.
RAISING can be used to specify the exceptions specified under AMDP -Exception Classes to handle these classes for a call. Other exceptions cannot be handled. No non-class-based exceptions can be created using the addition EXCEPTIONS. BEGIN_SECTION VERSION 5 OUT AMDP methods can be called with database hints, that is, an additional importing parameter with the name call_hints can be defined. The parameter must be passed by reference and must have the type TT_HINT of interface CL_AMDP_CALL_HINT. It can be optional. If used, ABAP callers can pass a list of hints and hint parameters to the AMDP method. Currently, only the hint parameters route_to and workload_class are supported. Hint parameters must consist of the characters a - z, A - Z, 0 - 9, and _. All other names must be enclosed in pairs with ' or '. If the hint parameters are not correct, the method terminates with the catchable exception AMDP_CALL_HINT_ILL_PARAM. Note that the parameter can be specified for database procedures, scalar functions, and BAdIs but not for table functions and graph workspaces. END_SECTION VERSION 5 OUT The following restrictions apply to method implementation:
An AMDP method must not be empty.
DDL statements are not allowed for creating, changing or deleting database objects.
No statements are allowed that are only possible in database tables and not in views, such as TRUNCATE TABLE or LOCK TABLE.
Local temporary database objects cannot be accessed.
Executing transactional statements is not allowed. In particular, no database commits and database rollbacks using COMMIT and ROLLBACK statements are allowed. This also applies to called procedures. LUWs should always be handled in the ABAP program to ensure data consistency between procedures.
Writes cannot be performed on database tables where table buffering is switched on, since SQLScript accesses are ignored by buffer synchronizations.
AMDP methods do not have any implicit enhancement options.
