SAP NetWeaver AS ABAP Release 740, ©Copyright 2014 SAP AG. All rights reserved.
ABAP Keyword Documentation → ABAP Programming Guidelines → Robust ABAP → Modularization units →Internal and External Procedure Calls
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 loaded, include:
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:
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.
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:
Note
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 andsapssubr share the table work area. Otherwise it is shared by sapmprog and sapssubr. You cannot rely on a specific assignment.