BC ABAP Programming PHẦN 4 pptx

BC - ABAP Programming SAP AG
The Parameter Interface
462 December 1999
screen, that is, in a PAI module, in the AT SELECTION-SCREEN event, or after an interactive list
event.
Specifying the Type of Formal Parameters
Formal parameters can have any valid ABAP data type. You can specify the type of a formal
parameter, either generically or fully, using the TYPE or LIKE addition. If you specify a generic
type, the type of the formal parameter is either partially specified or not specified at all. Any
attributes that are not specified are inherited from the corresponding actual parameter when the
subroutine is called. If you specify the type fully, all of the technical attributes of the formal
parameter are defined with the subroutine definition.
The following remarks about specifying the types of parameters also apply to the parameters of
other procedures (function modules and methods).
If you have specified the type of the formal parameters, the system checks that the
corresponding actual parameters are compatible when the subroutine is called. For internal
subroutines, the system checks this in the syntax check. For external subroutines, the check
cannot occur until runtime.
By specifying the type, you ensure that a subroutine always works with the correct data type.
Generic formal parameters allow a large degree of freedom when you call subroutines, since you
can pass data of any type. This restricts accordingly the options for processing data in the
subroutine, since the operations must be valid for all data types. For example, assigning one
data object to another may not even be possible for all data types. If you specify the types of
subroutine parameters, you can perform a much wider range of operations, since only the data
appropriate to those operations can be passed in the call. If you want to process structured data
objects component by component in a subroutine, you must specify the type of the parameter.
Specifying Generic Types
The following types allow you more freedom when using actual parameters. The actual
parameter need only have the selection of attributes possessed by the formal parameter. The
formal parameter adopts its remaining unnamed attributes from the actual parameter.
Type specification Check for actual parameters

No type specification
TYPE ANY
The subroutine accepts actual parameters of any type. The
formal parameter inherits all of the technical attributes of the
actual parameter.
TYPE C, N, P, or X The subroutine only accepts actual parameters with the type C,
N, P, or X. The formal parameter inherits the field length and
DECIMALS specification (for type P) from the actual parameter.
TYPE TABLE The system checks whether the actual parameter is a standard
internal table. This is a shortened form of TYPE STANDARD
TABLE (see below).
TYPE ANY TABLE The system checks whether the actual parameter is an internal
table. The formal parameter inherits all of the attributes (line type,
table type, key) from the actual parameter.
TYPE INDEX TABLE The system checks whether the actual parameter is an index
table (standard or sorted table). The formal parameter inherits all
of the attributes (line type, table type, key) from the actual
parameter.
TYPE STANDARD TABLE The system checks whether the actual parameter is a standard
internal table. The formal parameter inherits all of the attributes
(line type, key) from the actual parameter.
SAP AG BC - ABAP Programming
The Parameter Interface
December 1999 463
TYPE SORTED TABLE The system checks whether the actual parameter is a sorted
table. The formal parameter inherits all of the attributes (line type,
key) from the actual parameter.
TYPE HASHED TABLE The system checks whether the actual parameter is a hashed
table. The formal parameter inherits all of the attributes (line type,
key) from the actual parameter.

Note that formal parameters inherit the attributes of their corresponding actual parameters
dynamically at runtime, and so they cannot be identified in the program code. For example, you
cannot address an inherited table key statically in a subroutine, but you probably can
dynamically.

TYPES: BEGIN OF LINE,
COL1,
COL2,
END OF LINE.
DATA: WA TYPE LINE,
ITAB TYPE HASHED TABLE OF LINE WITH UNIQUE KEY COL1,
KEY(4) VALUE 'COL1'.
WA-COL1 = 'X'. INSERT WA INTO TABLE ITAB.
WA-COL1 = 'Y'. INSERT WA INTO TABLE ITAB.
PERFORM DEMO USING ITAB.
FORM DEMO USING P TYPE ANY TABLE.

READ TABLE P WITH TABLE KEY (KEY) = 'X' INTO WA.

ENDFORM.
The table key is addressed dynamically in the subroutine. However, the static
address
READ TABLE P WITH TABLE KEY COL1 = 'X' INTO WA.
is syntactically incorrect, since the formal parameter P does not adopt the key of
table ITAB until runtime.
Specifying Full Types
When you use the following types, the technical attributes of the formal parameters are fully
specified. The technical attributes of the actual parameter must correspond to those of the formal
parameter.
Type specification Technical attributes of the formal parameter

TYPE D, F, I, or T The formal parameter has the technical attributes of the predefined
elementary type
TYPE <type> The formal parameter has the type <type> This is a data type defined
within the program using the TYPES statement, or a type from the
ABAP Dictionary
TYPE REF TO <cif> The formal parameter is a reference variable (ABAP Objects) for the
class or interface <cif>
TYPE LINE OF <itab> The formal parameter has the same type as a line of the internal table
<itab> defined using a TYPES statement or defined in the ABAP
Dictionary
LIKE <f> The formal parameter has the same type as an internal data object
<f> or structure, or a database table from the ABAP Dictionary
BC - ABAP Programming SAP AG
The Parameter Interface
464 December 1999
When you use a formal parameter that is fully typed, you can address its attributes statically in
the program, since they are recognized in the source code.
Structured Formal Parameters
Since formal parameters can take any valid ABAP data type, they can also take structures and
internal tables with a structured line type, as long as the type of the formal parameter is
fully
specified
. You can address the components of the structure statically in the subroutine.
Generic Structures
If you pass a structured actual parameter generically to a formal parameter whose type is not
correctly specified, you cannot address the components of the structure statically in the
subroutine. For internal tables, this means that only line operations are possible.
To access the components of a generically passed structure, you must use field symbols, and
the assignment
ASSIGN COMPONENT <idx>|<name> OF STRUCTURE <s> TO <FS>. [Page 214]

<idx> is interpreted as the component number and the contents of <name> are interpreted as a
component name in the generic structure <s>.

DATA: BEGIN OF LINE,
COL1 VALUE 'X',
COL2 VALUE 'Y',
END OF LINE.
DATA COMP(4) VALUE 'COL1'.
PERFORM DEMO USING LINE.
FORM DEMO USING P TYPE ANY.
FIELD-SYMBOLS <FS>.
ASSIGN COMPONENT COMP OF STRUCTURE P TO <FS>.
WRITE <FS>.
ASSIGN COMPONENT 2 OF STRUCTURE P TO <FS>.
WRITE <FS>.
ENDFORM.
The output is:
XY
The components COL1 and COL2 of the structure of P (passed generically) are
assigned to the field symbol <FS>. You cannot address the components directly
either statically or dynamically.
Fitting Parameters into Structures
Instead of using TYPE or LIKE, you can specify the type of a structure as follows:
<p
i
> [STRUCTURE <s>]
where <s> is a local structure in the program (data object, not a type) or a
flat structure from the
ABAP Dictionary. The formal parameter is structured according to <s>, and you can address its
individual components in the subroutine. When the actual parameter is passed, the system only

checks to ensure that the actual parameter is at least as long as the structure. STRUCTURE
therefore allows you to force a structured
view of any actual parameter.

SAP AG BC - ABAP Programming
The Parameter Interface
December 1999 465
DATA: BEGIN OF LINE,
COL1,
COL2,
END OF LINE.
DATA TEXT(2) VALUE 'XY'.
PERFORM DEMO USING TEXT.
FORM DEMO USING P STRUCTURE LINE.
WRITE: P-COL1, P-COL2.
ENDFORM.
The output is:
XY
The string TEXT is fitted into the structure LINE.
The TABLES Addition
To ensure compatibility with previous releases, the following addition is still allowed before the
USING and CHANGING additions:
FORM <subr> TABLES <itab
i
> [TYPE <t>|LIKE <f>]
The formal parameters <itab
i
> are defined as standard internal tables with header lines. If you
use an internal table without header line as the corresponding actual parameter for a formal
parameter of this type, the system creates a

local header line in the subroutine for the formal
parameter. If you pass an internal table with a header line, the table body and the table work
area are passed to the subroutine. Formal parameters defined using TABLES cannot be passed
by reference. If you want to address the components of structured lines, you must specify the
type of the TABLES parameter accordingly.
From Release 3.0, you should use USING or CHANGING instead of the TABLES addition for
internal tables, although for performance reasons, you should not pass them by value.
BC - ABAP Programming SAP AG
Terminating Subroutines
466 December 1999
Terminating Subroutines
A subroutine normally ends at the ENDFORM statement. However, you can terminate them
earlier by using the EXIT or CHECK statement. When you terminate a subroutine with EXIT or
CHECK, the current values of the output parameters (CHANGING parameters passed by value)
are passed back to the corresponding actual parameter.
Use EXIT to terminate a subroutine unconditionally. The calling program regains control at the
statement following the PERFORM statement.

PROGRAM FORM_TEST.
PERFORM TERMINATE.
WRITE 'The End'.
FORM TERMINATE.
WRITE '1'.
WRITE '2'.
WRITE '3'.
EXIT.
WRITE '4'.
ENDFORM.
The produces the following output:
1 2 3 The End

In this example, the subroutine TERMINATE is terminated after the third WRITE
statement.
Use CHECK to terminate a subroutine conditionally. If the logical expression in the CHECK
statement is untrue, the subroutine is terminated, and the calling program resumes processing
after the PERFORM statement.

PROGRAM FORM_TEST.
DATA: NUM1 TYPE I,
NUM2 TYPE I,
RES TYPE P DECIMALS 2.
NUM1 = 3. NUM2 = 4.
PERFORM DIVIDE USING NUM1 NUM2 CHANGING RES.
NUM1 = 5. NUM2 = 0.
PERFORM DIVIDE USING NUM1 NUM2 CHANGING RES.
NUM1 = 2. NUM2 = 3.
PERFORM DIVIDE USING NUM1 NUM2 CHANGING RES.
FORM DIVIDE USING N1 N2 CHANGING R.
CHECK N2 NE 0.
R = N1 / N2.
WRITE: / N1, '/', N2, '=', R.
ENDFORM.
The produces the following output:
3 / 4 = 0.75
SAP AG BC - ABAP Programming
Terminating Subroutines
December 1999 467
2 / 3 = 0.67
In this example, the system leaves the subroutine DIVIDE during the second call
after the CHECK statement because the value of N2 is zero.
If the EXIT or CHECK statement occurs within a loop in a subroutine, it applies to the loop, and

not to the subroutine. EXIT and CHECK terminate loops in different ways (see Loops [Page
246]), but behave identically when terminating subroutines.
BC - ABAP Programming SAP AG
Calling Subroutines
468 December 1999
Calling Subroutines
You call subroutines using the statement
PERFORM [USING <p
i
> ]
[CHANGING <p
i
> ].
Subroutines can call other subroutines (nested calls) and may also call themselves (recursive
calls). Once a subroutine has finished running, the calling program carries on processing after
the PERFORM statement. You can use the USING and CHANGING additions to supply values to
the parameter interface of the subroutine.
Naming Subroutines [Page 469]
Passing Parameters to Subroutines [Page 472]
SAP AG BC - ABAP Programming
Naming Subroutines
December 1999 469
Naming Subroutines
With the PERFORM statement, you can call subroutines which are coded in the same ABAP
program (internal calls), or subroutines which are coded in other ABAP programs (external calls).
You can also specify the name of the subroutine dynamically at runtime, and call subroutines
from a list.
Internal Subroutine Calls
To call a subroutine defined in the same program, you need only specify its name in the
PERFORM statement:

PERFORM <subr> [USING <p
i
> ]
[CHANGING <p
i
> ].
The internal subroutine can access all of the global data of the calling program.

PROGRAM FORM_TEST.
DATA: NUM1 TYPE I,
NUM2 TYPE I,
SUM TYPE I.
NUM1 = 2. NUM2 = 4.
PERFORM ADDIT.
NUM1 = 7. NUM2 = 11.
PERFORM ADDIT.
FORM ADDIT.
SUM = NUM1 + NUM2.
PERFORM OUT.
ENDFORM.
FORM OUT.
WRITE: / 'Sum of', NUM1, 'and', NUM2, 'is', SUM.
ENDFORM.
The produces the following output:
Sum of 2 and 4 is 6
Sum of 7 and 11 is 18
In this example, two internal subroutines ADDIT and OUT are defined at the end of the
program. ADDIT is called from the program and OUT is called from ADDIT. The
subroutines have access to the global fields NUM1, NUM2, and SUM.
External subroutine calls

The principal function of subroutines is for modularizing and structuring local
programs. However, subroutines can also be called externally from other ABAP
programs. In an extreme case, you might have an ABAP program that contained
nothing but subroutines. These programs cannot run on their own, but are used by
other ABAP programs as pools of external subroutines.
However, if you want to make a function available throughout the system, you should
use function modules instead of external subroutines. You create function modules in
the ABAP Workbench using the Function Builder. They are stored in a central library,
and have a defined release procedure.
You can encapsulate functions and data in the attributes and methods of classes in
ABAP Objects. For any requirements that exceed pure functions, you can use global
classes instead of external subroutines.
BC - ABAP Programming SAP AG
Naming Subroutines
470 December 1999
When you call a subroutine externally, you must know the name of the program in
which it is defined:
PERFORM <subr>(<prog>) [USING <p
i
> ]
[CHANGING <p
i
> ] [IF FOUND].
You specify the program name <prog> statically. You can use the IF FOUND option to
prevent a runtime error from occurring if the program <prog> does not contain a
subroutine <sub>. In this case, the system simply ignores the PERFORM statement.
When you call an external subroutine, the system loads the whole of the program
containing the subroutine into the internal session of the calling program (if it has not
already been loaded). For further information, refer to Memory Structure of an ABAP
Program [Page 66]. In order to save memory space, you should keep the number of

subroutines called in different programs to a minimum.

Suppose a program contains the following subroutine:
PROGRAM FORMPOOL.
FORM HEADER.
WRITE: / 'Program started by', SY-UNAME,
/ 'on host', SY-HOST,
'date:', SY-DATUM, 'time:', SY-UZEIT.
ULINE.
ENDFORM.
The subroutine can then be called from another program as follows:
PROGRAM FORM_TEST.
PERFORM HEADER(FORMPOOL) IF FOUND.
In this example, no data is passed between calling program and subroutine.
Specifying Subroutines Dynamically
You can specify the name of a subroutine and, in the case of external calls, the name of the
program in which it occurs, dynamically as follows:
PERFORM (<fsubr>)[IN PROGRAM (<fprog>)][USING <p
i
> ]
[CHANGING <p
i
> ]
[IF FOUND].
The names of the subroutine and the external program are the contents of the fields <fsubr> and
<fprog> respectively. By using the option IF FOUND, you can prevent a runtime error from being
triggered if <fprog> does not contain a subroutine with the name <fsubr>. If you omit the
parentheses, this variant of the PERFORM statement behaves like the static variant.

Suppose a program contains the following subroutines:

PROGRAM FORMPOOL.
FORM SUB1.
WRITE: / 'Subroutine 1'.
ENDFORM.
FORM SUB2.
WRITE: / 'Subroutine 2'.
ENDFORM.
Dynamic subroutine specification:
PROGRAM FORM_TEST.
DATA: PROGNAME(8) VALUE 'FORMPOOL',
SUBRNAME(8).
SAP AG BC - ABAP Programming
Naming Subroutines
December 1999 471
SUBRNAME = 'SUB1'.
PERFORM (SUBRNAME) IN PROGRAM (PROGNAME) IF FOUND.
SUBRNAME = 'SUB2'.
PERFORM (SUBRNAME) IN PROGRAM (PROGNAME) IF FOUND.
The produces the following output:
Subroutine 1
Subroutine 2
The character field PROGNAME contains the name of the program, in which the
subroutines are contained. The names of the subroutines are assigned to the
character field SUBRNAME.
Calling Subroutines from a List
You can call a subroutine from a list as follows:
PERFORM <idx> OF <subr
1
> <subr
2

> <subr
n
>.
The system calls the subroutine specified in the subroutine list in position <idx>. You
can only use this variant of the PERFORM statement for internal subroutine calls, and
only for subroutines without a parameter interface. The field <idx> can be a
variable or a literal.

PROGRAM FORM_TEST.
DO 2 TIMES.
PERFORM SY-INDEX OF SUB1 SUB2.
ENDDO.
FORM SUB1.
WRITE / 'Subroutine 1'.
ENDFORM.
FORM SUB2.
WRITE / 'Subroutine 2'.
ENDFORM.
The produces the following output:
Subroutine 1
Subroutine 2
In this example, the two internal subroutines, SUB1 and SUB2, are called
consecutively from a list.
BC - ABAP Programming SAP AG
Passing Parameters to Subroutines
472 December 1999
Passing Parameters to Subroutines
If a subroutine has a parameter interface [Page 461], you must supply values to all of the formal
parameters in its interface when you call it. You list the actual parameters after the USING or
CHANGING addition in the PERFORM statement.

When you pass the values, the
sequence of the actual parameters in the PERFORM statement
is crucial. The value of the first actual parameter in the list is passed to the first formal parameter,
the second to the second, and so on. The additions USING and CHANGING have exactly the
same meaning. You only need to use one or the other. However, for documentary reasons, it is a
good idea to divide the parameters in the same way in which they occur in the interface
definition.
Actual parameters can be any data objects or field symbols of the calling program whose
technical attributes are compatible with the type specified for the corresponding formal
parameter. When you specify the actual parameters, note that any that you pass by reference to
a formal parameter, and any that you pass by value to an output parameter, can be changed by
the subroutine. You should therefore ensure that only data objects that you want to be changed
appear in the corresponding position of the actual parameter list.
If a subroutine contains TABLES parameters in its interface, you must specify them in a TABLES
addition of the PERFORM statement before the USING and CHANGING parameters. TABLES
parameters are only supported to ensure compatibility with earlier releases, and should no longer
be used.
You can specify actual parameters with
variable offset and length specifications. Offset
specifications for actual parameters function as offset specifications for field symbols. You can
select memory areas that lie outside the boundaries of the specified actual parameter.

PROGRAM FORM_TEST.
DATA: A1 TYPE P DECIMALS 3,
A2 TYPE I,
A3 TYPE D,
A4 TYPE SPFLI-CARRID,
A5 TYPE C.

PERFORM SUBR USING A1 A2 A3 A4 A5.

PERFORM SUBR CHANGING A1 A2 A3 A4 A5.

PERFORM SUBR USING A1 A2 A3
CHANGING A4 A5.

FORM SUBR USING
VALUE(F1) TYPE P
VALUE(F2) TYPE I
F3 LIKE A3
CHANGING
VALUE(F4) TYPE SPFLI-CARRID
F5.

ENDFORM.
SAP AG BC - ABAP Programming
Passing Parameters to Subroutines
December 1999 473
This example defines a subroutine SUBR with a parameter interface consisting of five
formal parameter F1 to F5. The subroutine is called internally three times. The actual
parameters are the data objects A1 to A5.
The three subroutine calls are all
equally valid.
There are further PERFORM statements that are also equally valid, so
long as the sequence of the actual parameters remains unchanged. In each call, A1 is
passed to F1, A2 to F2, and so on. When the subroutine ends, A3, A4, and A5 receive
the values of F3, F4, and F5 respectively. The third of the subroutine calls documents
in the program what the parameter interface of the subroutine shows, namely that only
A4 and A5 are changed. Whether A3 is changed depends on the way in which the
subroutine is programmed.

The following example shows how generically-typed formal parameters inherit their technical
attributes from their corresponding actual parameters.

REPORT FORMTEST.
DATA:
DATE1 TYPE D, DATE2 TYPE T,
STRING1(6) TYPE C, STRING2(8) TYPE C,
NUMBER1 TYPE P DECIMALS 2, NUMBER2 TYPE P,
COUNT1 TYPE I, COUNT2 TYPE I.
PERFORM TYPETEST USING DATE1 STRING1 NUMBER1 COUNT1.
SKIP.
PERFORM TYPETEST USING DATE2 STRING2 NUMBER2 COUNT2.
FORM TYPETEST USING NOW
TXT TYPE C
VALUE(NUM) TYPE P
INT TYPE I.
DATA: T.
DESCRIBE FIELD NOW TYPE T.
WRITE: / 'Type of NOW is', T.
DESCRIBE FIELD TXT LENGTH T.
WRITE: / 'Length of TXT is', T.
DESCRIBE FIELD NUM DECIMALS T.
WRITE: / 'Decimals of NUM are', T.
DESCRIBE FIELD INT TYPE T.
WRITE: / 'Type of INT is', T.
ENDFORM.
The produces the following output:
TYPE of NOW is D
Length of TXT is 6
Decimals of NUM are 2

Type of INT is I
TYPE of NOW is T
Length of TXT is 8
Decimals of NUM are 0
Type of INT is I
An internal subroutine TYPETEST is called twice with different actual parameters. All
actual and formal parameters are compatible and no error message occurs during the
syntax check. Had you declared COUNT2 with type F instead of type I, the syntax
check would have returned an error, since the formal parameter INT is specified with
type I. The formal parameters with generic types adopt different technical attributes
depending on their corresponding technical attributes.
BC - ABAP Programming SAP AG
Passing Parameters to Subroutines
474 December 1999
SAP AG BC - ABAP Programming
Examples of Subroutines
December 1999 475
Examples of Subroutines
Example of Passing Parameters by Reference

PROGRAM FORM_TEST.
DATA: NUM1 TYPE I,
NUM2 TYPE I,
SUM TYPE I.
NUM1 = 2. NUM2 = 4.
PERFORM ADDIT USING NUM1 NUM2 CHANGING SUM.
NUM1 = 7. NUM2 = 11.
PERFORM ADDIT USING NUM1 NUM2 CHANGING SUM.
FORM ADDIT
USING ADD_NUM1

ADD_NUM2
CHANGING ADD_SUM.
ADD_SUM = ADD_NUM1 + ADD_NUM2.
PERFORM OUT USING ADD_NUM1 ADD_NUM2 ADD_SUM.
ENDFORM.
FORM OUT
USING OUT_NUM1
OUT_NUM2
OUT_SUM.
WRITE: / 'Sum of', OUT_NUM1, 'and', OUT_NUM2, 'is', OUT_SUM.
ENDFORM.
The produces the following output:
Sum of 2 and 4 is 6
Sum of 7 and 11 is 18
In this example, the actual parameters NUM1, NUM2, and SUM are passed by
reference to the formal parameters of the subroutine ADDIT. After changing
ADD_SUM, the latter parameters are then passed to the formal parameters
OUT_NUM1, OUT_NUM2, and OUT_SUM of the subroutine OUT.
Input parameters which are changed in the subroutine are also changed in the
calling program. To prevent this, you must pass the parameter by value in a
USING addition.
Example of passing parameters by reference

PROGRAM FORM_TEST.
BC - ABAP Programming SAP AG
Examples of Subroutines
476 December 1999
DATA: NUM TYPE I VALUE 5,
FAC TYPE I VALUE 0.
PERFORM FACT USING NUM CHANGING FAC.

WRITE: / 'Factorial of', NUM, 'is', FAC.
FORM FACT
USING VALUE(F_NUM)
CHANGING F_FACT.
F_FACT = 1.
WHILE F_NUM GE 1.
F_FACT = F_FACT * F_NUM.
F_NUM = F_NUM - 1.
ENDWHILE.
ENDFORM.
The produces the following output:
Factorial of 5 is 120
To ensure that an input parameter is not changed in the calling program, even if it
is changed in the subroutine, you can pass data to a subroutine by value. In this
example, the factorial of a number NUM is calculated. The input parameter NUM
is passed to the formal parameter F_NUM of the subroutine. Although F_NUM is
changed in the subroutine, the actual parameter NUM keeps its old value. The
output parameter FAC is passed by reference.
Example of output parameters

PROGRAM FORM_TEST.
DATA: OP1 TYPE I,
OP2 TYPE I,
RES TYPE I.
OP1 = 3.
OP2 = 4.
PERFORM MULTIP
USING OP1 OP2
CHANGING RES.
WRITE: / 'After subroutine:',

/ 'RES=' UNDER 'RES=', RES.
FORM MULTIP
USING VALUE(O1)
VALUE(O2)
CHANGING VALUE(R).
R = O1 * O2.
WRITE: / 'Inside subroutine:',
/ 'R=', R, 'RES=', RES.
ENDFORM.
SAP AG BC - ABAP Programming
Examples of Subroutines
December 1999 477
The produces the following output:
Inside subroutine:
R= 12 RES= 0
After subroutine:
RES= 12
To return a changed formal parameter once the subroutine has finished
successfully, you can use a CHANGING parameter and pass the parameter by
reference. In this example, the actual parameters OP1 and OP2 are passed by
value in the USING addition to the formal parameters O1 and O2. The actual
parameter RES is passed by value to the formal parameter R using CHANGING.
By writing R and RES onto the screen from within the subroutine, it is
demonstrated that RES has not changed its contents before the ENDFORM
statement. After returning from the subroutine, its contents have changed.
Example of passing structures

PROGRAM FORM_TEST.
TYPES: BEGIN OF LINE,
NAME(10) TYPE C,

AGE(2) TYPE N,
COUNTRY(3) TYPE C,
END OF LINE.
DATA WHO TYPE LINE.
WHO-NAME = 'Karl'. WHO-AGE = '10'. WHO-COUNTRY = 'D'.
PERFORM COMPONENTS CHANGING WHO.
WRITE: / WHO-NAME, WHO-AGE, WHO-COUNTRY.
FORM COMPONENTS
CHANGING VALUE(PERSON) TYPE LINE.
WRITE: / PERSON-NAME, PERSON-AGE, PERSON-COUNTRY.
PERSON-NAME = 'Mickey'.
PERSON-AGE = '60'.
PERSON-COUNTRY = 'USA'.
ENDFORM.
The produces the following output:
Karl 10 D
MICKEY 60 USA
The actual parameter WHO with the user-defined, structured data type LINE is
passed to the formal parameter PERSON. The formal parameter PERSON is
typed with TYPE LINE. Since LINE is a user-defined data type, the type of
PERSON is completely specified. The subroutine accesses and changes the
components of PERSON. They are then returned to the components of WHO in
the calling program.
BC - ABAP Programming SAP AG
Examples of Subroutines
478 December 1999
Example of passing internal tables

PROGRAM FORM_TEST.
DATA: BEGIN OF LINE,

COL1 TYPE I,
COL2 TYPE I,
END OF LINE.
DATA ITAB LIKE STANDARD TABLE OF LINE.
PERFORM FILL CHANGING ITAB.
PERFORM OUT USING ITAB.
FORM FILL CHANGING F_ITAB LIKE ITAB.
DATA F_LINE LIKE LINE OF F_ITAB.
DO 3 TIMES.
F_LINE-COL1 = SY-INDEX.
F_LINE-COL2 = SY-INDEX ** 2.
APPEND F_LINE TO F_ITAB.
ENDDO.
ENDFORM.
FORM OUT USING VALUE(F_ITAB) LIKE ITAB.
DATA F_LINE LIKE LINE OF F_ITAB.
LOOP AT F_ITAB INTO F_LINE.
WRITE: / F_LINE-COL1, F_LINE-COL2.
ENDLOOP.
ENDFORM.
The produces the following output:
1 1
2 4
3 9
You can define the types of the formal parameters of the parameter interfaces of
procedures as internal tables. In the example, the subroutines FILL and OUT
each have one formal parameter defined as an internal table. An internal table
without header line is passed to the subroutines. Each subroutine declares a work
area F_LINE as a local data object. Were ITAB a table with a header line, you
would have to replace ITAB with ITAB[] in the PERFORM and FORM statements.

Example of the TABLES parameter
This example is provided for completeness. The TABLES parameter is only
supported for the sake of compatibility and should not be used.

PROGRAM FORM_TEST.
SAP AG BC - ABAP Programming
Examples of Subroutines
December 1999 479
TYPES: BEGIN OF LINE,
COL1 TYPE I,
COL2 TYPE I,
END OF LINE.
DATA: ITAB TYPE STANDARD TABLE OF LINE WITH HEADER LINE,
JTAB TYPE STANDARD TABLE OF LINE.
PERFORM FILL TABLES ITAB.
MOVE ITAB[] TO JTAB.
PERFORM OUT TABLES JTAB.
FORM FILL TABLES F_ITAB LIKE ITAB[].
DO 3 TIMES.
F_ITAB-COL1 = SY-INDEX.
F_ITAB-COL2 = SY-INDEX ** 2.
APPEND F_ITAB.
ENDDO.
ENDFORM.
FORM OUT TABLES F_ITAB LIKE JTAB.
LOOP AT F_ITAB.
WRITE: / F_ITAB-COL1, F_ITAB-COL2.
ENDLOOP.
ENDFORM.
The produces the following output:

1 1
2 4
3 9
In this example, an internal table ITAB is declared with a header line and an
internal table JTAB is declared without a header line. The actual parameter ITAB
is passed to the formal parameter F_ITAB of the subroutine FILL in the TABLES
addition. The header line is passed with it. After the body of the table has been
copied from ITAB to JTAB, the actual parameter is passed to the formal
parameter F_ITAB of the subroutine OUT using the TABLES addition. The
header line F_ITAB, which is not passed, is generated automatically in the
subroutine.
BC - ABAP Programming SAP AG
Shared Data Areas
480 December 1999
Shared Data Areas
For the sake of completeness, this section describes a technique that allows you to access the
global data of the calling program from an external subroutine. To do this, you declare a
common data area for the calling program and the program containing the subroutine. All
interface work areas [Page 131] declared using TABLES and NODES behave like the common
data area.
Like external subroutines themselves, you should use common data areas very sparingly. The
rules [Page 498] for accessing common data areas can become very complicated if you call
function modules from nested subroutines.
You declare a common data area in all programs concerned using the statement:
DATA: BEGIN OF COMMON PART [<name>],

END OF COMMON PART [<name>].
Between the two DATA statements, you declare all of the data you want to include in the
common data area.
The common part declaration must be exactly the same in all of the programs in which you want

to use it. It is therefore a good idea to put the declaration in an include program.
You can use several common parts in one program. In this case, you must assign a name
<name> to each common part. If you only have one common part in each program, you do not
have to specify a name. To avoid conflicts between programs that have different common part
declarations, you should always assign unique names to common parts.
Assume an include program INCOMMON contains the declaration of a common part
NUMBERS. The common part comprises three numeric fields: NUM1, NUM2, and
SUM:
***INCLUDE INCOMMON.
DATA: BEGIN OF COMMON PART NUMBERS,
NUM1 TYPE I,
NUM2 TYPE I,
SUM TYPE I,
END OF COMMON PART NUMBERS.
The program FORMPOOL includes INCOMMON and contains the subroutines
ADDIT and OUT:
PROGRAM FORMPOOL.
INCLUDE INCOMMON.
FORM ADDIT.
SUM = NUM1 + NUM2.
PERFORM OUT.
ENDFORM.
FORM OUT.
WRITE: / 'Sum of', NUM1, 'and', NUM2, 'is', SUM.
ENDFORM.
SAP AG BC - ABAP Programming
Shared Data Areas
December 1999 481
A calling program FORM_TEST includes INCOMMON and calls the subroutine
ADDIT from the program FORMPOOL.

PROGRAM FORM_TEST.
INCLUDE INCOMMON.
NUM1 = 2. NUM2 = 4.
PERFORM ADDIT(FORMPOOL).
NUM1 = 7. NUM2 = 11.
PERFORM ADDIT(FORMPOOL).
This produces the following output:
Sum of 2 and 4 is 6
Sum of 7 and 11 is 18
The subroutines in the program FORMPOOL access the global data of the shared
data area.

Assume a program FORMPOOL that contains two subroutines TABTEST1 and
TABTEST2 as follows:
PROGRAM FORMPOOL.
TABLES SFLIGHT.
FORM TABTEST1.
SFLIGHT-PLANETYPE = 'A310'.
SFLIGHT-PRICE = '150.00'.
WRITE: / SFLIGHT-PLANETYPE, SFLIGHT-PRICE.
ENDFORM.
FORM TABTEST2.
LOCAL SFLIGHT.
SFLIGHT-PLANETYPE = 'B747'.
SFLIGHT-PRICE = '500.00'.
WRITE: / SFLIGHT-PLANETYPE, SFLIGHT-PRICE.
ENDFORM.
A program FORM_TEST calls TABTEST1 and TABTEST2 as follows:
PROGRAM FORM_TEST.
TABLES SFLIGHT.

PERFORM TABTEST1(FORMPOOL).
WRITE: / SFLIGHT-PLANETYPE, SFLIGHT-PRICE.
PERFORM TABTEST2(FORMPOOL).
WRITE: / SFLIGHT-PLANETYPE, SFLIGHT-PRICE.
SAPMZTST then produces the following output:
A310 150.00
A310 150.00
B747 500.00
BC - ABAP Programming SAP AG
Shared Data Areas
482 December 1999
A310 150.00
All of the programs can access the table work area SFLIGHT, declared with the
TABLES statement. In the subroutine TABTEST2, the global work area is protected
against changes in the subroutine by the LOCAL statement.
SAP AG BC - ABAP Programming
Function Modules
December 1999 483
Function Modules
Function modules are procedures that are defined in function groups (special ABAP programs
with type F) and can be called from any ABAP program. Function groups act as containers for
function modules that logically belong together. You create function groups and function
modules in the ABAP Workbench using the Function Builder [Extern].
Function modules allow you to encapsulate and reuse global functions in the R/3 System. They
are stored in a central library. The R/3 System contains a wide range of predefined function
modules that you can call from any ABAP program. Function modules also play an important
role in database updates [Page 1328] and in remote communications [Extern]
between R/3
Systems or between an R/3 System and a non-SAP system.
Unlike subroutines, you do not define function modules in the source code of your program.

Instead, you use the Function Builder [Extern]. The actual ABAP interface definition remains
hidden from the programmer. You can define the input parameters of a function module as
optional. You can also assign default values to them. Function modules also support exception
handling. This allows you to catch certain errors while the function module is running. You can
test function modules without having to include them in a program using the Function Builder
[Extern].
The Function Builder [Extern] also has a release process for function modules. This ensures that
incompatible changes cannot be made to any function modules that have already been released.
This applies particularly to the interface. Programs that use a released function module will not
cease to work if the function module is changed.
Function Groups [Page 484]
Calling Function Modules [Page 486]
Creating Function Modules [Page 492]
BC - ABAP Programming SAP AG
Function Groups
484 December 1999
Function Groups
Function groups are containers for function modules. You cannot execute a function group.
When you call an function module, the system loads the whole of its function group into the
internal session of the calling program (if it has not already been loaded). For further information,
refer to Organization of External Procedure Calls [Page 498].
The following diagram shows the structure of a function group: The name of a function group can
be up to 26 characters long. This is used by the system to create the components of the group
(main program and corresponding include programs). When you create a function group or
function module in the Function Builder [Extern] , the main program and include programs are
generated automatically.
Main program SAPL<fgrp>
INCLUDE L<fgrp>TOP.
INCLUDE L<fgrp>UXX.
INCLUDE L<fgrp>U01.

INCLUDE L<fgrp>U02.
INCLUDE L<fgrp>U03.

INCLUDE L<fgrp>U01.
INCLUDE L<fgrp>U02.
INCLUDE L<fgrp>U03.

INCLUDE L<fgrp>F<xx>.
INCLUDE
FUNCTION-POOL <fgrp>.
TABLES:
TYPES:
DATA:
FUNCTION-POOL <fgrp>.
TABLES:
TYPES:
DATA:
FUNCTION <name>.

ENDFUNCTION.
FUNCTION <name>.

ENDFUNCTION.
FUNCTION <name>.

ENDFUNCTION.
FUNCTION <name>.

ENDFUNCTION.
FUNCTION <name>.

ENDFUNCTION.
FUNCTION <name>.

ENDFUNCTION.
FORM

ENDFORM.
FORM

ENDFORM.


Include programs
The main program SAPL<fgrp> contains nothing but the INCLUDE statements for the following
include programs:
• L<fgrp>TOP. This contains the FUNCTION-POOL statement (equivalent for a function
group of the REPORT or PROGRAM statement) and global data declarations for the
entire function group.
• L<fgrp>UXX. This contains further INCLUDE statements for the include programs
L<fgrp>U01, L<fgrp>U02, These includes contain the actual function modules.
• The include programs L<fgrp>F01, L<fgrp>F02, can contain the coding of subroutines
that can be called with internal subroutine calls from all function modules of the group.
The creation of these include programs is supported from the ABAP Workbench by forward
navigation (for example creation of a subroutine include by double clicking on the name of a
subroutine in a PERFORM statement within a function module).
SAP AG BC - ABAP Programming
Function Groups
December 1999 485
You cannot declare a COMMON PART in a function group. Function groups have their own table

work areas (TABLES). Function groups encapsulate data. In this respect, they are a precursor of
ABAP Objects (see From Function Groups to Objects [Page 1349] ).
All of the function modules in a function group can access the global data of the group. For this
reason, you should place all function modules that use the same data in a single function group.
For example, if you have a set of function modules that all use the same internal table, you could
place them in a function group containing the table definition in its global data.
Like executable programs (type 1) and module pools (type M), function groups can contain
screens, selection screens, and lists. User input is processed either in dialog modules or in the
corresponding event blocks in the main program of the function group. There are special include
programs in which you can write this code. In this way, you can use function groups to
encapsulate single screens or screen sequences.
BC - ABAP Programming SAP AG
Calling Function Modules
486 December 1999
Calling Function Modules
This section describes calling function modules from the Function Builder.
Finding Function Modules
Before programming a new function or creating a new function module, you should look in the
Function Builder to see whether there is an existing function module that already performs the
same task.
For more information about this, refer to Finding Function Modules [Extern] in the ABAP
Workbench documentation. For example, you might look for function modules that process
strings by entering *STRING*
as a search criterion in the Repository Information System. This is
an extract from the list of function modules found:
The title CSTR is the function group. There is a main program SAPLCSTR that contains these
function modules. If you select a function module, you can display its attributes in the Function
Builder.
Important attributes:
• Documentation

The documentation describes the purpose of the function module, lists the parameters
for passing data to and from the module, and the exceptions. It tells you how you can
pass data to and from the function module, and which errors it handles.
• Interface parameters and exceptions
This section provides further information about the interface parameters and exceptions,
and how to use the function module. For further information, refer to Displaying
Information about Interface Parameters [Extern] in the ABAP Workbench documentation.
Function modules can have the following interface parameters:
•
Import parameters. These must be supplied with data when you call the function module,
unless they are flagged as optional. You cannot change them in the function module.
• Export parameters. These pass data from the function module back to the calling program.
Export parameters are always optional. You do not have to receive them in your program.
• Changing parameters. These must be supplied with data when you call the function module,
unless they are flagged as optional. They can be changed in the function module. The
changed values are then returned to the calling program.
• Tables parameters. You use these to pass internal tables. They are treated like CHANGING
parameters. However, you can also pass internal tables with other parameters if you specify
the parameter type appropriately.