Get Example source ABAP code based on a different SAP table
Warning: Undefined variable $prev in /customers/b/9/9/trailsap.com/httpd.www/sap-help/index.php on line 54
ARTICLE
Kernel Methods For internal use>, kernel methods can be implemented in the ABAP kernel> instead of in the ABAP language.
Introduction Kernel methods allow ABAP kernel functions implemented in C or C++ to be called directly. Kernel methods replace the previous concepts of C calls>> and system calls>. No new C calls> or system calls> need to be introduced. Kernel methods offer the same checks and security features as normal ABAP methods. Except for the Constructors> and the C Destructor>, all ABAP methods can be implemented as kernel methods. An ABAP method can still be redefined as a kernel method and a kernel method can still be redefined as an ABAP method within a path of the inheritance hierarchy. For C developers who want to implement a kernel method, an API> is available that allows simple, high-performance, and secure access to arguments. Class-based exceptions> also continue to be supported.
Defining Kernel Methods
Declaration in ABAP A kernel method is declared in the same way as a normal ABAP method, in Class Builder> or in the declaration section of a local class. Whether a method is implemented as a kernel method is not important for the declaration. In ABAP, this means that a kernel method can be used just like a normal ABAP method.
Implementation in ABAP A method is specified as a kernel method in the implementation part of the class using the optional addition BY KERNEL MODULE kmod1 kmod2 ...> of the statement METHOD>>. kmod1>, kmod2>, ... are the names of kernel modules that implement the method. The ABAP implementation of a kernel method must be empty, which means that there cannot be any ABAP statements between METHOD> and ENDMETHOD>: METHOD meth BY KERNEL MODULE kmod1 kmod2 ...> ENDMETHOD.> Constructors> and the C Destructor> cannot be implemented as kernel methods. There is a separate mechanism for the C Destructor. After ABAP_KEY KERNEL MODULE>, a list of kernel modules kmod1 >, kmod2>, ... can be specified. Currently, only C functions of the kernel can be specified for kmod1>, kmod2>, ... The list after KERNEL MODULE> is evaluated by the compiler from left to right. The first kernel module in the list that is registered in the kernel (see below) is used in the generation. If no valid kernel module is found in the list, a syntax error occurs. There are still two standard C functions that can appear at the end of the list: FAIL> and IGNORE>. If one of these functions is specified at the end of the list, then a syntax error is avoided if the previous list does not contain a valid module. IGNORE> is used to ignore the call of a kernel method of this type (behavior as in an empty ABAP implementation) and, in the case of FAIL>, a handleable exception of the class CX_SY_DYN_CALL_ILLEGAL_METHOD> is raised.
ExamplesMETHOD meth BY KERNEL MODULE xx_impl_630 xx_impl_620 xx_impl_610.> First, the kernel is searched for xx_impl_630. The kernel is then searched for xx_impl_620, and finally for xx_impl_610. If none of these functions are found, a syntax error is raised. METHOD meth BY KERNEL MODULE xx_impl_630 xx_impl_620 FAIL.> First, the kernel is searched for xx_impl_630. Then the kernel is searched for xx_impl_620. If neither of these functions are found, a syntax error is not raised; a handleable exception of the class CX_SY_DYN_CALL_ILLEGAL_METHOD> is raised instead, when the method is called. METHOD meth BY KERNEL MODULE xx_impl_620 xx_impl_610 IGNORE.> First, the kernel is searched for xx_impl_620. Then the kernel is searched for xx_impl_610. If none of the functions are found, a syntax error is not raised; the empty ABAP implementation is called instead, when the method is called.
Implementation in the Kernel Currently, only C functions can be used as kernel modules of kernel methods. The C functions can have any position in the kernel. No special includes from the ABAP runtime environment> are required for implementing the C function. The C functions must have a specific interface. The interface itself is wrapped by a macro> called ARGUMENTS>. All required definitions and prototypes are in the include //src/include/abkmeth.h>. This is the only include needed for defining C functions for kernel methods. Since C functions can be defined in C and C++ , externC> must be used in C++: #include 'abkmeth.h' ... externC void name_of_cmodule( ARGUMENTS ) { ... }> A C function that implements a kernel method must be registered for the kernel method. If, after METHOD meth BY KERNEL MODULE>, the name of a C function is specified that was not registered for the kernel method, a syntax error occurs (as mentioned above). Multiple C functions can be registered for one kernel method. The sequence of the kernel modules kmod1>, kmod2>, ... specified in the list after METHOD meth BY KERNEL MODULE> defines which of the registered C functions is used. This allows downward-compatible further development of kernel methods. To make changes to the registration active, the destination lib> of the project krn/runt> must be recompiled and the kernel relinked.
Registration C functions are registered in the signature file //src/krn/runt/abkmeth.sig> using the following syntax for kernel methods (all ABAP IDs must be specified in uppercase letters): KERNEL_METHOD('CLASS','METH', cfunc,argcnt)> This definition registers the C function cfunc> for the kernel method meth> of a global class class>. The C function expects a number of argcnt> arguments. Kernel methods of local classes in class pools or other ABAP programs are registered using the following macros: KERNEL_METHOD_CLASS_LOCAL('GCLASS','CLASS','METH',cmodule,argcnt)> KERNEL_METHOD_PROGRAM_LOCAL('PROG','CLASS','METH',cmodule,argcnt)> The technique is the same as with KERNEL_METHOD>, except that the global class gclass> must be specified for local classes in class pools and the program prog> for program-local classes.
Registering Arguments All ABAP data objects (such as parameters, attributes, or global data) that are to be accessed in C functions for kernel methods, are treated as arguments of the C function. The argument list of a C function for a kernel method is not limited to the interface parameters of the ABAP method and does not have to contain these completely. Before arguments within C functions are accessed for kernel methods, these arguments must be registered. The argcnt> arguments must be registered immediately after the C function is registered using KERNEL_METHOD>. A single argument is defined (registered) using one of the following macros: ARGUMENT_basetype(index,'name',type_kind,'type',read_write)> ARGUMENT_[C|N|X](index,'name',type_kind,'type',read_write,length)> ARGUMENT_P(index,'name',type_kind,'type',read_write,length,decimals) > ARGUMENT_STRUCT(index,'name',type_kind,'type',read_write,ctype)> These macros> define an argument with the name name> and an index index>. basetype> must be used to assign the type of the ABAP data object in accordance with the following table. If the basetype> is C >, N>, X>, P>, or STRUCT>, more parameters must be specified than for other types. basetype>>ABAP Data Type>Type in C> C>c> with specified lengthSAP_CHAR (*) [Length]> C_GENERIC>c> without specified lengthSAP_CHAR*> X>x> with specified lengthSAP_RAW (*) [Length]> X_GENERIC>x> without specified lengthSAP_RAW*> N>n> with specified lengthSAP_CHAR (*) [Length]> N_GENERIC>n> without specified lengthSAP_CHAR*> P>p> with specified length and decimalsSAP_BCD (*) [Length]> P_GENERIC>p> without specified length and decimals SAP_BCD*> D>d>SAP_DATE*> T>t>SAP_TIME*> INT1>b>SAP_INT1*> INT2>s>SAP_SHORT*> INT8>s>SAP_LLONG*> I>i>SAP_INT*> F>f>SAP_DOUBLE*> DECFLOAT16>decfloat16>DecFloat16> DECFLOAT34>decfloat34>DecFloat34> STRING>string>StrRef*> XSTRING>xstring>StrRef*> TABLE>All table typesTABH_REF*> OBJ_REF>All object referencesObjRef*> DATA_REF>All data referencesFldRef*> STRUCT>All structure typesRegistered type ctype*> ANY>any>void*> DATA>data>void*> SIMPLE>simple>void*> CSEQUENCE>csequence>void*> XSEQUENCE>xsequence>void*> NUMERIC>numeric>void*> CLIKE>clike>SAP_CHAR*> C_POINTER>%_c_pointer>void**> The macro parameters have the following meanings:
name> is the ID for any ABAP data object in uppercase letters that could also be used in an ABAP implementation of the kernel method. In particular, the ID can contain links with component selectors, for example me->attr> or struc-comp>.
index> is a sequential number from 1 to argcnt>. The arguments are accessed using this index.
For type_kind>, either TYPE> or TYPE_REF_TO> can be specified.
type> is the ID for any ABAP data type in uppercase letters that could also be used in an ABAP implementation of the kernel method. type_kind> and type> are used to check the interface of the kernel method in ABAP.
For read_write>, either READ> or WRITE> can be specified. This defines whether reads or writes can be performed on the argument and this setting is evaluated in the access macros.
length> is used to specify the length of all ABAP data types with a generic length for ARGUMENT_[C|N|X|P]>. In characters for c > and n> and in bytes for x> and p>.
When using ARGUMENT_P>, decimals> must be used to specify the number of decimal places>.
When using ARGUMENT_STRUCT>, ctype> must be used to specify a suitable C type>. This type should be generated from an ABAP type definition using saphfile>.
Accessing Arguments After registering the arguments, the following macros can be used to access them within the C function. With the exception of the direct access to the data control block, the access macros do not require any includes from the ABAP runtime environment>. ARGUMENT_basetype_READ(index,'name');> This macro> returns the read address of an argument with the type const ctype>, where ctype> is defined by basetype> according to the above table. The index and name of the argument must be passed. Additional parameters must be specified for the generic types (see below). Only the index is needed to access the argument. However, to make the C function more legible and to ensure that additional consistency checks can be executed, the name must also be specified. If the kernel is compiled in debugging mode, the system executes a consistency check between index and name; the specified C type> and ABAP type of the argument are also checked. In the case of an error, an appropriate ABAP runtime error is triggered ( KMETH_INVALID_ARGUMENT_ID>, KMETH_INVALID_ARGUMENT_NAME>, or KMETH_INVALID_CTYPE_LENG>). No checks are made in the optimized kernel. ARGUMENT_basetype_WRITE(index,'name');> This macro has the same semantics as ARGUMENT_basetype_READ>. However, the system returns the write address. The system also checks whether the argument was defined as a write argument. If a write is performed on a read-only argument (for example, a constant), this triggers the ABAP runtime error KMETH_ARGUMENT_READ_ONLY>. ARGUMENT_[C|N]_READ(index,'name',lengthU);> ARGUMENT_[C|N]_WRITE(index,'name',lengthU);> ARGUMENT_X_READ(index,'name',lengthR);> ARGUMENT_X_WRITE(index,'name',lengthR);> If these macros are used, the expected length in bytes lengthR> or in characters lengthU> must be specified for the generic types c>, x>, and n>. ARGUMENT_P_READ(index,'name',lengthR,decimals);> ARGUMENT_P_WRITE(index,'name',lengthR,decimals);> If these macros are used, the expected length in bytes (lengthR>) and the number of decimal places (decimals>) must be specified for the generic type p>. ARGUMENT_[C_GENERIC|N_GENERIC|CLIKE]_READ(index,'name',size_tU);> ARGUMENT_[C_GENERIC|N_GENERIC|CLIKE]_WRITE(index,'name',size_tU);> ARGUMENT_X_GENRIC_READ(index,'name',size_tR);> ARGUMENT_X_GENERIC_WRITE(index,'name',size_tR);> When using these macros, a variable of the type size_tU> or size_tR>, containing the length in bytes or characters, must be specified for the types C_GENERIC>, X_GENERIC>, N_GENERIC>, and CLIKE>. ARGUMENT_P_GENERIC_READ(index,'name',size_tR,decimals);> ARGUMENT_P_GENERIC_WRITE(index,'name',size_tR,decimals);> If these macros are used, a variable decimals> (for the decimal places>) as well as the length size_tR> must be specified for the type P_GENERIC>. ARGUMENT_STRUCT_READ(index,'name',ctype);> ARGUMENT_STRUCT_READ(index,'name',ctype);> If these macros are used, a suitable C type>ctype> must be specified for all structured types STRUCT>.