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.

SAP Service Marketplace

Lesson Overview


This lesson introduces you to the central point of entry for all SAP services, the

SAP Service Marketplace. A few services that are particularly relevant to mySAP

Business Suite are presented as examples.

Lesson Objectives

After completing this lesson, you will be able to:

• List some of the services provided on the SAP Service Marketplace

• Find and use SAP Notes in the SAP Service Marketplace

Business Example

The system administrator has established that there is a problem in an SAP system

and is looking for a solution.

SAP Service Marketplace Target Group

You can find information on all SAP solutions and on SAP as a company at

http://www.sap.com. This website is open to the general public. The SAP Service

Marketplace on the other hand, at http://service.sap.com, is directed specifically at

SAP's customers and partners. The SAP Service Marketplace enables you to

access various services, special information and additional offers.

Logging on, Personalizing, and Navigating

To log on, you must be registered as an SAP Service Marketplace user (formerly

known as OSS user or SAPNet user). There is normally a contact person in each

company who creates users for employees as required and sets authorizations.

Access to the SAP Service Marketplace is free of charge to customers (apart from

the Internet access required).

Once you have logged on to the SAP Service Marketplace, you have a range of

topics to choose from. You can personalize your homepage, that is, set up your

own pages with topics that are of particular interest to you.

Quick Links enable you to quickly access specific areas of the SAP Service

Marketplace. To call up a Quick Link, simply add it to the Web address, preceded

by a “/” (for example: http://service.sap.com/ui). After logging on to the SAP

Service Marketplace, you can access a selection of “Quick Links”.
 
Important Services Provided on the SAP Service


Marketplace

Some SAP Service Marketplace functions are named below. The focus here is on

services that are particularly relevant to SAP Web Application Server.

Administering users

As an SAP Service Marketplace user with the appropriate authorizations,

you can request and administer other SAP Service Marketplace users

at /user-admin. SAP Service Marketplace users are also subject to an

authorization concept. You can, for example, withhold authorization to

create SAP messages (see below).

Developer key

A developer needs a developer key to be able to create or change objects

in an SAP system. You can request this key using the Quick Link /sscr

(“SAP Software Change Registration”).

Changes to SAP objects (such as ABAP programs) are called modifications

and require an object key, which you can also request at /sscr.
 
Notes Database


You can access the comprehensive Notes Database using the Quick Link

/notes. You can access specific SAP Notes either by entering the Note

number directly, or using search criteria (such as the name of a transaction or

an error code).

Note Assistant

All SAP systems as of the SAP Web AS 6.10 include the Note Assistant.

This is a tool (transaction SNOTE) that can automatically import corrections

to ABAP code from SAP Notes into SAP systems. /noteassistant provides

information on how to implement the Note Assistant in SAP systems with

earlier releases, as well as other information on the tool.

Corrections and messages

SAP regularly provides corrections for known problems (for example, as

Support Packages, kernel patches, or front-end patches). You can download

them at /patches. SAP recommends that you keep your correction status as

up-to-date as possible.

Itmay happen that an error occurs for which there is no relevant SAP Note

or correction available. If this does happen, you can enter a message to SAP

under /message. This message is then processed by SAP Support.

Access to your SAP system and to other services

If an SAP employee needs access to your SAP system to work on a problem,

then you can release the connection using /serviceconnection.

Other services, such as Remote Consulting (/remoteconsulting: SAP

consulting services without consultant site visits) or EarlyWatch

(/earlywatch: SAP experts proactively analyze your SAP systems to ensure

optimum performance and availability), also require this type of access.

You can find and order services provided by SAP in the Service Catalog

(Quick Link /servicecat).

Software requirements

Are you looking for information on software requirements (operating

system release or database release) for a specific SAP solution? You can find

the answer using the Quick Link /platforms.

Information on the latest developments

You can find information on the latest developments in the SAP NetWeaver

area using /netweaver.

For information about SAP Web AS, use the quick link /webas

Quick link /enterprise points to news about SAP R/3 Enterprise

Planing hardware investments


The Quick Sizer (/quicksizer) is a tool that helps you to plan your hardware

investment. Your expected hardware requirements (such as disk space and

main memory) are determined on the basis of your load profile. Standardized

SAP benchmarks carried out by SAP's hardware partners at regular intervals

on their servers help you to size your hardware correctly.

Contacts

If you need to get in touch with an SAP partner, you can find their contact

details in the Partner Directory at /partnerdir.

Training offer

/education provides details of SAP's current Education Services. You can

find out which courses in your country still have free places, or even book

them online.
 

Remote Function Calls and BAPIs

SAP systems use the following interface technologies that are listed in the above


graphic:

• ALE: Application Link Enabling

• BAPI: Business Application Programming Interface

• CPI-C: Common Program Interface Communication

• EDI: Electronic Data Interchange

• HTTP: HyperText Transfer Protocol

• LU 6.2: Logical Unit Type 6.2

• RFC: Remote Function Call

• OLE: Object Linking and Embedding

• SMTP: Simple Mail Transfer Protocol

• SOAP: Simple Object Access Protocol

• TCP/IP: Transmission Control Protocol / Internet Protocol

• XML: Extensible Markup Language

Remote Function Call

The Remote Function Call interface is an SAP interface protocol based on CPI-C

and TCP/IP. It simplifies the programming of communication processes between

different systems. RFCs enable you to call and execute predefined functions in a

remote system – or within the same system. RFCs manage the communication

process, parameter transfer and error handling.

RFC describes an interface, not the programming language in which the function


runs. You can also use RFCs to call functions in non-SAP systems. The procedure

for RFC communication between two SAP systems is that the calling system uses

an RFC definition in the system called to access a specific function.

This function is normally a remote-enabled function module. You can also,

depending on the release, use RFC to call functions in SAP R/2 systems.
If you want to start external programs remotely, you need an RFC interface outside


the SAP system. This could be, for example, a simple Dynamic Link Library

(DLL). Every RFC interface is bidirectional, so external programs can also use

RFC to access functions in SAP systems.

Note: All function modules (including those that are remote-enabled)

are created, together with their import and export parameters, using the

Function Builder. You can call the Function Builder using Tools → ABAP

Workbench → Development → Function Builder or using transaction

code SE37.

To call an RFC module from an SAP system, you need to know the import

and export parameters (defined in the Function Builder), and there must be a

technical connection between the two systems. This connection is called an RFC

connection or an RFC destination.
You can manage your RFC connections using Tools → Administration →


Administration → Network → RFC Destinations or using transaction SM59.

In the above graphic you can see, on the left side, the calling system, in which

an RFC destination named DEST has been created. An RFC destination in

transaction SM59 should not be confused with an SAP system, since an RFC

connection can only point to one specific client in an SAP system. These are

therefore also referred to as connections between logical systems; this term is

used, above all, in the ALE environment.

This also means that you can have at least as many RFC connections between two

systems as there are clients in the target system. Since you can specify a logon

user for the destination in each RFC connection, you can therefore also access

clients in the target system several times, for example, with a different logon user

each time. If you need a bidirectional RFC connection between two systems, that

is, that the system called can also execute RFC modules in the calling system, then

you need to set up an equivalent second RFC connection in the system called.

Hint: When you are defining RFC destinations, RFC connections are

• Addressed to one client, when they are pointing at an SAP system

• Accessible from all clients in the system

In ABAP, you use RFCs to call a function module in another system as follows:

CALL FUNCTION

DESTINATION

EXPORTING ...

IMPORTING ...


The function to be executed in the target system is named. The name of the target

must refer to one of the RFC connections available. When you are creating an

RFC connection, you can specify logon data for the target system; if you do not do

this, you need to enter logon parameters when you start the RFC. Exporting

and Importing are used to pass parameters to the target function and to receive

the returned parameters. The function called in the target system is executed using

the user ID entered for the connection.

Note: You can also create RFC connections for which the user of the user

making the call is used in the target system. That means different users

can use the same connection in the target system. This procedure is also

called Trusted RFC. It is, of course, a prerequisite that identical users are

created in the source and target systems. Trusted RFC is explained in the

course ADM960 - Security in SAP System Environments.

The RFC has become the most important interface in the SAP environment. Some

special RFC modules, which follow certain conventions, are also known as BAPIs

(Business Application Programming Interfaces).

BOR and BAPIs

A Business Application Programming Interface (BAPI) is a standardized

programming interface that facilitates internal and external access to business

processes and data in SAP systems. BAPIs are defined in the Business Object

Repository as methods of SAP business objects and enable an object-oriented

view of business data in an SAP system. Functions that can be called using BAPIs

are normally implemented and stored in the ABAP Workbench Function Builder

as RFC-enabled function modules. You can display an overview of available

BAPIs in the BOR, for example, using the Business Object Repository pushbutton

in the Business Object Builder (Tools → ABAP Workbench → Development →

Business Object Builder), transaction SWO1. You can access the BOR directly

using transaction code BAPI.

BAPIs, which represent methods for business objects in an SAP system, are used

in a variety of contexts. Here are some possible uses for BAPIs:

• To link business processes across system boundaries (for example, when

using ALE)

• Used by SAP to integrate various solutions in the framework of mySAP

Business Suite

• To connect an SAP system to the Internet

• Used in conjunction with SAP Business Workflow

• To connect to external programs

Note: BAPIs are created and tested in exactly the same way as other

function modules, using the Function Builder, transaction SE37, and are

then defined as BAPIs in the BOR.

Cross-System Business Processes

The Significance of Cross-System Business Processes


Let's start by defining cross-system business processes, using common situations

as examples.

For example, it may be the case that within a company, the human resources

system is separate from the rest of the business software system. Obviously, the

systems cannot be completely separate, since the accounting system needs the

employees' wage data. In this situation, you need cross-system business processes

to exchange the relevant data.

Cross-system business processes are used, for example, if two companies

collaborate closely and send joint orders to a vendor. The companies' business IT

systems need to communicate with each other to consolidate the quantities to be

ordered. In this case, the business process does not just cross system boundaries,

but also company boundaries.

An additional example is the transfer of a limited quantity of specific data, for

example, the electronic transfer of account statement data from a bank to a

company.

Recent developments suggest that the significance of cross-system business

processes will continue to increase rapidly.

Application Link Enabling (ALE)

Application Link Enabling is a means of creating and operating distributed

applications. The basic concept of Application Link Enabling is to ensure

operation of a distributed, yet integrated system landscape. This involves

business-controlled message exchange using consistent data across loosely linked


application systems. The applications are integrated through synchronous and

asynchronous communication, not through a central database.

Systems that use ALE to exchange data can be located at the same company, or

they may belong to different companies. One of the characteristics of ALE is

that different systems are linked in business terms through secure and consistent

data transfer.
You could also describe ALE as being composed of the elements: who exchanges


which data when, with whom, and by what means.

Implementing ALE therefore requires that you clarify the following points in

detail:

1. Identify the business process and the objects involved

2. Identify the information to be transmitted

3. Specify the format for the data to be transferred

4. Decide on the transfer technology to be used

5. Decide on the transfer type

6. Specify the destination of the data transfer

The following table contains examples for implementing ALE:
Process Internet Sales with mySAP CRM


Identify the information

to be transmitted

Order data from the SAP CRM System, which is to be

passed to an ERP backend

Format of the data IDoc format

Transfer technology by RFC

Transfer type asynchronously, every 60 seconds

Objective Provide goods and/or services for sale in the Internet

The data is often identified within the SAP system using a business object and its

Business Application Programming Interfaces (BAPIs). A BAPI is a method of a

business object, for example, the material master record. A permissible method

could be creating or changing the material master data. BAPIs normally enable

you to edit all data belonging to the object.

The IDoc format describes the structure of “intermediate documents”. There

are various kinds of IDoc formats for different types of data to be exchanged.

Alternatively, you can use ALE to transfer data in an agreed XML format.

You can select your preferred data transfer technology within the constraints

imposed by the system. For example, you can transfer data by Remote Function

Call (RFC) or using HTTP or HTTPS.

There are two basic transfer types: synchronous and asynchronous. Synchronous

transfer means that the data is transferred at the time of creation or change. You

can start asynchronous transfers at intervals of your choice.

There are very few restrictions on the systems that can be linked. The systems

involved must have the technical capability to receive the communications

(RFC-enabled, HTTP-enabled) and interpret the format transferred (IDoc, XML).

SAP systems of different releases can be linked using ALE.