Organization of External Procedure Calls 

Each execution (start or call) of an executable program opens up an internal session with the main session of an SAP application. When the program calls external procedures, their main program and working data are also loaded into the memory area of the internal session. Here, there is a difference between calling external subroutines, function modules, and working with classes in ABAP Objects. When you load a framework program into an internal session, the event LOAD-OF-PROGRAM is triggered. If a corresponding event block is defined in the framework program, it is executed once before the first other processing procedure of the framework program is executed.

Program Groups in an Internal Session

This illustration shows the memory organization for external subroutines and function modules.

 

The main program (executable program or module pool) belongs to a main program group. When you call, using CALL FUNCTION, a function module from a function group that has not already been loaded, an additional program group is opened. The function group of the function module is stored here. The additional program group, along with its data, exists for the rest of the lifetime of the internal session.

If you call an external subroutine using PERFORM, the framework program of the subroutine is loaded into the existing main program or function group in the corresponding main or additional program group (if it has not already been loaded).

An additional program group is only opened in an external PERFORM if the subroutine belongs to a function group that has not yet been loaded. This will happen if the main program of the subroutine begins with the FUNCTION-POOLstatement. The program type does not necessarily have to be set to F.

Classes in ABAP Objects behave like function groups. The first time you address a class (for example, using the CREATE OBJECTstatement) or address a static class component, the system opens an additional program group for the class.

Object Handling

The transient objects of ABAP Objects exist with equal status in the data area of an internal session. All the programs and objects of an internal session can use the objects of ABAP Objects of the same internal session. This means that references to objects within an internal session can be passed to external procedures (subroutines, function modules, and methods).

There are no memory areas for cross-transaction objects on the application server. Persistent objects in the database are handled by persistence services that do not belong to the language scope of ABAP.

Screen Handling

The system only displays and processes the screens, selection screens, and lists of the main program and main program group or function group of an additional program group, along with their associated GUI statuses. The CALL SCREEN, CALL SELECTION-SCREEN or list output statements in external subroutines apply to the screens of the main program or function group. The screens are processed in the main program or function group. So, for example, even if the framework program of an external subroutine has a screen with the number 100, a CALL SCREEN 100 statement will call screen number 100 in the calling main program.

Interface Work Areas

Interface work areas that you declare using the TABLES, NODES, or DATA BEGIN OF COMMON PART statements exist once only in each program group, and are shared by all of its programs. Each main program that begins with the PROGRAM or REPORTstatement, and each function group that begins with FUNCTION-POOL shares the interface work areas with the framework programs of all of its external subroutines.

Dynamic Assignment

The assignment of screens and interface work areas to subroutines is defined by the sequence of the subroutine calls. The first program to call an external subroutine shares its interface work areas with the subroutine, and the subroutine uses its screens. The sequence of the subroutine calls is not necessarily statically defined. Instead, it can change dynamically depending on user actions or the contents of fields. For example, a subroutine may belong to a main program group on occasion when it is run, but the next time, it may belong to an additional program group. For this reason, you should avoid using external subroutines if they use interface work areas or call screens.