GUIDELINE 6.42
Internal and External Procedure Calls
ABAP_BACKGROUND
When a procedure is called, a distinction is made between
internal
and external procedure calls. An internal call calls a
procedure of the same program, whereas an external call calls a
procedure of a different program. The major difference between internal
and external procedure calls is that the program might have to be loaded
first for an external call. With internal calls, the program is already
loaded. Possible external calls, where a program might have to be loade
d, include:
Methods of global classes in class pools
Function modules in function groups
Subroutines in all programs that can contain subroutines (
PERFORM...IN PROGRAM )
Methods of local classes, where the name of the class is dynamically
specified using an absolute type name (\PROGRAM= ... \CLASS=...\)
The programs loaded within an internal session are grouped into
program groups . There is always a main program group and
possibly multiple additional program groups . Each program group
contains a main program and possibly several additional programs (loaded
due to external use). The loaded programs are not always the result of a
call. The reason could also have to do with other references to
components of external programs, such as a reference to a visible data
type of a global class. The loaded programs are not always the result of
a call. The reason could also have to do with other references to
components of external programs, such as a reference to a visible data
type of a global class.
If shared resources of the program group are accessed in an externally
called procedure, the information about which program group the program
was loaded into is very important. Whether a program creates a separate
program group when loaded or whether it is loaded into an existing
program group, largely depends on the program type:
Class pools and function groups (and external calls of global class
methods or function modules) always create a new program group when
loaded.
If subroutines or methods of local classes of other program types (not
class pools and function groups) are called externally, the programs are
loaded into the program group of the calling program.
ABAP_RULE
Only call suitable procedures externally
Only call procedures externally that are intended for external calls.
The methods of global classes and function modules are intended for
external calls. Subroutines and the methods of local classes are not
designed for external calls.
ABAP_DETAILS
The only procedures designed for external calls are the visible methods
of global classes and function modules. The framework programs of these
procedures are always main programs of their program groups and the
procedure always works with the resources of this program group.
However, external calls of subroutines and dynamic calls of methods in
local classes of other programs are problematic. Usually, subroutines
and local classes are intended for internal use within their program.
External calls are not anticipated during the development phase. (On the
other hand, no problems occur when an already loaded program
deliberately passes a reference to an object of a local class to another
program). Therefore, these subroutines and local classes should always
be treated as private components of the program, even though they are
technically public.
In addition, an assignment to a particular program group is not
statically defined. Because the call sequence can depend on user actions
or data contents, the program of the called procedure can belong to the
main program group in one instance and can belong to an additional
program group in another instance. This does not define which program
group the shared resources belong to. The shared resources are:
Classical dynpros (including selection screens and classical lists)
and GUI status
The classical dynpros and GUI status are always shared within a program
group (the classical dynpro and GUI status of the main program in this
program group). For example, the CALL SCREEN statement in an
externally called procedure always calls a dynpro of the main program of
the program group and not a dynpro of the main program of the procedure.
The response to user actions in the dynpro (called as described above)
is also handled in the main program of the program group.
Interface Work Areas
Interface work areas are defined as table work areas using the
TABLES and NODES statements or using the obsolete statement
DATA ... COMMON PART . They are only created once for each program
group and are shared by the main program and the loaded additional
programs.
Latest notes:
Except for the warning regarding dynamic calls of methods of local
classes from other programs, this rule is basically intended to raise
the awareness of problems when using existing programs. In new programs,
the creation of new subroutines and the use of
shared resources are largely obsolete
anyway. The problems mentioned above can only occur if classical dynpros
or selection screens (and therefore GUI status and table work areas) are
used.
Example
The following source code demonstrates how to assign interface work
areas to program groups, in the case of external subroutine calls. The
table work area dbtab declared in sapssubr is shared
either with sapmprog or with saplfugr . If share has
the value 'FUGR' , saplfugr and sapssubr share the
table work area. Otherwise it is shared by sapmprog and
sapssubr . You cannot rely on a specific assignment.
***********************************
PROGRAM sapmprog.
TABLES dbtab.
...
IF share = 'FUGR'.
CALL FUNCTION 'FUNC'.
ENDIF.
...
PERFORM sub IN PROGRAM sapssubr.
***********************************
***********************************
FUNCTION-POOL saplfugr.�
TABLES dbtab.
...
FUNCTION func.
PERFORM sub IN PROGRAM sapssubr.
ENDFUNCTION.
***********************************
***********************************
PROGRAM sapssubr.
TABLES dbtab.
...
FORM sub.
...
ENDFORM.
***********************************
Documentation extract taken from SAP system, � Copyright SAP AG. All rights reserved