Modularisation

Modularisation
Branches and Loops

IF CASE
CASE <f>.
IF <condition1>.
WHEN <f1>.
<statement block>
<statement block>
ELSEIF <condition2>.
WHEN <f2>.
<statement block>
<statement block>
......
......
ELSE.
WHEN OTHERS.
<statement block>
<statement block>
ENDIF.
ENDCASE.
Unlimited nesting is allowed. An EVENT keyword may not be inside of block.
DO WHILE
DO [<n> TIMES] [VARYING <f> FROM WHILE <condition> [VARY <f> FROM
<f1> NEXT <f2>]. <f1> NEXT <f2>].
<statement block> <statement block>
...... ......
[CONTINUE.] [CONTINUE.]
[EXIT.] [EXIT.]
[CHECK <condition>. [CHECK <condition>.
<statement block>] <statement block>]
ENDDO. ENDWHILE.
Unlimited nesting is allowed. An EVENT keyword may not be inside of block.
<n> can be literal or a variable. If <n> <=0, the system does not process the loop.
SY-INDEX contains the number of times the loop has been processed.
<f>, <f1>, <f2> must be a series of equidistant fields of the same type and length in
memory. In the first loop pass, <f1> is assigned to <f>; in the second loop pass <f2> is
assigned to <f>; and so on. Several VARYING|VARY options can be used in one DO|
WHILE statement. If you change the control variable <f> inside the DO loop, the system
changes the corresponding field <fi> automatically. If loop processed more times than the
number of variables <fi>, this may result in a runtime error.
Terminating Loops.
CONTINUE.
Terminates a loop pass immediately without any condition, continues with the next loop
pass.

ABAP Training Page 1 of 8

 Modularisation

EXIT.
Acts in following sequence:
1. Terminates a loop entirely without any condition and continues the processing
after the closing statement (ENDDO, ENDWHILE, ENDSELECT). Within nested loops,
leaves the current loop;
2. Leaves the current AT processing block and branches to the processing block of
the next occurring event;
3. Leaves any processing block (except of AT events) immediately and branch to
the output screen;
4. Terminates a subroutine without any condition.
CHECK <condition>.
Acts in following sequence:
1. For a loop, if the condition is false, skips all the remaining statements in the
current statement block and continues with the next loop pass;
2. For GET event, if the condition is false, equivalent to REJECT. (Leaves the
processing block of a GET event and processes the next GET event at the same
hierarchical level of the logical database.);
3. For processing block, if the condition is false, leaves the processing block and
branches to the processing block of the next occurring event;
4. For a subroutine, if the condition is false, terminates the subroutine.

ABAP Training Page 2 of 8

 Modularisation

Events
All statements between two event keywords or between an event keyword and a FORM
statement are a processing block. When an event occurs, the system processes the
processing block after the corresponding event keyword. Each statement in an ABAP/4
report program is part of a processing block or a subroutine. Statements which do not
follow an event keyword or a FORM-ENDFORM block are automatically part of the
processing block of the default event START-OF-SELECTION.
Note. All statements between an ENDFORM statement and an event keyword or between
an ENDFORM statement and the end of the program are never processed. Do not place
any statements there. Place all subroutines at the end of your program.
Events that occur at runtime of a report program which
uses logical databases, or
has selection screens and processes tables (exept GET events):
INITIALIZATION.
Point before the selection screen is displayed.
AT SELECTION-SCREEN.
Point after processing user input on the selection screen while the selection screen is still
active.
START-OF-SELECTION.
Point after processing the selection screen and before accessing database tables using a
logical database.
GET <table> [FIELDS <f1> <f2> ...].
Point at which the logical database (LDB) offers a line of the database table <table>. The
LDB reads all columns from all database tables which are not designated for field
selection in the LDB and which are superior to <table> on the access path of the LDB,
even if GET for these tables are not specified. However, only the data of tables declared
by TABLES can be accessed. From tables that are not declared by TABLES system reads
only the key fields (the LDB needs the key fields to built up the access path).
GET <table> LATE [FIELDS <f1> <f2> ...].
Point after processing all tables which are hierarchically subordinate to the database table
<table> in the structure of the logical database.
END-OF-SELECTION.
Point after processing all lines offered by the logical database.
The following events occur during the processing of the output list of a report
program:
Events Control in Interactive Lists.
Terminating Events Processing Blocks:
STOP.
Leaves any processing block immediately and branches to the END-OF-SELECTION
processing block.
REJECT [<dbtab>].
 Leaves the processing block of a GET event and processes the next GET event of
a superior hierarchical level of the logical database <dbtab>
 Leaves the processing block of a GET event and processes the next GET event at
the same hierarchical level of the logical database.
See also: EXIT, CHECK.

ABAP Training Page 3 of 8

 Modularisation

Source Code Modules

Using Macros.
DEFINE <macro>.
<statements>
END-OF-DEFINITION.
Defines <macro>. The <statements> can contain up to 9 placeholders: &1, &2, ... &9.
<macro> [<p1> <p2> ... <p9>].
Calls <macro> (System replaced macro during generation of the program). Macro can
call another macro, but cannot call itself.
Using Include Programs.
INCLUDE <name_of_include_program>
Inserts the source code <name_of_include_program> into the ABAP/4 program during
the syntax check and during generation.
 INCLUDE statement must be whole on one line and only on this line;
 The INCLUDE program must consist of complete statements (and comments);
Service report RSINCL00 can be used to generate reference list for included programs.

ABAP Training Page 4 of 8

Modularisation

Subroutines.

Defining Subroutines.
FORM <subroutine> [<parameters>].
<statements>
ENDFORM.
Calling Subroutines.
Internal subroutines have the source code in the calling ABAP/4 program:
PERFORM <subroutine> [<parameters>].
PERFORM (<subrname>) [<parameters>].
Specifies the subroutine name at runtime.
PERFORM <subroutine> ON COMMIT [LEVEL <n>].
Calls the subroutine later on a first encountered COMMIT WORK statement. The
subroitine is called only once even if call performed many times. LEVEL <n> (literal or
constant, default is 0) defines order of execution of subroutines on COMMIT WORK.
The subroutines are called in ascending level order, or in order of calls if level the same.
External subroutines have the source code in another ABAP/4 program:
PERFORM <subroutine>(<program>) [<parameters>] [IF FOUND].
PERFORM <subroutine> IN PROGRAM <program> [<parameters>] [IF FOUND].
IF FOUND - call subroutine only if found in program, otherwise skip call.
PERFORM (<subrname>) IN PROGRAM (<progname>) [<parameters>] [IF
FOUND].
Specifies the subroutine and/or program names at runtime.
PERFORM <idx> OF <form2> ... <formn>.
Calls a subroutine that has index <idx> (literal or variable) from the list.
Passing Data to/from Subroutines.
Declaring Data as Common Part.
DATA: BEGIN OF COMMON PART [<name>].
<data declaration>
END OF COMMON PART [<name>].
<name> is needed if several common parts used. It is better way to use common parts
placed in INCLUDE. Table work areas defined in TABLES are common automatically.
Parameters.
[TABLES <list of internal tables with or without header line>]
[USING <list of parameters - all data types (including internal tables) and|or field
symbols>]
[CHANGING <list of parameters - all data types (including internal tables) and|or
field symbols>]
Actual parameters can be specified with variable offset and length specifications.
Methods of Passing Data Using Parameters:
By Reference.
FORM ... [USING <fi1> ... <fin>] [CHANGING <fo1> ... <fon>] ...
PERFORM ... [USING <ai1> ... <ain>] [CHANGING <ao1> ... <aon>] ...
In this case USING and CHANGING are equivalent.
By Value.

ABAP Training Page 5 of 8

 Modularisation

FORM ... USING ... VALUE(<fii>) ...

PERFORM ... USING ... <aii> ...
New local object <fii> created and processed for each call.
By Value and Result.
FORM ... CHANGING ... VALUE(<fii>) ...
PERFORM ... CHANGING ... <aii> ...
New local object <fii> created and processed for each call. Only when the subroutine has
completed successfully, system pass the current value of <fii> to <aii>. If the subroutine
processing is stopped because of a dialog message, the actual parameter <aii> remains
unchanged.
Typing Formal Parameters:
Type of a formal parameter can be specified in the FORM statement using TYPE <type>
or LIKE <object> after this parameter in the TABLES, USING, or CHANGING lists.
While PERFORM system checks types compatibility of the actual and formal parameters.
The compatibility rules are the same as for Field Symbols assignment. There are no type
conversions. If types are incompatible, the system outputs an error message during the
syntax check for internal subroutine calls or reacts with a runtime error in the case of
external subroutine calls.
Passing Fields Strings:
To pass a field string into subroutine and access components of this field string in this
subroutine - type of the field string must be specified. For internal subroutines - directly,
for external - also in the program where the called subroutine placed (can be done using
Type Groups, Includes or ABAP/4 Dictionary Structures).
Passing Internal Tables:
Can be passed after TABLES (always be Reference), USING or CHANGING. Type must
be specified also for access components separately (as for Field Strings). If actual
parameter table has no header line, but formal parameter table with header line, the
header line will be automatically created in the subroutine for this table.
Defining Local Data in Subroutines.
Dynamic Local Data Types and Objects.
TYPES, DATA - define automatic objects that newly created for each call and deleted
after exit.
Static Local Data Types and Objects.
STATICS - defines static objects that initialized for first call and keep their values after
exit.
LOCAL <f>.
Preserves the value of a global data object from being changed inside a subroutine (for
example, a work area of a database table defined using TABLES). Instead a local copy of
the <f> used inside of subroutine.
Terminating Subroutines.
See EXIT, CHECK.

Function Modules.

 Function modules are special external subroutines stored in a central library.

ABAP Training Page 6 of 8

 Modularisation

 Can be created users own function modules.

 The main difference between a function module and a normal ABAP/4 subroutine
is a clearly defined interface for passing data.
 The calling program and the called function module have separate work areas for
ABAP/4 Dictionary tables.
 Several function modules can be combined to a function group in the program
library with the attribute type F with definition of global data that can be accessed from
all function modules of one function group.

Interfaces:
Import parameter:

Pass data from the calling program to the function module. Cannot be overwritten, even
when passed by reference.
Export parameters:

Pass data from the function module back to the calling program. Always optional.
CHANGING parameter:

Passed by reference or by value and result. Act simultaneously as import and export
parameters. They change the value passed to the function module and return it to the
calling program.
Table parameters:

Internal tables. Treated like changing parameters and are always passed by reference.
Exception:

Used to handle error scenarios which can occur in function modules.

Proposal - default value for optional parameters.
Reference field|structure, Reference type - used for typing of formal parameters.
Calling Function Modules:
CALL FUNCTION <module_name>
[EXPORTING <f1> = <a1> ... <fn> = <an>]
[IMPORTING <f1> = <a1> ... <fn> = <an>]
[CHANGING <f1> = <a1> ... <fn> = <an>]
[TABLES <f1> = <a1> ... <fn> = <an>]

ABAP Training Page 7 of 8

Modularisation

[EXCEPTIONS <e1> = <r1> ... <en> = <rn> [ERROR_MESSAGE = <rE>]

[OTHER = <rO>]].
EXPORTING - the formal parameters must be declared as import parameters in the
function module.
IMPORTING - the formal parameters must be declared as export parameters in the
function module.
EXCEPTIONS - <ri> is a numeric literal that is assigned to SY-SUBRC if the exception
is raised. <rE> is used for additional exception ERROR_MESSAGE if a message of
types A, E was issued in the function module without RAISING option.
OTHERS - used to handle all exceptions that are not specified explicitly in the list. The
same number <ri> can be used for several exceptions.
Programming Function Modules:
FUNCTION <module_name>
....
RAISE <exception>.
....
MESSAGE ... RAISING <exception>.
....
ENDFUNCTION.
If an internal subroutine is needed, the program code of internal subroutines can be
placed directly behind the ENDFUNCTION statement of a module. This subroutines can
be called from all modules of the function group, but for clarity, should be called only
from the function module behind which it is written.
To create internal subroutines that can be called from all modules of one function group
<fgrp>, use special INCLUDE programs L<fgrp>F<xx>. You can open these INCLUDE
programs easily by double clicking their names in the main program SAPL<fgrp> after
selecting Main program on the Function Library->Maintain Function Modules screen.

ABAP Training Page 8 of 8