Skip to content

ABAP Keyword Documentation →  ABAP Programming Guidelines →  ABAP-Specific Rules →  Programm Type and Program Properties 

Program Type

Other versions: 7.31 | 7.40 | 7.54

Background

Every ABAP program has a program type that specifies which declarations and processing blocks a program can contain, and how it can be executed using the ABAP runtime environment. These are the possible program types in ABAP:

  • Executable program
    An executable program can contain all possible declarative statements. All processing blocks are possible except for function modules. The program supports classical dynpros and selection screens. It can be executed using the SUBMIT statement or using transaction codes. You create executable programs in the ABAP Editor.
  • Class pool
    A class pool always contains declarative statements for a global class. It can also include declarative statements for local types, interfaces, and classes. Only methods can be used as processing blocks. The pool does not support classical dynpros or selection screens. You can call global class methods externally (depending on visibility) and execute public methods of the global class using transaction codes. You create class pools using the Class Builder.
  • Interface pool
    An interface pool can only contain the declarative statements for a global interface. Processing blocks, classical dynpros and selection screens are not possible. You cannot call or execute an interface pool. You create interface pools using the Class Builder.
  • Function group (function pool)
    A function group can contain all types of declarative statements. All processing blocks are supported except for the reporting event blocks. Classical dynpros and selection screens are supported. You can call the associated function modules, but you can also access the dynpro processing screen of the function group by using transaction codes. You create function groups using the Function Builder.
  • Module pool
    A module pool can contain all possible declarative statements. All processing blocks are supported except for reporting event blocks and function modules. The module pool supports classical dynpros and selection screens. It can be executed using transaction codes. You create module pools using the ABAP Editor.
  • Subroutine pool
    A subroutine pool can contain all possible declarative statements. The LOAD-OFPROGRAM event block, subroutines and methods can be used as processing blocks. The pool does not support classical dynpros or selection screens. You can call the subroutines, but you can also execute methods using transaction codes. You create subroutine pools using the ABAP Editor.
  • Type group (type pool)
    A type group can contain the declarative statements, TYPES and CONSTANTS. Processing blocks, classical dynpros and selection screens are not possible. You cannot call or execute a type group. You create type groups using the ABAP Dictionary.

In addition to these compilation units (programs that can be compiled independently), include programs can also be used for source text organization.

In ABAP, a program execution means that the system loads a program into the memory and executes one or more of its processing blocks. A distinction is made between standalone and called program execution:

  • Standalone program execution
    With standalone program execution, you start the program using a transaction code (CALL TRANSACTION and LEAVE TO TRANSACTION statements) or using the SUBMIT statement for an executable program. The SUBMIT statement also allows execution in a background process.
  • Called program execution
    With called program execution, a program currently running calls a procedure (method, function module, or subroutine) of another program. If necessary, this other program is loaded into the internal session of the calling program.
  • The program flow for standalone program execution depends on the selected program type and the type of program call:
  • If the program is called using a transaction, a distinction is made between object-oriented (OO) transactions and dialog transactions. For object-oriented transactions, the transaction code is linked to a method of a local or global class. This method defines the program flow. Dialog transactions, however, are linked to a classical dynpro of the program. In this case, the program flow is defined by the associated dynpro flow logic.
  • The program flow of an executable program that was started using SUBMIT is defined by the reporting process of the ABAP runtime environment. The runtime environment calls the different reporting event blocks (START-OFSELECTION, GET and END-OF-SELECTION) of the program.
  • You must select the program type based on the technical program properties described here and the requirements for program execution. Not all the program types mention here are appropriate for new developments.

Rule

Select the appropriate program type

To select the program type, proceed as follows:

  • The program type "class pool" or "interface pool" is automatically set for global classes and interfaces.
  • To implement completed functionality that should be displayed in the class library, you can use the program type "subroutine pool" for local classes.
  • If you require function modules, the program type "function group" is automatically set. In addition, you must use function groups to wrap classical dynpros or selection screens.
  • If the programs needs to be executed within the scope of background processing, the executable program type is automatically set.
  • You should not create any new module pools or type groups.

Details

The above hierarchy for selecting the program type is derived from the basic rule described, which defines the use of ABAP Objects. The following list describes specific aspects in detail:

  • If ABAP Objects functionality needs to be provided across the whole package or system, this is achieved using global classes or interfaces that implicitly have the program type "class pool" or "interface pool". The call is performed using a method call or an OO transaction (if a standalone program execution is required).
  • You can use the subroutine pool program type to implement closed functionality, which is called using a transaction code (not using a method call), does not require passed parameters and does not have a user interface. Only local classes are used for implementation. The program is called using an OO transaction. Subroutine pools - as the name suggests - were originally intended for subroutines that were called from other programs. Subroutines (and calling subroutines externally in particular) are declared as obsolete, according to the existing programming guidelines. Subroutine pools no longer have this purpose. Instead, subroutine pools are suggested as independent containers for local classes. This is because they are otherwise barely affected by implicit processes of the ABAP runtime environment.
  • Remote-enabled function modules (RFM) - which provide functionality using the RFC interface across servers or across systems, or are used for parallelization - can only be created in a function group. The implementation of the actual functionality, however, is carried out in a class, for example, in a local class within the function group.
  • The same applies to update function modules (which are called for the update using CALL FUNCTION IN UPDATE TASK) as to RFMs.
  • Programs with a classical dynpro interface or selection screens (if still required) should also be created as a function group. The function group only implements the UI but does not contain its own application logic (based on the SoC principle). This program type is suitable because it can contain both classical dynpros and an external functional interface in the form of function modules. The dialog modules of the function group called by the dynpro flow logic should only contain method calls, for instance, for methods of local classes.
  • An executable program includes several event blocks that are executed when the various reporting events occur. This form of event control is largely obsolete and should no longer be used. Executable programs should only be used where they are technically required, thus mainly for background processing. In this case, the actual implementation should also be carried out in methods, for example, methods of a local class within the executable program. The event block of the initial event, START-OF-SELECTION, should only contain a method call. No other event blocks should be included anymore.
  • The module pool used to be the program type traditionally used for classical dialog programming with dynpros. The Separation of Concerns concept is not sufficiently supported by module pools. For this reason, you should not create any new module pools. Instead, you should encapsulate any classical dynpros that are still required in function groups.
  • The type group program type was initially implemented as a temporary solution. This was because it was not always possible to define types for internal tables in the ABAP Dictionary. The same applied to the global storage of constants. Both gaps have now been closed. In the ABAP Dictionary, you can define any types. In global classes and interfaces, you can create types and constants for package-wide or system-wide use. Therefore, the type group program type is obsolete, and you should not create any new type groups.


Note

In cases where you still use program types other than class and interface pools, you should activate the check Obsolete Statements (OO Context) in the extended program check. This enables you to implement the same stringent syntax check for program components not implemented in local classes as for within classes.