ABAP Program types

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!