Embed Size (px)
DESCRIPTION
Modularization Statements
Citation preview
ABAP Keyword DocumentationSAP NetWeaver AS ABAP Release 731, ©Copyright 2015 SAP AG. All rights reserved.
• Modularization Statements
• Procedures
• Dialog Modules
• Event Blocks
• Source Code Modules
Modularization Statements
Each ABAP program is divided into processing blocks. Each accessible statement of an ABAP program that does not belong to the global declaration section of the program belongs to a processing block. The possible processing blocks are:
Procedures You use ABAP statements to call their processing. Possible procedures are methods, function modules, and subroutines.
Dialog modules You use the flow logic to call their processing.
Event block Their processing is triggered by events in the ABAP runtime environment.
You can define the processing blocks in any order in the source text of the ABAP program. Non-declarative statements that appear between or after closed processing blocks cannot be accessed and can never be executed. The syntax check reports such dead coding as an error. Declarative statements that appear between or after closed processing blocks belong to the global data declarations of the ABAP program and are visible in all subsequent processing blocks.
You can also use macros and include programs to modularize a source text beyond the use of processing blocks.
Procedures
Procedures are processing blocks with an interface and a local data area. They can be called from an ABAP program. A distinction is made between:
Methods
Function modules
The following are an obsolete form of procedure:
Subroutines
Parameter Interface of Procedures
The parameter interface of a procedure consists of formal parameters and specifies the exceptions possible in the procedure.
Formal Parameters
Formal parameters are input parameters, output parameters, input/output parameters, or return values. Several obsolete table parameters also exist. Formal parameters are either generic or fully typed. Pass by reference or pass by value can be specified for most formal parameters. Pass by value is mandatory for some formal parameters.
Exception
Class-based exceptions can be declared using RAISING for all procedures (methods, function modules, and subroutines), and can then be propagated from the procedure. EXCEPTIONS can also be used in methods and function modules to define non-class-based exceptions, which can then be raised in the procedure using RAISE or MESSAGE ... RAISING.
Pass by Reference or Pass by Value
When deciding whether to use pass by reference or pass by value for a formal parameter, you must compare the performance and robustness of each transfer type.
In ABAP, pass by reference always leads to better performance since no local data object has to be stored and no data transport is necessary when the procedure is called. Therefore, for performance reasons, pass by reference is usually preferable, unless explicit or implicit write access exists to an input parameter in the procedure or you want to ensure that an input/output parameter or an output parameter is returned only if the procedure ends without any errors. In such cases, pass by value is mandatory; this is so that the assigned actual parameter is not simultaneously modified in the caller when write access exists for a formal parameter. For performance reasons, only parameters of 100 bytes or less should be passed in these cases, whenever possible.
Also note the following when using pass by reference:
In subroutines, write access to an input parameter defined using USING is possible without a syntax error being produced (as is the case with input parameters of methods or function modules defined using IMPORTING).
An output parameter that is passed by reference acts like an input/ output parameter; in other words, if read access to an output parameter exists in the procedure before the value of that parameter is
changed, this value is not initial, unlike with pass by value, but is the same as the current value of the actual parameter in the caller.
If a procedure is stopped because of an error (that is, if it is stopped for a reason other than reaching its last statement or RETURN, EXIT, or CHECK) all actual parameters that are passed by reference retain the value of the assigned formal parameter that that parameter had when the program was stopped. In pass by value, no values are passed to actual parameters when a procedure terminates.
Procedures and their calls have to be programmed so that these kinds of errors do not occur.
To summarize, pass by reference is always preferable when performance is an issue, while pass by value is more suitable in situations where robustness and data consistency are more important. These factors must be taken into account in each individual case when you decide which pass type to use with which type of parameter.
Notes
When strings or internal tables of the same type are passed by value, table sharing comes into force between the data object created locally and the data object transferred, similarly to with an assignment. However, table sharing only happens if the row type of the internal table permits it. This means that, when you pass strings and internal tables, the performance benefits of pass by reference over pass by value may be negated by sharing (in certain circumstances).
Only pass by reference can be specified for the obsolete table parameters.
Pass by value is mandatory for the return value of functional methods, the output parameters of events in ABAP Objects, and all formal parameters of RFC-enabled function modules and update function modules (pass by value is also used implicitly with table parameters).
A local data object is generated for formal parameters passed by reference that are not bound to an actual parameter during the call (as for pass by value).
There are special rules for defining literals and functions and expressions as actual parameters.
The result of the typing check when passing actual parameters to formal parameters is independent of the pass type. In a pass by value, the check for pass by reference is always carried out, even though this is stricter than necessary in individual cases. For example, a special reference variable cannot be passed to a general typed CHANGING parameter, even if pass by value is defined for this parameter.
Methods
Methods are the procedures of a class, whose functions are implemented between the METHOD and ENDMETHOD statements.
METHOD
Short Reference
Syntax
METHOD meth. ... ENDMETHOD.
Effect
Between the statements METHOD and ENDMETHOD the function of a method declared with [CLASS-] METHODS meth is implemented in a class. The implementation of a method is only possible in an implementation part of a class that begins with CLASS class IMPLEMENTATION
Local data types and data objects can be declared within the method. It is also possible to access the formal parameters of the method and all the components of all instances of its own class. The method and its interface are defined either using the statement [CLASS-]METHODS for a local class, or in the Class Builder tool for a global class.
In instance methods, all components of the method's own class can be addressed not only using their name, but also explicitly using the self-reference me-> In addition, all the components of other instances of the same class can be addressed through reference variables.
A method can be called using the statement CALL METHOD or using one of its abbreviated forms.
Note
Whenever a method of an interface intf is implemented, it is possible to specify for metheither the name declared in the interface with a prefix intf or an alias name of the class defined with ALIASES The method must exist in the interfface; otherwise, a syntax error will occur.
Example
If intf~is used, only a syntax warning will appear for global interfaces. The purpose of this is so that classes are not immediately rendered invalid if an unused method from a global inteface is deleted.In this example, the two methods m1 and m2 of the class METHOD between METHOD and ENDMETHOD are implemented. Although the local data object a1 hides the attribute of the same name, the attribute a1 can be addressed using me->a1.
CLASS c1 DEFINITION. PUBLIC SECTION. METHODS m1 IMPORTING p1 TYPE string. PRIVATE SECTION. DATA a1 TYPE string. METHODS m2. ENDCLASS. CLASS c1 IMPLEMENTATION. METHOD m1. a1 = p1. m2( ).
ENDMETHOD. METHOD m2. DATA a1 TYPE string. a1 = me->a1. ENDMETHOD. ENDCLASS.
METHOD - Internal Additions
Internal Additions
These additions are for internal use only. Do not use them in application programs.
Addition:
... BY KERNEL MODULE p1 ...
Effect
This addition of the statement METHOD defines the method meth as a kernel method. This means that the method meth is not implemented in ABAP but in the kernel instead by using one of the kernel modules p1 specified here. No statements are allowed between METHOD and ENDMETHOD.
Note
In global classes, the addition must be entered directly in the source code editor in Class Builder and is not listed under the properties of the method there.
ENDMETHOD
Short Reference
Syntax
ENDMETHOD.
Effect
The ENDMETHOD statement concludes a method implementation introduced with METHOD.
Function Modules
Function modules are cross-program, reusable procedures that are organized into function groups, and whose functions are implemented between the statements FUNCTION and ENDFUNCTION. Function modules and their interfaces are created in the Function Builder.
FUNCTION
Short Reference
Syntax
FUNCTION func. *"--------------------------------------------------------- *" Local Interface: *" parameter_interface *"--------------------------------------------------------- ... ENDFUNCTION.
Effect
Between the statements FUNCTION and ENDFUNCTION, the functions of a function module func are implemented in a function group. The function module and its interface are defined in the Function Builder tool. In the source code of the function module, the function module interface defined in the Function Builder is automatically displayed as parameter_interface in comment lines underneath the FUNCTION statement.
Within the function module, local data types and data objects can be declared. There is also access to the formal parameters of the function module and to the global data types and data objects of the function group. A function module is called using the statement CALL FUNCTION.
Note
The logical expression IS SUPPLIED can be used in the function module to determine whether an actual parameter has been specified for a formal parameter.
Example
Implementation of a function module that reads data in a table-type formal parameter flight_tab under the condition of an elementary formal parameter id. The parameter interface defined in the Function Builder is visible as a comment.
FUNCTION read_spfli_into_table. *"--------------------------------------------------------- *" Local Interface: *" IMPORTING *" VALUE(ID) LIKE SPFLI-CARRID DEFAULT 'LH ' *" EXPORTING *" FLIGHT_TAB TYPE SPFLI_TAB *"--------------------------------------------------------- SELECT * FROM spfli INTO TABLE flight_tab WHERE carrid = id. ENDFUNCTION.
Function Module Interface
The parameter interface of a function module is defined in Function Builder. It includes the definition of interface parameters and the specification of exceptions that can be triggered by a function module. Function Builder automatically generates comment lines below the FUNCTION statement in the source code of the function module. These represent the interface of the function module with the following syntax:
Syntax
... [IMPORTING parameters] [EXPORTING parameters] [CHANGING parameters] [TABLES table_parameters] [{RAISING exc1|RESUMABLE(exc1) exc2|RESUMABLE(exc2) ...} |{EXCEPTIONS exc1 exc2 ...}]
The syntax and semantics of IMPORTING, EXPORTING, CHANGING, RAISING, and EXCEPTIONS mainly correspond to the definition of method interfaces with [CLASS-]METHODS. The additional option of defining table parameters using TABLES is obsolete.
Interface Parameters
The interface parameters are defined on the relevant tab pages in Function Builder.
IMPORTING parameters are input parameters. When the function module is called, a suitable actual parameter must be specified for every non-optional input parameter. The content of the actual parameter is passed to the input parameter when the call is made. The content of an input parameter for which 'pass by reference' is defined cannot be changed in the function module.
EXPORTING parameters are output parameters. When the function module is called, a suitable actual parameter can be specified for every output parameter. The content of an output parameter that is defined for 'pass by value' is passed to the actual parameter if the function module is completed without errors. An output parameter that is defined for pass by reference is not initialized when the function module is called.
CHANGING parameters are input and output parameters. When the function module is called, a suitable actual parameter must be specified for every non-optional input or output parameter. When the function module is called, the content of the actual parameter is passed to the input/output parameter, and when the function module is completed, the content of the input/output parameter is passed to the actual parameter.
TABLES parameters are obsolete table parameters.
Note
The formal parameters of a function module can be registered as global parameters in Function Builder, however this is obsolete.
Exception
The exceptions of a function module are defined on the Exceptions tab page in Function Builder. Here you can select exception classes to define whether class-based exceptions are declared or non-class-based exception are defined. Class-based exceptions are represented in the above syntax by RAISING, and non-class-based exceptions are represented by EXCEPTIONS.
The addition RAISING is used to declare class-based exceptions that can be propagated from the function module to the caller. Exceptions in the categories CX_STATIC_CHECK and CX_DYNAMIC_CHECK must be explicitly declared, otherwise a propagation can lead to an interface violation. A violation of the interface raises the handleable exception CX_SY_NO_HANDLER. Exceptions of the category CX_NO_CHECK are always declared implicitly and with the RESUMABLE addition. The declaration of exceptions of the category CX_STATIC_CHECK is checked statically in the syntax check. For exceptions of the category CX_DYNAMIC_CHECK, the check is not performed until runtime. In a function module in which class-based exceptions are declared with the RAISING addition, the statement CATCH SYSTEM-EXCEPTIONS cannot be used. Instead, the relevant handleable exceptions should be handled in a TRY control structure.
The RESUMABLE addition declares an exception that can be propagated as a resumable exception. This addition has no relevance to a non-resumable exception. The addition does not have any effect on a non-resumable exception. If a resumable exception is propagated with RAISING without the addition RESUMABLE, it thus becomes non-resumable. If a superclass is declared as resumable, any subclasses must also be declared as resumable.
The addition EXCEPTIONS is used to define a list of non-class-based exceptions that can be triggered in the function module using the statements RAISE or MESSAGE RAISING. Exceptions defined in this way are (as with formal parameters) bound to the function module and cannot be propagated. If an exception of this type is raised in a function module, and no return value has been assigned to it with the homonymous addition EXCEPTIONS of the CALL FUNCTION statement when the call was made, this leads to a runtime error. In a function module in whose interface non class-based exceptions are defined, you are not allowed to use the statement RAISE EXCEPTION to raise class-based exceptions.
You can select the Resumable column in Function Builder to flag a class-based exception as a resumable exception. This places the RESUMABLE addition behind RAISING in the syntax above.
Note
For new developments, SAP recommends that you work with class-based exceptions that are independent of the function module.
Properties of Interface Parameters
When an interface parameter p1, p2... is defined in Function Builder, properties are determined for the parameter which are reflected in the syntax of parameters and table_parameters.
Syntax
... { VALUE(p1) | p1 } [ {TYPE [REF TO] type} | like_structure [OPTIONAL|{DEFAULT def1}] ] { VALUE(p2) | p2 } [ {TYPE [REF TO] type} | like_structure [OPTIONAL|{DEFAULT def2}] ] ...
The syntax and semantics of VALUE, TYPE, OPTIONAL, and DEFAULT are mainly the same as in the definition of method interfaces by [CLASS-]METHODS. The obsolete option like_structure also exists, which uses LIKE or STRUCTURE to type interface parameters.
Type of Parameter Passing
There are two types of parameter passing: pass by reference and pass by value. Pass by value is selected in Function Builder by selecting pass by value and differs from pass by reference in the above syntax by VALUE( ) being specified.
In pass by reference, the formal parameter points directly to the actual parameter, so that changes to the formal parameters have an immediate effect on the actual parameter.
In pass by value, when the function module is called, the formal parameter is created as a copy of the actual parameter (in IMPORTING and CHANGING parameters), or initial (in EXPORTING parameters) in the stack. In CHANGING and EXPORTING parameters, the formal parameter is copied to the actual parameter when returning from the function module.
Note the following for the different types of parameter:
In IMPORTING, EXPORTING, and CHANGING parameters, pass by reference and pass by value are possible, in TABLES parameters, only pass by reference is possible.
IMPORTING parameters passed by reference must not be overwritten in the function module.
An EXPORTING parameter passed by reference behaves like a CHANGING parameter, which means that EXPORTING parameters passed by reference are not initialized when the function module is called. For this reason, no read access to these parameters should be permitted before the first write access. In addition, be careful when adding content to such parameters as, for example, when inserting rows into internal tables.
Typing of Interface Parameters
The parameter interface of a function module is public across the system. Interface parameters can therefore only be typed with reference to data types from ABAP Dictionary or from the public visible section of global classes. In Function Builder, interface parameters can be typed selecting either TYPE or TYPE REF TO or by entering LIKE.
Typing with TYPE [REF TO] is the recommended typing for interface parameters of function modules. It takes place when TYPE or TYPE REF TO is selected in Function Builder. For IMPORTING, EXPORTING, and CHANGING parameters, any predefined ABAP type (complete or generic), or any data type from ABAP Dictionary or from the public visibility section of a global class can be specified after TYPE. After TYPE REF TO, the generic data type data, a non-generic data type, or an object type can be specified and the interface parameter is typed as a reference variable. The typing check is performed in the same way as for methods.
Note
Without an explicit typing, a formal parameter is typed implicitly with the fully generic type any.
Optional Parameters
IMPORTING, CHANGING, and TABLES parameters can be made optional by the selection of optional in Function Builder. EXPORTING parameters are always optional. IMPORTING and CHANGING parameters can be assigned a replacement parameter (default value in the Function Builder). In the above syntax, this is expressed using the additions OPTIONAL or DEFAULT. For an optional parameter, no actual parameter must be entered when the function module is called. While a formal parameter with the addition OPTIONAL is then initialized according to its type, a formal parameter with the addition DEFAULT assumes the value and type of the replacement parameter def1 def2 ....
If no actual parameter is specified for a generically typed formal parameter with the addition OPTIONAL when it is called, the type of the formal parameter is completed according to fixed rules.
Note
Within a function module, the logical expression IS SUPPLIED can be used to check if an optional formal parameter was assigned an actual parameter when it was called.
ENDFUNCTION
Short Reference
Syntax
ENDFUNCTION.
Effect
The statement ENDFUNCTION closes a function module started with FUNCTION.
Dialog Modules
Dialog modules help prepare and process screens of the dynpro. You cannot declare local data types and data objects within a dialog module, whose functionality is implemented between the statements MODULE and ENDMODULE. All declarative statements in dialog modules belong to the global data declaration of the ABAP program and are visible in all following processing blocks. A dialog module works with the global data types and data objects of the framework program and therefore should not contain its own declarations.
MODULE
Short Reference
Syntax
MODULE mod {OUTPUT|[INPUT]}. ... ENDMODULE.
Addition:
... OUTPUT|[INPUT]
Effect
The MODULE statement defines a mod dialog module. The naming conventions apply to the name mod. The functions of a mod dialog module are implemented between the MODULE ad ENDMODULE statements.
A dialog module is called using the MODULE statement with the same name of the dynpro flow logic of any ABAP program dynpro.
Addition
... OUTPUT|[INPUT]
Effect
The OUTPUT and INPUT additions determine whether the dialog module can be called for the PBO event or for the PAI event. The INPUT addition is the default and can therefore also be omitted, although this is not recommended for the readability of the program. Two dialog modules with the same name can be defined in a program, if one of them has the OUTPUT addition and the other has the INPUT addition, which is not recommended again for reasons of readability.
Note
For data encapsulation reasons, we recommend that you implement little functionality in dialog modules, and that you call procedures instead.
ENDMODULE
Short Reference
Syntax
ENDMODULE.
Effect
The ENDMODULE statement closes a module definition introduced with MODULE.
Event Blocks
Event blocks are used to handle events in the ABAP runtime environment. They are introduced by an event key word and finished by the next processing block. Since there is no closing statement, we recommend that you flag the end of an event block with a comment line.
Within an event block, no local data types or data objects can be declared. All declarative statements in event blocks belong to the ABAP program, and are visible in all subsequent processing blocks. An event block works with the global data types and data objects of the framework program, and therefore should not contain any of its own declarations. Exception: The event blocks AT SELECTION-SCREEN ... and GET ... are implemented internally as procedures and can contain local data).
For reasons of data encapsulation, it is advisable to only implement a few functions in event blocks, and to call methods instead.
The following events exist:
Program constructor event This event occurs in all program types, except for class pools and interface pools.
Reporting Events These events only occur in executable programs.
Selection screen and list events occur during selection screen processing or list processing.
Notes
When the execution of each event block is completed, the statement NEW-LINE is executed.
With the exception of AT SELECTION-SCREEN ... and GET ... event blocks can be listed multiple times in a program. Event block START-OF-SELECTION can also be implicitly listed multiple times. Whenever an event occurs, all associated event blocks are executed in the order of their occurrence. Where event blocks are implicitly listed multiple times, the extended program check posts a warning.
program constructor
The program constructor can be used to initialize the global data of a program. It is initiated with the statement LOAD-OF-PROGRAM
. The related event occurs when a program is loaded into the internal session .
Note
Class pools do not have a program constructor, since the static constructor from the global class defined in the class pool can be used instead.
LOAD-OF-PROGRAM
Short Reference
Syntax
LOAD-OF-PROGRAM.
Effect
This event keyword defines the program constructor of an executable program, a module pool, a function group, or a subroutine pool. The program constructor is an event block whose event is triggered by the ABAP-
runtime environment when one of the executable programs mentioned above is loaded into the internal session.
When a program is called using SUBMIT or using a transaction code, then (at every call) a new internal session is opened and the event block is executed once at every call. You can initialize global data objects of the program here. The event block must be fully executed, otherwise a runtime error occurs. This means that statements can be specified that exit the event block without returning to it.
The first time an external procedure (subroutine or function module) or a subscreen is called, the framework program of the called procedure is loaded into the internal session of the caller, thus triggering the event LOAD-OF-PROGRAM. The event block is executed before the called procedure. Each time a procedure of the same framework program is called again by a caller of the same internal session, the event LOAD-OF-PROGRAM is not triggered.
Notes
The event LOAD-OF-PROGRAM should mainly be used to initialize global data when calling external procedures or transactions. If you call executable programs using SUBMIT, we recommend that you use the event INITIALIZATION, since the start values for parameter and selection criteria are set after LOAD-OF-PROGRAM (see program flow after SUBMIT).
If a program is only loaded because declarations are required from it, such as when using absolute type names, the LOAD-OF-PROGRAM event is not triggered. The program constructor is only executed if an executable unit of the program is called afterwards.
Class pools do not have a program constructor, since the static constructor from the global class defined in the class pool can be used instead.
Reporting Events
Event key words for reporting events include:
INITIALIZATION ,
START-OF-SELECTION ,
GET node (for logical databases only),
END-OF-SELECTION (for logical databases only).
Reporting events occur in a predefined sequence and only in executable programs started using SUBMIT. In general, every executable program is implicitly started using SUBMIT. Only when a regular transaction code (not a reporting transaction) is used for the start (or external calls of their procedures), is a SUBMIT not triggered.
When an executable program is associated with a logical database, the assigned subroutine is executed in the database program before a reporting event is triggered.
INITIALIZATION
Short Reference
Syntax
INITIALIZATION.
Effect
This event keyword defines an event block for initializing an executable program. The associated event is triggered by the ABAP runtime environment during the flow of an executable program, directly after LOAD-OF-PROGRAM and before the selection screen processing of any existing standard selection screen. This gives you the one-time opportunity to initialize the input fields of the selection screen, including those defined in the logical database linked with the program.
Note
When an executable program defines a standard selection screen, it is called again by the ABAP runtime environment after execution, which triggers the INITIALIZATION event again. In this case, initializing parameters or selection criteria of the selection screen has no effect, because they are automatically supplied with the preceding user inputs from the selection screen during the selection screen event AT SELECTION-SCREEN OUTPUT. To explicitly initialize the selection screen for each call, you must use the event AT SELECTION-SCREEN OUTPUT.
START-OF-SELECTION
Short Reference
Syntax
START-OF-SELECTION.
Effect
This event keyword defines the standard processing block of an executable program. The associated event is triggered by the ABAP runtime environment during the running of an executable program after any standard selection screens have been processed.
In an executable program, all statements that are not declarations and that are listed before the first explicit processing block, or if the program does not contain any explicit processing blocks, then all functional
statements of the program, are assigned to an implicit event block START-OF-SELECTION, which is inserted before any explicit START-OF-SELECTION event blocks.
Note
If the program is associated with a logical database, preparatory tasks can be performed in START-OF-SELECTION before the logical database imports the data. If the program is not associated with a logical database, this event block becomes a type of "main program" from which procedures or screens are called.
Example
The following are three executable programs with exactly the same functions:
The first program contains an explicit event block START-OF-SELECTION and shows the recommended spelling.
REPORT test_start_of_selection.
DATA text TYPE string.
START-OF-SELECTION. text = `Hello World!`. WRITE text.
In the second program, an assignment is inserted before the first processing block, which forms a second implicit event block START-OF-SELECTION before the explicit event block.
REPORT test_start_of_selection.
DATA text TYPE string.
text = `Hello World!`.
START-OF-SELECTION. WRITE text.
In the third program, there is no explicit processing block. All statements implicitly form the event block START-OF-SELECTION.
REPORT test_start_of_selection.
DATA text TYPE string.
text = `Hello World!`. WRITE text.
The third program has exactly the same meaning as the first program. The second program, in contrast, would have the following form if expressed explicitly:
REPORT test_start_of_selection.
DATA text TYPE string.
START-OF-SELECTION. text = `Hello World!`.
START-OF-SELECTION. WRITE text.
This means that if the second program contained a WRITE statement before the explicit event block, it would behave differently to the first or third programs with the same WRITE statement, as the statement NEW-LINE is executed at the end of the implicit event block.
GET node
Short Reference
Syntax
GET node [LATE] [FIELDS f1 f2 ...].
Alternatives:
1. GET node [FIELDS f1 f2 ...].
2. GET node LATE [FIELDS f1 f2 ...].
Addition:
... FIELDS f1 f2 ...
Effect
The statement GET is only intended for use in executable programs that are associated with a logical database. You can use GET to handle two types of events after submitting these types of executable programs:
Read events of the logical database
Closing a hierarchy level in the logical database
If a list is written during a GET event, an automatic line feed is created first.
Notes
The event blocks after GET are implemented internally as procedures. Declarative statements in GET event blocks create local data.
If logical databases are no longer used, then you no longer need to use the statement REJECT either.
Alternative 1
GET node [FIELDS f1 f2 ...].
Effect
This statement defines an event block whose result is triggered by the ABAP runtime environment after submitting an executable program, if the logical database with which the program is associated provides data in the work area node. The node work area must be declared with the NODES statement (or TABLES). The data can be processed in the event block.
GET node also controls the behavior of the logical database.
The logical database reads all data from all nodes that are not defined for field selection using SELECTION-SCREEN FIELD SELECTION in the logical database and are located on the access path of the logical database superior to node. This is independent of whether GET event blocks have been defined for these nodes or not. However, only the data of those nodes can be accessed for which a work area was declared using the NODES (or TABLES) statement.
If a field selection is defined in the logical database for those nodes on the access path of the logical database superior to node (and for which no GET event blocks are defined), then all data is read only for the nodes for which a NODES (or TABLES) statement exists. For nodes without a NODES (or TABLES) statement, only the key fields are read, because the logical database needs the key fields to build the access path.
After the event block GET is ended regularly, the nodes that are inferior in the hierarchical structure of the logical database are processed (see PUT).
At the end of a hierarchy level of the logical database, all fields of the work area node are set to hexadecimal null.
Alternative 2
GET node LATE [FIELDS f1 f2 ...].
Effect
This statement defines an event block whose result is triggered by the ABAP runtime environment after submitting an executable program, when the logical database has read all records of node node. For node and FIELDS, the same applies as for the previous variant. You can use this event block for final processing actions on the hierarchy level of the node.
Addition
... FIELDS f1 f2 ...
Effect
The addition FIELDS specifies that the logical database reads only the specified fields f1 f2 ... and the key fields for node node. As a prerequisite, the node must be defined for field selection in the logical database using SELECTION-SCREEN FIELD SELECTION. The content of the other fields of the work area is set to hexadecimal null.
Example
See Example for Reporting Events
END-OF-SELECTION
Short Reference
Syntax
END-OF-SELECTION.
Effect
The statement END-OF-SELECTION is only intended for use in executable programs that are associated with a logical database. The statement defines an event block whose event is triggered as follows by the ABAP runtime environment during the process flow of the executable program:
If the executable program is associated with a logical database, END-OF-SELECTION is triggered (if the logical database has fully completed its work).
In an executable program without a logical database, END-OF-SELECTION is triggered directly after START-OF-SELECTION.
Notes
In this event block, all data read by the logical database can be processed in summary form.
In an executable program without a logical database, there is no need to implement the event block END-OF-SELECTION.
Example
See Example for Reporting Events
Selection Screen and List Events
Selection screen and list events are events from classical screen processing, which are converted by the ABAP runtime environment into ABAP events and are handled directly in the ABAP program instead of in the dynpro flow logic.
Selection screen eventsoccur during selection screen processing.
List events occur during classical list processing.
They are described in their respective environment.
Source Code Modules
Source code modularization is the segmentation of a program's source code into individual units. Modularization operates independently of the segmentation of an ABAP program into processing blocks.
Source code modules are implemented as either include programs or as macros. Include programs are used to structure large programs, whereas macros are used to recycle individual parts of programs.
Include Programs
Include programs are used to split ABAP source code into individual repository objects. An ABAP program can be created in the program attributes using the program type include program. Include programs do not need to contain introductory statements for programs and cannot be generated independently from the ABAP compiler. When using the statement INCLUDE, however, include programs can be integrated into compilation units.
An include program must contain complete statements. It can include other include programs but not it cannot include itself. An include program does not need to contain complete processing blocks.
Notes
You should use include programs to modularize the source code of a single ABAP program. We do not recommend reusing an include program in multiple ABAP programs.
For the global declaration section of an ABAP program, a special top include is available which is included in the compilation of individual include programs of a program.
Framework programs such as class pools or function groups are organized in include programs automatically by ABAP Workbench.
INCLUDE
Short Reference
Syntax
INCLUDE incl [IF FOUND].
Effect
The statement INCLUDE includes the include program incl at this position in the source code. In syntax checks and when the programs is generated by ABAP Compiler, statement is replaced by the source code of the include program. The included INCLUDE program must consist of full statements.
If the specified include program does not exist, a syntax error is produced. This error message can be suppressed by specifiying the addition IF FOUND.
Programming Guidelines
Use include programs to modularize source code.
Do not use include programs more than once.
Notes
The statement INCLUDE is the only statement that can be used instead of a statement that introduces a program at the first position of a program. The requirement is that, after the include program is resolved, a statement that introduces a program is located at the beginning of the including program.
ABAP Workbench supports the automatic creation of include programs for specific program parts, such as the top include for global declarative statements. Always use the naming conventions proposed by ABAP Workbench. The top include can contain only declarative statements and is respected when individual include programs of a program are compiled.
In Repository Browser in ABAP Workbench's Object Navigator, the INCLUDE programs bound by a program are executed as the program's subnodes.
Example
These lines show the framework program of the function group ABAP_DOCU. This function group displays the keyword documentation on the Application Server ABAP. It only contains INCLUDE statements which embed
the actual source code. labap_docutop itself is made up of include programs for the individual declarations (global data and class declarations local to the program).
*&----------------------------------------------------------------* *& Function Group SAPLABAP_DOCU *&----------------------------------------------------------------*
INCLUDE labap_docutop. " Global Declarations
INCLUDE labap_docue00. " Load of Program
INCLUDE labap_docuuxx. " Function Modules
INCLUDE labap_docuo01. " PBO Modules
INCLUDE labap_docui01. " PAI Modules
INCLUDE labap_docue01. " Handling of Runtime-Events
INCLUDE labap_docup01. " Class implementations INCLUDE labap_docup02. INCLUDE labap_docup03. INCLUDE labap_docup04.
INCLUDE labap_docut99. " Unit tests
Macros
Macros enable source code modularization within an ABAP program. They are
defined between the statements DEFINEand END-OF-DEFINITION and
included by their name being specified.
DEFINE
Short Reference
Syntax
DEFINE macro. ... &1 ... &9 ... END-OF-DEFINITION.
Effect
The statement DEFINE defines a macro macro. The following naming conventions macro apply and ABAP words cannot be used. Macros can be defined in all program types, particularly in type groups.
Any number of ABAP statements can come between the statements DEFINE and END-OF-DEFINITION, except for DEFINE, END-OF-DEFINITION, and program-initiating statements. These statements form a source code section that can included under the name macro. The definition of a macro is not bound to the limits of processing blocks.
The validity of a macros is determined buy its position in the compilation unit. It can be inserted at any point after END-OF-DEFINITION in the same compilation unit. If another macro is defined with the same name, it overwrites the previous macro from its new position.
Within a macro, you can use up to nine placeholders &1 ... &9 instead of ABAP words and operands. These placeholders must be replaced by fixed words when the macro is inserted.
Notes
Breakpoints cannot be inserted into macros and the statements of a macro cannot be performed as individual steps in ABAP Debugger.
Macros must not include more than a few lines, and should be used sparingly, since it is very difficult to analyze macro errors. Instead of macros, use internal procedures.
Apart from in the code text of a program and in type groups, macros can also be stored as cross-program macros in the table TRMAC. However no new macros should be defined in the TRMAC table. An example of a macro stored in the TRMAC table is break, which sets a breakpoint depending on the current user name in the sy-unamesystem field.
Example
See Inserting Macros and Macros.
END-OF-DEFINITION
Short Reference
Syntax
END-OF-DEFINITION.
Effect
The statement END-OF-DEFINITION closes a macro definition that was initiated by DEFINE.
Inserting Macros
Syntax
macro [p1 p2 ... ].
Effect
If a macro is executed instead of a valid ABAP keyword, as the first word in an ABAP statement, its statements are included at this position in the source text. Suitable ABAP words or operands p1 p2 ... must be transferred to all of the macro's placeholders. The specified operands p1 p2 ... replace the placeholders sequentially.
The ABAP Compiler searches for a macro specified in a program, first in the preceding source text of the same compilation unit and then in the type groups which are used for the program. Local macros of the program hide macros of the same name in type groups.
A macro can insert other macros but not itself.
Notes
Previously, a specified macro not defined in the current program was only searched for in explicitly loaded type groups using the TYPE-POOLS statement. The search now covers all usable type groups.
If the ABAP Compiler does not find a specified macro in the current program or in a type group, it searches in the TRMAC table. Macros in the TRMAC table usually follow different name conventions to those in type groups and therefore nothing should be hidden.
Example
In this example, the two macros operation and output are defined. output is nested in operation. operation is called three times with different parameters. Note how the placeholders &1, &2, ... are replaced in the macros.
DATA: result TYPE i, n1 TYPE i VALUE 5, n2 TYPE i VALUE 6.
DEFINE operation. result = &1 &2 &3. output &1 &2 &3 result. END-OF-DEFINITION.
DEFINE output. write: / 'The result of &1 &2 &3 is', &4. END-OF-DEFINITION.
operation 4 + 3.
operation 2 ** 7. operation n2 - n1.
