Você está na página 1de 24

ABAP Keyword Documentation

• 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.

Você também pode gostar