Get Example source ABAP code based on a different SAP table
VERSION 5 OUT
SPA/GPA Parameters in the User Memory The user memory is a user-specific memory area of the current ABAP_ASINSTANCE , which can be accessed by all ABAP sessions of a user session simultaneously. ABAP programs have access to SPA/GPA parameters stored in the user memory (also referred to as <(>SET/GET<)> parameters). ITOC
Properties of SPA/GPA Parameters Each SPA/GPA parameter is identified by an ID of up to 20 characters. SPA/GPA parameters can either be created explicitly using the statement SET PARAMETER, or implicitly in a PAI event and are available to any programs and any sessions for the whole duration of a user session after they have been saved in the user memory. SPA/GPA parameters are usually evaluated by the ABAP runtime framework. In ABAP programs, they can be read using the statement GET PARAMETER.
Example ABAP Coding
An example of a program that uses SPA/GPA parameters is the user maintenance (transaction SU01). In this transaction, user-specific parameters can be entered on the Parameters tab page, which are then set when the user logs on to AS ABAP and are evaluated by other programs. ABAP_EXAMPLE_END
SPA/GPA Parameters and ABAP Programs The statements SET PARAMETER and GET PARAMETER of a program do not directly access the SPA/GPA parameters of the user memory.
As soon as an ABAP program is rolled in to the memory, all SPA/GPA parameters of the user memory are copied to the session memory of the program. The statements SET PARAMETER and GET PARAMETER of a program work with the local SPA/GPA parameters of the session memory.
As soon as a program is rolled out of the memory, all local SPA/GPA parameters are copied to the cross-session user memory, where they replace all SPA/GPA parameters. Any SPA/GPA parameters that do not exist in the session memory also do not exist in the user memory afterwards. A roll out is performed, for example:
When exiting a program.
When calling a new program using SUBMIT, CALL TRANSACTION, or LEAVE TO TRANSACTION.
During any work process change A work process is changed in the same situations that cause implicit database commits.
In the statement COMMIT WORK.
Latest notes: The fact that ABAP programs do not access the user memory directly but all SPA/GPA parameters are imported or exported implicitly only at certain times, has consequences for programs that run in parallel in different ABAP sessions of the same user:
If a program sets a SPA/GPA parameter using SET PARAMETER, a program in a parallel ABAP session can only be started after the rolling program has been rolled out if it needs to access the modified parameter.
If a program sets a SPA/GPA parameter using SET PARAMETER while another program in a parallel ABAP session is active, and the latter has been running longer than the setting program, these changes are overwritten when the program that has been running longer is rolled out. Premature rollouts can be forced by statements such as WAIT UP TO, but the fact that the state of the user memory is always determined by the program that was last rolled out creates a serious obstacle for cross-session use of SPA/GPA parameters in parallel programs. This type of programming is therefore not recommended. ABAP_HINT_END
Managing SPA/GPA Parameters The names of SPA/GPA parameters are managed in the database table TPARA. In the Object Navigator of the ABAP Workbench, the names of SPA/GPA parameters are created in uppercase letters in the database table TPARA and are linked to packages. The database table TPARA acts as a reservation table for SPA/GPA parameters. If SPA/GPA parameters are used in a program, the name of the parameter must be contained in the PARAMID column in the database table TPARA. SPA/GPA parameters from other applications should not be unintentionally overwritten.
Latest notes: If a name exists in the database table TPARA, this does not automatically mean that the corresponding parameter also exists in the user memory. SPA/GPA parameters are created only during the execution of ABAP programs. ABAP_HINT_END
SPA/GPA Parameters and Dynpro Fields When defining input fields, dynpro fields can be linked to SPA/GPA parameters by entering the name of an SPA/GPA parameter from the database table TPARA as the property PARAMETER ID. If the corresponding property <(>GET PARAMETER <)> is set, no other value is assigned to the input field, and the dynpro is not processed in a batch input session, the input field is filled with the value of the SPA/GPA parameter when the screen layout is sent. If the corresponding property <(>SET PARAMETER<)> is set, the content of the input field is assigned to the SPA/GPA parameter at the PAI event. If the parameter does not yet exist in the user memory, it is created implicitly in the PAI event. In the case of selection screens, the addition MEMORY ID links the statements PARAMETERS and SELECT-OPTIONS.
