Lesson 25 Calling Programs and Passing Data

CALLING PROGRAM AND PASSING DATA:


There are two ways of starting an ABAP program from another ABAP program that is already running:

By interrupting the current program to run the new one - the called program is executed, and afterwards, processing returns to the program that called it.

By terminating the current program and then running the new one.
Complete ABAP programs within a single user session can only run sequentially. We refer to this technique as using synchronous calls.

If you want to run functions in parallel, you must use function modules. For further information about this technique, refer to course BC415 (Communication Interfaces in ABAP), and the documentation for the CALL FUNCTION … STARTING NEW TASK… statement.
The way in which main memory is organized from the program's point of view can be represented easily in the above model. There is a distinction between internal and external sessions:

Generally, an external session corresponds to an R/3 window. You create new external sessions by choosing System ® Create session or entering /o in the command field. You can have up to six external sessions open simultaneously in one terminal session.

External sessions are subdivided into internal sessions . Each program that you run occupies its own internal session. Each external session can contain up to nine internal sessions.

The data in a program is only visible within that internal session, so it is only visible to the program.

The following pages illustrate how the stack inside an external session changes with various program calls.

When you insert a program, the system creates a new internal session, which contains the new program context.

The new session is placed on the stack The program context of the calling program also remains on the stack.

When the called program finishes, its internal session (the top one in the stack) is deleted.

Processing is resumed in the next-highest internal session in the stack.
When you end a program and start a new one, there is a difference between calling an executable program and calling a transaction.

If you start an executable program using its program name, the internal session of the program you are ending (the top one) is removed.

The system creates a new internal session, which contains the program context of the called program. The new session is placed on the stack. Any program contexts that already existed are retained. The topmost internal session on the stack is replaced.
If you start a program using its transaction code (if one is assigned), all of the existing internal sessions are removed from the stack.

The system creates a new internal session, which contains the program context of the called program.

After the call, the ABAP memory is reset.
When you call a function module, the ABAP runtime system checks whether you have already called a function module from the same function group in the current program.

If this is not the case, the system loads the relevant function group into the internal session of the calling program. Its global data is initialized and the
LOAD-OF-PROGRAM event is triggered.

If your program had already used a function module from the same function group before the call, the function group is already resident in the internal session, and the new call can access the same global data. We say that the function group remains active until the end of the program that called it.

The data is only visible in the corresponding program - each program can only address its own data, even if there are identically-named objects in both programs. The same applies when the stack is extended. If a program is added to the stack that calls a function module from a function group already called by another program, the function group is loaded again into the new internal session.

The system creates new copies of its data objects, initializes them, and, as before, they are only visible within the function group, and only in the internal session in which the function group was loaded.

To start an executable (type 1) program, use the SUBMIT statement.
If you use the VIA SELECTION-SCREEN addition, the system displays the standard selection screen of the program (if one has been defined).

If you use the AND RETURN addition, the system resumes processing with the first statement after the SUBMIT statement once the called program has finished.
For further information, refer to the documentation for the SUBMIT statement.
When you use the LEAVE TO TRANSACTION '' statement, the system terminates the current program and starts the transaction with transaction code . The statement is the equivalent of entering /n in the command field.

CALL TRANSACTION '' allows you to insert an ABAP program with a transaction code into the call chain.

To terminate an ABAP program, use the LEAVE PROGRAM statement. If the statement occurs in a program that you called using CALL TRANSACTION '' or SUBMIT AND RETURN, the system resumes processing at the next statement after the call in the calling program. In all other cases, the user returns to the application menu from which he or she started the program.

If you use the …AND SKIP FIRST SCREEN addition, the system does not display the screen contents of the first screen in the transaction. However, it does process the flow logic.

If you started a transaction using CALL TRANSACTION that uses update techniques, you can use the UPDATE… addition to specify the update technique (asynchronous (default), synchronous, or local) that the program should use.

There are various ways of passing data to programs running in separate internal sessions:

You can use

The interface of the called program (usually a standard selection screen)
ABAP memory
SAP memory
Database tables
Local files on your presentation server

Function modules have an interface that the calling program and the function module use to exchange data. Subroutines also use a similar technique. Certain restrictions apply to the interfaces of remote enabled
function modules.

When you call ABAP programs that have a standard selection screen, you can pass data for the input fields in the call. There are two ways to do this:

By specifying a variant for the selection screen when you call the program.

By specifying values for the input fields when you call the program.
The WITH addition in the SUBMIT statement allows you to assign values to the fields on a standard selection screen. The abbreviations "EQ, NE, … , I, E" have the same meanings as with select options.

If you want to pass several selections to a selection option, you can use the RANGES statement instead of individual WITH additions. The RANGES statement creates a selection table , which you can fill as though it were a selection option. You then pass the whole table to the executable program.

If you want to display the standard selection screen when you call the program, use the VIA SELECTION-SCREEN addition.

When you use the SUBMIT statement, use the Pattern function in the ABAP Editor to insert an appropriate statement pattern for the program you want to call. It automatically suppplies the names of the parameters and selection options that are available on the standard selection screen.

The example shown above is an extract from transaction BC402_CALD_CONN. When the user requests the coordinates of a city, the executable program SAPBC402_TABD_HASHED is called.

The parameters are filled with the city and country code from the transaction. The standard selection screen does not appear.

For further information about working with variants and about other syntax variants of the WITH addition, refer to the documentation for the SUBMIT statement.
To pass data between programs, you can use either the SAP memory or the ABAP memory.

SAP memory is a user-specific memory area that you can use to store field values. It is only of limited value for passing data between internal sessions. Values in SAP memory are retained for the duration of the user's terminal session. The memory can be used between sessions in the same terminal session. You can use the contents of SAP memory as default values for screen fields. All external sessions can use the SAP memory.

ABAP memory is also user-specific. There is a local ABAP memory for each external session. You can use it to exchange any ABAP variables (fields, structures, internal tables, complex objects) between the internal sessions in any one external session.
When the user exits an external session (/i in the command field), the corresponding ABAP memory is automatically initialized or released.

Use the EXPORT … TO MEMORY statement to copy any number of ABAP variables with their current values (data cluster) to ABAP memory. The ID… addition (maximum 32 characters long) enables you to identify different clusters.
If you use a new EXPORT TO MEMORY statement for an existing data cluster, the new one will overwrite the old.

The IMPORT… FROM MEMORY ID… statement allows you to copy data from ABAP memory into the corresponding fields of your ABAP program. In the IMPORT statement, you can also restrict the selection to a part of the data cluster.

The variables into which you want to read data from the cluster in ABAP memory must have the same types in both the exporting and the importing programs.
To release a data cluster, use the FREE MEMORY ID… statement.
Remember when you call programs using transaction codes that you can only use the ABAP memory to pass data to the transaction.

You can define memory areas (parameters) in the SAP memory in various ways:

By creating input/output fields with reference to the ABAP Dictionary. These take the parameter name of the data element to which they refer.
Alternatively, you can enter a name in the attributes of the input/output fields. Then, you can also choose whether the entries from the field should be transferred to the parameter (SET), or whether the input field should be filled with the value from the parameter (GET).
To find out about the names of the parameters assigned to input fields, display the field help for the field (F1), then choose Technical info.

You can also fill a memory area directly using the statement
SET PARAMETER ID '' FIELD .
and read it using the statement GET PARAMETER ID '' FIELD .

You can also define parameters using the Object Navigator and fill them with values.

When you call a transaction using the statement CALL TRANSACTION '' USING … you can run the transaction using the values from in the screen fields. The internal table must have the structure bdcdata.

The MODE addition allows you to specify whether the screen contents should all be displayed ('A' - the default setting), only when an error occurs ('E'), or not at all ('N'). You can use the MESSAGE INTO to specify an internal table into which any system messages should be written. The internal table must have the structure bdcmsgcoll. You can find out if the transaction was executed successfully from the system field sy-subrc.

You might use this technique if

You are processing in the foreground, but the input fields have not been filled using GET parameters.

You want to process the transaction invisibly. In this case, you normally have to pass the function codes in the table as well.

This technique is also one of the possible ways of transferring data from non-SAP systems. When you do this, the internal table with the structure bdcdata must be filled completely.

Filling the internal table in batch input format:

Each screen that you want to process automatically in the transaction must be identified by a line in which only the fields program, dynpro, and dynbegin are filled.

After the record that identifies the screen, use a new bdcdata record for each field you want to fill. These records use the fields fnam and fval. You can fill the following fields:
• Input/output fields (with data)
• The command field bdc_okcode, (with a function code)
• The cursor positioning field, bdc_cursor (with a field name)

The filled internal table in bdcdata format is illustrated above. At runtime, stands for the customer name from the input field, stands for the city.

You use the field BDC_OKCODE to address the command field, into which you enter the function code that would have been triggered by the user choosing a function key, pushbutton, or menu entry in dialog mode (or by entering a code directly in the command field).