When programs that run in different internal sessions use the same global class, the global class is created separately in each internal session. The static attributes of the class can have different values in different internal sessions.

 

 

Same Function Group or Class Within an  internal session

When two programs run in the same internal session, for example, an executable program and the AB function group it addresses, and both programs address the same XY function group, then the system loads the function group XY in the internal session once only. Therefore, the main program and function group AB can exchange data using function group XY. The same applies for global classes.

 

In practice, this situation can result in errors because the main program and function group AB (or class CL_A) affect each other inadvertently. The main program may buffer data in function group XY, for example, but function group AB or class CL_A can unintentionally overwrite the data or initialize it. This can result in program termination and even data inconsistency.

 

The causes of such errors are difficult to find, particularly when the program does not use the function group AB or class CL_A directly but through other function groups or classes instead.

 

Hint: When the shared program is a global class (class CL_B in the figure), there is only a risk of unintended interaction with regard to static attributes. The two programs used see only the same instances (and therefore the instance attribute values) of a class when they specifically exchange references to these instances.

 

An elegant way of avoiding unintended interaction for global classes is to use instance attributes instead of static attributes. Also, make sure that every user of the class generates a separate instance.

 

 

External Subroutine Calls

 

The figure explains the impact of external subroutine calls on Executable programs (type 1), Module pools (type M) and subroutine pools (type S).

 

When a program calls a subroutine externally, the system does not generate a new program group in the internal session. Instead, it loads the main program of this subroutine into the existing program group of the calling program.

 

Hint: Subroutines of a function group are an exception. When a subroutine of a function group is called externally, the system loads the corresponding function group into an additional program group.

 

Data Transfer Options

When programs run in different program groups, internal sessions, or external sessions, they do not share any data objects. However, various options are available for exchanging data between these programs.

 

Some techniques for passing data are as follows:

• Using the interface of the called program (screen or selection screen)
• ABAP memory
• SAP memory
• Database tables
• Local files on the presentation server

 

 

ABAP Memory and SAP Memory

When you need to transfer data between two different programs but cannot specify the data as an addition in the program call, you can use SAP memory and ABAP memory to transfer data.

 

SAP memory is a user-specific memory area for storing field values. It is, therefore, not useful for passing data between internal sessions.

 

The system retains values in SAP memory for the duration of the terminal session for the user. You can also use SAP memory between sessions in the same terminal session. All external sessions of a user session can access SAP memory. You can use the contents of SAP memory as default values for screen fields.

 

ABAP memory is also user specific. There is a local ABAP memory for each external session. You can use it to exchange any ABAP data objects (such as fields, structures, internal tables, and complex objects) between internal sessions in any one external session.

 

When the user exits an external session (by entering /I in the command field), the system automatically initializes or releases the corresponding ABAP memory.