ABAP MEMORY

ABAP MEMORY:


A logical memory model illustrates how the main memory is distributed from the view of executable programs. A distinction is made here between external sessions and internal sessions .

An external session is usually linked to an R/3 window. You can create an external session by choosing System/Create session, or by entering /o in the command field. An external session is broken down further into internal sessions. Program data is only visible within an internal session. Each external session can include up to 20 internal sessions (stacks).

Every program you start runs in an internal session.

All "squares" with rounded "corners" displayed in the status diagram represent a set of data objects in the main memory.

The data in the main memory is only visible to the program concerned.

CALL TRANSACTION and SUBMIT AND RETURN open a new internal session that forms a new program context. The internal sessions in an external session form a memory stack. The new session is added to the top of the stack.

When a program has finished running, the top internal session in the stack is removed, and the calling program resumes processing.

The same occurs when the system processes a LEAVE PROGRAM statement.

LEAVE TO TRANSACTION removes all internal sessions from the stack and opens a new one containing the program context of the calling program.

The ABAP memory is initialized after the program is called. In other words, you cannot transfer any data to a program called with LEAVE TO TRANSACTION via the ABAP memory.

SUBMIT replaces the internal session of the program performing the call with the internal session of the program that has been called. The new internal session contains the program context of the called program with which it is performed.

When a function module is called, the following steps are executed:

A check is made to establish whether your program has called a function module of the same function group previously.

If this is not the case, the system loads the associated function group to the internal session of the calling program as an additional program group. This initializes its global data.

If your program used a function module of the same function group before the current call, the function module that you have called up at present can access the global data of the function group. The function group is not reloaded.

Within the internal session, all of the function modules that you call from the same group access the global data of that group.

If, in a new internal session, you call a function module from the same function group as in internal session 1, a new set of global data is initialized for the second internal session. This means that the data accessed by function modules called in session 2 may be different from that accessed by the function modules in session 1.

You can call function modules asynchronously as well as synchronously. To do so, you must extend the function module call using the addition STARTING NEW TASK ''. Here, '' is a symbolic name in the calling program that identifies the external session, in which the called program is executed.

Function modules that you call using the addition STARTING NEW TASK '' are executed independently of the calling program. The calling program is not interrupted.

To make function modules available for local asynchronous calls, you must identify them as executable remotely (processing type: Remote-enabled module).


There are various ways of transferring data between programs that are running in different program contexts (internal sessions). You can use:

(1) The interface of the called program (standard selection screen, or interface of a
subroutine, function module, or dialog module)
(2) ABAP memory
(3) SAP memory
(4) Database tables
(5) Local files on your presentation server.


For further information about transferring data between an ABAP program and your presentation server, refer to the documentation for the function modules WS_UPLOAD and WS_DOWNLOAD.

Function modules have an interface, which you can use to pass data between the calling program and the function module itself (there is also a comparable mechanism for ABAP subroutines). If a function module supports RFC, certain restrictions apply to its interface.

If you are calling an ABAP program that has a standard selection screen, you can pass values to the input fields. There are two options here:

By using a variant of the standard selection screen in the program call
By passing actual values for the input fields in the program call

If you want to call a report program without displaying its selection screen (default setting), but still want to pass values to its input fields, there is a variety of techniques that you can use.

The WITH addition allows you to assign values to the parameters and select-options fields on the standard selection screen.

If the selection screen is to be displayed when the program is called, use the addition: VIA SELECTION-SCREEN.

Use the pattern button in the ABAP Editor to insert a program call via SUBMIT. The structure shows you the names of data objects that you can complete with the standard selection screen.

For further information on working with variants and further syntax variants for the WITH addition, see the key word documentation in the ABAP Editor for SUBMIT.

You can use SAP memory and ABAP memory to pass data between different programs.

The SAP memory is a user-specific memory area for storing field values. It is available in all of the open sessions in a user's terminal session, and is reset when the terminal session ends. You can use its contents as default values for screen fields. All external sessions can access SAP memory. This means that it is only of limited use for passing data between internal sessions.

The ABAP memory is also user-specific, and is local to each external session. You can use it to pass any ABAP variables (fields, structures, internal tables, complex objects) between the internal sessions of a single external session.

Each external session has its own ABAP memory. When you end an external session (/i in the command field), the corresponding ABAP memory is released automatically.

To copy a set of ABAP variables and their current values (data cluster) to the ABAP memory, use the EXPORT TO MEMORY ID statement. The (up to 32 characters) is used to identify the different data clusters.

If you repeat an EXPORT TO MEMORY ID statement to an existing data cluster, the new data overwrites the old.

To copy data from ABAP memory to the corresponding fields of an ABAP program, use the IMPORT FROM MEMORY ID statement.

The fields, structures, internal tables, and complex objects in a data cluster in ABAP memory must be declared identically in both the program from which you exported the data and the program into which you import it.

To release a data cluster, use the FREE MEMORY ID statement.

You can import just parts of a data cluster with IMPORT, since the objects are named in the cluster.

In the SAP memory, you can define memory areas (SET/GET parameters, or parameter IDs), which you can then address by a name of up to 20 characters.

You can fill these memory areas either using the contents of input/output fields on screens, or using the ABAP statement:
SET PARAMETER ID '' FIELD .
The memory area with the name now has the value .

You can use the contents of a memory area to display a default value in an input field on a screen.

You can also read the memory areas from the SAP memory using the ABAP statement GET PARAMETER ID FIELD . The field then contains the value from parameter .

The link between an input/output field and a memory area in SAP memory is inherited from the data element on which the field is based. You can enable the set parameter or get parameter attributes in the input/output field attributes.

Once you have set the Set parameter attribute for an input/output field, you can fill it with default values from SAP memory. This is particularly useful for transactions that you call from another program without displaying the initial screen. For this purpose, you must activate the Set parameter functionality for the input fields of the first screen of the transaction.

You can:

(1) Copy the data that is to be used for the first screen of the transaction to be called to the parameter ID in the SAP memory. To do so, use the statement SET PARAMETER immediately before calling the transaction.


(2) Start the transaction using CALL TRANSACTION or LEAVE TO
TRANSACTION . If you do not want to display the initial screen, use the AND
SKIP FIRST SCREEN addition.

(3) The system program that starts the transaction fills the input fields that do not already have default values and for which the Get parameter attribute has been set with values from SAP memory.

The Technical information for the input fields in the transaction you want to call contains the names of the parameter IDs that you need to use.

Parameter IDs should be entered in table TPARA. This happens automatically if you create them via the Object navigator.

Programs that you call using the statements SUBMIT , LEAVE TO TRANSACTION , SUBMIT AND RETURN, or CALL TRANSACTION run in their own SAP LUW, and update requests receive their own update key.

When you use SUBMIT and LEAVE TO TRANSACTION , the SAP LUW of the calling program ends. If no COMMIT WORK statement occurred before the program call, the update requests in the log table remain incomplete and cannot be processed. They can no longer be executed. The same applies to inline changes that you make using PERFORM … ON COMMIT.

Data that you have written to the database using inline changes is committed the next time a new screen is displayed.

If you use SUBMIT AND RETURN or CALL TRANSACTION to insert a program and then return to the calling program, the SAP LUW of the calling program is resumed when the called program ends. The LUW processing of calling and called programs is independent.

In other words, inline changes are committed the next time a new screen is displayed. Update requests and calls using PERFORM ... ON COMMIT require an independent COMMIT WORK statement in the SAP LUW in which they are running.



Function modules run in the same SAP LUW as the program that calls them.

If you call transactions with nested calls, each transaction needs its own COMMIT WORK, since each transaction maps its own SAP LUW.

The same applies to calling executable programs, which are called using SUBMIT AND RETURN.

The statement CALL TRANSACTION allows you to

Shorten the user dialog when calling using CALL TRANSACTION USING .

Determine the type of update (asynchronous, local, or synchronous) for the transaction called. For this purpose, use the addition CALL TRANSACTION USING UPDATE 'update_mode', where update_mode can have the values a (asynchronous), L (local), or S (synchronous).

Combining the two options enables you to call several transactions in sequence (logical chain), to reduce their screen sequence, and to postpone processing of the SAP LUW 2 until processing of the SAP LUW 1 has been completed.

When you call a function module asynchronously using the CALL FUNCTION STARTING NEW TASK ' ' statement, it runs in its own SAP LUW.

Programs that are executed with a SUBMIT AND RETURN or CALL
TRANSACTION statement starts their own LUW processing. You can use these to perform nested (complex) LUW processing.

You can use function modules as modularization units within an SAP LUW.

Function modules that are called asynchronously are suitable for programs that allow parallel processing of some of their components.

All techniques are suitable for including programs with purely display functions.

Note that a function module called with CALL FUNCTION STARTING NEW TASK is executed as a new logon. It, therefore, sees a separate SAP memory area. You can use the interface of the function module for data transfers.

Example: In your program, you want to call a display transaction that is displayed in a separate window (amodal). To do so, you encapsulate the transaction call in a function module, which you set as to Remote-enabled module. You use the function module interface to accept values that you write to the SAP memory. You then call up the transaction in the function module using CALL TRANSACTION AND SKIP FIRST SCREEN. You call the function module itself asynchronously.

Type ‘E' locks for nested program calls may be requested more than once from the same object. This behavior can be described as follows:
Lock entries from function modules called synchronously increment the cumulative counter, And are therefore successful.

Lock entries from programs called with CALL TRANSACTION or SUBMIT

AND
RETURN is refused. The object to be locked by the called program is displayed as already Locked by another user.

Programs that you call using SUBMIT or LEAVE TO TRANSACTION cannot come into conflict with lock entries from the calling program, since the old program ends when the call is made. When a program ends, the system deletes all of the lock entries that it had set.

Lock requests belonging to the same user from different R/3 windows or logons are treated as lock requests from other users.