ARTICLE
Program Groups in External Procedure Calls
The programs 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. In an external procedure call, it is important to
know the program group of the framework program of the procedure, if the
procedure accesses shared resources of the program group. This causes
non-critical and critical external procedure calls.
Non-Critical External Procedure Calls
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.
Note
For this reason, only call the methods of global classes and function
modules.
Critical External Procedure Calls
Subroutines and the methods of local classes are not designed for
external calls. There is no static assignment to a program group in
external subroutine calls or in dynamic calls of the local class of a
program that does not form its own program group. The program in which
an unloaded program is used for the first time determines the program
group. The order of user actions, field contents, or switches can
determine the order of the programs, which means that the framework
program of the procedure can be in the main program group in one
instance, and in an additional program group in another instance.
The usage of external procedures of additional programs is critical for
the following reasons:
Within a program group, only the screens ,
selection screens ,
lists , and GUI
statuses of the main program are used. For example, the statement
CALL SCREEN does not call any screens of
its own framework program in an externally called subroutine of an
additional program; instead, it calls a screen of the main program of
its program group. The reaction to user actions also takes place in the
main program.
Interface work areas that you
declare using the TABLES ,
NODES , or DATA BEGIN OF COMMON PART
statements exist once only in each program group, and are shared by all
of its programs. Each main program is shared by the additional programs
of the interface work areas.
Therefore, there is no static way of defining which interface work areas
and which screens are used by an externally called subroutine or local
class. The following figure shows how programs are added to program
groups, using the example of an external subroutine call.
Subroutines and methods of local classes must always be called
internally and never externally.
Note
The text elements of an added program
are always taken from its own text pool .
Example
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 .
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