Organization of Data Areas of Programs

Terminal sessions, sessions and program groups

When a user logs on to an instance ( application server) in the SAP system, the system creates a new terminal session and an external session.
To open another terminal session, use RFC (function module call using Remote Function Call: CALL FUNCTION ... DESTINATION ).
To create another external session, choose System -> Create session, enter "/o..." in the OK-code field or use an asynchronous RFC (function module call through CALL FUNCTION ... STARTING NEW TASK).

All users within this SAP system have access to the system's corresponding database. The information stored there is therefore permanently available.
Data that is supposed to be accessible to all terminal sessions of an SAP instance can be exported to the shared application buffer using EXPORT TO SHARED {BUFFER|MEMORY} and imported from the buffer using IMPORT FROM SHARED {BUFFER|MEMORY}.
If you want to keep small amounts of data across several external (and internal) sessions, or pass the data between these sessions, you can write these amounts to the SAP memory with SET PARAMETER and read them from there with GET PARAMETER.

----------------------------------------------------------------------
|                             SAP System                             |
| ------------------------------------------------------------------ |
| ||                           Database                           || |
| ------------------------------------------------------------------ |
| ------------------------------------------------------------ ----- |
| |            SAP Instance (Application Server)             | |...| |
| | -------------------------------------------------------- | |   | |
| | ||         Shared Application Buffer                  || | |   | |
| | ||  (EXPORT/IMPORT/DELETE...SHARED {BUFFER|MEMORY})   || | |   | |
| | -------------------------------------------------------- | |   | |
| | -------------------------------------------------- ----- | |   | |
| | | |          External Mode               | |...| | |   | | |   | |
| | | | ------------------------------------ | |   | | |   | | |   | |
| | | | ||          ABAP Memory           || | |   | | |   | | |   | |
| | | | || (EXPORT/IMPORT/FREE...MEMORY)  || | |   | | |   | | |   | |
| | | | ------------------------------------ | |   | | |   | | |   | |
| | | | ------------------------------ ----- | |   | | |   | | |   | |
| | | | |  Internal Mode (Roll Area)   |...| | |   | | |   | | |   | |
| | | | |                         D -----> | | |   | | |   | | |   | |
| | | | -----------------------------| |---- | |   | | |   | | |   | |
| | | |                                   C -----> | | |   | | |   | |
| | | |--------------------------------------| |---- | |   | | |   | |
| | |                                             B -----> | | |   | |
| | |------------------------------------------------| |---- | |   | |
| |                                                       A -----> | |
| |----------------------------------------------------------| |---- |
|                                                                    |
|--------------------------------------------------------------------|
A: CALL FUNCTION ... DESTINATION
B: CALL FUNCTION ... DESTINATION 'NONE'
C: Function in System menu or "/o..." in the command field
D: CALL TRANSACTION, CALL DIALOG, SUBMIT ... AND RETURN

To create a new internal session, you can call a transaction (with CALL TRANSACTION), call a dialog module (with CALL DIALOG), or submit a report (with SUBMIT ... AND RETURN). These commands load the relevant program. For one external session, there can be up to nine internal sessions. These are managed in a stack.
The system manages a roll area for each internal session. This is where the data areas of the used programs are created. It is also in this data area that the transient objects of ABAP Objects exist.
You can write data that you want to keep or pass across several internal sessions to ABAP memory with EXPORT TO MEMORY and read it from there with IMPORT FROM MEMORY. The ABAP memory is only available until the first transaction is ended.
Objects of ABAP Objects can only be used within their internal mode. Therefore, it does not make sense and is forbidden from a syntactical point of view to pass an object reference to a program called using the ABAP memory.

When you open an internal session, you create the main program group.
If you call a function module belonging to a function group not yet loaded (with CALL FUNCTION), the system creates an additional program group. The same is true when loading a class by addressing it for the first time with CREATE OBJECT or by accessing a static class component.
The first program of a program group is known as the main program.
All programs and objects of an internal mode can use the objects of ABAP Objects of the same internal mode. This means that you can pass object references within an internal mode to external procedures (subroutines, function modules, and methods).

When you return from an additional program group, this group is retained. If you navigate again to a program in this additional program group, its data is available in the previous state.
When you return from an internal session, this session is destroyed. This means you can no longer access internal program data of a program in this internal session.

If you call an external subroutine (with PERFORM form(prog) or PERFORM form IN PROGRAM prog), the system loads the relevant program and adds it to the (main or additional) program group of the calling program, as long as it has not already been loaded.
However, if the subroutine is in a function group that has not yet been loaded, the system behaves as with CALL FUNCTION and creates a new program group.

---------------------------------------------------------
|                    External Mode                      |
| ----------------------------------------------------- |
| ||                  ABAP Memory                    || |
| ||      (EXPORT TO MEMORY/IMPORT FROM MEMORY)      || |
| ----------------------------------------------------- |
| ----------------------------------------------- ----- |
| |       Internal Mode (Roll area)             | |...| |
| | ------------------------------------- ----- | |   | |
| | | Main or Additional Program Group  | |...| | |   | |
| | | --------------------------- ----- | |   | | |   | |
| | | |    (Main-) Program      | |...| | |   | | |   | |
| | | |                      F -----> | | |   | | |   | |
| | | --------------------------| |---- | |   | | |   | |
| | |                                E -----> | | |   | |
| | ------------------------------------| |---- | |   | |
| |                                          D -----> | |
| ----------------------------------------------| |---- |
|                                                       |
---------------------------------------------------------
D: CALL TRANSACTION, CALL DIALOG, SUBMIT ... AND RETURN
E: CALL FUNCTION, Loading a class
F: PERFORM form(prog), PERFORM form IN PROGRAM prog

Common data areas

Interface work areas (variables created using TABLES or NODES) and common data areas with the same name (defined with DATA BEGIN/END OF COMMON PART ...) are created only once for each program group and then shared by all programs in the program group. Classes do not have interface work areas.

• The assignment of these data areas to the main program of the program group is fixed the first time a function module or external subroutine is called.
  Any subsequent calls made by other program groups do not alter the assignment determined by the first call.

• Therefore, the main program of the program group with which the program calling the external subroutine shares the data depends on the exact sequence of calls!

Example: Sharing the table work area of DBTAB

---------------------------    ----------------------------
| PROGRAM SAPMPROG.       |    | FUNCTIONPOOL SAPLFUGR.  |
| TABLES DBTAB.           |    | TABLES DBTAB.            |
| ...                     |    | ...                      |
| IF SHARE = 'FUGR'.      |    |                          |
|   CALL FUNCTION 'FUNC'. |    | FUNCTION FUNC.           |
| ENDIF.                  |    |   PERFORM SUB(SAPSSUBR). |
| PERFORM SUB(SAPSSUBR).  |    | ENDFUNCTION.             |
---------------------------    ----------------------------
               ---------------------------
               | PROGRAM SAPSSUBR.       |
               | TABLES DBTAB.           |
               | FORM SUB.               |
               |   ...                   |
               | ENDFORM.                |
               ---------------------------

In this example, no separate memory area is reserved for the work area of the table DBTAB of program SAPSSUBR.
If the value of SHARE is 'FUGR', SAPLFUGR and SAPSSUBR share the table work area. Otherwise, SAPMPROG and SAPSSUBR share this area.

Assignment of screens, lists and user interfaces

Only the main program of a program group can display its screens. When you create a main program group and open an internal session, only the main program has screens initially.
The main program of an additional program group may also have screens temporarily, but only if a screen is called for display ( CALL SCREEN) from within the additional program group.
Lists always belong to the program which has screens. Modules and events must also be contained in this program.
A list system, consisting of a basic list and all details lists belonging to the basic list, is always assigned to exactly one screen level.

Similarly, the statement SET PF-STATUS (without the addition OF PROGRAM) activates a status from the CUA interface of the main program in a program group. When you open a new internal session, its interface is initially "empty" (i.e. only the System and Help menus are displayed); you have to activate your own user interface with the SET PF-STATUS statement.
If the interface contains dynamic texts for menus or pushbuttons, the system searches for the relevant variables only in the program to which the interface belongs.