ARTICLE
Programs in the Internal Session
The following figure shows the memory organization within an
internal session :
Program Groups
In an internal session it is possible to load multiple programs that can
be organised in program groups. After returning from an internal
session, this is dismantled. It is then no longer possible to access
data and objects of the internal session.
Main Program Group
During the creation of an internal session using the
call of an ABAP program using
SUBMIT or a
transaction code , the main program group is created and the called
program makes up its main program. The internal session exists for as
long as the main program of the main program group is executed. This can
be an executable program , a
module pool , or a
function group .
Additional Program Group
Every time that a new class pool or a new
function group is loaded by an
external usage, an additional program group is created and the class
pool or the function group is the main program of the additional program
group. An external usage is usually an access to components exposed
(visible components of the global class or function module) by the class
pool or function group. However, it can also be an access to local
components, such as in a type specification using
absolute type names . An additional
program group exists for as long as the internal session exists.
Main Program of a Program Group
The first program loaded of a program group is the main program of this
group. The main program of a main program group is the first program
loaded into the internal session due to a program call (executable
program, module pool, or function group). The main program of an
additional program group is a class pool or a function group whose
loading results in the forming of the additional program group.
Programs Loaded into a Program Group
When programs that are not function groups or class pools are loaded
because of an external usage, they do not form additional program
groups, instead they are loaded into the program group of the user. This
happens for example:
during the external call of subroutines that are defined in executable
programs, module pools or subroutine pools
when using the screen statement CALL SUBSCREEN
sub_area INCLUDING prog , if the screen is not defined in a
function group
during dynamic access to a local data type or object type of an
executable program, module pool, or a subroutine using
absolute type names
with statements such as SET PF-STATUS
OF PROGRAM , if the program of the necessary component is not a
function group.
Notes
It is not the program type that is
important for the assignment of a program to a program group, but the
introductory program statement
. For example, if the the statement
FUNCTION-POOL is used in a subroutine pool instead of
PROGRAM , when the program is loaded by an
external usage it forms an additional program group.
Since all the programs of a program group use the interface work area,
the screens, lists, and GUI statuses of the main program (more below),
the assignment of a program that is loaded into a program group is
particularly important if procedures of this program are
called externally .
Data Objects
The data objects of a program, with the
exception of the interface work area
, belong exclusively to their program and are only visible there. A
loaded program exists for the same length of time as the internal
session. After returning from a program, its data objects are retained
and are available if a procedure of the
program is called again.
Class Instances
Objects as instances of classes can be used by all programs (and
objects) of an internal session. An object exists for as long as there
are users for (and hence references to) the object.
Note
This means that references to objects of the internal session can be
transferred to externally called procedures.
Interface Work Areas
Data objects declared with TABLES or
DATA BEGIN|END OF COMMON PART ... are
interface work areas . These are
only created once per program group and are used by all programs of a
program group together.
Note
The assignment of a program to a program group, and thus the
determination of which other programs it shares the interface work area
with, can depend on the usage sequence.
Dynpros, Lists, and GUI Statuses
Only the dynpros of the main program of a
program group can be called using CALL SCREEN
. After an internal session is loaded, these are the dynpros of
the main program of the main program group. The main programs (function
groups) of additional program groups can also call their own dynpros.
Lists are always assigned to the current
dynpro sequence and therefore also to
the main program of the program group.
As standard, SET PF-STATUS is
used to access the GUI status of the main
program of a program group and use its data objects for dynamic texts.
All programs of a program group work with the dynpros, lists, and GUI
status of the main program by default. A statement CALL SCREEN in
an externally called subprogram, for example, never calls a dynpro from
its own framework program. The dialog modules and list result blocks of
the main program are executed.
Documentation extract taken from SAP system, � Copyright SAP AG. All rights reserved