Program types

Question

Hi,
Pls explain the following :
Executable program
Include program
Module pool
Function group
Sub-routine pool
Interface pool
Class pool
Type pool
XSLT program
Thanks
Mahathi

Answer 1

Hi,
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.
Regards,
Omkar.