Ansicht
Dokumentation

ABENAMDP_PROCEDURE_METHODS - AMDP PROCEDURE METHODS

ABENAMDP_PROCEDURE_METHODS - AMDP PROCEDURE METHODS

Addresses (Business Address Services)   General Data in Customer Master  
This documentation is copyright by SAP AG.
SAP E-Book

- 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 function implementation is indicated as an AMDP method in the implementation part of the class using the addition BY DATABASE FUNCTION 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, however, with respect to the parameter interface of an AMDP procedure implementation:

  • The typing of the parameters must not be generic.

  • 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 data types DF16_SCL or DF34_SCL in the ABAP Dictionary.
  • 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.

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 function and BAdIs but not for table functions and graph workspaces.

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.

Further restrictions may apply depending on the programming language of the database system and these are listed in the corresponding sections:

Notes

  • It is strongly recommended that only the character set 7-bit ASCII is used when implementing an AMDP method.
  • The use of dynamic programming techniques is strongly discouraged, even if supposedly allowed by the programming language of the database system.
  • The existence of other database objects cannot be checked or guaranteed when they are accessed dynamically. This is particularly relevant when other AMDP methods are called.

  • When database tables in the ABAP Dictionary are accessed dynamically, the AMDP framework cannot respect the order of the fields defined here and the order of fields on the database, which might be different, is used instead. This can produce the incorrect values when making assignments to ABAP data objects declared with respect to the ABAP Dictionary.

  • In dynamic accesses, it is not possible to prevent writes from being performed on database tables with activated table buffering, which can cause inconsistencies in buffer synchronizations.

  • Dynamic accesses can lead to SQL injections related to input from outside.

  • When passed to an actual parameter, a null value is passed to its type-dependent initial value.





rdisp/max_wprun_time - Maximum work process run time   Vendor Master (General Section)  
This documentation is copyright by SAP AG.

Length: 11423 Date: 20240420 Time: 112002     sap01-206 ( 86 ms )