Get Example source ABAP code based on a different SAP table
VERSION 5 OUT
Programs in the ABAP_ISESS_L The following figure shows the organization of programs within an ABAP_ISESS > of an ABAP session> in a user session> of an ABAP_ASINSTANCE >.
IMAGE ABDOC_Memory2.gif 504 620
ITOC
Program Groups Multiple programs organized in program groups can be loaded into an ABAP_ISESS . Once an ABAP_ISESS is exited, it is closed. It is then no longer possible to access data and objects of this ABAP_ISESS .
Main Program Group When an ABAP_ISESS is created by calling an ABAP program> using SUBMIT>> or a transaction code>, the main program group is created and the called program is its main program. The entire ABAP_ISESS exists for as long as the main program of the main program group is being executed. This can be an executable program>, a module pool>, or a function pool>.
Additional Program Group Each time a new class pool> or a new function pool> is loaded by external use , an additional program group is created and the class pool or the function pool is the main program of the additional program group. An external usage is usually an access to components that are exposed by class pool or function group (these are the visible components of the global class or function module), however, can also be an access to local components, such as when a type is specified using absolute type names>. An additional program group is preserved for the entire lifetime of the ABAP_ISESS .
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 ABAP_ISESS by a program call (this program is an executable program, module pool, or function pool). The main program of an additional program group is a class pool or a function pool for which the additional program group is created during its loading.
Programs Loaded into a Program Group When programs that are not function pools or class pools are loaded by 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 dynpro statement CALL SUBSCREEN sub_area INCLUDING prog>>, if the dynpro is not defined in a function pool
In dynamic access to a local data type or object type of an executable program, module pool, or a subroutine using absolute type names>
For statements such as SET PF-STATUS OF PROGRAM>>, if the program of the required component is not a function pool.
Latest notes:
To assign a program to a program group, the program-initiating statement> and not the program type> is of importance. For example, if the statement FUNCTION-POOL>> is used in a subroutine pool instead of PROGRAM>>, the program creates an additional program group when it is loaded by external usage.
The assignment of an additional program to its program group is particularly important if procedures of this program are called externally>, since all the programs of a program group use the interface work areas, the dynpros, lists, and GUI status of the main program (see below for more information). ABAP_HINT_END
Data Objects The data objects> of a program, except for the interface work area >, belong exclusively to their program and are only visible there. A loaded program exists for as long as the ABAP_ISESS exists. After returning from a program, its data objects are retained and are available when 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 ABAP_ISESS . An object exists for as long as there are users for and hence references to the object.
Latest notes: This means that references to objects of the ABAP_ISESS can be passed to externally called procedures. ABAP_HINT_END
Interface Work Areas Data objects declared using TABLES>> or DATA BEGIN$|END OF COMMON PART ...>> are interface work areas>. They are only created once per program group and are shared by all programs of a program group together.
Latest notes: The assignment of a program to a program group, and thus the definition of the other programs with which it shares the interface work area, can depend on the usage sequence. ABAP_HINT_END
Dynpros, Lists, and GUI Statuses Only the dynpros> of the main program of a program group can be called using CALL SCREEN >>. After an ABAP_ISESS is loaded, these are the dynpros of the main program of the main program group. The main programs (function pools) 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. By default, SET PF-STATUS>> is used to access the GUI status> of the main program of a program group and uses 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 subroutine, for example, never calls a dynpro of its own compilation unit. The dialog modules and list event blocks of the main program are executed.