Kernel Methods For internal use>, kernel methods can be implemented in the kernel instead of in ABAP.
Introduction As of Release 6.20, kernel methods allow you to directly call kernel functions implemented in C or C++. Kernel methods replace the previous concepts of C Calls> and System Calls>. After Release 6.20, no new C calls or system calls should be introduced. Kernel methods offer the same checks and securities 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 the C developer, who wants to implement a kernel method, an API > is available that allows simple, high-performing, and secure access to arguments. Class-based exceptions> also continue to be supported.
Defining Kernel Methods
Declaration in ABAP A kernel method is declared like a normal ABAP method, in the Class Builder> or in the declaration section of a local class. It is completely irrelevant fro the declaration that a method is declared as a kernel method. In ABAP, a kernel method can therefore be used just as a normal ABAP method.
Implementation in ABAP You define a method as a kernel method by using the optional addition KERNEL MODULE kmod1 kmod2 ... to the METHOD> statement in the implementation section of the class.kmod1>, kmod2>, ... are the names of the kernel modules that implement the method. The ABAP implementation of a kernel method must be empty, that is 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>, you can specify a list of kernel kmod1>, kmod2>, ... You can currently only specify C functions of the kernel 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, a syntax error occurs if the previous list does not contain a valid module. With IGNORE> the call of such a kernel method is ignored (behavior as with empty ABAP implementation) and in the case of FAIL the exception that can be handled of the class CX_SY_DYN_CALL_ILLEGAL_METHOD> is raised.
Examples METHOD meth BY Kernel MODULE xx_impl_630 xx_impl_620 xx_impl_610.>
First the system searches in the kernel for l xx_impl_630>. Lastly, the system searches for xx_impl_610>. If none of the functions are found, a syntax error occurs. METHOD meth BY Kernel MODULE xx_impl_630 xx_impl_620 FAIL.>
First the system searches in the kernel for xx_impl_630>. Lastly, the system searches for xx_impl_620>. If none of the functions are found, a syntax error occurs and when the method is called, the exception that can be handled of the class CX_SY_DYN_CALL_ILLEGAL_METHOD> is raised. METHOD meth BY Kernel MODULE xx_impl_620 xx_impl_610 IGNORE.>
First the system searches in the kernel for xx_impl_620>. Lastly, the system searches for xx_impl_610>. If none of the functions are found, no syntax error occurs and when the method is called, the empty ABAP implementation 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 of 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 the macro> ARGUMENTS> All necessary 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++ , you must use externC > 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>, you specify the name of a C function that was not registered for the kernel method a syntax error occurs (as mentioned above). You can register several C functions for a 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. So that changes to the registration become active, you must recompile the destination lib> of the project krn/runt> and relink the kernel.
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 capital 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)>
The technique is the same as with Kernel_METHOD>, except that you must specify the global class gclass> for local classes is 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 you access arguments within C functions for kernel methods, these arguments must be registered. The argcnt> arguments must be registered immediately after the C functions are 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)>
With these macros> an argument is defined with the name name> and an index index>. With basetype> you must assign the type of the ABAP data object according to the following table. If the basetype> is C>, N>, X>, P>, or STRUCT>, you must specify more parameters than for other types. basetype>ABAP data type>Type in C> C>c> with length specificationSAP_CHAR (*) [Length] > C_GENERIC>c> without length specificationSAP_CHAR* > X>x> with length specificationSAP_RAW (*) [Length] > X_GENERIC>x> without length specificationSAP_RAW*> N>n> with length specificationSAP_CHAR (*) [Length] > N_GENERIC>n> without length specificationSAP_CHAR* > P>p> with length and decimal specification SAP_BCD (*) [Length]> P_GENERIC>p> without length and decimal specification SAP_BCD*> D>d>SAP_DATE*> T>t>SAP_TIME*> I>i>SAP_INT*> F>f>SAP_DOUBLE*> STRING>string>StrRef*> XSTRING>xstring>StrRef*> INT2>s>SAP_SHORT*> INT1>b>SAP_INT1*> 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 following applies for the macro parameters:
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 continuous number from 1 to argcnt>. The arguments are accessed using this index. For type_kind> you can specify either TYPE> or TYPE_REF_TO>. type> is the ID (in upper-case) for any data type in ABAP 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> you can specify either READ> or WRITE >. This defines whether you can read or write access the argument and is evaluated in the access macros. For ARGUMENT_[C|N|X|P]> you use length> to specify the length of all ABAP data types with generic length (for C and n> in characters, for x> and p> in bytes). For ARGUMENT_P> you use decimals> to specify the number of decimal places>. For ARGUMENT_STRUCT> you use ctype> to specify a suitable C type. This type should be generated from an ABAP type definition using saphfile>.
Accessing Arguments After registering the arguments, you can use the following macros to access them within the C function. With exception of the direct access to the data control block, the access macros do not require any includes of 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. For the generic types you must specify additional parameters (see below). You only need the index to access the argument. However, to make the C function more legible and ensure that additional consistency checks can be executed, you must also specify the name. 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, a corresponding ABAP runtime error is triggered ( KMETH_INVALID_ARGUMENT_ID>, KMETH_INVALID_ARGUMENT_NAME>, or KMETH_INVALID_CTYPE_LENG>). No checks are executed 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 you try to write access a write-protected 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);> With these macros you must specify the expected length in bytes lengthR> or in characters lengthU> for the generic types C>, X>, and N>. ARGUMENT_P_READ(index,'name',lengthR,decimals);>
ARGUMENT_P_WRITE(index,'name',lengthR,decimals);> With these macros you must specify the expected length in bytes ( lengthR>) and the number of decimal places (decimals>) 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);> With these macros you must specify a variable of the type size_tU> or size_tR>, containing the length in bytes or characters, 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);> With these macros you must specify a variable decimals> (for the decimal places>) as well as the length size_tR> for the type P_GENERIC>. ARGUMENT_STRUCT_READ(index,'name',ctype);>
ARGUMENT_STRUCT_WRITE(index,'name',ctype);> With these macros you must specify a suitable C type ctype> for all structured types STRUCT>. ARGUMENT_C_POINTER(index,'name');>
This macro> is available specifically for the type %_C_POINTER>. This type is a special internal ABAP type that has exactly the byte length of a C pointer (4, 8, or 16 bytes, depending on platform). The type is always mapped to the predefined ABAP type X>. The macros for the type X> or X_GENERIC> are not used due to the variable length and platform-dependency. ARGUMENT_IS_SUPPLIED(index,'name');>
This macro has the same semantics as the logical expression IS SUPPLIED> in ABAP. The same consistency checks are executed as for ARGUMENT_READ>. ARGUMENT_DATA(index,'name',ctype);>
This macro returns the data control block with the C type const DATA *>. The same consistency checks are executed as for ARGUMENT_READ >. The macro is only active if the include //src/include/abdata.h > of the ABAP runtime environment > was included.
Raising Exceptions C functions that implement kernel method can raise class-based exceptions>.
Registering Exceptions The relevant global> exception classes must be registered with an