Introduction to Logical Databases

A Logical Database (LDB) is an ABAP program that reads data from the database



and makes the data available to report programs. This lesson provides an overview


of the features and structure of a logical database. It also lists the advantages of


using a logical database.
You can use either Open SQL or Native SQL statements to read data from the



database. Avoid using Native SQL to maintain portability from one RDBMS to


another. Also, Native SQL requires to be recoded to take advantage of upgrades in


the RDBMS. Open SQL has no such limitations or requirements.


The use of a logical database program provides an excellent alternative to


programming data retrieval. Logical databases retrieve data records in primary


key sequence and make the data available to ABAP programs. They also offer the


advantage of security because authority checks are made in the logical database


program rather than in the report program
A logical database is an ABAP program that reads data from the database and



makes the data available to other report programs.


A hierarchical structure determines the order in which the data is supplied to


programs. A logical database also provides a selection screen that checks user


entries and conducts error dialogs. You can add your own parameters and select


options.


The SAP system provides approximately 190 logical databases in Release 4.6.


The names of logical databases have been extended from three characters to 20


characters in Release 4.0 (namespace prefix maximum of 10 characters).


If the name of the logical database is three characters in length, the first two


characters name the logical database and the third character identifies the


application area. A list of the values for the third character can be displayed by


looking at a program’s attributes and then pressing F4 on the Application field. For


example, DDF is named for Debtor Data and the letter F represents financial data.

The following tables form the nodes of the logical database F1S:


• SPFLI: Flight connections


• SFLIGHT: Flights


• SBOOK: Bookings
You need to specify the name of the logical database in the program’s attributes



for an executable (type 1) program.


Use the keyword NODES to specify the nodes of the logical database


that you want to use in the program. NODES allocates appropriate storage space


for the node (a work area or a table area depending on the node type).


Note: The keyword TABLES can still be used in Release 4.6.data records,


it issues the statement PUT which triggers the GET event in


the report program.
Advantages of a Logical Database


A logical database can be the data source for several QuickViews, queries, and



reports. In QuickView, the logical database program (LDB) can be specified


directly as a data source. A query works with the logical database when the


InfoSet that generated the query is defined with a logical database. In the case


of executable programs, the LDB is entered in the attributes or called using the


function module LDB_PROCESS. See appendix for information on how to use


the function module.


Logical databases offer several advantages over other methods of data retrieval,


such as:


• The system generates a selection screen. The use of selection screen versions


or variants provides the required flexibility.


• The programmer does not need to know the exact structure or relationship of


the tables involved. The data ismade available to the application program in


primary key sequence. Performance improvements within logical databases


directly affect all programs linked to the logical database without having


to change the programs themselves.


• Maintenance and enhancements can be performed at a central location.


• Authorization checks are made in the logical database program rather than


in the application program.

Logical Database Subobjects and Data Retrieval

This lesson focuses on logical database (LDB) subobjects. The lesson begins with



an explanation of the structure of logical database subobjects. It explains how to


use selections in logical database subobjects. It also explains the importance of


database programs and the use of database program in logical database subobjects.


Finally, it explains how data is read from the database.

Logical databases comprise of several subobjects. The structure determines the



hierarchy and the read sequence of data records.


Node names can contain up to 14 characters. There are four node types such as:


• Table (type T): The node name is the name of a transparent table. This node


type corresponds to the concept prior to Release 4.0A. The table name must


be identical to the node name. Deep types (complex) are not allowed.


• DDIC type (type S): Any node name is possible. The node is assigned a


structure or a table type from the Dictionary. The node name can differ from


the type name. Deep structures are possible.


• Type groups (type C): The node type is defined in a type group. The name of


the type group must be maintained in the Type group field. DDIC types are


generally preferred because other applications that use the logical database,


such as SAP Query, can access them (short texts, and so on).


• Dynamic nodes (type A): Do not have a fixed type and are not classified


until program run time. The types that are permitted are determined when


the structure is created.

The START-OF-SELECTION event triggers before control is given to the


read routine of the logical database. The END-OF-SELECTION event triggers


after all GET events have been processed (all data records have been read and


processed).



The GET event triggers when the logical database supplies data for this


node. This means that GET events are processed several times and that data has


already been read from the database for these events. The sequence in which GET


events are processed is determined by the structure of the logical database.


The GET LATE event triggers when all subordinate nodes of node


have been processed before the data is read for the next (when


a hierarchy level has been completed).


At the start of the event, the system automatically adds a line feed and sets the


font and intensity to the system defaults. If colors were set in other events, they


are reset.
The CHECK keyword ends the current processing block if the condition is false.



The STOP keyword ends program processing. Unlike the EXIT statement, the


processing block END-OF-SELECTION processes first (if it exists).


If there is a STOP statement within the END-OF-SELECTION processing


block, program processing ends and the list buffer is displayed.


The EXIT statement exits the program but does not trigger the


END-OF-SELECTION event. Any list buffer that was created before the EXIT


keyword is encountered will be displayed.


You can also use the REJECT statement. The data record does not process


further. Processing continues on the same hierarchy level when the next data


record is read. REJECT can also be used within a subroutine.
 
Logical database programs have an include named db sel in which the



logical database selection screen(s) are defined. The addition FOR NODE assigns


selections to individual logical nodes. The appearance of a selection screen


directly depends on the NODES statement contained within your program.


A field selection can be defined in the logical database program for individual


nodes. This is done using the keyword FIELD SELECTION FOR NODE in the


SELECTION-SCREEN statement. The code in the logical database program


enables the application program to use the GET FIELD


list> to restrict the amount of data retrieved.


A few logical databases also designate dynamic selections for individual nodes.


This is done by dynamic selection using the addition DYNAMIC SELECTIONS


FOR NODE. The Dynamic selection button appears on the report’s selection


screen. You can determine which selection fields can be set by choosing a


particular selection view (type: CUS) or using the selection view delivered by


the SAP system (type: SAP).


A few large logical databases have several selection screen versions. Each


selection screen version contains a subset of the selection criteria (language


element: EXCLUDE). You can specify which selection screen to display by


entering the selection screen version number in the program attributes.
When you enter a logical database in the attributes of the type 1 program, the



system processes the selection screen of the logical database. The concrete


characteristics of the selection screen depend on the node specified in the NODES


statement. If you specify a node of type T (table), you can also declare the table


work area using the TABLES statement.


If you address only subordinate nodes (in the hierarchy) of the logical database in


the program (for example, SFLIGHT), the selection screen criteria for the superior


node in the hierarchy (SPFLI) also appears. You can thus restrict the dataset to be


read so that it meets specific requirements.


Note: A logical database always reads in accordance with its structure.


This means that if you need data only from a node deep in the hierarchy,


you should either find another logical database where the desired node is


higher in the structure or program data retrieval .
If the logical database supports dynamic selections, Dynamic selections appears


on the selection screen. When the user selects Dynamic selections, a second

selection screen is displayed, which enables the user to select additional database

fields. The system transfers the selections directly to the logical database program

and to the database (dynamic selections).
Logical database programs are named SAPDB for logical database


. The programs are a collection of subroutines, each of which is

performed for specific events. For example, subroutine is processed

once at the start of the database program. This program can define default values

for the selection screen of the LDB.

Other subroutines are processed during the event PBO (Process Before Output)

and PAI (Process After Input) of the selection screen. Checks such as authorization

checks (AUTHORITY-CHECK), are usually performed during the event PAI.

Database access (SELECT statements) is programmed in put_

subroutines. These subroutines may be processed several times depending on the

selection criteria specified by the user. The sequence in which these subroutines

are processed is determined by the structure of the logical database.

When a report program that uses a logical database is started, control is initially


passed to the database program of the logical database. Each event has a

corresponding subroutine in the database program (for example, subroutine init

for event INITIALIZATION). During the interaction between the LDB and the

associated report, the subroutine is always processed first, followed by the event

(if there is one in the report).

Logical database programs read data from a database according to the structure

declared for the logical database. They begin with the root node and then process

the individual branches consecutively from top to bottom.

The logical database reads the data in PUT_ subroutines. During event

PUT, control passes from the database program to the GET event of the associated

report. The data is made available in the corresponding work areas in the report.

The processing block defined for the GET event is performed and control then

returns to the logical database. PUT activates the next form subroutine found in

the structure. This flow continues until the report collects all the available data.

The depth of data read in the structure depends upon a program’s GET events.

A logical database reads to the lowest GET event contained within structure

attributes. Only those GET events for which processing is supposed to take place

are written in the report program. Logical databases read all data records found on

the direct access path.

If you specify a logical database and declare additional selections in the program


attributes that refer to the fields of a node not designated for dynamic selection,

you need to use the CHECK statement to see if the current data

record fulfills the selection criteria.

If the data record does not fulfill these selection criteria, processing of the current

event block ends.
The selection view determines which fields are displayed on the selection screen.

Create your own view with type CUST and use it to override the view with type

SAP.

Selection Screen

The selection screen has the following standard functions:

• Texts on the selection screen (selection texts) can be maintained in several

languages. At runtime the texts are automatically displayed in the user’s

logon language. (Automatic language)

• The system checks types automatically: If the user enters something that

does not correspond to the type of the input field, the SAP GUI will ignore it,

so it won’t even appear on the selection screen.

• In addition to single value entries (PARAMETERS), you can also implement

complex selections (SELECT-OPTIONS) on the selection screen. The

user can then enter intervals, comparative conditions or even patterns as

restrictions.

• If the input field is defined using a Dictionary element (e.g. data element),

then the field documentation (documentation of the data element) can be

displayed on the input field, using the F1 (input help) function key.

The data element’s search help for displaying possible inputs can be called

up using the F4 (input help) function key.

• You can easily save completed selection screens as variants for reuse or

use in background operation.
The above graphic illustrates the use of selection options, which enable complex


entries. Every selection screen contains an information icon (also known as a

“Help on Screen” icon). Choose this icon to display additional information.

You will learnmore about defining selection options using the SELECT-OPTIONS

statement later in this lesson.
Figure 197: Semantic Information on Global Types on the Selection Screen


If an input field is typed with a data element, the following additional semantic

information is available on the selection screen:

• The long field label of the data element can be copied to describe the input

field on the selection screen (selection text). (See next graphic)

• Thedocumentation of the data element is automatically available as an

input help (F1 help).

• Ifasearch help is linked to the data element , it is available as an input

help (F4 help).

(A search help is an independent dictionary object that displays a list of

possible input values to the user (possibly with additional information), from

which he can then select one for input.)

If the input field is typed with a structure field which is in turn defined using a

data element, then the above-described semantic information of the data element

is available on the selection screen. If the structure field is also copied to a search

help, then this “overwrites” the search help of the data element.

For more information, refer to the online documentation for the ABAP Dictionary.
 
On the selection screen, the names of the input fields appear as their description


by default. However, you can replace these with corresponding selection texts,

which you can then translate into any further languages you require. At runtime,

the selection texts are then displayed in the logon language of the user (automatic

language).

Just like the list headers and text symbols, selection texts belong to the text

elements of the program. From the ABAP Editor, choose the menu GoTo → Text

Elements→Selection Texts to maintain them. You can implement your translation

using the menu GoTo → Translation.

If the input field is typed directly or indirectly with a data element, you can copy

the long field name from one of the texts stored in the Dictionary (“dictionary

reference”). This provides you with an easy option for standardizing the texts.
 
The completed selection screens are the variants of the program. After the


program has been started, the user can load variants to the respective selection

screen to facilitate repeated identical or almost identical inputs. You have

to include a variant when you schedule an ABAP program in the background

run, if the program has a selection screen, as user inputs are not possible in the

background.

You define program-specific variants by starting the program, completing the

selection screen and saving it (disc pushbutton). You can also define different

attributes for the variant.

If variants have already been defined for a program, then an additional pushbutton

appears on the selection screen with the text flag “get variant...”. This push button

lists the defined variants for selection.

In order to be able to define his own variants, the user must have the corresponding

authorization (in the production system). But you can also define variants in the

development system and then have them transported to the production system.

Variants with the name prefix ’CUS&’ are system variants. They are transported

like ordinary repository objects and are not client-specific. All other variants are

client-specific and must be transported separately. From the ABAP Editor, choose

the menu GoTo → Variants to go to the variant management of your program,

where you can perform follow-up maintenance for your variants with regards to

values and attributes. There, choose the menu Tools → Transport Request to

specify the variants to be transported as well as a request. The transport happens

when the request is released.

For more information on variants, choose the pushbutton Information on Variant

Attributes on the screen in order to maintain your variant attributes.

The above graphic shows the usage and the runtime behavior of an input variable


defined using a PARAMETERS statement. Once again, the definition of such an

input variable creates a variable in the system and implicitly generates a selection

screen with a corresponding input option.

An input variable is defined in the same way as an ordinary variable. The only

difference is that the PARAMETERS keyword is used instead of DATA.

You have to consider three particularities:

• The name of the input variable may be up to 8 characters long.

• It may not be typed with the standard types F, STRING and XSTRING.

• The assignment of a default value is not implemented with the VALUE

addition but with the DEFAULT addition.

A default value assignment by means of the DEFAULT addition or value

assignment before displaying the selection screen (INITIALIZATION) is

displayed on the selection screen as a default value that can be overwritten.

If the user enters a value and chooses Execute, the input values are transferred to

the internal value and, for example, can be used to restrict the database selection.

Selection options are defined when you use the


SELECT-OPTIONS name FOR data_object.

statement, where name is the name of the select option and data_object is an

already defined variable. Such a definition creates an internal table of the specified

name within the program (here so_car) and generates a selection screen with an

input option for limiting the specified variable (here: wa_spfli-carrid).

User entries are transported to the automatically generated internal table when

Execute is chosen. This table always has four columns: sign, option, low, and

high. The above graphic shows, which entries are created for which user input:

• If ’LH’ is entered, a row is generated with the values ’I’ (inclusive), ’EQ’

(equal), ’LH’ and Space.

• If the interval ’AA’ to ’DL’ is entered, a row is generated with the values

’I’ (inclusive), ’BT’ (between), ’AA’ and ’DL’.

• If ’BA’ is entered as the single value to be excluded, a row is generated with

the values ’E’ (exclusive), ’EQ’ (equal), ’BA’ and Space.

The internal table filled with the entered selection criteria can be used for the

database selection, as illustrated in the graphic. The table content is interpreted as

follows:

If I_1, ... , I_n and E_1, ... , E_m are the inclusive/exclusive

conditions of the internal table, then the following composite condition is used to

limit the data selection:
 
( I_1 OR ... OR I_n ) AND ( NOT E_1 ) AND ... AND (


NOT E_m )

If the table is empty because there are no restrictions, the WHERE conditions

always applies to the respective field.

Hint: The IN operator can also be used in logical expressions:

IF wa_spfli-carrid IN so_car.

For defining a selection option, the same three particularities apply as for the

PARAMETERS statement (see above).

If the internal table of the selection option is filled using the DEFAULT addition or

APPEND statement before the selection screen is displayed (INITIALIZATION,

then its content is displayed on the selection screen as suggested conditions that

can be overwritten.

For further details, refer to the keyword documentation for SELECT-OPTIONS.
 
On the selection screen the AT SELECTION-SCREEN event is triggered both


by choosing Enter as well as Execute (F8). After the corresponding processing

block has been processed, the following START-OF-SELECTION event is

triggered and the relevant processing started, if Execute was used. However, if

Enter was chosen, the selection screen is displayed again.
Immediately before processing the AT SELECTION-SCREEN block, the user


entries are automatically transferred to the corresponding variables in the program.

Hence, it makes sense to implement required input and authorization checks in

this processing block. If the check result is negative, you can simply send out an

error message to the user and have the selection screen displayed again. The user

then has then option of making new entries.

In contrast, an error message in the START-OF-SELECTION block would be

displayed under program termination.

The following graphic illustrates a simple example program with authorization

check and error dialog on the selection screen.

Additional information can be found in the keyword documentation for “AT

SELECTION-SCREEN”.

Classic List Processing

The main purpose of a list is to display data with a minimum of programming


efforts. Lists also take the special requirements of business data into account:

• Lists can be designed in multiple languages: Texts and headers appear in the

logon language whenever a corresponding translation is available.

• Lists can display monetary values in the appropriate currency.

The following options are available when programming a list:

• Screen: You can add colors and icons

• Printers

• Internet/Intranet: The system is able to automatically convert to HTML.

• Save: You can save lists within the SAP system as well as outside (for further

processing, for example, using spreadsheet programs).
 
Each list can have a single line list header and up to four lines of column


headers. If no list header is defined, the program title (short description) is used

as the header.

For the initial maintenance of the headlines, you must first activate your program.

Afterwards, create the list by running the program. You can then maintain the

headers directly above your list using the menu System → List → List Header.

The next time you start the program, they will appear in the list automatically.

If you want to change the maintained header (follow-up maintenance), then you

do not have to start the program again and generate the list. Instead, starting

from the editor into which the program is loaded you can get to the maintenance

environment for changing the headers by choosing Goto → Text Elements →

List Headers .
 
The text elements of a program - this also includes the header - can be translated


into different languages. When a user executes a program, relevant text elements

are always automatically displayed in the logon language of the user (automatic

language).

To translate the text elements of your program choose the Menu Goto →

Translation from the ABAP-Editor.
 
In order to design texts in the list body in multiple languages and use the


automatic language, text symbols are used. A text symbol consists of a three-digit

alphanumeric ID xxx as well as a translatable text and, like the headers,

belongs to the text elements of a program. There are two options for defining

text symbols for your program:

• FromtheABAP Editor, choose the menu Goto → Text Elements → Text

Symbols or

• you address the text symbol in your source code using the syntax described

below and double-click its ID (Forward navigation).

From your program, you address a text symbol with TEXT-xxx. At runtime the

text is inserted in the logon language of the user if the appropriate translation

exists (see “translating the text elements” above).

In order to make specifying a text symbol more intuitive you can also use the

following syntax instead of TEXT-xxx: ’...’(xxx). Here, ’...’ should be

the text of the text symbol in the original language of the program.

Hint: Please note that text elements also have to be activated.
The above graphic shows the generation of the basic list as an introduction to


the details list. In addition to the WRITE statement, you can also use SKIP and

ULINE to structure the list. Refer to the ABAP keyword documentation for

these two statements.
 
When the user selects a basic list by means of double-click or function key F2,


the ABAP event AT LINE-SELECTION is triggered. If you want to have the

system display a list with the required detailed information (interactive list) as the

response to this user action, then you must implement this in your program in the

form of a corresponding processing block. There, you can read the data requested

by the user and output them with the WRITE statement. The details list with the

output data, which “overwrites” the basic list, is generated automatically. By

pressing the pushbutton with the “green arrow” or the F3 function key, the user

can return to the basic list and choose another row.

Hint: If an AT LINE-SELECTION block is implemented in the

program, then a pushbutton with the magnifying glass symbol also

appears above the list. Marking the list row and then choosing this button

has the same effect as double-clicking the list row.

The row selection on the detail list also triggers the AT LINE-SELECTION

event. This means that the corresponding processing block in the program is

executed in this case as well. Hence you must be able to determine within this

block on which list the current row selection was made so that you can react

adequately. You can use the sy-lsind system field for this. This field shows

the current list level: “0” for the basic list, “1” for the first details list, and so on.

The above graphic shows the value of sy-lsind and how it is set in each case:

Each row selection automatically increases sy-lsind by 1; each return to the

previous list level reduces sy-lsind by 1. Up to 20 list levels are possible.

The value of sy-lsind should be used to control processing in the AT

LINE-SELECTION block (for example, by means of a CASE statement).

A WRITE statement is always executed on the current list level.

If no details list is generated for a row selection in the AT LINE-SELECTION

block, then sy-lsind is automatically reduced by one. Afterwards, the system

displays the same level where the row selection took place.
The above example program has the following function:


• On the basic list, the text “Basic list” is output followed by the current

sy-lsind value of 0.

• When a basic list row is selected, the text “1st details list” is displayed on the

details list followed by the current sy-lsind value of 1.

• When the user selects a row from the details list, he or she gets a second

details list on which the text “2nd details list” appears followed by the

current sy-lsind value of 2.

• If a line of the seconds details list is selected, sy-lsind is increased to 3

but no further details list is generated. Hence sy-lsind is automatically

reduced by 1 and the second details list is displayed again.

In order to be able to access the key values of the selected row when a basic list

row is selected, you have to implement the following concept:

• Foreach basic list row, the relevant key values are stored in the HIDE area

within the program.

• When a row is selected the data that has been hidden for that particular

row will be made available again.

The row-specific holding of key values in the HIDE area happens by

means of the HIDE statement (here: HIDE: wa_spfli-carrid,

wa_spfli-connid.), which must be executed directly after generating each

basic list row. When the row is selected, the relevant key values are transported

back to the source fields (here: wa_spfli-carrid and wa_spfli-connid)

and the AT LINE-SELECTION event is triggered. The following graphic

illustrates this.

Hint: You do not have to output the HIDE fields with the WRITE

statement first. That means: For each basic list row, you can also store

information that does not appear on the basic list in the HIDE area by

means of the HIDE statement. The HIDE field can also be a “flat”

structure.

Hint: Details lists do not have fixed standard headers like basic lists as


they can be varied dynamically. Hence, you might have to implement

your own headers using WRITE statements.

The following graphic shows the entire AT LINE-SELECTION block of the

example program. In this block, basically data (here: flight schedules) is read

and output by means of the HIDE values that have been transported back to the

source fields.

Subroutines

Figure 168: Parameter Passing (Motivation 2)


You can address all (global) variables defined in the main program from a

subroutine. But, in order to call up a subroutine for a specific situation with

different data objects for each situation, you do not use global variables in

the subroutine but placeholders, which are replaced with the required global

variables at the time the subroutine is called. These placeholders are called formal

parameters and together they form the interface of the subroutine, which has to

be declared when the subroutine is defined.

When the subroutine is called, formal parameters must be specialized by means of

corresponding global variables (actual parameters), in order to implement the

reference of the subroutine processing to real variables. This assignment of actual

parameters to formal parameters when calling a subroutine is called parameter

passing.

3

Figure 169: Ways of Passing Interface Parameters

They way these variables of the main program are passed to the formal parameters

of the subroutine is called passing type and is specified for each parameter in

the interface of the subroutine.

There are three passing types:

Call by Value

A copy is made of the actual parameter. This copy is assigned to the formal

parameter. If in the subroutine a value is assigned to the corresponding

formal parameter, this value will actually be assigned to a copy of the formal

parameter and not its original.

You use this pass type, to make the value of a global variable available to

the subroutine (in the form of a variable copy) without making it possible

to change the respective global variable (protecting the original). Please

note, however, that creating copies, especially for large internal tables, can

be time-consuming.

 

Call by value and result


With this transfer type, the same applies as for “call by value”. However, at

the regular end of the subroutine, the value that was changed to this point

is written back to the original. If the program is prematurely terminated

through a STOP statement or a user message of type E, the writing back

of the values is suppressed.

You use this pass type to transfer the value of a global variable to the

subroutine and to have the fully processed final value of the copy written

back to the original. But note that the creation of copies and the writing back

of values can be time-consuming, especially for large internal tables.

Call by reference

The actual parameter is assigned directly to the formal parameter. This

means that value assignments to the formal parameter are executed directly

on the actual parameter.

You use this pass type if you want to run the subroutine processing directly on

the specified actual parameter. It is popular for avoiding the time-consuming

creation of copies for large internal tables.


Figure 170: Defining and Calling Subroutines


• A subroutine is introduced with FORM.

• The name and the interface of the subroutine are to be specified behind FORM.

• The statements of the subroutine follow.

• TheENDFORM statement concludes the subroutine.

In the interface definition you list the formal parameters of the subroutine (here:

f1, f2, f3) and type them if necessary. The required pass type has to be specified

for each parameter:

Call by value

You list each of the formal parameters that is supposed to have the pass type

“call by value” (here: f1) with the VALUE prefix in the USING section.

(Refer to the above graphic for the syntax.)

Call by value and result

You list each of the formal parameters that is supposed to have the pass

type “call by value and result” (here: f1) with the VALUE prefix in the

CHANGING section. (Refer to the above graphic for the syntax.)

Call by reference


You list each of the formal parameters that is supposed to have the pass type

“call by reference” (here: f3) without the VALUE prefix in the CHANGING

section. (Refer to the above graphic for the syntax)

Note: A parameter without VALUE prefix, but placed in the USING

section also has the pass type “call by reference”. However, this

declaration syntax only makes sense for formal parameters that are

passed to larger internal tables, which are not to be changed in the

subroutine (documentation via USING) but are to be passed using

“call by reference” in order to avoid making time-consuming copies.

When the subroutine is called, the actual parameters to be transferred without

VALUE prefix are specified under USING or CHANGING. The order of

specification determines their assignment to the formal parameters. In the example

in the above graphic, a is passed to f1, b to f2, and c to f3.

Figure 171: Typing the Interface Parameters

A formal parameter is typed generically, if it is typed using TYPE ANY or not

typed at all. Actual parameters of any type can be transferred to such a parameter.

At runtime, the type of the actual parameter is determined and assigned to the

formal parameter (type inheritance) when the subroutine is called. However, if

the statements in the subroutine are not suited to the inherited type, a runtime
error may occur (type conflict). Hence, generic typing should only be used if the


type of the actual parameter is yet to be determined when the program is created

or if it can vary at runtime (dynamic programming).

You implement the concrete typing of a formal parameter by specifying a global

or built-in type in the TYPE addition. In doing so, you specify that only actual

parameters of the specified type are to be passed to the subroutine. A violation of

the type consistency between formal and actual parameters is already picked up in

the syntax check. This increases the stability of your program as type conflicts in

statements within the subroutine are prevented.

If you type with the standard types P, N, C or X, the missing characteristic “field

length” is not inherited from the actual parameter until runtime. You achieve

a complete type assignment with this type (i.e., including the field length) by

defining and specifying locally defined types.

You must type formal parameters for structures and internal tables so that you can


access the corresponding components. The components of structure parameters are

known in the subroutine, as a result of the assigned type, so that you can address

these components with the usual syntax. The typing of table parameters enables

you to address these as internal tables using the usual syntax in the subroutine.

Hint: Larger internal tables should be transferred by call by reference

in order to avoid time consuming copies.

Figure 173: Visibility of Global and Local Data Objects


Variables defined in the main program are global data objects. They are visible

(can be addressed) in the entire main program in every subroutine called.

Variables defined within a subroutine are called local, as they only exist in the

relevant subroutine - just like the formal parameters. The memory for formal

parameters and local data objects is only allocated during the subroutine run and

released again after execution.

The formal parameters and local data objects of a subroutine can not have the

same names. If there is a global data object with the same name as a formal

parameter or a local data object, then the formal parameter or local data object is

addressed within the subroutine and the global data object is addressed outside

the subroutine. This is called hiding rule. Within a subroutine the local data

objects “hides” the global one with the same name.

To clearly label your program-internal objects you

could, for example, use the following prefixes:

f_... for “formal parameters” and

l_... for a “local data object”.
Figure 174: Syntax Example: Passing an Internal Table


In the above syntax example, the internal table it_flightinfo and the global variable

carrid are passed by means of call by reference, even though they are not changed

in the subroutine. The advantage of this is that no copies have to be made.

To loop through the internal table, you need a work area with a compatible line

type. This is locally defined in the subroutine with reference to the table parameter

f_itab. The reference is possible because f_itab is typed in the interface of the

subroutine.
You can have the PERFORM statement for calling a subroutine generated into


your source code. First, define the subroutine and then save your main program.

The newly-defined subroutine appears in the navigation area. Move it to the

required call point in your program by means of drag & drop. All you have to do

is replace the formal parameters in the generated source code with corresponding

actual parameters.

(Alternatively, the call generation can also be implemented using the “Pattern”

pushbutton in the ABAP editor.)

The advantage of the call generation is that it is impossible to forget or mix

parameters.