The next two Blogs might be a bit boring for you. But that will not hinder me from telling you, which types of memory an ABAP program can access and what kind of data can be addressed there. I will start with the most general memory and will work my way down to the individual ones. If you prefer it another way around, you must read this Blog bottom up.
SAP System
The most general entity we have in an ABAP based SAP world is what was called R/3 System in ancient times. Let’s call it SAP System now. Technically, such a SAP System is based on the SAP Web Application Server ABAP (containing the former SAP Basis), which is part of SAP NetWeaver. From everywhere in such a SAP System, you can access the same persistent data of its central database. But since a SAP System normally runs on several application servers, there is no transient memory that can be accessed from everywhere in the system. For that we have to step one level down.
Application Server
A SAP System is distributed among one or more application servers. On each application server an instance of the SAP System is running. The common memory of an application server is its Shared Memory. Every ABAP program running on an application server has access to the Shared Memory. There are two ways of how you can access the Shared Memory from an ABAP program:
- Before Release 6.40, you could only use the well known EXPORT and IMPORT statements to store and read data clusters in the Shared Memory. With the additions SHARED MEMORY or SHARED BUFFER, data clusters are stored in or read from so called application buffers of the Shared Memory. The two application buffers differ in respect to how the system behaves when reaching the memory limit. Data clusters in Shared Memory are stored in memory tables that reflect the structure of an INDX type database table.
- As of Release 6.40, you can also store and access Shared Objects in the Shared Memory. Shared Objects are instances of shared memory-enabled classes that are stored in an area of the shared memory. An area in the Shared Memory is managed by an area class. The instances of an area class are used as area handles. In an ABAP program, you access an area and its Shared Objects via area handles. For example, a shared object is generated with the addition AREA HANDLE of statement CREATE OBJECT.
User Session
When an user or an application (e.g. via RFC) logs on to a SAP system, he, she, or it connects to a certain application server where an User Session is created. The common memory of an User Session is the so called SAP Memory. ABAP programs have access to SPA/GPA parameters stored in the SAP memory. SPA/GPA parameters (or SET/GET parameters) are set using SET PARAMETER and read with GET PARAMETER. Input fields on dynpro screens can be linked with SPA/GPA parameters. When a screen is called, the default values of such input fields are taken from the SAP Memory. When the screen is left, the field values are stored in SAP Memory (that’s why you always find the name of the last edited program in the input field of the ABAP
Editor SE38). SPA/GPA parameters are managed in the database table TPARA.
Main Session
For each User Session, at least one so called Main Session (or External Session) is created. In dialog processing, one User Session can manage up to six Main Sessions, where each Main Session is connected to a window on the screen. Additional Main Sessions are opened with the GUI function Create a new Session or with the addition STARTING NEW TASK during a remote function call (RFC). The memory area of a Main Session, that can be accessed from several ABAP programs is the so called ABAP Memory. You access the ABAP Memory with the EXPORT and IMPORT statements again. This time, you use the addition MEMORY ID. With that you store or read a data cluster with a specific id in the ABAP Memory. An ABAP Memory and its lifetime is connected to a call sequence. A call sequence is created if you can return from a called ABAP program to the calling ABAP program. The respective statements are SUBMIT AND RETURN and CALL TRANSACTION. All programs of a call sequence have access to the same ABAP Memory. When a call sequence is finished, the respective ABAP Memory is deleted.
Internal Session
For each call of an ABAP program, a so called Internal Session is created in the Main Session. The Internal Session contains all the ABAP program's own data and objects during the execution of the program. That's what you mostly work with! (DATA, CREATE OBJECT and all that stuff!) Other ABAP programs (their
data, and their objects) can be loaded into the same Internal Session via external procedure calls (more about this in the next Blog). An Internal Session lives as long, as its first ABAP Program (the main program) is executed. During call sequences, the respective internal sessions are stacked. You can stack maximally nine internal sessions.
Technical note: From a conceptual point of view it is always OK to speak of “loading programs into an Internal Session”. But technically, each Internal Session is subdivided into PXA and Roll Area. The PXA (Program Execution Area) is a shared memory for the byte codes of all programs running concurrently at any one time on an application server. Only the Roll Area is the memory that is actually reserved for the data and objects of each individual internal session. Just if anybody asks …
