GUIDELINE 3.2
Program Type
ABAP_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.
ABAP_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.
ABAP_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.
Documentation extract taken from SAP system, � Copyright SAP AG. All rights reserved