In the realm of SAP ABAP programming, efficient data handling and transfer between programs are crucial for optimal performance and user experience. The SPA/GPA technique, often referred to within the SAP ecosystem as Sap Spa for its ability to facilitate seamless data flow, provides a robust solution for populating transaction input fields with data from calling programs. This method leverages SPA/GPA parameters, which are essentially global, user-specific variables stored in the SAP memory.

SAP memory acts as a central repository, enabling value sharing across different programs within a user’s terminal session, including parallel sessions. Each SPA/GPA parameter is uniquely identified by a 20-character code, manageable within the ABAP Workbench’s Repository Browser. These parameters are user-specific, ensuring data privacy and relevance to individual user sessions.

ABAP programs interact with these parameters using dedicated statements: SET PARAMETER for writing values and GET PARAMETER for retrieving them.

To store a value in SAP memory, the SET PARAMETER statement is employed:

SET PARAMETER ID pid FIELD f.

This command saves the content of the field f under the identifier pid in the SAP memory. The pid can be up to 20 characters long. If a value already exists under the same pid, it is overwritten. Notably, within the ABAP Editor, double-clicking on pid allows for the creation of non-existent parameters as Repository objects, enhancing development efficiency.

To retrieve a value from SAP memory, the GET PARAMETER statement is used:

GET PARAMETER ID pid FIELD f.

This statement retrieves the value associated with the identifier pid from the SAP memory and assigns it to the variable f. The system variable sy-subrc is set to 4 if no value is found for pid, and to 0 if the retrieval is successful.

For pre-filling the initial screen of a program using SAP SPA parameters, the SET PARAMETER statement is primarily utilized. The key is to establish a link between the relevant screen fields and their corresponding SPA/GPA parameters.

On selection screens, this linkage is achieved using the MEMORY ID addition within the PARAMETERS or SELECT-OPTIONS statements. By specifying an SPA/GPA parameter ID during parameter or selection option declaration, the associated input field becomes connected to that parameter.

Within screens, the connection is configured in the Screen Painter. In the field attributes of an input field, the name of the SPA/GPA parameter can be entered in the “Parameter ID” field. Furthermore, “SET parameter” and “GET parameter” checkboxes control whether the field is populated from the SPA/GPA parameter during the PBO (Process Before Output) event and whether the SPA/GPA parameter is updated with the screen field’s value during the PAI (Process After Input) event.

When an input field is linked to an SAP SPA parameter, it automatically initializes with the parameter’s current value each time the screen is displayed. This explains why SAP system screens often retain values when revisited, enhancing user convenience and data consistency.

Utilizing SAP SPA parameters when calling programs eliminates the need for extensive coding, particularly when pre-filling mandatory fields on the initial screen of the called program. The system seamlessly transfers values from the parameters to the program’s input fields.

Programmatically controlling parameter values using the SET PARAMETER statement before a program call offers greater flexibility. This is especially beneficial when bypassing the initial screen of a called program, especially if it contains required fields.

To effectively leverage SAP SPA parameters, understanding the parameter IDs linked to specific fields on the initial screen is essential. A straightforward method to identify these IDs involves launching the target program, positioning the cursor on the input field, and pressing F1 for help. Selecting “Technical Info” reveals the “Parameter ID” field, displaying the associated SPA/GPA parameter name. Alternatively, the screen definition can be inspected in the Screen Painter.

For instance, examining the technical information for the “Company” input field in the booking transaction TCG2 reveals the SPA/GPA parameter ID “CAR”:

By employing this approach, you can determine the SPA/GPA parameter IDs “CON,” “DAY,” and “BOK” for the other input fields in the TCG2 transaction.

Consider the following executable program, connected to the logical database F1S, which calls an update transaction:

REPORT bookings NO STANDARD PAGE HEADING.
TABLES sbook.
START-OF-SELECTION.
WRITE: 'Select a booking',
/ '----------------'.
SKIP.
GET sbook.
WRITE: sbook-carrid, sbook-connid,
sbook-fldate, sbook-bookid.
HIDE: sbook-carrid, sbook-connid,
sbook-fldate, sbook-bookid.
AT LINE-SELECTION.
SET PARAMETER ID: 'CAR' FIELD sbook-carrid,
'CON' FIELD sbook-connid,
'DAY' FIELD sbook-fldate,
'BOK' FIELD sbook-bookid.
CALL TRANSACTION 'BOOK'.

This program’s basic list presents data from the SBOOK database table based on user selections. This data is also stored in the HIDE areas of each line.

Upon a user double-clicking a booking data line, the AT LINE-SELECTION event is triggered. The program then retrieves the hidden data and populates the SPA/GPA parameters corresponding to the initial screen fields of the transaction. Subsequently, the transaction is invoked. Without suppressing the initial screen using AND SKIP FIRST SCREEN, the initial screen may appear as shown below, pre-filled with the selected booking data:

If the AND SKIP FIRST SCREEN option were used with the CALL TRANSACTION statement, the second screen would appear immediately, as all mandatory fields on the initial screen would be already populated through the SAP SPA mechanism. This demonstrates the power and efficiency of SAP SPA parameters in streamlining transaction execution and enhancing user workflow in SAP environments.