http://searchsap.techtarget.com/tip/1,289483,sid21_gci1024396,00.html
ABAP/BAPI/JAVA-
DEVELOPER
ABAP Geek 2 -- ABAP program types
Horst Keller, SAP
09 Nov 2004
The
following matrix shows all ABAP program types and their supported features.
These programs are so called compilation units, which are compiled
independently and which are loaded as units into memory for execution. Besides
compilation units, there are also Include Programs, that are mere pieces of
source code, which are not compiled independently but included in compilation
units.
Supported Features |
Executable Program |
Module Pool |
Function Pool |
Subroutine Pool |
Type Pool |
Class Pool |
Interface Pool |
Global Data Types & Data |
x |
x |
x |
x |
x |
x |
|
Dynpro |
x |
x |
x |
|
|
|
|
Dialog Modules |
x |
x |
x |
|
|
|
|
Selection. Screen Events |
x |
x |
x |
|
|
|
|
List Events |
x |
x |
x |
|
|
|
|
Reporting Events |
x |
|
|
|
|
|
|
Classes |
x |
x |
x |
x |
|
x |
|
Interfaces |
x |
x |
x |
x |
|
x |
x |
Methods |
x |
x |
x |
x |
|
x |
|
Function Modules |
|
|
x |
|
|
|
|
Subroutines |
x |
x |
x |
x |
|
|
|
SUBMIT |
x |
|
|
|
|
|
|
Transaction Code |
x |
x |
x |
x |
|
x |
|
The
supported features show:
·
whether
a program can contain declarations of global data types and data,
·
whether
a program can contain its own components for user dialogs (general Dynpros,
Selection Screens, Lists),
·
which
event blocks a program can contain in order to react to events from the runtime
environment,
·
which
procedures (methods, function modules, subroutines) a program can contain,
·
how
the program can be executed -- either via SUBMIT or via a transaction
code.
As you can
see, the first three program types -- executable programs, module pools, and
function pools -- are the most versatile ones. They represent the classical
ABAP programming models of reporting (executable programs), dialog programming
(dialog modules), and procedural programming by outsourcing functionality to
function modules (function pools). The other four program types are more
specialized ones.
·
Executable
programs are made
for reporting. They are the only programs that can be started via SUBMIT
(which is the ABAP statement that lies behind transaction SA38!). SUBMIT
starts a reporting process in the ABAP runtime environment, that is tailor made
for receiving user input, selecting data from database tables, and displaying
them on a list. The reporting process triggers a sequence of events -- as for
example INITIALIZATION, START-OF-SELECTION etc. -- that can be
handled in the executable program. Stay tuned for an upcoming Weblog about SUBMIT.
·
Module pools are very similar to
executable programs. Except for reporting events and for being callable via SUBMIT,
module pools support the same features as executable programs. In another way
around, module pools could be fully replaced by executables. Traditionally,
module pools are chosen to implement the application logic of so called dialog
programs. Those are programs that communicate with the user via Dynpros. A
Module pool Ís usually executed by calling a transaction code connected to one
of its Dynpros. The dialog modules are then called from the Dynpro's flow
logic.
·
Function
pools are the only
programs that can contain function modules. They are not maintained in the
standard ABAP Editor, but in the Function Builder instead. Function pools and
their function modules deliver reusable functions to other programs. Besides
that, function pools have the same features as module pools. Especially, they
can contain Dynpros and dialog modules. Therefore, function pools are the first
choice, if you want to encapsulate dynpro based user dialogs (note that class
pools do not support Dynpros). An application program or a class can call a function
module, which then calls one of the function pool's Dynpros via CALL SCREEN.
·
Subroutine
pools -- as the
name says -- were created to contain selections of subroutines, that can be
called externally from other programs. Before release 6.10, this was the only
way, how subroutine pools could be used. But besides subroutines, subroutine
pools can also contain local classes and interfaces. As of release 6.10, you
can connect transaction codes to methods. Therefore, you can now also call
subroutine pools via transaction codes. This is the closest to a Java program
you can get in ABAP: a subroutine pool with a class containing a method -- say
-- main connected to a transaction code!
·
Type
pools are the
precursors to general type definitions in the ABAP Dictionary. Before release
4.0, only elementary data types and flat structures could be defined in the
ABAP Dictionary. All other types, that should be generally available, hat to be
defined with TYPES in type pools. As of release 4.0, type pools were
only necessary for constants. As of release 6.40, constants can be declared in
the public sections of global classes and type pools can be replaced by global
classes.
·
Class
pools serve as
containers for exactly one global class. Besides the global class, they can
contain global types/data and local classes/interfaces to be used in the global
class. A class pool is executed by calling a public method of its global class.
This can be done from any ABAP program, but also via a transaction code
connected to one of its public methods. You maintain class pools in the class
builder.
·
Interface
pools serve as
containers for exactly one global interface -- nothing more and nothing less.
You use an interface pool by implementing its interface in classes and by
creating reference variables with the type of its interface. You maintain
interface pools in the class builder.
Looking
into an ABAP based SAP system you will find all those program types. Their
purpose should be clear to you now. Starting a new development, you must select
the program types that fit your needs most. I recommend to encapsulate all
pre-Web Dynpro user dialogs in function groups and to code the application
logic in classes with its "main" method connected to a transaction
code. You can either use global classes in class pools or local classes in --
why not -- subroutine pools. A renaissance of that old fashioned program type
-- but, please, without subroutines!