Ansicht
Dokumentation

CALL interface
Tip-No.: 26 ( INFO26 )

Short text

CALL interface
Tip-No.: 26

Symptom

C functions can be called from ABAP programs. These are linked
in the SAP System.

Cause

See solution.

Solution

Syntax:
CALL function name ID id1 FIELD f1 ID id2 FIELD f2 ...
The function to be called must introduced to the system over file
sapactab.h. This file can only contain entries in the form:
SAPACDEF (function name, function)
for comments. As the first parameter, the name of the function must
be specified here (as a string) as it is used in the ABAP program.
The second parameter is the (address of the) function to be called.
Example:
SAPACDEF ( "TEST", test )
makes a function "test" callable from ABAP program under the
name "TEST".
Die functions to be called must be of type
int (void)
The return value of the function is rejected SY-SUBRC. The parameters
to be transferred are not transferred as C-transfer parameters, but
must be fetched from the called function via calls from "ab_pfetch"
itself.
Example:
ABAP:
DATA P(10).
CALL 'TEST' ID 'PARA1' FIELD P.
IF SY-SUBRC = 1.
...
C:
#include "saptype.h"
#include "abcall.h"
int test()
€
SAP_BYTE * ptr;
SAP_USHORT length;
ptr = ab_pfetch( 'PARA1", TYPC, &length );
€
/* ptr points to ABAP variable P,
* length hats contents 10.
*/
...
õ
return 1; /* -> SY-SUBRC */
Function ab_pfetch ('parameter fetch') is of type
SAP_BYTE * ab_pfetch ( char * parameter_name,
int parameter_type,
SAP_USHORT * length_pointer )
It has 3 parameters:
1. The name of the transfer parameter as (zero-terminated) string.
2. The type of variables. This must agree with the transferred
variables. Type macros TYPC, TYPX, ... are defined in abtypes.h
and can be introduced to the program via "#include abcall.h".
3. An output field of type SAP_USHORT, in which the length of the
field is placed by ab_fetch.
Function ab_fetch returns the address of the transferred field as
return value (or ZERO, if the search field does not exist).
The address is set properly (important for TYP FLOAT).
It is generally not allowed when functions that are called via the call
interface possess static memory (the programmer should at least know
exactly what he/she is doing).
Furthermore, the following is not allowed (for example):
- commit/rollback calls
- malloc calls (or similar)
Storage can be obtained via rstg_get, but must be findable again
via ZTTA entries.
a) rstg_get with type=PERM, pointer in the ZTTA
This storage is work process-specific.
b) rstg_get with type=ROLL, pointer in the SPA
This storage is user and mode-specific.
Before the next screen change ( == rollout), all possible
contacts to the operating system: especially all multi-step
actions such as:
open .. close
fopen .. fclose
opendir .. closedir
getserverbyname , ...
getpwent , ...
Operations such as umask, renice, ... refer to the work
process and not to the user.