Kontakt

Ansicht
Dokumentation

ABENINTERNAL_SESSION - INTERNAL SESSION

ABENINTERNAL_SESSION - INTERNAL SESSION

RFUMSV00 - Advance Return for Tax on Sales/Purchases   CL_GUI_FRONTEND_SERVICES - Frontend Services  
This documentation is copyright by SAP AG.
SAP E-Book

Programs in the Internal Session

The following figure shows the organization of programs within an internal session of an ABAP session in a user session of an .

IMAGE @@ABDOC_Memory2.gif@@504@@620@@

Program Groups

Multiple programs organized in program groups can be loaded into an internal session. Once an internal session is exited, it is closed. It is then no longer possible to access data and objects of this internal session.

Main Program Group

When an internal session 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 internal session 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 internal session.

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 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
  • In dynamic access to a local data type or object type of an executable program, module pool, or a subroutine using absolute type names

Notes

  • 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).

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 internal session 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 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 passed to externally called procedures.

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.

Note

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.

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 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.






SUBST_MERGE_LIST - merge external lists to one complete list with #if... logic for R3up   CL_GUI_FRONTEND_SERVICES - Frontend Services  
This documentation is copyright by SAP AG.

Length: 8533 Date: 20240424 Time: 182827     sap01-206 ( 117 ms )