This article provides a summary. The same subject is handled in more detail in the following sections of the extended help:
Memory Structures of an ABAP Program
Organisation of External Procedure Calls
Overview of ABAP Calls
When a user logs on to an instance (application server) in the R/3 System, the system creates a new
terminal session and an external session.
To open another terminal
session, use RFC (i.e. call a function module with
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 R/3 System have access to the system's corresponding database. Thus, the information
stored there is permanently available.
Data that is supposed to be accessible to all terminal sessions
of an R/3 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
SAP memory with SET PARAMETER
and read them from there with GET
PARAMETER.
----------------------------------------------------------------------
|
R/3 System
|
| ------------------------------------------------------------------ |
| ||
Database
|| |
| ------------------------------------------------------------------ |
| ------------------------------------------------------------
----- |
| | R/3 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 on 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 are available in the old state.
When you return
from an internal mode, this mode is destroyed. This means you can no longer access internal program data of a program in this internal mode.
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
Interface work areas (i.e. work areas defined with the
TABLES statement) and common work 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.
Example: Sharing the table work area of DBTAB
--------------------------- ----------------------------
| PROGRAM SAPMPROG. | | FUNCTION-POOL
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.
Only the main program of a program group can display 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 SETPF-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.