Anda di halaman 1dari 4

Program Type

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-OFSELECTION) 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.