SAP ABAP Material Free Download

Lists in Unicode Systems

2009-06-23T16:22:00.001+05:30

A WRITE statement writes the content of data objects to a list. When you write using a WRITE statement, the output is stored in the list buffer and is displayed from there when the list is accessed.

Each time a data object is output with WRITE, the system determines an output length either implicitly or explicitly; the implicit output length depends on the data type. The output length defines the following two attributes:

Number of positions or storage spaces available for characters in the list buffer

Number of columns or cells available in the actual list

If the output length is shorter than the length of the data object, the system shortens its content according to certain rules when writing the data to the list buffer. Any values lost in numeric fields are indicated by a *.

When a list is displayed or printed, the contents stored in the list buffer are transferred to the list as follows:

In non-Unicode systems, each character occupies the same amount of space in the list buffer as it requires columns in the list. In single-byte systems, a character requires one byte in the list buffer and one column in the list, while a character that occupies several bytes in the list buffer in a multi-byte system also occupies the same number of columns in the list. For this reason, all characters stored in the list buffer are displayed in the list in non-Unicode systems.

In Unicode systems, each character usually requires one position in the list buffer. However, a character can also occupy more than one column, as is the case for Eastern Asian characters. However, since the list only contains the same number of columns as there are positions in the list buffer, the number of characters that can be displayed in the list is smaller than the number of characters stored in the list buffer in this case. List output is shortened accordingly, with the page formatted according to the specified alignment and marked with the characters > or <. You can then only display the entire content of the list by choosing the menu path System → List → Unicode Display.

For this reason, the horizontal position of the list cursor only has the same meaning as the output column in a list displayed or printed in non-Unicode systems. In Unicode systems, this is only guaranteed for the top and bottom output limits.

Rules for WRITE Statements

To avoid cutting off values unintentionally as far as possible, the rules for WRITE statements in Unicode programs have been modified and extended.

Operands in the WRITE statement

If the data object specified in WRITE is a

flat structure, this must only be character-type in Unicode programs.

Note

This also applies for the statement WRITE TO, in which the target field must also be character-type.

WRITE Statements with Implicit Output Length

In Unicode programs, WRITE statements without an explicitly specified output length for all data objects with the exception of text field literals and data objects of the type string behave in the same way as in non-Unicode programs. This means fewer characters may be displayed in the list than are stored in the list buffer.

In the case of text field literals and data objects of the type string, the system assumes that all characters are to be displayed. For this reason, the implicit output length is calculated according to the characters in the data object in such a way that it corresponds to the number of columns required in the list. If this output length is greater than the length of the data object, superfluous positions are filled with blanks when the data is written to the list buffer. When displaying the data in the list, the system removes these blanks, since the character representation fills the output length exactly.

WRITE Statements with Explicit Output Length

If a numeric data object is specified as an explicit output length after the AT addition for a WRITE statement, the value of this number is used as the output length, both in Unicode and non-Unicode systems. In Unicode systems, the number of characters displayed in the list can differ from the number of characters stored in the list buffer. You can specify the output length in the following way instead of using numeric data objects:

WRITE AT (*) ...
1. In data objects of the types c and string, the output length is set to the number of columns required to display the entire content in the list; closing blanks are not taken into account for type c. In the case of data objects of the type string, this has the same meaning as the implicit length.
2. In data objects of types d and t, the output length is set to 10 and 8.
3. In data objects of the numeric types i, f, and p, the output length is set to the value required to display the current value including thousand separators. This rule is applied to the value after any CURRENCY, DECIMALS, NO-SIGN, ROUND, or UNIT have been used.
4. The implicit output length is used for data objects of the types n, x, and xstring.
WRITE AT (**) ...
1. In data objects of the type c, the output length is set to twice the length of the data object, and in data objects of the type string, to twice the number of characters contained in the object.
2. In data objects of the types d and t, the output length is set to 10 and 8.
3. In data objects of the numeric types i, f, and p, the output length is set to the value required in order to display the maximum possible values for these types, including plus and minus signs and thousand separators. This rule is applied to the value after any CURRENCY, DECIMALS, NO-SIGN, ROUND, or UNIT additions have been used.
4. The implicit output length is used for data objects of the types n, x, and xstring.

The behavior of the output lengths (*) and (**) when using the addition USING EDIT MASK and the templates for date fields is described in Formatting Options.

Additions for GET/SET CURSOR FIELD/LINE

The additions DISPLAY OFFSET and MEMORY OFFSETtake account of the fact that data objects can occupy different lengths when displayed in a list and when stored temporarily in the list buffer.

In accordance with this fact, the addition DISPLAY OFFSET off positions the cursor in the column in the output area specified in off for the SET CURSOR { FIELD f | LINE l } statement. The addition MEMORY OFFSET off positions the cursor on the character in the output area that is located in the position (of the data object in f) in the list buffer specified in off.

In the same way, a GET CURSOR { FIELD f | LINE l } statement used with the addition DISPLAY OFFSET off places the cursor position in the output area in the data object off. When you use the addition MEMORY OFFSET off, the cursor position in the list buffer that is assigned to the character displayed is placed in the data object off. The addition DISPLAY is the standard setting and can therefore be ignored.

Class for Formatting Lists

Class CL_ABAP_LIST_UTILITIES has been introduced to calculate output lengths, convert values from the list buffer, and define field limits. The return values of the methods of this class can be used to program a correct column alignment in ABAP lists, even for output of Eastern Asian characters.

List Settings

The objects in a list can be displayed in different output lengths by specifying the desired length in the menu under System → List → Unicode Display. This is particularly advantageous for screen lists in Unicode systems where the output is cut off as indicated by the characters > or <.

Recommendations

We recommend that you adhere to the following rules when programming lists, to ensure that they have the same appearance and functions both in Unicode and non-Unicode systems:

Specify an adequate output length

Do not overwrite parts of a field

Do not use the additions RIGHT-JUSTIFIED or CENTERED for WRITE TO if this statement is followed by list output with WRITE.

In customer-programmed horizontal scrolling with a SCROLL statement, you should only specify the upper or lower limit of data objects displayed, since the positions in the list buffer and in the list displayed are only certain to match for these field limits in Unicode systems.

The File Interface in Unicode Programs

2009-06-23T16:21:00.000+05:30

Since the content of files frequently reflects the structure of data in the working memory, the file interface in a Unicode system must fulfill the following requirements:

It must be possible to exchange data between Unicode and non-Unicode systems.

It must be possible to exchange data between different Unicode systems.

It must be possible to exchange data between different non-Unicode systems that use different code pages.

For this reason, in Unicode programs, you must always define the code page used to encode the character-type data that is written in text files or that is read from text files.

You must also consider that a Unicode program must be executable in a non-Unicode system as well as a Unicode system. Some of the syntax rules for the file interface have therefore been modified so that programming data access in Unicode programs is less prone to errors than in non-Unicode programs.

Before every read or write access, a file must be opened explicitly using OPEN DATASET. Furthermore, a file that is already open cannot be opened again. In non-Unicode programs, the first time a file is accessed, it is implicitly opened using the standard settings. The statement for opening a file can be applied to an open file in non-Unicode-programs, although a file can only be opened once within a program.

When opening the file, the access type and type of file storage must be specified explicitly using the following additions:

INPUT|OUTPUT|APPENDING|UPDATE

[LEGACY] BINARY|TEXT MODE

When opening a file in TEXT MODE, the ENCODING addition must be used to specify the character representation. When opening a file in LEGACY MODE, the byte order (endian) and a non-Unicode code page must be specified.

In non-Unicode programs, if nothing is entered, a file is opened with implicit standard settings.

If a file is opened for reading, the content can only be read. In non-Unicode programs, it is also possible to gain write access to these files.

If a file is opened as a text file, only the content of character-type data objects can be read or written. In non-Unicode programs, byte-type and numeric data objects are also allowed.

Note

In Unicode programs, file names can also contain blank characters.

Character String and Byte String Processing in Unicode Programs

2009-06-23T16:20:00.002+05:30

In Unicode programs, character string and byte string processing are strictly separated. The operands of character string processing must be character-like data objects, and operands in byte string processing must be byte-like data objects. In non-Unicode programs, byte strings are normally handled in the same way as character strings.

Syntactic separation

Statements for character string and byte string processing

In the statements for character string and byte string processing, in Unicode programs, the distinction is made in the statements that are intended for both types of processing by the optional addition IN CHARACTER|BYTE MODE. In this case, IN CHARACTER MODE is the default.

Note

The addition IN CHARACTER|BYTE MODE is also used in the statements for determining length and offset:

DESCRIBE FIELD ... LENGTH

DESCRIBE DISTANCE

In this case, the specifications are obligatory

Relational operators for character strings and byte strings

There are relational operators for character strings and for byte strings. In Unicode programs, the latter can no longer be used for byte strings.

Functions for character strings and byte strings

The description functions are divided into description functions for character strings and description functions for byte strings. In particular, in Unicode programs, strlen can now only be used for character-like arguments, while xstrlen is available for byte-like arguments.

Structure Enhancements and Unicode Programs

2009-06-23T16:20:00.001+05:30

Since Release 3.0, the ABAP Dictionary structures and database tables that are delivered by SAP can be subsequently enhanced with Customizing-Includes or append structures. Such changes cause problems in unicode programs if the enhancement changes the unicode fragment view.

For this reason, the option to classify structures and database tables was introduced, which makes it possible to recognize and handle problems related to structure enhancements. This classification is used during the program check to create a warning at all points where it works with structures, and where later structure enhancements can cause syntax errors or changes in program behavior. When you define a structure or a database table in the ABAP Dictionary, you can specify the enhancement categories that are displayed in the following table as classification.

Level	Category	Meaning
1	Not classified	The structure does not have an enhancement category.
2	Cannot be enhanced	The structure may not be enhanced.
3	Can be enhanced and character-type	All structure components and their enhancements have to be character-type flat.
4	Can be enhanced and character-type or numeric.	All structure components and their enhancements have to be flat.
5	Any enhancements	All structure components and their enhancements can have any data type.

The warnings displayed after the program check - depending on the effects of the structure enhancements that are permitted - are classified into three levels from the following table.

Level	Type of Check	Meaning
A	Syntax check	An enhancement that fully utilizes the enhancement category of the relevant structure. It leads to a syntax error.
B	Extended check	Permitted enhancements can, but do not always have to, result in a syntax error.
C	Extended check	Permitted enhancements cannot result in syntax errors, although changes to program behavior do result in semantic problems.

Example

If the structure ddic_struc in the ABAP Dictionary is defined only with flat components but is classified as Any enhancements, then the following program section leads to a warning during the syntax check. If the structure were enhanced by a deep component after the program was delivered, the program would be syntactically incorrect and no longer executable. This is why in this case you either have to classify the structure ddic_struc in the ABAP Dictionary as Can be enhanced and character-type or else you cannot specify the offset/length in the program.

DATA: my_struc TYPE ddic_struc,
str TYPE string,
off TYPE i,
len TYPE i.
...
str = my_struc+off(len).

Structure Typing in Unicode Programs

2009-06-23T16:19:00.002+05:30

For downward compatibility reasons, a structure can still be cast for field symbols and parameters of function modules and subroutines using the obsolete addition STRUCTURE.

When assigning a data object to such a field symbol or passing an actual parameter to such a formal parameter, in non-Unicode programs, the system only checks whether the length of the data object or actual parameter has at least the length of the structure and whether the alignment is identical at runtime. Unicode programs make a difference between structured and elementary data objects or actual parameters. For a structured data object or actual parameter, its Unicode fragment view must match the cast structure including all alignment gaps (including the closing ones). In addition, an elementary data object or actual parameter must be character-type and flat.

When a formal parameter of a function module is typed with a flat structure using LIKE instead of TYPE, LIKE has the same effect as STRUCTURE. However, the system checks the exact length during the parameter transfer in non-Unicode programs.

Note

The check of the Unicode fragment view can avoid problems that occur in non-Unicode systems due to closing alignment gaps. Example: The filliing of actual parameters with the content of an alignment gap which is not type-specific.

Conversion of Structures in Unicode Programs

2009-06-23T16:19:00.001+05:30

The most important differences between the behaviors of Unicode programs and non-Unicode programs are the changed conversion rules for structures for assignments and for comparisons.

Note

Two structures in Unicode programs are only compatible when all alignment gaps are identical on all platforms. This applies in particular for alignment gaps that are created by included structures (INCLUDE)

Assignments between flat structures

In non-Unicode programs, incompatible flat structures are treated as data objects of the type c, whereas in Unicode programs, conversion rules apply which assign the most important role to the Unicode fragment view of the structures.

Assignments between flat structures and single fields

In non-Unicode programs, flat structures are treated as data objects of the type c in case of the assignment of elementary data objects and the assignment to elementary data objects, whereas in Unicode programs, aconversion rule applies according to which the structure must be character-type either completely or at least in the initial fragment.

Comparisons between incompatible flat structures

As is the case with the assignment, the structures are not treated as c fields, but according to their Unicode fragment view (see comparison rules between operands).

Comparisons between flat structures and single fields

As is the case with the assignment, the system checks whether the structure is character-type either completely or at least in the initial fragment (see Comparison Operators for All Data Types).

Access to memory sequences in Unicode programs

2009-06-23T16:18:00.003+05:30

The following (in some cases obsolete) statements access data objects that are stored in the memory as an equally spaced sequence:

DO ... VARYING

WHILE ... VARY

ADD ... THEN ... UNTIL

ADD ... FROM ... TO

In the DO and WHILE loops in Unicode programs, all data objects of the sequence must be compatible and either be structure components that belong to the same structure, or subareas of the same data object specified using offset/length specifications. In Unicode programs, a RANGE must also be entered if it cannot be statically recognized that the data objects involved are components of the same structure. Otherwise, the permitted memory area is determined from the smallest possible substructure.

When memory sequences are added using ADD, in Unicode programs, all data objects of the sequence must be components of a structure. If this cannot be statically recognized in the syntax check, a structure must be specified using the addition RANGE.

Offset and Length Specifications in Unicode Programs

2009-06-23T16:18:00.001+05:30

Offset/length specifications are made by appending [+off][(len)] to the name of a data object in operand position, and the specifications are used to access subareas of a data object. This type of programming is no longer completely possible in Unicode systems because, for example when accessing structures with components of different data types, it is not possible to define whether offset and length should be specified in characters or bytes. Furthermore, restrictions have been introduced that forbid access to memory areas outside of flat data objects.

Offset/length specifications for elementary data objects

Offset/length specifications are permitted for character-type and byte-type data objects. The specification of offset and length is interpreted either as a number of characters or as a number of bytes. The rules that determine which data objects in Unicode programs count as character-type or byte-type objects do not allow for offset/length specifications for data objects of numeric data types.

Note

The method of using data objects of type c as containers for storing structures of different types, which are often not known until runtime, in which components are accessed using offset/length access, is no longer possible in Unicode programs. Instead of these containers, the statement CREATE DATA can be used to generate data objects of any structure. To enable access to existing containers, these can be assigned to a field symbol using the CASTING addition of the statement ASSIGN. The COMPONENT addition can then be used to access components.

Offset/length specifications for structures

An offset/length specification for a structure is only permitted in Unicode systems if the structure is either

character-type (i.e. it only contains flat character-type components), or it is

flat, has a character-type initial fragment according to the Unicode fragment view, and the offset/length specification accesses this initial fragment.

In both cases, the specification of offset and length is interpreted as a number of characters.

Example

The following structure has both character-type and non-character-type components:

BEGIN OF STRUC,
a TYPE c LENGTH 3, "Length 3 characters
b TYPE n LENGTH 4, "Length 4 characters
c TYPE d, "Length 8 characters
d TYPE t, "Length 6 characters
e TYPE decfloat16, "Length 8 bytes
f TYPE c LENGTH 28, "Length28 characters
g TYPE x LENGTH 2, "Length 2 bytes
END OF STRUC.

The Unicode fragment view splits the structure into four areas F1 - F5.

[ aaa | bbbb | cccccccc | ddd | AAA | eeee | fffffffffffff | gg ]
[ F1 | F2 | F3 | F4 | F5 ]

Offset/length access is only possible for the character-type initial fragment F1. Specifications such as struc(21) or struc+7(14) are accepted and are handled as a single field of type c. An access such as struc+57(2), for example, is not permitted in Unicode systems.

Offset/length specifications for actual parameters

For actual parameters specified in PERFORM, in Unicode programs, it is not possible to specify a memory area outside of the actual parameter using offset/length specifications. In particular, it is no longer possible to specify an offset without a length, as this would implicitly set the length of the actual parameter.

Offset/length specification for field symbols

When assigning a memory area to a field symbol using the ASSIGN statement, in Unicode programs it is now only possible to use offset/length specifications to access the memory within the data object. The addition RANGE determines the data object.

Field symbols themselves are also allocated an assignable memory area. This is effective if a field symbol is used as a source in the ASSIGN statement.

In non-Unicode programs, the assignable area is defined by the data area of the current program, which can lead to references being overwritten.

If a data object is entered as a source in ASSIGN, no offset can be specified without a length unless the explicit RANGE addition is specified. Otherwise, this would implicitly set the length of the data object. If the name of a field symbol is specified, its data type in Unicode programs must be flat and elementary if an offset is specified without a length.

Note

Previously, cross-field offset/length accesses could be usefully implemented in the ASSIGN statement for processing repeating groups in structures. In order to enable this in Unicode systems, the ASSIGN statement has been enhanced with the additions RANGE and INCREMENT.

Alignment in Unicode Systems

2009-06-23T16:17:00.001+05:30

In Unicode systems, in addition to the alignment requirements for numeric data objects of types i, decfloat16, decfloat34, and f and of deep data objects, all character-type data types are also affected. The alignment is determined by the length requirement of a character in the memory.

As a consequence, in structures with components of different data types, the alignment gaps in Unicode systems may be different to those in non Unicode systems. For enhancements between structures, the Unicode fragment view concept has been introduced, which divides a structure into fragments according to its alignment gaps.

Note

Alignment gaps can also occur at the end of structures, as the overall length of the structure is determined by the component with the largest alignment requirement.

Example

In the following structure, alignment gaps (A) occur in Unicode systems that are not present in non-Unicode systems. The first alignment gap is formed as a result of the alignment of the substructure struc2, the second due to the alignment of the component c of type c>, and the third is due to the component d of type i.

BEGIN OF struc1
a TYPE x LENGTH 1,
BEGIN OF struc2
b TYPE x LENGTH 1,
c TYPE c LENGTH 6,
END OF struc2
d TYPE i,
END OF struc1

Non-Unicode system [ a | b | cccccc | dddd ]
Unicode system [ a | A | b | A | cccccccccccc | AA | dddd ]

Operand Types in Unicode Programs

2009-06-23T16:15:00.002+05:30

One of the most important differences between Unicode and non-Unicode programs is the clear distinction between character-type data objects and byte-type data objects, and the restriction of data types whose objects can be viewed as character-type. This has an influence on all statements in which character-type operands are expected, and in particular on character string and byte string processing.

Character-type data objects

In Unicode programs, only the following elementary data objects are now character-type:

Data type	Meaning
c	Text field
d	Date field
n	Numerical text
t	Time field
string	Text string

In addition, structures are character-type if they contain only flat character-type components (only components from the above table with the exception of text strings).

In Unicode programs, a structure can now essentially only be used at an operand position that expects a single field if the structure is character-type. It is then handled in the same way as a data object of type c.

In non-Unicode programs, all flat structures and byte-type data objects are also still handled as character-type data objects (implicit casting).

Note

The incorrect use of structures at operand positions is greatly restricted in Unicode programs. For example, a structure that contains a numeric component can no longer be used at a numeric operand position.

Byte-type data objects

In Unicode programs, elementary data objects of types x and xstringare byte-type. In non-Unicode programs, data objects of this type are generally handled as character-type. Conversely, in non-Unicode programs, at positions in which byte processing takes place (SET BIT, GET BIT and the logical operators O, Z, M), character-type data objects are still expected, while in Unicode programs only byte-type data objects are permitted.

Note

In Unicode programs, the storage of byte strings in character-type containers causes problems, as the byte order of character-type data objects in Unicode systems is platform dependent. In non-Unicode systems, this only applies for data objects of numeric data types. The content of the data objects is interpreted incorrectly if a container of this type is stored persistently and is then imported to an application server with a different byte sequence.

Names in Unicode Programs

2009-06-23T16:15:00.001+05:30

Names in Unicode Programs

Only the following characters are allowed in names in Unicode programs:

The letters "A" through "Z"
The digits "0" through "9"
Underscores ("_")

For compatibility reasons, you can also use the characters "%", "$", "?", "-", "#", and "*" but these should be used only in exception cases (for example, for existing program generations) and with good justification. You can also use forward slashes ("/") for namespace prefixes.

Note

Apart from ABAP Objects, non-Unicode programs can also use characters other than the ones listed above. This can cause the following problems in these programs:

If characters are used that are not available in all code page supported by SAP, it might not be possible to run certain programs when using a different code page to the one in which they were created.

No string templates can be used in a non-Unicode program.

Comments and Literals in Non-Unicode Programs

2009-06-23T16:14:00.000+05:30

In non-Unicode systems, no characters should be used in comments unless they are available in all code pages supported by SAP. In the worst case, a program can no longer be executed when a code page other than the one in which it was created is used. We recommend the usage of 7-Bit-ASCII-characters only.

Note

In a Unicode system, all source codes are stored in Unicode and this is why this problem does not occur there. However, even in Unicode programs, do not use characters for comments and literals if they cannot be displayed in non-Unicode programs, so that programs can be transported from a Unicode system to a non-Unicode system without losses during conversion.

Differences between Unicode and Non-Unicode Programs

2009-06-23T16:13:00.000+05:30

The ABAP key word documentation describes the ABAP statements for both Unicode and non-Unicode systems. Only Unicode programs can be compiled and executed in Unicode systems. In non-Unicode systems, this is also possible for non-Unicode programs. However, Unicode programs should also be used in non-Unicode systems, for the following reasons:

Static type checks are executed in Unicode programs.

Byte processing and string processing is separated in Unicode programs.

Structures are always handled as structures in Unicode programs.

Uncontrolled access to segments of the working memory is not possible in Unicode programs.

This makes Unicode programs easier to understand, more robust, and easier to maintain than non-Unicode programs.

The following section lists the language constructs and statements for which there are differences between Unicode and non-Unicode programs:

Comments and Literals in Non-Unicode Programs

Names in Unicode Programs

Program Structure of Unicode Programs

Operand Types in Unicode Programs

Alignment in Unicode Systems

Offset and Length Specifications in Unicode Programs

Access to Memory Sequences in Unicode Programs

Conversion of Structures in Unicode Programs

Structure Typing in Unicode Programs

Structure Enhancements and Unicode Programs

String and Byte String Processing in Unicode Programs

Function Module Calls in Unicode Programs

Open SQL in Unicode Programs

File Interface in Unicode Programs

Lists in Unicode Systems

Unicode - Overview

2009-06-23T16:12:00.000+05:30

Application Server ABAP supports both Unicode and non-Unicode systems. Non-Unicode systems are traditional ABAP systems in which one character is usually represented by one byte. Unicode systems are ABAP systems that are based on Unicode representation and an appropriate operating system and database.

Before Unicode, SAP used various different codes for representing characters in different fonts, such as ASCII, EBCDIC as single-byte code pages, or double-bytecode pages:

ASCII (American Standard Code for Information Interchange) encodes every character with one byte. This means that a maximum of 256 characters can be displayed (strictly speaking, standard ASCII only encodes one character using 7 bit and can therefore only represent 128 characters. The extension to 8 bit is introduced with ISO-8859). Examples of common code pages are ISO-8859-1 for Western European, or ISO-8859-5 for Cyrillic fonts.

EBCDIC (Extended Binary Coded Decimal Interchange) also encodes each character using one byte, and can therefore also represent 256 characters. For example,EBCDIC 0697/0500 is an IBM format that has been used on the AS/400 (now known as IBM System i)platform for Western European fonts.

Double byte code pages require between 1 and 2 bytes per character. This enables the representation of 65,536 characters, of which only 10,000 to 15,000 characters are normally used. For example, the code page SJIS is used for Japanese and BIG5 for traditional Chinese fonts.

Using these character sets, all languages can be handled individually in one AS ABAP. Difficulties arise if texts from different incompatible character sets are mixed in one central system. The exchange of data between systems with incompatible character sets can also lead to problems.

The solution to this problem is the use of a character set that includes all characters at once. This is realized by Unicode (ISO/IEC 10646). A variety of Unicode character representations is possible for the Unicode character set, for example UTF, in which a character can occupy between one and four bytes.

From Release 6.10, the SAP NetWeaver Application Server supports both Unicode and non-Unicode systems. Non-Unicode systems are conventional ABAP systems, in which one character is usually represented by one byte. Unicode systems are ABAP systems that are based on a Unicode character set and which have a corresponding underlying operating system, including a database.

Before Release 6.10, many ABAP programming methods were based on the fact that one character corresponds to one byte. Before a system is converted to Unicode, ABAP programs must therefore be modified at all points where an explicit or implicit assumption is made about the internal length of a character.

ABAP supports this conversion using new syntax rules and new language constructs, whereby emphasis was placed on retaining as much of the existing source code as possible. As a preparation for the conversion to Unicode - but also independently of whether a system will actually be converted to Unicode - the checkbox Unicode checks active can be selected in the program properties. The transaction UCCHECK supports the activation of this check for existing programs. If this property is set, the program is identified as a Unicode program. In a Unicode program, an additional stricter syntax check is performed than in non-Unicode programs. In some cases, statements must also be enhanced by using new additions. A syntactically correct Unicode program will normally run with the same semantics and the same results in Unicode and non-Unicode systems. (Exceptions to this rule are low-level programs that query and evaluate the number of bytes per character). Programs that are required to run in both systems should therefore also be tested on both platforms.

In a Unicode system, only Unicode programs can be executed. Before converting to a Unicode system, the profile parameter abap/unicode_check should be set to "ON" so that only the execution of Unicode programs is permitted. Non-Unicode programs can only be executed in non-Unicode systems. All language constructs that have been introduced for Unicode programs can, however, also be used in non-Unicode programs.

It has been established that existing programs that have been programmed with no errors mostly fulfill the new Unicode rules and therefore require very little modification. Conversely, most programs that require significant changes are due to an error-prone and therefore questionable programming style. Even if you are not planning a conversion to a Unicode system, Unicode programs are preferable because they are more easily maintained and less prone to errors. Just as outdated and dangerous language constructs are declared obsolete and are no longer permitted for use in ABAP objects, the rules for Unicode programs also offer increased security when programming, for example when working with character fields and mixed structures. This applies particularly for the storage of external data (for example using the file interface), which has been completely reviewed for use in Unicode programs. When creating a new program, SAP therefore recommends that you always identify the program as a Unicode program, and older programs can be converted to Unicode in stages.

Statements in Class and Interface Pools

2009-06-23T16:10:00.000+05:30

Class and interface pools are the ABAP programs in the Class Library. They are defined using the Class Builder tool in ABAP Workbench and are used as a repository for global classes and interfaces.

A program with the program type class pool is launched using the statement CLASS-POOL.

A program with the program type interface pool is launched using the statement INTERFACE-POOL.

These statements are generated by Class Builder.

Each class pool or interface pool can only contain a single global class or a single global interface. These classes or interfaces are declared using the following statements:

CLASS ... PUBLIC. ... ENDCLASS.

INTERFACE ... PUBLIC. ... ENDINTERFACE.

Class Builder uses the properties entered here to generate these statements.

Further Statements in Class Pools

As well as the declaration of the global class, a class pool can only contain the following statements:

Declaration of local data types using the statement TYPES. These data types can be used by the global class in the private visibility section and in the implementation part.

Declaration of local interfaces using the interfaces INTERFACE ... ENDINTERFACE. These interfaces can be used by the global class in the private visibility section and in the implementation part.

Declaration and implementation of local classes using the statements CLASS ... ENDCLASS. These classes can be used by the global class in the private visibility section and in the implementation part.

Definition of macros using DEFINE ...END-OF-DEFINITION . These macros can be used by the global class in the implementation part.

Locally defined types, classes, and interfaces in class pools can be used in the following ways:

Only the methods of the global class access the local declarations and implementations in the program. These methods can provide utility methods, for example, which are invisible in the interface of the global class. This is the most common scenario. Any changes made to local declarations in the program do not influence the interface of the global class.

As well as the methods in the global class, declarations in the private visibility section of the class also reference local declarations in the program. This is a more unusual scenario, in which changes made to the local declarations influence the interface of the global class, and subclasses and friends of the global class are recompiled before the program is executed again.

Further Statements in Interface Pools

An interface pool cannot contain any local declarations or implementations as well as the declaration of the global interface. The interface pool cannot contain any of its own declarations or implementations.

Program Organization

Like any other ABAP program, class pools and interface pools consist of a global declaration part for declarations and an implementation part for implementations (or procedures).

This means that the global declaration part of a class pool can contain the declarations of local data types, local interfaces, and local classes, as well as the actual declaration part of the global class. The implementation part of a class pool can contain the implementation parts of local classes, as well as the implementation part of the global class.

The global declaration part of an interface pool can only contain the declaration of type groups alongside the declaration of the global interface. The implementation part of an interface pool is always empty.

Class Builder organizes the various declarations and implementations of a class pool or interface pool in include programs.The developer cannot usually view the names of these programs. A Class Builder function allows you to open the associated include programs in ABAP Editor and edit them. Include programs exist for:

Each visibility section in the declaration part of the global class

Each implementation of a method from the global class

Local declarations and implementations in programs

Test classes from ABAP Unit

As well as the editing functions for the individual include programs, Class Builder also provides you with a source code-based mode where you can display all the include programs as a single program, and edit them.

Restrictions

Apart from the statements listed above, class pools and interface pools do not require any other statements outside of CLASS - ENDCLASS orINTERFACE - ENDINTERFACE, nor are these statements allowed. The stricter syntax for ABAP Objects applies to all permitted statements.

The following restrictions are particularly important:

No processing blocks except methods

Event blocks such as START-OF-SELECTION, AT SELECTION-SCREEN, GET, or AT LINE-SELECTION are not allowed, and neither are dialog modules (defined by MODULE - ENDMODULE). This means that runtime environment events cannot be processed. ABAP Objects has its own event concept. Nor can you define function modules or subroutines using FUNCTION - ENDFUNCTION or FORM - ENDFORM. The methods of a class pool can still call external function modules and subroutines, as well as methods.

No shared data areas with other programs

The statements TABLES, NODES, and the addition COMMON PART of the DATA statement are not possible. This means that class pools and interface pools do not support any global data areas across programs within a single internal mode.

No separate screens

Screen processing as implemented in other ABAP programs is not possible. No screens ("dynpros") can be defined in a class pool or interface pool. If you want to use classic dynpros, including selection screens, we recommend that you encapsulate them in function groups. We also recommend that you use alternatives to classic lists, for example classes from SAP List Viewer (ALV) such as CL_SALV_TABLE, for displaying lists in tables.. For simple text output, we recommend browser control wrappers such as dynamic documents or text edit control wrappers.

No processing of extracts

In global classes, extract data sets can be edited, since the defining statement FIELD-GROUPS is forbidden in class or interface pools.

Statements for Defining Classes and Interfaces

2009-06-23T16:09:00.000+05:30

he following statements define classes and interfaces and their components. You can use them in any ABAP program in which class and interface can be defined.

Statements for Defining Classes

Defining the Declaration Part

CLASS ... DEFINITION ...
...
ENDCLASS ...

Defining the Implementation Part

CLASS ... IMPLEMENTATION ...
...
ENDCLASS ...

Statements for Defining Class Components

Statements in the Declaration Part

PUBLIC SECTION.
PROTECTED SECTION.
PRIVATE SECTION.

TYPES ...

INTERFACES ...
ALIASES ...

CONSTANTS ...

CLASS-DATA ...
DATA ...

CLASS-METHODS ...
METHODS ...

CLASS-EVENTS ...
EVENTS ...

Statements in the Implementation Part

METHOD ...
...
ENDMETHOD.

Statements for Defining Interfaces

Declaring the Interface

INTERFACE ...
...
ENDINTERFACE ...

Statements for Declaring Interface Components

In interfaces, you can use the same statements to declare interface components as those used in the declaration part of classes.

Note

In the declaration part of a class or in interface, you declare its components, that is, its attributes, methods, and events. You can declare local data types using the TYPES statement. You can also declare alias names for the components of implemented interfaces using the ALIASES statement. In a class, all declarations must belong to one of the four visibility sections introduced by the relevant statement.

The implementation part of a class only contains method implementations in METHOD - ENDMETHOD blocks. In a method, you can only use the statements for method implementations.

No statements other than those listed above are necessary for defining classes or interfaces. Consequently, no other statements are allowed between CLASS and ENDCLASS or INTERFACE - ENDINTERFACE except within methods.

The stricter syntax in ABAP Objects applies to all statements for defining classes and interfaces.

ABAP Objects - Keywords

2009-06-23T16:06:00.000+05:30

The following list displays the keywords specially introduced for ABAP objects.

ALIASES	Declaration of an alias name
CALL METHOD	Call of a method
CLASS ... ENDCLASS	Definition of a class
CLASS-DATA	Declaration of a static attribute
CLASS-EVENTS	Declaration of a static event
CLASS-METHODS	Declaration of a static method
CREATE OBJECT	Creation of an object
EVENTS	Declaration of an instance event
INTERFACE ... ENDINTERFACE	Definition of an interface
INTERFACES	Including an interface
METHOD ... ENDMETHOD	Definition of a method
METHODS	Declaration of an Instance method
PRIVATE SECTION	Start of private visibility section
PROTECTED SECTION	Start of a protected visibility section
PUBLIC SECTION	Start of the public visibility section
RAISE EVENT	Triggering an event
SET HANDLER	Registering an event

Inheritance Events

2009-06-23T16:04:00.001+05:30

The example demonstrates the behavior of inheritance events.

Source Text

REPORT demo_event_inheritance.

CLASS c1 DEFINITION.
PUBLIC SECTION.
CLASS-EVENTS ce1.
CLASS-METHODS cm1.
EVENTS ie1.
METHODS im1.
ENDCLASS.

CLASS c2 DEFINITION INHERITING FROM c1.
PUBLIC SECTION.
CLASS-METHODS cm2.
METHODS im2.
ENDCLASS.

CLASS c3 DEFINITION INHERITING FROM c2.
PUBLIC SECTION.
CLASS-METHODS cm3.
METHODS im3.
ENDCLASS.

CLASS c4 DEFINITION.
PUBLIC SECTION.
CLASS-METHODS cm4 FOR EVENT ce1 OF c2.
METHODS im4 FOR EVENT ie1 OF c2.
ENDCLASS.

CLASS event_demo DEFINITION.
PUBLIC SECTION.
CLASS-DATA handle_flag TYPE c LENGTH 1.
CLASS-METHODS main.
ENDCLASS.

CLASS event_demo IMPLEMENTATION.
METHOD main.

DATA oref1 TYPE REF TO c1.
DATA oref2 TYPE REF TO c2.
DATA oref3 TYPE REF TO c3.
DATA oref4 TYPE REF TO c4.

"Static event

SET HANDLER c4=>cm4.

c1=>cm1( ).
WRITE: / 'c1=>cm1( ):', handle_flag.
c2=>cm1( ).
WRITE: / 'c2=>cm1( ):', handle_flag.
c3=>cm1( ).
WRITE: / 'c3=>cm1( ):', handle_flag.
c2=>cm2( ).
WRITE: / 'c2=>cm2( ):', handle_flag.
c3=>cm2( ).
WRITE: / 'c3=>cm2( ):', handle_flag.
c3=>cm3( ).
WRITE: / 'c3=>cm3( ):', handle_flag.

SKIP.

"Instance event

CREATE OBJECT: oref1, oref2, oref3, oref4.
SET HANDLER oref4->im4 FOR ALL INSTANCES.

oref1->im1( ).
WRITE: / 'oref1->im1( ):', handle_flag.
oref2->im1( ).
WRITE: / 'oref2->im1( ):', handle_flag.
oref3->im1( ).
WRITE: / 'oref3->im1( ):', handle_flag.
oref2->im2( ).
WRITE: / 'oref2->im2( ):', handle_flag.
oref3->im2( ).
WRITE: / 'oref3->im2( ):', handle_flag.
oref3->im3( ).
WRITE: / 'oref3->im3( ):', handle_flag.

ENDMETHOD.
ENDCLASS.

START-OF-SELECTION.
event_demo=>main( ).

CLASS c1 IMPLEMENTATION.
METHOD cm1.
CLEAR event_demo=>handle_flag.
RAISE EVENT ce1.
ENDMETHOD.
METHOD im1.
CLEAR event_demo=>handle_flag.
RAISE EVENT ie1.
ENDMETHOD.
ENDCLASS.

CLASS c2 IMPLEMENTATION.
METHOD cm2.
CLEAR event_demo=>handle_flag.
RAISE EVENT ce1.
ENDMETHOD.
METHOD im2.
CLEAR event_demo=>handle_flag.
RAISE EVENT ie1.
ENDMETHOD.
ENDCLASS.

CLASS c3 IMPLEMENTATION.
METHOD cm3.
CLEAR event_demo=>handle_flag.
RAISE EVENT ce1.
ENDMETHOD.
METHOD im3.
CLEAR event_demo=>handle_flag.
RAISE EVENT ie1.
ENDMETHOD.
ENDCLASS.

CLASS c4 IMPLEMENTATION.
METHOD cm4.
event_demo=>handle_flag = 'X'.
ENDMETHOD.
METHOD im4.
event_demo=>handle_flag = 'X'.
ENDMETHOD.
ENDCLASS.

Description

In a c1 superclass, a static event ce1 and an instance event ie1 are declared. The superclass c1, and its subclass c2, and its subclass c3, each contain a static method and an instance method to trigger events.

In the c4 class, event handlers are declared in c2 for the events inherited from c1. The main method of the event_demo class registers events and calls all methods which can trigger events, whereby different possibilities are used to address the methods. The output displays an "X" after the method call for a handled event.

The event handler cm4, declared for the c2 class, can only handle events which are triggered in this class or in its subclasses. Events which are triggered by the static method cm1 in c1, are not handled, irrelevant of the class name which is specified for the call (also refer to Inheritance and Static Components).

The event handler im4, declared for the c2 class, can also only handle events which are triggered in this class or in its subclasses. Unlike when calling static methods, the class of the object is always addressed when addressing an object using an object reference, and triggered events in the inherited method im1 of the c2 and c3 classes are handled.

Inheritance and Events

2009-06-23T16:03:00.002+05:30

After its declaration in a superclass, an event is known in all subclasses of the inheritance tree in which it is visible, and can be triggered in the methods there.

An event handler can be declared with reference to all classes of the inheritance tree in which the event is visible for the event handler. However, it can only handle events which are triggered in classes which more specific or the same as the class for which it is declared. If the event is triggered in a method of a superclass of the class, for which an event handler is declared it cannot handle it.

Note the latter especially when triggering static events in static methods, since a static method is always executed in the class in which it was declared (also refer to Inheritance and Static Components).

Note

For event handlers for events declared in interfaces, the above applies correspondingly to the class in which the interface is bound

Inheritance and Instantiation

2009-06-23T16:03:00.001+05:30

If you instantiate a subclass, you instantiate all the superclasses at the same time, whereby the initialization of superclass attributes is ensured by the call of the superclass constructors, as described in Inheritance and Constructors.

For each individual class, the CREATE PUBLIC|PROTECTED|PRIVATE additions to the CLASS statement control who can create an instance of the class or, in other words, can call its instance constructor.

The effects of this is are:

If you defined a superclass in a path of the inheritance tree using the CREATE PRIVATEaddition, outside users cannot instantiate a subclass, and a subclass cannot even instantiate itself, because it has no access to the instance constructor of the superclass.

It would be useful, therefore, also to apply the FINAL addition to a class that was defined using the CREATE PRIVATE addition, in order to prevent a derivation of subclasses. Otherwise subclasses of such superclasses have the implicit CREATE NONE addition.

The only exception to this rule is if a superclass that can be privately instantiated offers its friendship to its subclasses. The direct route is rarely the case here because the superclass must know its subclasses in order for it to be possible. However, a superclass can also offer friendship to an interface which, in turn, can be implemented by its subclasses.

Conversely, you cannot create objects of subclasses in their superclass, if these are declared using CREATE PROTECTED or CREATE PRIVATE, unless they are friends of its subclasses.

Possible Cases

Superclass with no addition or CREATE PUBLIC

Whether they are friends of the superclass or not, subclasses can have every CREATE addition. Without addition they inherit the attribute CREATE PUBLIC. The superclass instance constructor is visible to everyone. The subclass controls the visibility of its own instance constructor, independently of the superclass.

Superclass with CREATE PROTECTED addition.

Whether they are friends of the superclass or not, subclasses can have every CREATE addition. Without addition they inherit the attribute CREATE PROTECTED. The superclass allows its subclasses unlimited instantiation and therefore also the publishing of its protected instance constructor.

Superclass with CREATE PRIVATE addition

Subclass no friend of the superclass

The subclass has the implicit addition CREATE NONE. Since nobody other than the superclass itself can call its instance constructor, the subclass cannot be instantiated. None of the CREATE additions is permitted since this would always lead to the unauthorized publishing of the superclass constructor.

Subclass is friend of the superclass

If the subclass has no addition, it inherits the attribute CREATE PRIVATE. However, all CREATE additions are permitted. As a friend, the subclass can publish the superclass' private constructor in any form.

Inheritance and Constructors

2009-06-23T16:02:00.000+05:30

Constructors are subject to the following inheritance rules.

Instance Constructors

Each class has an instance constructor called constructor. This name does not comply with the rule of unique component names within a path of an inheritance tree. Consequently, the instance constructors of the individual classes of an inheritance tree are totally independent of each other.

Instance constructors of superclasses cannot be redefined in subclasses.

They cannot be called explicitly using [CALL METHOD] constructor.

This avoids namespace conflicts.

The instance constructor of a class is called when you create an object using the CREATE OBJECT statement. Since a subclass inherits all attributes from its superclasses that are visible to it, and since the content of these attributes can be set by instance constructors of its classes, the instance constructor of a subclass is responsible for ensuring that the instance constructors of all superclasses are called as well. This requires that the instance constructor of each subclass contains a [CALL METHOD] super->constructor call of the instance constructor of the direct superclass even if it is not explicitly declared. Exceptions to this rule are the direct subclasses of the root node object.

In superclasses that do not have an explicitly defined instance constructor, the implicit instance constructor is called. This constructor automatically ensures that the instance constructor of the next higher superclass is called.

When instance constructors are called, all non-optional input parameters of these constructors must be populated, as follows:

Parameter population at CREATE OBJECT

Starting from the class of the created objects, the first explicitly defined instance constructor in the corresponding path of the inheritance tree is taken into account. This is the instance constructor of the class itself or the first explicitly defined instance constructor of a superclass.

Population at [CALL METHOD] super->constructor

Starting from the direct superclass, the first explicitly defined instance constructor in the corresponding path of the inheritance tree is taken into account.

The interface of the first explicitly defined instance constructor is populated as is the case with a normal method - that is,

If no input parameters exist, no parameters are passed.

Optional input parameters can be populated using EXPORTING.

Non-optional input parameters must be populated using EXPORTING.

If there are no explicitly defined instance constructors in the path of the inheritance tree below the root class object, no parameters are passed.

Both at CREATE OBJECT and at [CALL METHOD] super->constructor, the next possible explicit instance constructor must be taken into account. If one exists, its interface must be populated. The same applies to exception handling in instance constructors. Using inheritance requires in-depth knowledge of the entire inheritance tree since when an object of a class is created that resides on a deep level of the tree, parameters may have to be passed to the constructor of a class that resides closer to the root node.

The instance constructor of a subclass is split into two parts by the [CALL METHOD] super->constructor call, which is required from a syntactical point of view. In the statements before the call, the constructor behaves like a static method. This means it cannot access the instance attributes of its class. It is only after the call that instance attributes can be addressed. The statements before the call are used to determine actual parameters for the interface of the instance constructor of a superclass. Only static attributes or local data can be used for this.

When a subclass is instantiated, the system makes a nested call of the instance constructors from the subclass to the superclasses where the instance attributes can only be addressed at the deepest nesting level, that is, in the highest superclass. When the system returns to the constructors of the underlying subclasses, their instance attributes can then also be successively addressed.

The methods of subclasses are not visible in constructors. If an instance constructor calls an instance method of the same class using the implicit self reference me, the method is called as it is implemented in the class of the instance constructor and not as the possibly redefined method of the subclass to be instantiated. This is an exception to the rule that when instance methods are called the implementation is always called in the class to whose instance the reference currently points.

Static Constructors

Each class has a static constructor called class_constructor. As far as the namespace in an inheritance tree is concerned, the static constructor is subject to the same rules as the instance constructor.

The static constructor is called when a subclass is first addressed within a program. However, all preceding static constructors of the entire inheritance tree must have been executed before. Otherwise, a static constructor can only be called once at the runtime of the program. This is why when a subclass is addressed for the first time the system searches the next higher superclass whose static constructor has not yet been called. This static constructor is executed first. Afterwards the constructors of all subsequent subclasses are called successively down to the subclass addressed.

Inheritance and Static Components

2009-06-23T16:01:00.002+05:30

Static components, like all components, exist only once in each inheritance tree, and can be used as of the declaring class:

A subclass can access all non-private static components of its superclasses. The class in which the static component is declared is always the class that is addressed.

From outside, the class component selector can be used to access all visible static components. Each class can be specified in which the component exists (that is, the declaring class and each subclass). Regardless of the class name used in the class component selector, however, the class in which the component is declared is addressed.

The class in which the component is declared is addressed, whether the static component is used internally or externally. This is important for:

Calling the static constructors.

Static constructors are called the first time you address a class. If you address a static component declared in a superclass using the class name of a subclass, only the static constructor of the superclass is called.

Access to the static attributes

A subclass has access to the content of all non-private static attributes of all superclasses. Conversely, a superclass shares its public and protected static attributes with all of its subclasses. When inherited, therefore, static attributes are not assigned to a single class; instead they are assigned to the subtree of the inheritance tree that consists of all subclasses of the defining class. Changes to the values are visible in all involved classes, regardless of the class used to address an attribute.

The registration of event handlers.

If an event handler is declared for a static event of a subclass inherited from a superclass, it can react to this event only if it is triggered by a method of the subclass or one of its subclasses. If the event is triggered in a static method of a superclass, it is not handled, even if the method is called in a subclass or if the name of the subclass is specified.

Example

Calls a static method of a superclass using the name of a subclass. Before the method is executed, the static constructor of the superclass is executed, but not the static constructor of the subclass. The method returns the value set in the superclass.

CLASS c1 DEFINITION.
PUBLIC SECTION.
CLASS-DATA a1 TYPE string.
CLASS-METHODS: class_constructor,
m1 RETURNING value(r1) LIKE a1.
ENDCLASS.

CLASS c1 IMPLEMENTATION.
METHOD class_constructor.
a1 = 'c1'.
ENDMETHOD.
METHOD m1.
r1 = a1.
ENDMETHOD.
ENDCLASS.

CLASS c2 DEFINITION INHERITING FROM c1.
PUBLIC SECTION.
CLASS-METHODS class_constructor.
ENDCLASS.

CLASS c2 IMPLEMENTATION.
METHOD class_constructor.
a1 = 'c2'.
ENDMETHOD.
ENDCLASS.

DATA v1 TYPE string.

START-OF-SELECTION.
v1 = c2=>m1( ).

Example

This example shows how a subclass is used to change a static attribute of a superclass, and how the change is visible in a subclass of a different path in the inheritance tree.

CLASS c1 DEFINITION.
PUBLIC SECTION.
CLASS-DATA a1 TYPE string.
ENDCLASS.

CLASS c11 DEFINITION INHERITING FROM c1.
...
ENDCLASS.

CLASS c12 DEFINITION INHERITING FROM c1.
...
ENDCLASS.

c11=>a1 = 'Hello Sister'.

MESSAGE c12=>a1 TYPE 'I'.

Example

For an example of static events, see Inheritance Events.

Inheritance and the Component Namespace

2009-06-23T16:01:00.001+05:30

A subclass contains all components of all its superclasses. Only the public and the protected components are visible. This is why all public and protected components of an inheritance tree lie within a single namespace and must have unique names. Private components, in contrast, must only be named uniquely within a class.

When methods are redefined, the newly implemented method hides the identically named method of the superclass. As soon as the method is redefined, it replaces the old method to ensure that the name remains unique. The pseudo reference super-> can be used in subclasses to access a method of the direct superclass which is hidden as a result of a redefinition.

Inheritance and Visibility

2009-06-23T16:00:00.001+05:30

You cannot change the visibility area to which a component is assigned using inheritance. Component visibility affects inheritance as follows:

Public Components

The public visibility area of a subclass consists of all its own public components plus the public components of all its superclasses. From outside the class, public components are visible without restrictions.

Protected Components

The protected visibility area of a subclass consists of all its own protected components plus the protected components of all its superclasses. If the OPEN FOR PACKAGE addition is not specified, the protected area is only visible in the class itself and in all its subclasses. If the addition is specified, the protected area is also visible in the current package. If the OPEN FOR PACKAGEaddition is not specified protected seems the same as private from outside. If the addition is specified, within the current package protected has the effect of public and from outside it seems like private.

Private Components

The private visibility area of a subclass includes only the private components of this class. They are visible only in this class. The private components of superclasses cannot be used in subclasses. Only methods inherited from superclasses use (provided they have not been redefined) the private attributes of the superclass (even if the subclass has private attributes with the same name).

Example of Protected Components

Within a subnode in the inheritance tree, you can always access the protected components of superclasses. The classes affected - such as the static types of reference variables - must however be part of the inheritance tree.

In the following example, the reference variables lrefx and lref2 can see the protected components of cx in the context of the subclass c2. The static type of lref1 is c1 and is in another subnode of the inheritance tree. It cannot see any protected components of cx, in the context of c2. In a stricter model (C++ or Java), access in this example would only be possible using lref2. Access using lrefx would not be permitted, since it would involve classes (not subclasses) seeing protected components from outside. At present, ABAP extends the view of lrefx but only in a specific context. We intend, however, to introduce a stricter model and forbid access using lrefx. For this reason, you should not use this option; it causes a warning to be displayed in the extended program check.

CLASS cx DEFINITION.
PROTECTED SECTION.
METHODS mx.
ENDCLASS.

CLASS cx IMPLEMENTATION.
METHOD mx.
...
ENDMETHOD.
ENDCLASS.

CLASS c1 DEFINITION INHERITING FROM cx.
...
ENDCLASS.

CLASS c2 DEFINITION INHERITING FROM cx.
PUBLIC SECTION.
METHODS m2.
ENDCLASS.

CLASS c2 IMPLEMENTATION.
METHOD m2.
DATA: lrefx TYPE REF TO cx,
lref2 TYPE REF TO c2,
lref1 TYPE REF TO c1.
lrefx->mx( ). <--- Warning!!
lref2->mx( ).
lref1->mx( ). <--- Error!!
ENDMETHOD.
ENDCLASS.

Inheritance and Interfaces

2009-06-23T15:59:00.001+05:30

Interfaces are independent constructs in ABAP Objects that support polymorphism of classses. The polymorphism of interfaces is based on the fact that each class implementing an interface can implement the methods of that interface differently. To the outside world, all interface components look similar which is why interface reference variables can point to objects of all classes that implement the associated interface. The interface concept exists independently of and in addition to the inheritance concept.The classes of an inheritance tree can implement any number of interfaces but each interface can be implemented only once in each inheritance tree. This ensures that each interface component comp has a unique name in the entire inheritance tree intf~icomp and that, starting with the class that implements it, it is contained in all subclasses.

Interface reference variables that can point to a class of the inheritance tree can also point to all subclasses. Having been implemented, interface methods are fully functioning components of a class and can be redefined in subclasses.

Inheritance and Polymorphism

2009-06-23T15:58:00.001+05:30

Since a subclass contains all components of all superclasses along the inheritance tree and the interfaces of methods cannot be changed, a reference variable typed with reference to a superclass or to an interface implemented by a superclass may contain references to objects of all subclasses of this superclass. This means that the content of a reference variable typed with reference to a subclass can always be assigned to reference variables typed with reference to one of its superclasses or the interfaces of these superclasses (Up Cast). In particular, the target variable can always be typed with reference to the class object.

A static user can use a reference variable to address the components visible to it, which are contained in the superclass to which the reference variable refers. This means that it cannot address any specializations that have been added to the subclasses. With dynamic accesses, however, all components can be addressed.

When an instance method is redefined in one or more subclasses, different implementations of the method can be executed after a method call using the same reference variable, depending on where the class of the referenced object is located in the inheritance tree. The feature that different classes have the same interface and can therefore be addressed using reference variables of one type is called polymorphism.

Abstract and Final Methods and Classes

2009-06-23T15:57:00.000+05:30

Using the ABSTRACT and FINAL additions of the METHODS and CLASS statements, you can define abstract and final methods or classes.

Abstract methods are declared in abstract classes and cannot be implemented in the same class but only in a subclass of the inheritance tree. Abstract classes can consequently not be instantiated. A non-abstract method is a concrete method. Except for the instance constructor, the concrete instance methods of a class can also call its abstract methods.

Final methods cannot be redefined in subclasses. Final classes cannot have any more subclasses and constitute the final node of an inheritance tree.

Note

In classes that are abstract and final at the same time, only the static components can be used. Instance components can be declared, but these cannot be used. For this reason, it is recommended that you specify both ABSTRACT and FINAL only for static classes.

Redefining Methods

2009-06-23T15:56:00.000+05:30

Each subclass contains the components of all classes that lie between this class and the root node in the inheritance tree. The visibility of a component is always the same and cannot be changed. However, it is possible to redefine the public and protected instance methods of all preceding superclasses using the REDEFINITION addition of the METHODS statement in order to adjust them to the requested specialization. The interface of a redefined method cannot be changed. The method is merely re-implemented under the same name. Constructors cannot be redefined; instead, special rules apply.

The method declaration remains with the superclass, and its previous implementation is also retained there. The implementation of the redefinition is generated additionally with the subclass and obscures the implementation of the superclass. A redefined method works with the private attributes of the subclass and not with possible private superclass attributes of the same name.

Each reference that points to a subclass object uses the redefined method, even if it was typed with reference to a superclass. In particular, this also applies to the self-reference me. For example, if a superclass method m1 contains a call [me->]m2( ) or CALL METHOD [me->]m2 and if m2 is redefined in a subclass, the call of m1 in an instance of the superclass causes the original method m2 to be executed and the call of m1 in an instance of the subclass causes the redefined method m2 to be executed.

Within a redefined method the pseudo reference super-> can be used to access the obscured method, for example, to adopt and supplement its functions.

Inheritance

2009-06-23T15:55:00.000+05:30

The concept of inheritance allows you to derive new classes from existing classes. To do this, you use the INHERITING FROM addition of the CLASS ... DEFINITION statement. The new class adopts or inherits all components of the existing class. The new class is called subclass, and the existing class is called superclass.

If you make no further declarations, a subclass contains exactly the components of the superclass. However, only the components of the public, protected, and package visibility sectionof the superclass are visible in the subclass. Although the private components of the superclass are also contained in the subclass, they are not visible. In a subclass, you can declare private components with the same name as the corresponding components of the superclass. Each class works with its private components. As long as a method inherited from the superclass is not redefined, it uses the private attributes of the superclass and not the possible subclass attributes of the same name.

If the superclass does not have a private visibility section, the subclass is an exact copy of the superclass. You can, however, add further components to the subclass. These components are used to specialize the subclass in relation to the superclass. If a subclass is then used as the superclass for a new class, you can then define a further level of specialization.

Each class can have several direct subclasses, but only one direct superclass. ABAP Objects applies the principle of single inheritance. If subclasses inherit from superclasses that are subclasses themselves, all classes involved represent an inheritance tree whose specialization increases the more deeper hierarchy levels are added. Specialization decreases the closer a level is located to the root node of the inheritance tree. The root node of all inheritance trees in ABAP Objects is the predefined empty class object. This class is the most generic class because it does not contain attributes or methods. When you define a new class, you must not explicitly specify this class as a superclass because it always exists implicitly. In the inheritance tree, two neighboring nodes are known as the direct superclass and subclass, while all preceding and succeeding nodes are collectively referred to as superclasses and subclasses. The declaration of the components of a subclass is distributed among all superclasses of the inheritance tree.

Definition of Classes and Interfaces

2009-06-23T15:53:00.000+05:30

In ABAP Objects, you can define classes and interfaces either globally or locally. You define global classes and interfaces with the Class Builder tool in the ABAP Workbench; they are then stored centrally in the class library in the repository. All ABAP programs in an AS ABAP can access these global classes and interfaces. Conversely, you can only use local classes and interfaces in the program that defines them. When an ABAP program uses a class, the system searches first for a local class, then for a global class of the same name. Otherwise, there is no difference in the use of local and global classes or interfaces.

Since local classes are only used by one program, it is generally sufficient to define the public interface - that is, the outwardly visible components appropriate for this program. Conversely, each global class is available throughout the system, which means that its public interface can only be typed with reference to data types that are themselves visible throughout the system.

The following sections describe classes and interfaces using the syntax for the definition of local classes and interfaces in an ABAP program. For the definition of global classes and interfaces, all language elements have a counterpart in the operating elements of the Class Builder. For more information, see the documentation for the Class Builder.

Defining Local Classes

Local classes consist of ABAP source code enclosed between the CLASS - ENDCLASS statements. A complete class definition consists of a declaration part and, if necessary, an implementation part.

The declaration part of a class class consists of one statement block:

CLASS class DEFINITION.
...
ENDCLASS.

This declaration part contains the declaration of the components (attributes, methods, events) of a class. All the components of a class must be assigned explicitly to a visibility section (PUBLIC SECTION, PROTECTED SECTION, PRIVATE SECTION), which defines from where each component can be accessed. In global classes, the declaration part belongs to the global data declarations and should be at the start of the program.

If methods are declared in the declaration part of a class, the class needs an implementation part, which consists of one statement block:

CLASS class IMPLEMENTATION.
...
ENDCLASS.

The implementation part of a class contains the implementation of all the methods of this class. Methods are procedures - that is, processing blocks of an ABAP program. The position of the implementation part in the source code is thus unimportant. For clarity, however, you should either put all the implementation parts of local classes at the end (as in subroutines), or directly after the relevant definition part. If you do the latter, note that you must then assign subsequent non-declarative statements explicitly to a processing block, such as START-OF-SELECTION, so that they can be accessed.

Defining Local Interfaces

You define the local interface intf using the

INTERFACE intf. and
...
ENDINTERFACE. statements.

The definition contains all the components (attributes, methods, events) of the interface. In interfaces, you can define the same components as in classes. You cannot assign the components of a interface explicitly to a visibility section, because interface components always extend the public area of the class. There is no implementation part for interfaces, since the methods of an interface must be implemented in the same class that implements the interface.

Object Orientation

2009-06-23T15:52:00.000+05:30

Object orientation (or, more correctly, object-oriented programming) is a problem-solving method that represents the real world in a series of software object.

Object-oriented programming is based on a progamming model in which data and functions are united in objects. The remaining language scope of ABAP mainly supports procedural programming, where the data is stored at other places than the objects and where programs that are modularized by procedures access this data.

This document defines a few general terms that are widely used in object orientation and in ABAP Objects.

Objects

Objects represent abstract or concrete objects of the real world. An object is a section of program code that has data (called attributes) and provides services called methods (sometimes also known as operations or functions). Methods typically work with private data in the object (attributes, also known as the object state), that are only visible within the object. This guarantees the internal consistency of the object, since the data is only changed by the methods, not by the user. This ensures that the object is consistent in itself.

Classes

Classes are program code that describes objects. Technically, an object is an instance of a class. In theory, you can create an infinite number of objects from a single class definition. Each instance of a class (object) has its own values for its attributes.

Object References

In a program, you identify and address objects using a unique object reference. They allow you to access the attributes and methods of an object.

In object-oriented programming, objects usually have the following characteristics:

Encapsulation

Objects restrict the external visibility of their resources (attributes and methods). Each object hat an interface that determines how other objects or applications can use it. The implementation of the object is encapsulated (not visible outside the class).

Polymorphism

Methods with the same name can behave differently in different classes. In object-oriented programming, you can use interfaces to address methods with the same name in different objects. The form of address always remains the same, but the actual method implementation is class-specific, and can be different in each class.

Inheritance

You can derive a class from another class. A derived class (subclass) inherits the data and methods of its superclass. You can add new methods to a subclass, or redefine existing methods. Redefined methods have the same name and interface as the original method. Their classes are therefore polymorphous, too.

Uses of Object Orientation

Object-orientation has the following advantages:

Complex software systems become easier to understand, since an object-oriented architecture resembles reality more closely than other programming techniques.

Changes in object-oriented systems should be possible locally (at class level), without further changes being necessary in other parts of the system. This reduces the amount of maintenance required.

Polymorphism and inheritance enable many individual components to be reused.

Object-oriented systems require less adjustment and maintenance, because the majority of problems can be discovered and corrected in the design and development phases.

Achieving these goals requires:

Object-oriented Programming Languages

Object-oriented programming techniques do not necessarily require object-oriented programming languages. However, they do depend on the implementation of object-oriented constructions in the system kernel.

Object-oriented Tools

Object-oriented tools help you create object-oriented programs in object-oriented languages. They allow you to store and visualize your program objects and the relationship between them.

Object-oriented Modeling

Object-oriented modeling of a software system is the most important, most time consuming, and most difficult task required to achieve the above goals. Object-oriented design encompasses more than just object-oriented programming, and offers logical advantages that are independent of the eventual implementation.

CLASS-METHODS - FOR EVENT

2009-06-23T15:51:00.002+05:30

Syntax

CLASS-METHODS meth
FOR EVENT evt OF {class|intf}
[IMPORTING p1 p2 ...[sender]].

Effect

This statement declares the static method meth as the event handler for the event evt of the class class or the interface intf. The syntax and meaning of the additions are identical to the declaration of instance methods as event handlers.

Static event handlers can be called by the event evt independently of an instance of the class.

Example

In the class dialog_box, a static event handler close_box is defined for the event that is triggered when the user chooses to close a Control Framework (CFW) dialog box.

CLASS dialog_box DEFINITION.
PUBLIC SECTION.
METHODS constructor.
...
PRIVATE SECTION.
CLASS-DATA open_boxes TYPE i.
CLASS-METHODS close_box
FOR EVENT close OF cl_gui_dialogbox_container
IMPORTING sender.
...
ENDCLASS.

CLASS dialog_box IMPLEMENTATION.
METHOD constructor.
... " create a dialogbox
open_boxes = open_boxes + 1.
ENDMETHOD.
METHOD close_box
... " close the dialogbox referred by sender
open_boxes = open_boxes - 1.
ENDMETHOD.
ENDCLASS.

CLASS-METHODS - class_constructor

2009-06-23T15:51:00.001+05:30

Syntax

CLASS-METHODS class_constructor.

Effect

This statement declares the static constructor class_constructor of the class. It can only be used in the public visibility section of the declaration section of a class.

Each class has a predefined method class_constructor in its public visibility section. Its functions can be implemented class-specifically by explicit declaration. Without explicit declaration, the static constructor is empty.

The static constructor is automatically called exactly once per class and internal session before the class is first accessed. An access to the class is the creation of an instance of the class or the addressing of a static component using the class component selector.

When a subclass is first accessed, the inheritance tree is searched for the next-highest superclass whose static constructor was not yet called. Then the static constructor of this superclass is executed followed by those of all subsequent subclasses up to the subclass in question. The static constructor must be fully executed, otherwise a runtime error occurs.

Like all static methods, the static constructor can only access the static components of its class. Furthermore, the static constructor cannot explicitly address its own class.

Notes

Like instance constructors, static constructors are also an exception to the rule that all public components along a path in the inheritance tree are in one namespace.
The execution time of the static constructor is not fixed. Only its call before the first access to the class is guaranteed. It can therefore happen that static methods are executed before the static constructor is ended.
The execution sequence of static constructors is dependent on the program flow. Statc constructors must be implemented so that they can be executed in any sequence.
In static constructors, you cannot declare class-based exceptions using RAISING, since it is generally not specified whether the user of a class is the first user and whether or not he must handle exceptions propagated by the static constructor.
If a statc component of a superclass is addressed using the name of a subclass, then the superclass is addressed and its static constructor is executed, but not the static constructor of the subclass.

Example

When a class is first accessed, the static constructor of this class uses the system field sy-repid to set the static attribute access_program<> for the name of the program of an internal session that uses the class first.

CLASS some_class DEFINITION.
PUBLIC SECTION.
CLASS-METHODS class_constructor.
PRIVATE SECTION.
CLASS-DATA access_program TYPE sy-repid.
ENDCLASS.

CLASS some_class IMPLEMENTATION.
METHOD class_constructor.
access_program = sy-repid.
ENDMETHOD.
ENDCLASS.

CLASS-METHODS - RETURNING

2009-06-23T15:50:00.001+05:30

Syntax

CLASS-METHODS meth
[IMPORTING parameters] [PREFERRED PARAMETER p]]
RETURNING VALUE(r) typing
[{RAISING exc1|RESUMABLE(exc1) exc2|RESUMBALE(exc2) ...}
|{EXCEPTIONS exc1 exc2 ...}].

Effect

Declares a functional static method meth. The additions have exactly the same syntax and meaning as those for functional instance methods.

Example

The class circle contains two functional static methods, circumference and area, which work with the constant pi.

CLASS circle DEFINITION.
PUBLIC SECTION.
CONSTANTS pi TYPE decfloat34
VALUE '3.141592653589793238462643383279503'.
CLASS-METHODS: circumference IMPORTING r TYPE decfloat34
RETURNING value(c) TYPE decfloat34,
area IMPORTING r TYPE decfloat34
RETURNING value(a) TYPE decfloat34.
ENDCLASS.

CLASS circle IMPLEMENTATION.
METHOD circumference.
c = 2 * pi * r.
ENDMETHOD.
METHOD area.
a = pi * r ** 2.
ENDMETHOD.
ENDCLASS.

DATA: circ TYPE decfloat34,
area TYPE decfloat34,
radius TYPE decfloat34.

START-OF-SELECTION.

radius = '1.00'.
circ = circle=>circumference( radius ).
area = circle=>area( radius ).

METHODS - IMPORTING, EXPORTING, CHANGING, RAISING

2009-06-23T15:49:00.000+05:30

Syntax

METHODS meth [ABSTRACT|FINAL]
[IMPORTING parameters [PREFERRED PARAMETER p]]
[EXPORTING parameters]
[CHANGING parameters]
[{RAISING exc1|RESUMABLE(exc1) exc2|RESUMABLE(exc2) ...}
|{EXCEPTIONS exc1 exc2 ...}].

Extras:

1. ... IMPORTING parameters [PREFERRED PARAMETER p]

2. ... EXPORTING parameters

3. ... CHANGING parameters

4. ... RAISING exc1|RESUMABLE(exc1) exc2|RESUMABLE(exc2) ...

5. ... EXCEPTIONS exc1 exc2 ...

6. ... ABSTRACT ...

7. ... FINAL ...

Effect

This statement declares a general instance method meth. Use additions ABSTRACT and FINAL to make the method abstract or final.

The additions IMPORTING, EXPORTING and CHANGING define the parameter interface of the method. After every addition, the corresponding formal parameters are defined by a specification of the list parameters. The order of the additions is stipulated.

The other additions determine which exceptions the method can propagate or trigger and determine whether the method is abstract or final.

Note

Within a method, you can use the logical expression IS SUPPLIED to check whether an actual parameter was assigned to an optional formal parameter at the call.

Addition 1

... IMPORTING parameters [PREFERRED PARAMETER p]

Effect

IMPORTING defines input parameters. When calling the method, you need not specify an appropriate actual parameter for every non-optional input parameter. During the call, the content of the actual parameter is passed to the input parameter. The content of the input parameter - for which the reference transfer is defined - cannot be changed in the method.

Use PREFERRED PARAMETER to identify an input parameter p1 p2 ... of list parameters after IMPORTING as a preferred parameter. This specification makes sense only if all input parameters are optional. When calling the method with the syntax

[CALL METHOD] meth( a ).

the actual parameter a is assigned to the preferred parameter

functional method at an operand position.

Addition 2

... EXPORTING parameters

Effect

EXPORTING defines output parameters. When calling the method, you can specify an appropriate actual parameter for every output parameter. The content of the output parameter - which is defined for value transfer - is passed to the actual parameter at the call after the method has been completed successfully.

Note

An output parameter that is defined for the reference transfer, behaves like an input/output parameter, which means that it is not initialized when the method is called. For this reason, it should not be read before the first write access. Beware also if content is added to such parameters, for example, when inserting rows in internal tables.

Addition 3

... CHANGING parameters

Effect

CHANGING defines input/output parameters. When calling the method, you must specify an appropriate actual parameter for every non-optional input/output parameter. The content of the actual parameter is passed to the input/output parameter at the call, and after the method has been completed, the content of the input/output parameter is passed to the actual parameter.

Example

The method read_spfli_into_table of this example has an input and an output parameter, which are typed fully by reference to the ABAP Dictionary.

CLASS flights DEFINITION.
PUBLIC SECTION.
METHODS read_spfli_into_table
IMPORTING VALUE(id) TYPE spfli-carrid
EXPORTING flight_tab TYPE spfli_tab.
...
ENDCLASS.

Addition 4

... RAISING exc1|RESUMABLE(exc1) exc2|RESUMABLE(exc2) ...

Effect

Use addition RAISING to declare the class-based exceptions exc1 exc2 ... that can be propagated from the method to the caller.

For exc1 exc2 ..., you can specify all exception classes that are visible at this position and are subclasses of CX_STATIC_CHECK or CX_DYNAMIC_CHECK. You must specify the exception classes in ascending order corresponding to their inheritance hierarchy. Each exception class may only be specified once.

With addition RESUMABLE, an exception is declared in such a way that it can be propagated as a resumable exception.

Thus:

A resumable exception is propagated as such.
The addition does not have any effect on a non-resumable exception.
If a resumable exception is propagated with RAISING without addition RESUMABLE, it thus becomes non-resumable.

If a class is declared as resumable, all of the subclasses listed need resumable too.

Exceptions of the categories CX_STATIC_CHECK and CX_DYNAMIC_CHECK must be declared explicitly, otherwise a propagation results in a violation of the interface. An interface violation results in a treatable exception CX_SY_NO_HANDLER. Exceptions of category CX_NO_CHECK are always declared implicitly and with addition RESUMABLE..

Notes

The declaration of exceptions of category CX_STATIC_CHECK is checked statically at the syntax check. For exceptions of category CX_DYNAMIC_CHECK, the check is executed at runtime.
In a method in which class-based exceptions are declared with the addition RAISING, you cannot use the statement CATCH SYSTEM-EXCEPTIONS. Instead, handle the relevant treatable exceptions in a TRY control structure.
An exception that is triggered as resumable in the method with RAISE RESUMABLE EXCEPTION, should also be declared as resumable in the interface, as the exception would otherwise lose this property when you leave the method.

Example

In class math, you can propagate all exceptions represented by class CX_SY_ARITHMETIC_ERROR and its subclasses from within method divide_1_by. If, for example, the input parameter operand is filled at the call with the value 0, then the exception CX_SY_ZERODIVIDE is triggered, propagated, and can, as shown in the example, be handled by the caller in a TRY control structure.

CLASS math DEFINITION.
PUBLIC SECTION.
METHODS divide_1_by
IMPORTING operand TYPE I
EXPORTING result TYPE decfloat34
RAISING cx_sy_arithmetic_error.
ENDCLASS.

CLASS math IMPLEMENTATION.
METHOD divide_1_by.
result = 1 / operand.
ENDMETHOD.
ENDCLASS.

START-OF-SELECTION.

DATA oref TYPE REF TO math.
DATA exc TYPE REF TO cx_sy_arithmetic_error.
DATA res TYPE decfloat34.
DATA text TYPE string.

CREATE OBJECT oref.
TRY.
oref->divide_1_by( EXPORTING operand = 4
IMPORTING result = res ).
text = res.
CATCH cx_sy_arithmetic_error INTO exc.
text = exc->get_text( ).
ENDTRY.
MESSAGE text TYPE 'I'.

Addition 5

... EXCEPTIONS exc1 exc2 ...

Effect

Use addition EXCEPTIONS to define a list of non-class-based exceptions exc1 exc2..., which can be triggered with the statements RAISE or MESSAGE RAISING in the method. You specify identifiers exc1 exc2 ... for the exceptions to be defined at will and directly. Exceptions defined in this way are bound to the method - similar to formal parameters - and cannot be propagated.

If such an exception is triggered in a method and no return value has been assigned to it in the addition EXCEPTIONS of the CALL METHOD statement in the method call, then a runtime error occurs.

You cannot use the additions RAISING and EXCEPTIONS simultaneously. Furthermore, you are not allowed to use the statement RAISE EXCEPTION to raise a class-based exception in a method in whose interface non class-based exceptions are defined.

Note

For new developments, we recommend to use class-based exceptions, which are independent of the respective method.

Example

In the class math, for method divide_1_by an exception arith_error is defined, which is triggered in the method with the RAISE statement if an arithmetic error occurs. If, for example, the input parameter operand is filled with value 0 at the call, the exception arith_error is triggered in the method-internal handling of exception CX_SY_ZERODIVIDE and handled after the call of the method by evaluating sy-subrc.

CLASS math DEFINITION.
PUBLIC SECTION.
METHODS divide_1_by
IMPORTING operand TYPE I
EXPORTING result TYPE decfloat34
EXCEPTIONS arith_error.
ENDCLASS.

CLASS math IMPLEMENTATION.
METHOD divide_1_by.
TRY.
result = 1 / operand.
CATCH cx_sy_arithmetic_error.
RAISE arith_error.
ENDTRY.
ENDMETHOD.
ENDCLASS.

START-OF-SELECTION.

DATA res TYPE decfloat34.
DATA oref TYPE REF TO math.

CREATE OBJECT oref.
oref->divide_1_by( EXPORTING operand = 4
IMPORTING result = res
EXCEPTIONS arith_error = 4 ).

IF sy-subrc = 0.
WRITE res.
ELSE.
WRITE 'Arithmetic error!'.
ENDIF.

Addition 6

... ABSTRACT ...

Effect

Use addition ABSTRACT to define an abstract method meth. Addition ABSTRACT is allowed only in abstract classes, not in interfaces. An abstract method is not implemented in the implementation section of its class. To implement an abstract method, you must redefine it in a non-abstract subclass using addition REDEFINITION.

Notes

Abstract methods can be defined in classes that are either abstract or final, but they can never be implemented and therefore are not usable.
Methods in interfaces are implicitly abstract, because interfaces do not contain method implementations.
With the exception of instance constructors, the concrete instance methods of a class can also call their abstract methods.

Addition 7

... FINAL ...

Effect

Addition FINAL is allowed only in classes, not in interfaces. Use addition FINAL to define a final method meth. A final method cannot be redefined in a subclass. In final classes, all methods are automatically final; the addition FINAL is not allowed.

CLASS-METHODS - IMPORTING, EXPORTING, CHANGING, RAISING

2009-06-23T15:48:00.001+05:30

Syntax

CLASS-METHODS meth
[IMPORTING parameters [PREFERRED PARAMETER p]]
[EXPORTING parameters]
[CHANGING parameters]
[{RAISING exc1|RESUMBALE(exc1) exc2|RESUMBALE(exc2) ...}
|{EXCEPTIONS exc1 exc2 ...}].

Effect

Declares a general static method meth. The additions define the parameter interface for the method and specify the exceptions that the method can raise and propagate. The additions have the same syntax and meaning as those for general instance methods.

Note

You cannot redefine static methods. This means that you cannot define them as abstract or final.

Static methods are always executed in the class in which they were declared, even if they were called in subclasses or using the names of subclasses.

CLASS-METHODS

2009-06-23T15:47:00.001+05:30

Syntax Forms

General Static Methods

1. CLASS-METHODS meth
[IMPORTING parameters [PREFERRED PARAMETER p]]
[EXPORTING parameters]
[CHANGING parameters]
[{RAISING exc1|RESUMBALE(exc1) exc2|RESUMBALE(exc2) ...}
|{EXCEPTIONS exc1 exc2 ...}].

Functional Static Methods

2. CLASS-METHODS meth
[IMPORTING parameters [PREFERRED PARAMETER p]]
RETURNING VALUE(r) typing
[{RAISING exc1|RESUMBALE(exc1) exc2|RESUMBALE(exc2) ...}
|{EXCEPTIONS exc1 exc2 ...}].

Static Constructors

3. CLASS-METHODS class_constructor.

Event Handlers

4. CLASS-METHODS meth
FOR EVENT evt OF {class|intf}
[IMPORTING p1 p2 ... [sender]].

Effect

The CLASS-METHODS statement declares a static method meth. The naming conventions apply for the name meth.

With the class component selector (=>), static methods can be used independently of objects. In static methods, you can only access the static components of the class or its superclasses if you do not use the component selector.

Using the variants of the CLASS-METHODS statement, different types of method declaration are possible :

General Static Methods
The most general form of the CLASS-METHODS statement allows you to define static methods with any number of input and output parameters.
Functional Static Methods
Functional methods can have any number of input parameters and exactly one return value as the output parameter.
Static Constructors
Static constructors are methods with the predefined name class_constructor, which are automatically called before their class is first used. Static constructors have no parameter interface.
Static Event Handlers
Static event handlers are static methods, that are called by an event of a class or an interface. The only possible formal parameters of an event handler are input parameters that were defined as output parameters of the event.

Note

Like all static components in the inheritance, the static methods of a superclass exist in all subclasses. A static method is always executed in the class in which it was declared. A static method which is visible from outside can be called using the class component selector, as can all names and classes in which it exists. The class in which it was declared is always the one that is addressed. This has an influence on the execution of the static constructor or on the event handlers.

Kernel Methods

2009-06-23T15:46:00.000+05:30

For internal use, kernel methods can be implemented in the kernel instead of in ABAP.

Introduction

Kernel methods allow you to directly call kernel functions implemented in C or C++. Kernel methods replace the previous concepts of C-Calls and System-Calls. After Release 6.20, no new C-Calls or System-Calls should be introduced.

Kernel methods offer the same checks and securities as normal ABAP methods. Except for the Constructors and the C Destructor, all ABAP methods can be implemented as kernel methods. An ABAP method can still be redefined as a kernel method and a kernel method can still be redefined as an ABAP method within a path of the inheritance hierarchy.

For the C developer, who wants to implement a kernel method, an API is available that allows simple, high-performing, and secure access to arguments. Class-based exceptions also continue to be supported.

Defining Kernel Methods

Declaration in ABAP

A kernel method is declared like a normal ABAP method, in the Class Builder or in the declaration section of a local class. It is completely irrelevant for the declaration that a method is declared as a kernel method. In ABAP, a kernel method can therefore be used just as a normal ABAP method.

Implementation in ABAP

You define a method as a kernel method by using the optional addition KERNEL MODULE kmod1 kmod2 ... to the METHOD statement in the implementation section of the class. kmod1, kmod2, ... are the names of the kernel modules that implement the method. The ABAP implementation of a kernel method must be empty, that is there cannot be any ABAP statements between METHOD and ENDMETHOD:

METHOD meth BY Kernel MODULE kmod1 kmod2 ...
ENDMETHOD.

Constructors and the C Destructor cannot be implemented as kernel methods. There is a separate mechanism for the C destructor.

After kernel MODULE, you can specify a list of kernel kmod1, kmod2, ... You can currently only specify C functions of the kernel for kmod1, kmod2, ... The list after kernel MODULEis evaluated by the compiler from left to right. The first kernel module in the list that is registered in the kernel (see below) is used in the generation,

If no valid kernel module is found in the list, a syntax error occurs. There are still two standard C functions that can appear at the end of the list: FAIL and IGNORE. If one of these functions is specified at the end of the list, a syntax error does not occur if the previous list does not contain a valid module. With IGNORE the call of such a kernel method is ignored (behavior as with empty ABAP implementation) and in the case of FAIL the exception that can be handled of the class CX_SY_DYN_CALL_ILLEGAL_METHOD is raised.

Examples

METHOD meth BY Kernel MODULE xx_impl_630 xx_impl_620 xx_impl_610.

First the system searches in the kernel for xx_impl_630, then for xx_impl_620, and then for xx_impl_610. If none of the functions are found, a syntax error occurs.

METHOD meth BY Kernel MODULE xx_impl_630 xx_impl_620 FAIL.

First the system searches in the kernel for xx_impl_630. Lastly, the system searches for xx_impl_620. If none of the functions are found, no syntax error occurs and when the method is called, the exception that can be handled of the class CX_SY_DYN_CALL_ILLEGAL_METHOD is raised.

METHOD meth BY Kernel MODULE xx_impl_620 xx_impl_610 IGNORE.

First the system searches in the kernel for xx_impl_620. Lastly, the system searches for xx_impl_610. If none of the functions are found, no syntax error occurs and when the method is called, the empty ABAP implementation is called.

Implementation in the kernel

Currently, only C functions can be used as kernel modules of kernel methods. The C functions can have any position in the kernel. No special includes of the ABAP runtime environmentare required for implementing the C function. The C functions must have a specific interface. The interface itself is wrapped by the macro ARGUMENTS All necessary definitions and prototypes are in the include //src/include/abkmeth.h. This is the only include needed for defining C functions for kernel methods.

Since C functions can be defined in C and C++ , you must use externC in C++:

#include "abkmeth.h"
...
externC void name_of_cmodule( ARGUMENTS )
{
...
}

A C function that implements a kernel method must be registered for the kernel method. If, after METHOD meth BY Kernel MODULE, you specify the name of a C function that was not registered for the kernel method a syntax error occurs (as mentioned above). You can register several C functions for a kernel method. The sequence of the kernel modules kmod1, kmod2, ... specified in the list after METHOD meth BY Kernel MODULE defines which of the registered C functions is used. This allows downward-compatible further development of kernel methods.

So that changes to the registration become active, you must recompile the destination lib of the project krn/runt and relink the kernel.

Registration

C functions are registered in the signature file //src/krn/runt/abkmeth.sig using the following syntax for kernel methods (all ABAP IDs must be specified in capital letters):

KERNEL_METHOD("CLASS","METH", cfunc,argcnt)

This definition registers the C function cfunc for the kernel method meth of a global class class. The C function expects a number of argcnt arguments.

Kernel methods of local classes in class pools or other ABAP programs are registered using the following macros:

KERNEL_METHOD_CLASS_LOCAL("GCLASS","CLASS","METH",cmodule,argcnt)

KERNEL_METHOD_PROGRAM_LOCAL("PROG","CLASS","METH",cmodule,argcnt)

The technique is the same as with Kernel_METHOD, except that you must specify the global class gclass for local classes is class pools and the program prog for program-local classes.

Registering Arguments

All ABAP data objects (such as parameters, attributes, or global data) that are to be accessed in C functions for kernel methods, are treated as arguments of the C function.

The argument list of a C function for a kernel method is not limited to the interface parameters of the ABAP method and does not have to contain these completely. Before you access arguments within C functions for kernel methods, these arguments must be registered.

The argcnt arguments must be registered immediately after the C functions are registered using KERNEL_METHOD. A single argument is defined (registered) using one of the following macros:

ARGUMENT_basetype(index,"name",type_kind,"type",read_write)

ARGUMENT_[C|N|X](index,"name",type_kind,"type",read_write,length)

ARGUMENT_P(index,"name",type_kind,"type",read_write,length,decimals)

ARGUMENT_STRUCT(index,"name",type_kind,"type",read_write,ctype)

With these macros an argument is defined with the name name and an index index.

With basetype you must assign the type of the ABAP data object according to the following table. If the basetype is C, N, X, P, or STRUCT, you must specify more parameters than for other types.

basetype	ABAP data type	Type in C
C	c with length specification	SAP_CHAR (*) [Length]
C_GENERIC	c without length specification	SAP_CHAR*
X	x with length specification	SAP_RAW (*) [Length]
X_GENERIC	x without length specification	SAP_RAW*
N	n with length specification	SAP_CHAR (*) [Length]
N_GENERIC	n without length specification	SAP_CHAR*
P	p with length and decimal specification	SAP_BCD (*) [Length]
P_GENERIC	p without length and decimal specification	SAP_BCD*
D	d	SAP_DATE*
T	t	SAP_TIME*
I	i	SAP_INT*
F	f	SAP_DOUBLE*
STRING	string	StrRef*
XSTRING	xstring	StrRef*
INT2	s	SAP_SHORT*
INT1	b	SAP_INT1*
TABLE	All table types	TABH_REF*
OBJ_REF	All object references	ObjRef*
DATA_REF	All data references	FldRef*
STRUCT	All structure types	Registered type ctype*
ANY	any	void*
DATA	data	void*
SIMPLE	simple	void*
CSEQUENCE	csequence	void*
XSEQUENCE	xsequence	void*
NUMERIC	numeric	void*
CLIKE	clike	SAP_CHAR*
C_POINTER	%_c_pointer	void**

The following applies for the macro parameters:

name is the ID for any ABAP data object in uppercase letters that could also be used in an ABAP implementation of the kernel method. In particular, the ID can contain links with component selectors, for example me->ATTR or struc-comp.

index is a continuous number from 1 to argcnt. The arguments are accessed using this index.

For type_kind you can specify either TYPE or TYPE_REF_TO.

type is the ID (in upper-case) for any data type in ABAP that could also be used in an ABAP implementation of the kernel method. type_kind and type are used to check the interface of the kernel method in ABAP.

For read_write you can specify either READ or WRITE. This defines whether you can read or write access the argument and is evaluated in the access macros.

For ARGUMENT_[C|N|X|P] you use length to specify the length of all ABAP data types with generic length (for c and n in characters, for x and p in bytes).

For ARGUMENT_P you use decimals to specify the number of decimal places.

For ARGUMENT_STRUCT you use ctype to specify a suitable C type. This type should be generated from an ABAP type definition using saphfile.

Accessing Arguments

After registering the arguments, you can use the following macros to access them within the C function. With exception of the direct access to the data control block, the access macros do not require any includes of the ABAP runtime environment.

ARGUMENT_basetype_READ(index,"name");

This macro returns the read address of an argument with the type const ctype, where ctype is defined by basetype according to the above table. The index and name of the argument must be passed. For the generic types you must specify additional parameters (see below). You only need the index to access the argument. However, to make the C function more legible and ensure that additional consistency checks can be executed, you must also specify the name. If the kernel is compiled in debugging mode, the system executes a consistency check between index and name; the specified C type and ABAP type of the argument are also checked. In the case of an error, a corresponding ABAP runtime error is triggered (KMETH_INVALID_ARGUMENT_ID, KMETH_INVALID_ARGUMENT_NAME, or KMETH_INVALID_CTYPE_LENG). No checks are executed in the optimized kernel.

ARGUMENT_basetype_WRITE(index,"name");

This macro has the same semantics as ARGUMENT_basetype_READ. However, the system returns the write address. The system also checks whether the argument was defined as a write argument. If you try to write access a write-protected argument (for example, a constant), this triggers the ABAP runtime error KMETH_ARGUMENT_READ_ONLY.

ARGUMENT_[C|N]_READ(index,"name",lengthU);
ARGUMENT_[C|N]_WRITE(index,"name",lengthU);
ARGUMENT_X_READ(index,"name",lengthR);
ARGUMENT_X_WRITE(index,"name",lengthR);

With these macros you must specify the expected length in bytes lengthR or in characters lengthU for the generic types c, x, and n

ARGUMENT_P_READ(index,"name",lengthR,decimals);
ARGUMENT_P_WRITE(index,"name",lengthR,decimals);

With these macros you must specify the expected length in bytes (lengthR) and the number of decimal places (decimals) for the generic type p.

ARGUMENT_[C_GENERIC|N_GENERIC|CLIKE]_READ(index,"name",size_tU);
ARGUMENT_[C_GENERIC|N_GENERIC|CLIKE]_WRITE(index,"name",size_tU);
ARGUMENT_X_GENRIC_READ(index,"name",size_tR);
ARGUMENT_X_GENERIC_WRITE(index,"name",size_tR);

With these macros you must specify a variable of the type size_tU or size_tR, containing the length in bytes or characters, for the types C_GENERIC, X_GENERIC, N_GENERIC, and CLIKE.

ARGUMENT_P_GENERIC_READ(index,"name",size_tR,decimals);
ARGUMENT_P_GENERIC_WRITE(index,"name",size_tR,decimals);

With these macros you must specify a variable decimals (for the decimal places) as well as the length size_tR for the type P_GENERIC.

ARGUMENT_STRUCT_READ(index,"name",ctype);
ARGUMENT_STRUCT_WRITE(index,"name",ctype);

With these macros you must specify a suitable C typectype for all structured types STRUCT.

ARGUMENT_C_POINTER(index,"name");

This macro is available specifically for the type %_c_pointer. This type is a special internal ABAP type that has exactly the byte length of a C pointer (4, 8, or 16 bytes, depending on platform). The type is always mapped to the predefined ABAP type x. The macros for the type X or X_GENERIC are not used due to the variable length and platform-dependency.

ARGUMENT_IS_SUPPLIED(index,"name");

This macro has the same semantics as the logical expression IS SUPPLIED in ABAP. The same consistency checks are executed as for ARGUMENT_READ.

ARGUMENT_DATA(index,"name",ctype);

This macro returns the data control block with the C type const DATA *. The same consistency checks are executed as for ARGUMENT_READ. The macro is only active if the include //src/include/abdata.h of the ABAP runtime environment was included.

Raising Exceptions

C functions that implement kernel method can raise class-based exceptions.

Registering Exceptions

The relevant global exception classes must be registered with an extension of //src/include/abexcpc.h. Local exception classes cannot be registered.

In //src/include/abexcpc.h, theexception class is declared and any text IDs are defined:

//src/include/abexcpc.h
...
CX_ABSTR (CX_..., "CX_...")
CX_TXTID (CX_..._bar, CX_..., "BAR") /* special text for class */
...

Classes can also be declared with their standard text only:

//src/include/abexcpc.h
...
CX_CLASS (CX_..., "CX_...") /* class with standard text */
...

The exact documentation is in the file //src/include/abexcpc.h.

You must extend the file //src/include/abexcpa.hso that any attributes of an exception class in a C function can be populated; you must specify the name, internal type (according to //src/include/abtypes.h), and the byte length:

//src/include/abexcpa.h
...
CX_ATTR (CX_..._attr1, CX_..., "ATTR1", TYPCSTRING, sizeofR(StrRef))
CX_ATTR (CX_..._attr2, CX_..., "ATTR2", TYPC, LEN_UC2RAW(30))
...

Finally, you must register exceptions as well as arguments in the file //src/krn/runt/abkmeth.sig. This is not forced but, during the syntax check, only registered exceptions are checked for their existence:

//src/krn/runt/abkmeth.sig
...
EXCEPTION(CX_...)
...

Raising Exceptions

A C function can raise an exception by calling the following macros consecutively:

EXCEPTION_CREATE(CX_..._bar);
EXCEPTION_SET_CSTRING(CX_..._attr1, value, valueLength);
EXCEPTION_SET_C (CX_..._attr2, value, valueLength);
EXCEPTION_RAISE();

Within the macros EXCEPTION_CREATE or EXCEPTION_RAISE, a long jump to Extri always takes place, that is the C function that implements the kernel method is exited in a long jump and the ABAP runtime environment takes control. Therefore, the C function should release its temporary memory before raising an exception. If the exception is caught in ABAP using CATCH without the INTO addition, the long jump takes place in EXCEPTION_CREATE. If the exception is caught with the INTO addition (the exception object is used) or not at all, the long jump takes place in EXCEPTION_RAISE.

The exceptions are processed in the runtime environment, as if they were raised in ABAP and the same dynamic checks are executed.

Currently, the following macros, which can be extended if necessary, are available for setting exception attributes. Strings, integer and C fields are supported. See the above sequence for use.

EXCEPTION_SET_CSTRING_UC
EXCEPTION_SET_C

Value with length specification

EXCEPTION_SET_C_UC
EXCEPTION_SET_INT

Value with null termination

Auxiliary Program for Kernel Methods

The ABAP program RSKMETH serves as a browser for the registration of kernel modules. You can use it to ascertain which C functions are registered for which kernel methods and which arguments/exceptions are registered for these functions. This is helpful when analyzing syntax errors, because with kernel methods information is processed that only exists in the kernel modules.

Example

The following example is a simplified calculation class for floating point numbers. The class has an instance attribute in which the last result of each calculation is stored. A method executes a division and is implemented as a kernel method. If the divisor equals zero, the method triggers a class-based exception.

Declaration Section of the Class in ABAP

CLASS cl_my_calculation DEFINITION ...
...
DATA last_result TYPE decfloat16.
...
METHODS div
IMPORTING p_dividend TYPE decfloat16 p_divisor TYPE decfloat16
RETURNING VALUE(p_result) TYPE decfloat16.
...
ENDCLASS.

Signature file //src/krn/runt/abkmeth.sig in the kernel

...
KERNEL_METHOD(CL_MY_CALCULATION, DIV, xx_myDiv,4)
ARGUMENT_F(1, "P_DIVIDEND", TYPE, "F", READ)
ARGUMENT_F(2, "P_DIVISOR", TYPE, "F", READ)
ARGUMENT_F(3, "P_RESULT", TYPE, "F", WRITE)
ARGUMENT_F(4, "ME->LAST_RESULT",TYPE, "F", WRITE)
EXCEPTION("CX_MY_DIV_BY_ZERO")
...

C++ source code //src/krn/.../mycalc.cpp in the kernel

#include "abkmeth.h"
...
externC void xx_myDiv( ARGUMENTS ){

const SAP_DOUBLE *const dividend = ARGUMENT_F_READ(1,"P_DIVIDEND");
const SAP_DOUBLE *const divisor = ARGUMENT_F_READ(2,"P_DIVISOR");
SAP_DOUBLE *result = ARGUMENT_F_WRITE(3,"P_RESULT");
SAP_DOUBLE *last_result = ARGUMENT_F_WRITE(4,"ME->LAST_RESULT");

if( 0 == *divisor )
{
EXCEPTION_CREATE(CX_MY_DIV_BY_ZERO);
EXCEPTION_RAISE();
}

*result = *dividend / *divisor;
*last_result = *result;

}

Implementation section of the class in ABAP

CLASS cl_my_calculation IMPLEMENTATION.
...
METHOD div BY KERNEL MODULE xx_myDiv.
ENDMETHOD.
...
ENDCLASS.

The C Destructor in Methods

2009-06-23T15:45:00.000+05:30

A destructor is a special method which is called automatically when an object is deleted. Destructors can be used to release resources used by the object that are not included in the Garbage Collection. Currently ABAP Objects does not include a destructor, in which a regular ABAP processing block can be programmed.

For special cases and for internal use only, the predefined instance method destructor can be declared in the public visibility section of a class:

CLASS class DEFINITION.
PUBLIC SECTION.
METHODS destructor [NOT AT END OF MODE].
...
ENDCLASS.

In the implementation of the method destructor only one statement can currently be used:

CLASS class IMPLEMENTATION.
METHOD destructor.
SYSTEM-CALL c-destructor 'name' USING attr.
ENDMETHOD.
ENDCLASS.

This means that the destructor makes it possible to call a C routine name when an object is deleted. The routine must exist in the kernel in order that no syntax error occurs.

When the optional addition NOT AT END OF MODE is used, the destructor is not executed if the internal mode is closed anyway. Usually a destructor is also executed at the end of a mode and should mainly be used to release external resources involved that are not released automatically when the mode is closed.

When the C routine is called, an attribute attr of the class of any complex data type can be passed on to the routine. If several parameters are to be passed, an appropriate data type must be defined.

During the lifetime of an internal mode, the time when the method destructor is executed depends on when the Garbage Collector is started. When an internal mode is closed, the destructors that are not declared with the addition NOT AT END OF MODE are executed for all objects. In connection with inheritance, the destructors of the subclasses are executed before the destructors of the superclasses.

Interface Parameters in Methods

2009-06-23T15:44:00.002+05:30

Interface parameters in methods are input parameters (IMPORTING, CHANGING parameters) and output parameters (EXPORTING, CHANGING, RETURNING parameters). In declarations with the statements

METHODS

CLASS-METHODS

EVENTS

CLASS-EVENTS

the following attributes are determined:

Passing parameters by reference or by value

With the exception of the return value (RETURNING parameters), parameters can be passed both by value or reference. Passing by reference is standard with methods. If only a name p is specified in the parameter declaration, the parameter is passed implicitly as a reference. If a VALUE(p) is specified instead, then the parameter is passed as a value. The return value may only be passed as a value. Passing by reference can also be explicitly specified with other parameters using REFERENCE(p). An IMPORTING parameter transferred by reference, cannot be changed in the method.

Typing parameters

All parameters must be typed during declaration using the addition TYPE or the addition LIKE. The following entries are allowed after TYPE as parameter types:

Optional parameters

All input parameters (IMPORTING, CHANGING parameters) can be defined in the declaration as optional parameters using the additions OPTIONAL or DEFAULT. These parameters must not necessarily be transfered when the method is called. With the addition OPTIONAL your parameter remains initialized according to type, while the addition DEFAULT allows you to enter a start value.

Data Types and Constants

2009-06-23T15:44:00.001+05:30

Data Types

Independent Types

You can use the TYPES statement to define any number of your own ABAP data types within a class. Types are not instance-specific and are only available once for all the objects in the class.

In particular, it is possible to define data types in the public visibility section of global classes, which makes the use of type groups in this context obsolete.

Bound Data Types

Bound data types that occur as properties of instance or static attributes also belong to the static attributes of a class. After a LIKE addition, the class name can be used to access the properties of instance attributes (exceptions to this rule are the statements ASSIGN ... CASTING and SELECT-OPTIONS ... FOR). In addition, a reference variable can be used with an object component selector without the object having previously been generated.

Constants

Constants are special static attributes for which values are specified when they are declared. These values cannot be changed later. Use the CONSTANTS statement to declare constants. Constants are not instance-specific - they are only available once for all the objects in the class.

In particular, it is possible to declare constants in the public visibility section of global classes, which makes the use of type groups in this context obsolete.

Events In Components of classes

2009-06-23T15:43:00.001+05:30

n ABAP Objects, events are declared as components of classes. SAP makes a distinction between instance events and static events. Triggers and handlers can be objects and classes, depending on whether they are instance events, static events, or event handlers.

Instance events

Instance events are declared using the EVENTS statement. They can only be triggered in instance methods.

Static events

Static events are declared using the CLASS-EVENTS statement. All methods (instance or static) can trigger them, but only static events can be triggered by static methods.

Constructors In Components of Classes

2009-06-23T15:42:00.000+05:30

Constructors are special methods that produce a defined initial state for objects and classes. The state of an object is determined by its instance attributes and static attributes. You can assign contents to attributes using the VALUE addition in the DATA statement. Constructors are necessary when you want to set the initial state of an object dynamically.

Like normal methods, there are two types of constructor - instance constructors and static constructors.

For inheritance, some special rules apply to constructors that are not described here. These are covered in more detail in the inheritance context.

Instance Constructors

Each class has one instance constructor. It is a predefined instance method of the CONSTRUCTOR class. If you want to use the instance constructor, the constructor method must be declared in a visibility area of the class using the METHODS statement, and implemented in the implementation section. The visibility area in which the instance constructor can be declared, must be more general or equal to the instantiability defined by the addition CREATE of the CLASS statement, where the most specialized area is recommended. Unless it is explicitly declared, the instance constructor is an implicit method, which inherits and accesses the interface from the instance constructor in the upper class.

The declaration is carried out in a visibility area of the declaration part due to technical reasons. The actual visibility of the instance constructor is controlled by the CREATE PUBLIC|PROTECTED|PRIVATE additions of the CLASS statement. For more information refer to Visibility of Instance Constructors.

Instance constructors are called once for each instance. They are called automatically, immediately after you have created an instance using the CREATE OBJECT statement. It is not possible to call an instance constructor directly using the CALL METHOD statement.

An instance constructor can contain an interface with IMPORTING parameters and exceptions. You define the interface using the same syntax as for normal methods in the METHODS statement. The fact that there are no exporting parameters shows that constructors serve only to define the state of an object and have no other function. To transfer parameters and handle exceptions, use the EXPORTING and EXCEPTIONS additions to the CREATE OBJECT statement.

Static Constructors

Each class has a single static constructor. This is a predefined, public, static method of the class named constructor. If you want to use the static constructor, you must declare the static method class_constructor in the public section of the declaration part of the class using the CLASS-METHODS statement, and implement it in the implementation part. The static constructor has no interface parameters and cannot trigger exceptions. Unless you declare it explicitly, it is merely an empty method.

The static constructor is called once per class and internal session. It is called automatically for the class class before the class is accessed for the first time - that is, before one of the following actions:

Generating an instance of a class using CREATE OBJECT obj, where obj has the data type REF TO class.

Calling a static method using [CALL METHOD] class=>meth.

Registering a static event handler using SET HANDLER class=>meth for obj.

Registering an event handler for a static event of the class class.

Addressing a static attribute with class=>a.

The static constructor is always called immediately before the action is executed, with one exception: If your first access to the class is to address a static attribute, the static constructor is executed at the beginning of the processing block (dialog module, event block, procedure) in which access takes place.

Notes

The point at which the static constructor is called has not yet been finalized. SAP only guarantees that it will be called before the class is accessed for the first time. For this reason, static methods may be executed before the static constructor was ended.

The execution sequence of static constructors is dependent on the program flow. Static constructors must be implemented in such a way that they can be executed in any sequence.

Methods in Components of classes

2009-06-23T15:41:00.000+05:30

Methods are internal procedures of a class that determine the behavior of an object. They can access all the attributes of their class and can thus change the object status. Methods have a parameter interface, through which the system passes values to them when they are called, and through which they can return values to the caller. The private attributes of a class can only be changed using methods.

A method meth is declared in the declaration section of a class and in the implementation part of the class using the processing block.

METHOD meth.
...
ENDMETHOD.

You can declare local data types and data objects in methods, just as in all procedures. Methods are called using the CALL METHOD statement or one of its abbreviated forms. You can also call the method dynamically (dynamic invoke).

Instance Methods

Instance methods are declared using the METHODS statement. They can access all the attributes of a class and can trigger all its events.

Static Methods

Static methods are declared using the CLASS-METHODS statement. They can access static attributes of a class and are only allowed to trigger static events.

Constructors

As well as the normal methods that are called using CALL METHOD, there are two special methods called constructor and class_constructor, which are called implicitly when an object is created or when a class component is accessed for the first time.

Functional Methods

Functional methods are methods with any number of IMPORTING parameters and one RETURNING parameter. Functional methods cannot only be called using CALL METHOD. The following expressions can also be used to insert them at operand positions for functions and expressions:

Functional method without IMPORTING parameters:

meth( )

Functional method with a non-optional IMPORTING parameter or a number of optional IMPORTING parameters with a preferred parameter:

meth( f1 )

Functional method with IMPORTING parameters:

meth( p1 = f1 ... pn = fn )

At this operand position it is also possible to link function modules together to make method chains.

Attributes

2009-06-23T15:40:00.000+05:30

Attributes are internal data objects of any ABAP data type within a class. The content of the attributes specifies the status of the object. You can also define reference variables, which you can then use to create and address objects. This allows objects to be accessed within classes.

Attributes are defined in the declaration part of a class. Public attributes are completely visible from outside the class and as such are part of the interface between objects and their user. To encapsulate the status of the object, you need to use protected or private attributes. You can also limit the changeability of non-private attributes using the READ-ONLY addition during the declaration.

Instance Attributes

The content of instance attributes forms the instance-specific status of the object. Instance attributes are declared using the DATA statement. You cannot use the COMMON PART addition in classes.

Static Attributes

The content of static attributes forms the instance-independent status of the object, which is valid for all instances of the class. Static attributes are available once for each class. They are declared using the CLASS-DATA statement and are retained throughout the entire runtime. All the objects within a class can access its static attributes. Changes to a static attribute in an object are visible to all other objects within that class.

Data Types of Attributes

The data types of all attributes including the instance attributes and in particular the bound data types belong to the static properties of a class. Therefore, in a LIKE addition, you can use the class component selector or reference variables to refer to the visible attributes of a class without first creating an object. In this way, the access to the properties of the public static attributes of global classes is possible in every program.

Example

Reference to the data type of an instance attribute attr of a global class cl_global.

DATA dref TYPE REF TO cl_global.

DATA: f1 LIKE cl_global=>attr,
f2 LIKE dref->attr.

Boxed Components

Attributes declared as structures can be declared as boxed components using the addition BOXED, like substructures of nested structures. In boxed components, initial value sharingcauses less memory to be used for little used structures of much used objects. A boxed component is a deep component administered using an internal reference, like strings and internal tables.

Visibility Sections in Classes

2009-06-23T15:39:00.001+05:30

The declaration section of a class can be split into up to three different visibility sections.

These sections define the external visibility of the class components and therefore the interfaces of the class for all users allowed by the package concept. Each component of a class must be explicitly assigned to one of the visibility sections.

Public visibility section

All components declared in the public visibility section defined with PUBLIC SECTION are accessible to all users as well as in the methods of all heirs and in the class itself. The public components are the interface of the class to each user.

Protected visibility section

All components declared in the protected visibility section defined with PROTECTED SECTION are accessible in the methods of all heirs and in the class itself. The protected components form a specific interface between the class and its subclasses.

Private visibility section

All components declared in the private visibility section defined with PRIVATE SECTION are only accessible in the methods of the class itself, and are not even visible to the heirs. The private components therefore do not form an interface to the users of the class.

The following table groups the visibilities for a class:

Visible for	PUBLIC SECTION	PROTECTED SECTION	PRIVATE SECTION
Same class and its friends	X	X	X
Any subclasses	X	X	-
Any Repository objects	X	-	-

Note

A subclass cannot access the protected components from a subclass of a different branch in the hierarchy that is inherited from a common superclass.

Encapsulation

The three visibility sections form the basis for the important object property of encapsulation in ABAP Objects. When declaring a class, you should declare the minimum possible number of components in the public section and these public components must be created carefully. For global classes, they can no longer be changed after the class is released.

Note

The class is the smallest encapsulation unit in ABAP Objects. A method can therefore use all components of all instances of the same class, except for the components of its own class. The exceptions to this rule are subclasses, which cannot access the private components of superclasses if they are not their friends.

Example

In the method m1 of the class c1, reference variables of the static type c1 can be used to access the protected attribute a11 and the private attribute a12 of any objects of c1. In the method m2 of the subclass c2, a reference variable of the static type c2 can similarly be used to access the protected attribute a11. Access to the attribute using a reference variable of the static type c1 is not permitted, as otherwise it would also be possible to access an object of the superclass or another subclass. It is not possible to access the private attribute of the superclass with either reference variable.

CLASS c1 DEFINITION.
PUBLIC SECTION.
METHODS m1.
PROTECTED SECTION.
DATA a11 TYPE i.
PRIVATE SECTION.
DATA a12 TYPE i.
ENDCLASS.

CLASS c1 IMPLEMENTATION.
METHOD m1.

DATA lref1 TYPE REF TO c1.

lref1->a11 = 0. "OK

lref1->a12 = 0. "OK

ENDMETHOD.
ENDCLASS.

CLASS c2 DEFINITION INHERITING FROM c1.
PUBLIC SECTION.
METHODS m2.
ENDCLASS.

CLASS c2 IMPLEMENTATION.
METHOD m2.

DATA: lref1 TYPE REF TO c1,
lref2 TYPE REF TO c2.

lref1->a11 = 0. "Syntax warning, access to a11 not permitted

lref2->a11 = 0. "OK

lref1->a12 = 0. "Syntax error, access to a11 not permitted

lref2->a12 = 0. "Syntax error, a12 not visible

ENDMETHOD.
ENDCLASS.

Components of Classes

2009-06-23T15:38:00.001+05:30

The content of a class is composed of components. The components define the attributes of objects of a class. Each component is declared in the definition of the class in one of the four visibility areas that the interfaces define externally. Within a class, all its components are visible. All components are in the same namespace, which means that the names of all components in a class must be different.

The individual components are:

Attributes

Methods

Events

Types and Constants

SAP makes a distinction between components of this type that are available on an instance-dependent basis for every object, and components that are only available once in a class and are instance-independent. The instance-dependent components are called instance components, the instance-independent components are known as static components.

In ABAP Objects, classes can define the components listed above. Since all components that can be declared in classes can also be declared in interfaces, this description also applies for interfaces.

The components of classes can be accessed from inside, and depending on the visibility, also from outside the class. If they are accessed from externally, component selectors must be used for addressing.

Classes

2009-06-23T15:37:00.001+05:30

The type of an object is known as its class. A class is an abstract representation, or, metaphorically speaking, a set of instructions for building objects. So that you can describe the properties of objects, classes contain components, which define the state and behavior of objects.

Global and Local Classes

You can define classes globally in the class library in the repository or locally in an ABAP program.

Global classes are coded in a special ABAP program, a class pool, whereas local classes can be coded in almost every ABAP program. Global classes can be used and are visible in all ABAP programs, which is the case for local classes only in their own program. When a global class is used for the first time, the class pool is loaded into the internal mode of the user. The local classes of a class pool can be used by the pool's global classes.

Except for the storage type and the visibility, there are hardly any conceptual differences between global and local classes. One of the few differences is that in the public interface of a global class only references to public types are possible. These types are subdivided into global and local friends.

In principle, it also does not make any difference if you call a method of a local or global class. This is the reason why classes that are used by several programs are exclusively created in the class library. You should avoid, if possible, to reuse local classes using include programs.

ABAP Objects

2009-06-23T15:35:00.000+05:30

ABAP Objects is the object-oriented extension of ABAP.

ABAP Objects contains a complete set of language elements that allow object-oriented programming on the basis of classes and interfaces. Object orientation in ABAP builds on the existing language, and is largely compatible with it. You can use ABAP Objects in existing programs. Vice versa, the Statements in ABAP Objects cover almost the complete ABAP language set; however, specific Obsolete Language Constructs are not allowed in connection with ABAP objects due to a clean-up of the ABAP language.

ABAP Objects supports:

Classes

Interfaces

Objects

Object references

Inheritance

Note

The package SABAP_DEMOS_CAR_RENTAL contains a complete example application written in ABAP objects, for which the presentation layer is realized using a Web Dynpro. The Web Dynpro calls interface methods that are implemented in a class that, in turn, accesses classes that perform database accesses

ABAP Programming Language - Overview

2009-06-23T15:32:00.000+05:30

ABAP is a programming language developed by SAP for programming commercial applications in the SAP environment.

ABAP and SAP NetWeaver

In SAP NetWeaver, ABAP is the programming interface of the Application Server ABAP (AS ABAP). Prerequisite for the use of the ABAP programming language is the installation of an Application Server ABAP. Most of the components of an AS ABAP can be organized according to their tasks in the layers of a three-tier client-server architecture with presentation, application, and database layers.

The presentation layer is distributed on the workstations of individual users and represents the user interface of an AS ABAP ( SAP GUI or Web browser).

The application layer is realized by one or more application servers. The ABAP runtime environment contains the ABAP runtime environment in which ABAP programs are executed.

The database layer consists of a database system in which the central dataset of an AS ABAP is stored.

Next to the three layers are the following communication components:

Internet Communication Manager (ICM)

The Internet Communication Manager is a process of AS ABAP and allows direct communication with the internet via HTTP/HTTPS/SMTP. The ICM can be used to connect Web-based presentation components such as Web Dynpro ABAP and BSP. The ICM also allows an AS ABAP to work both as a client and as a server for Web Services. To access the ICM from within ABAP programs, the classes and interfaces of the Internet Communication Framework (ICF) are used.

RFC interface

This is the classical functional interface of AS ABAP. A Remote Function Call is a call of a function in system different from the one in which the calling program is running. Calls are possible between different AS ABAP or between an AS ABAP and an external system. On an AS ABAP, the functions are realized in function modules. In external systems, specially programmed functions are called whose interface simulates a function module.

The main role of ABAP programs in the application layer is the processing and formatting of data from the database layer and its transfer to, and receipt of input from the presentation layer or the communication components.

Scope and Application Areas of ABAP

ABAP is a 4GL language developed specifically for the mass processing of data in commercial applications. It offers the following advantages in comparison to elementary languages in which these functions are stored in libraries:

Database access integrated into the language as Open SQL.

Performance optimization of database accesses integrated into the ABAP runtime environment through the use of SAP buffering.

Internal tables for dynamic storage and processing of tabular mass data in the working memory.

The concept of Online Transaction Processing (OLTP integrated in the ABAP runtime environment, enabling several users to access the central database at the same time using the SAP LUW.

The language has an integrated interface to other programming environments via Remote Function Call.

The language has an integrated interface to XML.

The integration of these functions into the language is particularly advantageous for the static checkability and the performance of programs. In return, this means that ABAP also contains considerably more language elements than an elementary programming language.

Programming Models

ABAP supports an object-oriented programming model that is based on classes and interfacesand a procedural model based on subroutines and function modules. Both models are interoperable.

Note

We recommend that you use ABAP Objects as much as possible for both new projects and for redesigning existing projects.

Multilingual Capability

ABAP programs can be programmed completely independently of language. This is enabled by the extraction of language-specific program components from the source code, which are then reloaded during program execution according to the environment. A text environment determines the precise program behavior, for example the order in which text is sorted, at runtime. ABAP supports code pages, single-byte code, double byte code, and Unicode. For use in a Unicode system, a program must fulfill certain prerequisites and be identified as a Unicode program.

Example of a Logical Database

2009-06-17T21:25:00.002+05:30

Let us consider the logical database TEST_LDB.

Structure

Selections in the Selection Include

SELECT-OPTIONS: SLIFNR FOR LFA1-LIFNR,
SBUKRS FOR LFB1-BUKRS,
SGJAHR FOR LFC1-GJAHR,
SBELNR FOR BKPF-BELNR.

Database Program

*-------------------------------------------------------*
* DATABASE PROGRAM OF THE LOGICAL DATABASE TEST_LDB
*-------------------------------------------------------*
PROGRAM SAPDBTEST_LDB DEFINING DATABASE TEST_LDB.
TABLES: LFA1,
LFB1,
LFC1,
BKPF.

*-------------------------------------------------------*
* Initialize selection screen (process before PBO)
*-------------------------------------------------------*
FORM INIT.
....
ENDFORM. "INIT

*-------------------------------------------------------*
* PBO of selection screen (always before selection
* screen
*-------------------------------------------------------*
FORM PBO.
....
ENDFORM. "PBO

*-------------------------------------------------------*
* PAI of selection screen (process always after ENTER)
*-------------------------------------------------------*
FORM PAI USING FNAME MARK.
CASE FNAME.
WHEN 'SLIFNR'.
....
WHEN 'SBUKRS'.
....
WHEN 'SGJAHR'.
....
WHEN 'SBELNR'.
....
ENDCASE.
ENDFORM. "PAI

*-------------------------------------------------------*
* Call event GET LFA1
*-------------------------------------------------------*
FORM PUT_LFA1.
SELECT * FROM LFA1
WHERE LIFNR IN SLIFNR.
PUT LFA1.
ENDSELECT.
ENDFORM. "PUT_LFA1

*-------------------------------------------------------*
* Call event GET LFB1
*-------------------------------------------------------*
FORM PUT_LFB1.
SELECT * FROM LFB1
WHERE LIFNR = LFA1-LIFNR
AND BUKRS IN SBULRS.
PUT LFB1.
ENDSELECT.
ENDFORM. "PUT_LFB1

*-------------------------------------------------------*
* Call event GET LFC1
*-------------------------------------------------------*
FORM PUT_LFC1.
SELECT * FROM LFC1
WHERE LIFNR = LFA1-LIFNR
AND BUKRS = LFB1-BUKRS
AND GJAHR IN SGJAHR.
PUT LFC1.
ENDSELECT.
ENDFORM. "PUT_LFC1

*-------------------------------------------------------*
* Call event GET BKPF
*-------------------------------------------------------*
FORM PUT_BKPF.
SELECT * FROM BKPF
WHERE BUKRS = LFB1-BUKRS
AND BELNR IN SBELNR
AND GJAHR IN SGJAHR.
PUT BKPF.
ENDSELECT.
ENDFORM. "PUT_BKPF

The PROGRAM statement has the addition DEFINING DATABASE TEST_LDB. This defines the database program as belonging to the logical database TEST_LDB.

The nodes of the structure are declared with the TABLES statement which generates the appropriate table work areas. You can also use the NODES statement to define database tables as nodes. If a node of a logical database is not a database table, you must use the NODES statement. The interface work areas are shared by the database program and the user, and so act as an interface for passing data. The term "user" here can mean either an executable program to which the logical database is linked, or the function module LDB_PROCESS.

The subroutines INIT and PBO initialize the selection screen.

In the PAI subroutine, you can include an authorization check for the user input on the selection screen. Plausibility or value range checks are also possible. If a check fails, you can write an error dialog. The corresponding field on the selection screen is then made ready for input again.

The PUT_ subroutines read the database tables according to the selection criteria entered by the user and trigger the relevant events in the executable program. This program is intended only to show the essential structure of a logical database. It does not contain any refinements to improve response times. The order in which the subroutines are called is determined by the structure of the logical database.

Logical Databases

2009-06-17T21:25:00.001+05:30

Logical databases are special ABAP programs that retrieve data and make it available to application programs. The most common use of logical databases is still to read data from database tables by linking them to executable ABAP programs.

However, from Release 4.5A, it has also been possible to call logical databases using the function module LDB_PROCESS. This allows you to call several logical databases from any ABAP program, nested in any way. It is also possible to call a logical database more than once in a program, if it has been programmed to allow this. This is particularly useful for programs with type 1.

Logical databases contain Open SQL statements that read data from the database. You do not therefore need to use SQL in your own programs. The logical database reads the program, stores them in the program if necessary, and then passes them line by line to the application program or the function module LDB_PROCESS using an interface work area.

Logical Databases - Views of Data

A logical database provides a particular view of database tables in the R/3 System. It is always worth using logical databases if the structure of the data that you want to read corresponds to a view available through a logical database.

The data structure in a logical database is hierarchical. Many tables in the R/3 System are linked to each other using foreign key relationships. Some of these dependencies form tree-like hierarchical structures. Logical databases read data from database tables that are part of these structures.

The diagram illustrates how the R/3 System might represent the structure of a company. A logical database can read the lines of these tables one after the other into an executable program in a sequence which is normally defined by the hierarchical structure. The term logical database is sometimes used to mean not only the program itself, but also the data that it can procure.

Tasks of Logical Databases

As well as allowing you to read data from the database, logical databases also allow you to program other tasks centrally, making your application programs less complicated. They can be used for the following tasks:

Reading the same data for several programs.

The individual programs do not then need to know the exact structure of the relevant database tables (and especially not their foreign key relationships). Instead, they can rely on the logical database to read the database entries in the right order during the GET event.

Defining the same user interface for several programs.

Logical databases have a built-in selection screen. Therefore, all of the programs that use the logical database have the same user interface.

Central authorization checks

Authorization checks for central and sensitive data can be programmed centrally in the database to prevent them from being bypassed by simple application programs.

Improving performance

If you want to improve response times, logical databases permit you to take a number of measures to achieve this (for example, using joins instead of nested SELECT statements). These become immediately effective in all of the application programs concerned and save you from having to modify their source code.

Position of the Basis System Within the R/3 System

2009-06-17T21:23:00.000+05:30

The following sections describe three different views of the R/3 System, which show the role of the Basis system.

Logical View

The following illustration represents a logical view of the R/3 System.

The difference between the logical view and a hardware- or software-based view is that not all of the above components can be assigned to a particular hardware or software unit. The above diagram shows how the R/3 Basis system forms a central platform within the R/3 System. Below are listed the tasks of the three logical components of the R/3 Basis system.

Kernel and Basis Services

The kernel and basis services component is a runtime environment for all R/3 applications that is hardware-, operating system- and database-specific. The runtime environment is written principally in C and C++. However, some parts are also written in ABAP. The tasks of the kernel and basis services component are as follows:

Running applications
All R/3 applications run on software processors (virtual machines) within this component.

User and process administration
An R/3 System is a multi-user environment, and each user can run several independent applications. In short, this component is responsible for the tasks that usually belong to an operating system. Users log onto the R/3 System and run applications within it. In this way, they do not come into contact with the actual operating system of the host. The R/3 System is the only user of the host operating system.

Database access
Each R/3 System is linked to a database system, consisting of a database management system (DBMS) and the database itself. The applications do not communicate directly with the database. Instead, they use Basis services.

Communication
R/3 applications can communicate with other R/3 Systems and with non-SAP systems. It is also possible to access R/3 applications from external systems using a BAPI interface. The services required for communication are all part of the kernel and basis services component.

System Monitoring and Administration
The component contains programs that allow you to monitor and control the R/3 System while it is running, and to change its runtime parameters.

ABAP Workbench

The ABAP Workbench component is a fully-fledged development environment for applications in the ABAP language. With it, you can create, edit, test, and organize application developments. It is fully integrated in the R/3 Basis system and, like other R/3 applications, is itself written in ABAP.

Presentation Components

The presentation components are responsible for the interaction between the R/3 System and the user, and for desktop component integration (such as word processing and spreadsheets).

Software-oriented View

The following illustration represents a software-oriented view of the R/3 System. The software-oriented view describes the various software components that make up the R/3 System. In the software-oriented view, all of the SAPgui components and application servers in the R/3 System make up the R/3 Basis system.

The R/3 Basis system is a multi-tier client/server system. The individual software components are arranged in tiers and function, depending on their position, as a client for the components below them or a server for the components above them. The classic configuration of an R/3 System contains the following software layers:

Database Layer

The database layer consists of a central database system containing all of the data in the R/3 System. The database system has two components - the database management system (DBMS), and the databse itself. SAP does not manufacture its own database. Instead, the R/3 System supports the following database systems from other suppliers: ADABAS D, DB2/400 (on AS/400), DB2/Common Server, DB2/MVS,INFORMIX, Microsoft SQL Server, ORACLE, and ORACLE Parallel Server.

The database does not only contain the master data and transaction data from your business applications, all data for the entire R/3 System is stored there. For example, the database contains the control and Customizing data that determine how your R/3 System runs. It also contains the program code for your applications. Applications consist of program code, screen definitions, menus, function modules, and various other components. These are stored in a special section of the database called the R/3 Repository, and are accordingly called Repository objects. You work with them in the ABAP Workbench.

Application Layer

The application layer consists of one or more application servers and a message server. Each application server contains a set of services used to run the R/3 System. Theoretically, you only need one application server to run an R/3 System. In practice, the services are distributed across more than one application server. This means that not all application servers will provide the full range of services. The message server is responsible for communication between the application servers. It passes requests from one application server to another within the system. It also contains information about application server groups and the current load balancing within them. It uses this information to choose an appropriate server when a user logs onto the system.

Presentation Layer

The presentation layer contains the software components that make up the SAPgui (graphical user interface). This layer is the interface between the R/3 System and its users. The R/3 System uses the SAPgui to provide an intuitive graphical user interface for entering and displaying data. The presentation layer sends the user’s input to the application server, and receives data for display from it. While a SAPgui component is running, it remains linked to a user’s terminal session in the R/3 System.

This software-oriented view can be expanded to include further layers, such as an Intenet Transaction Server (ITS).

Software-oriented and Hardware-oritented View

The software-oriented view has nothing to do with the hardware configuration of the system. There are many different hardware configuration possibilities for both layers and components. When distributing the layers, for example, you can have all layers on a single host, or, at the other extreme, you could have at least one host for each layer. When dealing with components, the distribution of the database components depends on the database sytsem you are using. The application layer and presentation layer components can be distributed across any number of hosts. It is also possible to install more than one application server on a single host. A common configuration is to run the database system and a single application server (containing special database services) on one host, and to run each further application server on its own host. The presentation layer components usually run on the desktop computers of the users.

Advantages of the Multi-tier Architecture

The distribution of the R/3 software over three layers means that the system load is also distributed. This leads to better system performance.

Since the database system contains all of the data for the entire R/3 System, it is subject to a very heavy load when the sytsem is running. It is therefore a good idea not to run application programs on the same host. The architecture of the R/3 System, in which the application layer and database layer are separate, allows you to install them on separate hosts and let them communicate using the network.

It also makes sense to separate program execution from the tasks of processing user input and formatting data output. This is made possible by separating the presentation layer and the application layer. SAPgui and the application servers are designed so that the minimum amount of data has to be transported between the two layers. This means that the presentation layer components can even be used on hosts that have slow connections to application servers a long way away.

The system is highly scalable, due to the fact that the software components of an R/3 System can be distributed in almost any configuration across various hosts. This is particularly valuable in the application layer, where you can easily adapt your R/3 System to meet increasing demand by installing further application servers.

Consequences for Application Programming

The fact that the application and presentation layers are separate carries an important consequence for application programmers. When you run an application program that requires user interaction, control of the program is continually passed backwards and forwards between the layers. When a screen is ready for user input, the presentation layer is active, and the application server is inactive with regard to that particular program, but free for other tasks. Once the user has entered data on the screen, program control passes back to the application layer. Now, the presentation layer is inactive. The SAPgui is still visible to the user during this time, and it is still displaying the screen, but it cannot accept user input The SAPgui does not become active again until the application program has called a new screen and sent it to the presentation server.

As a consequence, the program logic in an application program that occurs between two screens is known as a dialog step.

User-oriented View

The following illustration represents a user-oriented view of the R/3 System:

For the user, the visible components of the R/3 System are those that appear as a window on the screen. The windows are generated by the presentation layer of the R/3 System, and form a part of the R/3 Basis system.

Before the user logs onto the R/3 System, he or she must start a utility called SAP Logon, which is installed at the front end. In SAP Logon, the user chooses one of the available R/3 Systems. The program then connects to the message server of that system and obtains the address of a suitable (most lightly-used) application server. It then starts a SAPgui, connected to that application server. The SAP Logon program is then no longer required for this connection.

SAPgui starts the logon screen. Once the user has successfully logged on, it displays the initial screen of the R/3 System in an R/3 window on the screen. Within SAPgui, the R/3 window is represented as a session. After logging on, the user can open up to five further sessions (R/3 windows) within the single SAPgui. These behave almost like independent SAPguis. The different sessions allow you to run different applications in parallel, independently of one another.

Within a session, the user can run applications that themselves call further windows (such as dialog boxes and graphic windows). These windows are not independent - they belong to the session from which they were called. These windows can be either modal (the original window is not ready for input) or amodal (both windows are ready for input).

The user can open other SAPguis, using SAP Logon, to log onto the same system or another R/3 System. The individual SAPguis and corresponding R/3 terminal sessions are totally independent. This means that you can have SAPguis representing the presentation layers of several R/3 Systems open on your desktop computer.

Running ABAP Programs

2009-06-17T21:19:00.000+05:30

ABAP programs can only be executed in an R/3 System. The R/3 Basis system contains a component called Kernel & Basis Services that provides a cross-platform runtime environment for ABAP programs (see also The Basis System).

Each ABAP program consists of self-contained processing blocks, which may occur in any order in the source code. Processing blocks are sections of programs, made up of structure blocks. They are processed sequentially. A processing block can be called either from outside the ABAP program, or from a processing block within the same ABAP program (see also Structure of ABAP Programs). When a processing block is called from outside the program, it can be called either by the ABAP runtime environment or another ABAP program.

To start an ABAP program, at least one of its processing blocks must be started from outside the program itself. Each ABAP program has a program type, which determines whether and how a program can be run.

Programs that can be run

These programs can be run by a user by entering the program name or a transaction code. They are they actual application programs within the R/3 System, and are explained in more depth later on.

Type 1

You can start a type 1 program by entering its program name. For this reason, they are also known as executable programs. When you start a type 1 program, processors are started in the runtime environment that call a series of processing blocks (event blocks) in a predefined sequence. The sequence is oriented towards reporting tasks. This is why executable programs are also known as reports. For further information, refer to Running Programs Directly - Reports.

A special type of type 1 program is a logical database. You can start logical databases together with reports. A logical database contains subroutines that are called by an invisible system program in a prescribed sequence for type 1 programs. The subroutines make certain reporting functions reusable. For further information, refer to Logical Databases.

Type M

Type M programs can only be started using a transaction code. A transaction code starts a screen, which consists of the screen itself and its flow logic. Screen flow logic can call special processing blocks (dialog modules) in the corresponding ABAP program. Since type M programs contain mostly dialog modules, they are known as module pools. For further information about running module pools, refer to Dialog-controlled Program Execution - Transactions.

Programs that Cannot Be Run Directly

These programs cannot be started directly by a user. Instead, they contain processing blocks or other source code that can only be used by an application program that is already running. They are described in more detail in a later section.

Type F

Type F programs are not executable. They serve as a container for function modules. When you call a function module from an ABAP program, the entire main program is loaded into the internal session of the current program. Since type M programs contain mainly function modules, they are known as function groups. Function modules are a type of procedure. They are described in more detail in the Procedures section.

Type K

Type K programs are not executable. They are container programs for global classes, and are known as class definitions. Classes belong to ABAP Objects and are described in more detail in that section.

Type J

Type J programs are not executable. They are container programs for global interfaces, and are known as interface definitions. Interfaces belong to ABAP Objects and are described in more detail in that section.

Type S

Type S programs are not executable. They are container programs for subroutines that should only be called externally. When you call a subroutine from an ABAP program, the entire main program is loaded into the internal session of the current program. Since type S programs contain mainly subroutines, they are known as subroutine pools. Subroutines are a type of procedure. They are described in more detail in the Procedures section.

Type I

Type I programs cannot be run directly, and contain no callable processing blocks. They are used exclusively for modularizing ABAP source code, and are included in other programs. Include programs are described in more detail in the Source Code Modules section.

Starting Programs in ABAP

For all programs that can be started directly, there are ABAP statements that you can use to call a program from another application program that is already running. For further information, refer to Program Calls.

Calling ABAP Dialog Modules

2009-06-10T20:08:00.000+05:30

The main task of the screen flow logic is to call dialog modules in an ABAP program. You can do this using the MODULE statement, which can be programmed in the four possible event blocks of screen flow logic. In the PBO event, you can use this statement to call any dialog module in the ABAP program that has been defined using

MODULE OUTPUT.
...
ENDMODULE.

In the PAI, POH, and POV events, you can use the statement to call any dialog module in the ABAP program that has been defined using

MODULE [INPUT].
...
ENDMODULE.

It is technically possible to have two dialog modules with the same name in the same program, one defined using OUTPUT, the other with INPUT. However, this is not recommended.

Since dialog modules in an ABAP program can be called from more than one screen, you can program functions that you need in several screens centrally in a single module. For example, it is usual to copy the contents of the OK-code field into an auxiliary variable and then reset the field in all PAI events. You could program this task in a single module that you would then call from the PAI event of all screens.

If you need to distinguish between screen numbers in a dialog module, you can use the system field SY-DYNNR, which always contains the number of the current screen. This would allow you, for example, to analyze the function code in a single PAI module and then control the further program flow according to the screen number and function code.

The actual screen sequence is as follows:

The screen display is prepared in the PBO event. The flow logic calls the corresponding ABAP dialog modules. Then, the screen is displayed. When this happens, control passes from the application server to the SAPgui. The screen accepts user input until the user triggers the PAI event. The control then returns to the application server. The program processes user input by calling the corresponding ABAP dialog modules. After the PAI processing is complete, the PBO processing of the next screen starts. The PAI processing and the PBO processing of the next screen form a single dialog step on the application server. The current screen remains visible until the PBO of the next screen is complete, but is not ready for input.

There are various ways of calling the dialog modules in the flow logic. The syntax of the flow logic allows you to call dialog modules conditionally, and to control the transfer of data between the screen and the ABAP program.

Data Types in the ABAP Dictionary

2009-06-10T20:04:00.000+05:30

The ABAP Dictionary allows you to define global data types. You can use the TYPE addition of an appropriate ABAP statement to refer to these data types in any ABAP program in the system.

You define these data types using the ABAP Dictionary. The following input fields are relevant to data types:

There are three groups on the initial screen:

Database Tables and Views

One of the most important tasks of the ABAP Dictionary is to administer database tables in the R/3 database. The Dictionary contains meta-descriptions of the database tables, and uses these to create the physical tables in the database. A view is a "virtual table" containing fields from one or more tables.

In the description of a database table, the table lines consist of single fields or columns. An elementary data type must be assigned to each column. The elementary types in the ABAP Dictionary are data elements. Like data objects in ABAP programs, database tables and views have data types as attributes. A line of a database table or view has the data type of a flat structure, which consists of individual data elements.

In ABAP programs, you can use the TYPE addition with the data type of a database table or view. You may refer to the whole structure or to individual components:

... TYPE ...

refers to the complex data type of the structure,

... TYPE -_i> ...

refers to the elementary data type of component _i>.

If you define a complex data type as a structure using

TYPES TYPE .

the components of the data type inherit the names of the components of the database table or view, and can be addressed in the program using -_i>.

To ensure compatibility with previous releases, you can still use the LIKE addition to refer to database tables or views, except within classes. The reason for this is that in earlier releases, the physical presence of the database tables as objects was emphasized, even though the Dictionary only contains meta-descriptions and data types.

Defining program-local data types by referring to database tables and views is one of the essential techniques for processing data from database tables in ABAP. Data objects that you define in this way always have the right type to contain data from the corresponding database table. ABAP Open SQL allows you to read a single field, a range of fields, or an entire database table or view into an internal table.

TYPES: city type spfli-cityfrom,
spfli_type TYPE STANDARD TABLE OF spfli WITH DEFAULT KEY.

DATA: wa_city TYPE city,
wa_spfli TYPE spfli_type.

...

SELECT SINGLE cityfrom FROM spfli
INTO wa_city
WHERE carrid = 'LH' AND connid = '400'.

...

SELECT * FROM spfli INTO TABLE wa_spfli.

...

This example defines an elementary data type CITY that refers to a single field of the database table SPFLI and an internal table SPFLI_TYPE, whose line type is the same as the structure of the database table. The SELECT statement reads data from the database into the corresponding data objects.

Data types

Data types are the actual type definitions in the ABAP Dictionary. They allow you to define elementary types, reference types, and complex types that are visible globally in the system. The data types of database tables are a subset of all possible types, namely flat structures. Global object types (classes and interfaces) are not stored in the ABAP Dictionary, but in the class library. You create them using the Class Builder.

For a detailed description of data types and their definitions, refer to the Types section of the ABAP Dictionary documentation. The following descriptions mention the types only briefly, along with how you can refer to them from ABAP programs.

Data Elements

Data elements in the ABAP Dictionary describe individual fields. They are the smallest indivisible units of the complex types described below, and are used to specify the types of columns in the database. Data elements can be elementary types or reference types.

Elementary Types

Elementary types are part of the dual-level domain concept for fields in the ABAP Dictionary. The elementary type has semantic attributes, such as texts, value tables, and documentation, and has a data type. There are two different ways to specify a data type:

By directly assigning an ABAP Dictionary type.

You can assign a predefined ABAP Dictionary type and a number of characters to an elementary type. The ABAP Dictionary has considerably more predefined types than the ABAP programming language. The number of characters here is not the field length in bytes, but the number of valid characters excluding formatting characters. The data types are different because the predefined data types in the ABAP Dictionary have to be compatible with the external data types of the database tables supported by the R/3 System.

When you refer to data types from the ABAP Dictionary in an ABAP program, the predefined Dictionary types are converted to ABAP types as follows:

Dictionary type	Meaning	Maximum length n	ABAP type
DEC	Calculation/amount field	1-31, 1-17 in tables	P((n+1)/2)
INT1	Single-byte integer	3	Internal only
INT2	Two-byte integer	5	Internal only
INT4	Four-byte integer	10	I
CURR	Currency field	1-17	P((n+1)/2)
CUKY	Currency key	5	C(5)
QUAN	Amount	1-17	P((n+1)/2)
UNIT	Unit	2-3	C(n)
PREC	Accuracy	16	Internal only
FLTP	Floating point number	16	F(8)
NUMC	Numeric text	1-255	N(n)
CHAR	Character	1-255	C(n)
LCHR	Long character	256-max	C(n)
STRING.	String of variable length	1-max	STRING.
RAWSTRING	Byte sequence of variable length	1-max	XSTRING
DATS	Date	8	D
ACCP	Accounting period YYYYMM	6	N(6)
TIMS	Time HHMMSS	6	T
RAW	Byte sequence	1-255	X(n)
LRAW	Long byte sequence	256-max	X(n)
CLNT	Client	3	C(3)
LANG	Language	internal 1, external 2	C(1)

("max" in LCHR and LRAW is the value of a preceding INT2 field. The "internal" length of a LANG field is in the Dictionary, the "external" length refers to the display on the screen.

Assigning a domain

The technical attributes are inherited from a domain. Domains are standalone Repository objects in the ABAP Dictionary. They can specify the technical attributes of a data element. One domain can be used by any number of data elements. When you create a domain, you must specify a Dictionary data type (see above table) and the number of characters.

Reference Types

Reference types describe single fields that can contain references to global classes and interfaces from the ABAP class library.

In an ABAP program, you can use the TYPE addition to refer directly to a data element. The predefined Dictionary data types of the domain are then converted into the corresponding ABAP types.

If you define a local data type in a program by referring to a data element as follows:

TYPES TYPE .

the semantic attributes of the data element are inherited and will be used, for example, when you display a data object with type on the screen. Since all data types in the ABAP Dictionary are based on data elements, they all contain the corresponding semantic attributes.

TYPES company TYPE s_carr_id.

DATA wa_company TYPE company.

wa_company = 'UA '.

WRITE: 'Company:', wa_company.

This example defines a local type COMPANY that refers to the data element S_CARR_ID. The data element is linked to the identically-named domain S_CARR_ID. The domain defines the technical attributes as data type CHAR with length 3. The local data type COMPANY in the program therefore has the ABAP type C(3). COMPANY also adopts the semantic attributes of the data element. In the above example, we declare a data object WA_COMPANY with this type and display it on a list. If the user chooses F1 help for the output field, the help text stored in the ABAP Dictionary will appear in a dialog box.

structures

A structure is a sequence of any other data types from the ABAP Dictionary, that is, data elements, structures, table types, or database tables. When you create a structure in the ABAP Dictionary, each component must have a name and a data type.

In an ABAP program, you can use the TYPE addition to refer directly to a structure.

If you define a local data type in a program by referring to a structure as follows:

TYPES TYPE .

the construction blueprint of the structure is used to create a local structure in the program. The predefined Dictionary data types of the domains used by the data elements in the structure are converted into the corresponding ABAP types. The semantic attributes of the data elements are used for the corresponding components of the structure in the program. The components of the local structure have the same names as those of the structure in the ABAP Dictionary.

To ensure compatibility with previous releases, it is still possible to use the LIKE addition in an ABAP program to refer to a structure in the ABAP Dictionary (except in classes).

Suppose the structure STRUCT is defined as follows in the ABAP Dictionary:

Field name	Type name	Description
COL1	CHAR01	Character field with length 1
COL2	CHAR08	Character field with length 8
COL3	CHAR10	Character field with length 10

The types CHAR01 to CHAR10 are data elements with corresponding domains. We can refer to this structure in ABAP:

TYPES struct_type TYPE struct.

DATA wa TYPE struct_type.

wa-col1 = '1'.
wa-col2 = '12345678'.
wa-col3 = '1234567890'.

This program creates a local structure in the program - STRUCT_TYPE - and a corresponding data object WA. We can address the components using the component names from the original structure.

Table Types

Table types are construction blueprints for internal tables that are stored in the ABAP Dictionary. When you create a table type in the ABAP Dictionary, you specify the line type, access type, and key. The line type can be any data type from the ABAP Dictionary, that is, a data element, a structure, a table type, or the type of a database table. You can also enter a predefined Dictionary type directly as the line type, in the same way that you can with a domain.

In an ABAP program, you can use the TYPE addition to refer directly to a table type.

If you define a local data type in a program by referring to a table type as follows:

TYPES TYPE

the construction blueprint of the table type is used to create a local internal table in the program. The predefined Dictionary data types of the domains used by the data elements in the structure are converted into the corresponding ABAP types. The semantic attributes of the data elements are used for the corresponding components of the internal table in the program.

Suppose the table type STRUCT_TABLE is defined in the Dictionary with the line type STRUCT from the previous example. We can refer to this in ABAP:

TYPES table_type TYPE struct_table.

DATA: table_wa TYPE table_type,
line_wa LIKE LINE OF table_wa.

...

LOOP AT table_wa INTO line_wa.
...
WRITE: line_wa-col1, line_wa-col1, line_wa-col1.
...
ENDLOOP.

This program defines an internal table type TABLE_TYPE. From it, we define data objects TABLE_WA and LINE_WA. LINE_WA corresponds to the line type of the table type in the Dictionary, and is therefore compatible with the structure STRUCT.

Type Groups

Before Release 4.5A, it was not possible to define standalone types in the ABAP Dictionary to which you could refer using a TYPE addition in an ABAP program. It was only possible to refer to flat structures. Structures in programs corresponded to the structures of database tables or structures in the ABAP Dictionary. In ABAP programs, you could only refer to database tables and structures in the ABAP Dictionary using LIKE. It was, however, possible to refer to individual components of the Dictionary type. Complex local data types such as internal tables or deep structures had no equivalent in the ABAP Dictionary. The solution to this from Release 3.0 onwards was to use type groups. Type groups were based on the include technique, and allowed you to store any type definitions globally in the Dictionary by defining them using TYPES statements.

The definition of a type group is a fragment of ABAP code which you enter in the ABAP Editor. The first statement for the type group is always:

TYPE-POOL .

After this came the definitions of data types using the TYPES statement, as described in Local Data Types in Programs. It was also possible to define global constants using the CONSTANTS statement. All the names of these data types and constants must begin with the name of the type group and an underscore:

In an ABAP program, you must declare a type group as follows before you can use it:

TYPE-POOLS .

This statement allows you to use all the data types and constants defined in the type group in your program. You can use several type groups in the same program.

Let the type group HKTST be created as follows in the ABAP Dictionary:

TYPE-POOL hktst.

TYPES: BEGIN OF hktst_typ1,
col1(10) TYPE c,
col2 TYPE i,
END OF hktst_typ1.

TYPES hktst_typ2 TYPE p DECIMALS 2.

CONSTANTS hktst_eleven TYPE i VALUE 11.

This type group defines two data types HKTST_TYP1 and HKTST_TYP2, as well as a constant HKTST_ELEVEN with the value 11.

Any ABAP program can use this definition with the TYPE-POOLS statement:

TYPE-POOLS hktst.

DATA: dat1 TYPE hktst_typ1,
dat2 TYPE hktst_typ2 VALUE '1.23'.

WRITE: dat2, / hktst_eleven.

The output is:

1,23

The data types defined in the type group are used to declare data objects with the DATA statement and the value of the constant is, as the output shows, known in the program.

Pushbuttons on the Screen

2009-06-10T20:00:00.000+05:30

Pushbuttons are the only elements of screens that trigger the PAI event when the user chooses them. In the attributes of a pushbutton, you can specify a function code up to 20 characters long.

Pushbuttons have a label - the text that you specify statically in the attributes - and can also have icons. If you set the Output field attribute for a pushbutton, you can also set its text dynamically in the ABAP program. To do this, you must create a field in the ABAP program with the same name as the pushbutton. You must then assign the required text to the field before the screen is displayed. You can also assign icons to dynamic texts on pushbuttons by including the icon code in the text. The icon codes are all contained in the include program . For example, the ICON_CANCEL () icon has the code @0W@.

In each PAI event, the function code, as long as it is not empty, is placed in the system field SYST-UCOMM (SY-UCOMM) and assigned to the OK_CODE field. Empty function codes are placed in neither the SY-UCOMM field nor the OK_CODE field. The function code of a pushbutton is empty if you have not entered it in the corresponding attribute in the Screen Painter. Before you can work with the OK_CODE field, you must assign a name to it in the Screen Painter. For further information, refer to Reading Function Codes.

The main way of allowing users to choose functions that trigger the PAI event and send function codes to the program is through the GUI status. The main reason is one of space - the GUI status can contain many more functions than you would be able to place on the screen as pushbuttons.

However, you should use pushbuttons in the following cases:

Very important and frequently-used function codes that should appear on the screen as well as in the GUI status, for example, the Execute, Display, and Change functions on the initial screen of the ABAP Editor.

Applications that only use pushbuttons, where function codes in the GUI status make no sense - for example, in a calculator application. The function codes of the corresponding pushbuttons have no corresponding function in the GUI status elements, and only exist as attributes of screen elements.

When you have a GUI status that is used for a large number of screens, but use it on screens that have a particular function that is not required anywhere else. In this case, you should place it on the screen as a pushbutton.

When you define pushbuttons, you must ensure that your function code is either the same as a corresponding function in the GUI status, or does not accidentally coincide with the function code of an entirely different function. Although the consistency of function codes in GUI statuses is checked in the Menu Painter, this is not possible for pushbuttons, since the GUI status of a screen is not known until runtime.

Pushbuttons on screens.

PROGRAM DEMO_DYNPRO_PUSH_BUTTON.

DATA: OK_CODE LIKE SY-UCOMM,
SAVE_OK LIKE OK_CODE,
OUTPUT(8) TYPE C.

CALL SCREEN 100.

MODULE USER_COMMAND_0100 INPUT.
SAVE_OK = OK_CODE.
CLEAR OK_CODE.
CASE SAVE_OK.
WHEN 'BUTTON_EXIT'.
LEAVE PROGRAM.
WHEN 'BUTTON_1'.
OUTPUT = 'Button 1'(001).
WHEN 'BUTTON_2'.
OUTPUT = 'Button 2'(002).
WHEN 'BUTTON_3'.
OUTPUT = 'Button 3'(003).
WHEN 'BUTTON_4'.
OUTPUT = 'Button 4'(004).
WHEN OTHERS.
OUTPUT = SAVE_OK.
ENDCASE.
ENDMODULE.

The next screen (statically defined) for screen 100 is itself. It has the following layout:

The part of the element list relevant for the screen fields is as follows:

Name	Type	Format	Text	Function code
OUTPUT	I/O	CHAR
BUTTON1	Push		Pushbutton 1	BUTTON_1
BUTTON2	Push		Pushbutton 2	BUTTON_2
BUTTON3	Push		Pushbutton 3	BUTTON_3
BUTTON4	Push		Pushbutton 4	BUTTON_4
EXIT_BUTTTON	Push		Cancel	BUTTON_EXIT
OK_CODE	OK	OK

The input option for the screen field OUTPUT has been switched off in the Screen Painter.

The screen flow logic is as follows:

PROCESS BEFORE OUTPUT.

PROCESS AFTER INPUT.
MODULE USER_COMMAND_0100.

When the user chooses a pushbutton, the PAI event is triggered. The function code of the pushbutton is assigned to the screen field OK_CODE, which is then passed onto the ABAP field with the same name. The module USER_COMMAND_0100 is then processed.

Firstly, the contents of the OK_CODE field are copied to the auxiliary variable SAVE_OK code, and OK_CODE is initialized. You should always do this, since it ensures that the screen field OK_CODE has always been initialized before the PBO event and can therefore not unintentionally contain an incorrect value.

Next, in the CASE structure, a text symbol is assigned to the OUTPUT field according to the button that the user chose. This is displayed in the output field on the screen. If the user chooses Cancel, the program ends.

Processing Input/Output Fields

2009-06-10T19:59:00.000+05:30

Input/output fields can be either conventional fields in which the user can enter values using the keyboard or by selecting from a value list, or checkboxes or radio buttons, for which the mouse is required. All input/output fields have a name linking them to a screen field. The data type of the screen field determines the input format. For example, you cannot enter letters in a numeric field. The screen recognizes when you try to enter invalid values. Radio buttons and checkboxes always have the data type CHAR and length 1. A selected radio button or checkbox has the value ‘X’, when empty, both have the value SPACE.

The ABAP program must contain identically-named data objects that correspond to the screen fields, otherwise data may be lost (see also Linking ABAP Strings to Screen Fields). The ABAP data types that correspond to the screen data types are listed in a table in the Data Types in the ABAP Dictionary section. The ABAP fields for checkboxes and radio buttons must have type C and length 1.

After the PBO event has been processed, the screen fields are filled with the values from the ABAP fields. Before or during the PAI event, the values from the screen fields are written to the ABAP fields. Note that only one radio button within a group can be selected. If more than one of the fields contains the value ‘X’, the program terminates.

To ensure that screen fields and ABAP fields always correspond exactly, use the following procedure.

Local Program Fields

If you want to use input/output fields in one program only, you should create them in the ABAP program, activate the program, and then copy the fields from the ABAP program to the screen. Afterwards, however, you must avoid changing the fields in the ABAP program.

Screen Fields with Dictionary Reference

If your input/output fields are required in more than one program, and you want to use information from the ABAP Dictionary, such as field labels, field help, and input help, you should copy fields from the ABAP Dictionary. You can refer to both structures and database tables.

You must then declare identically-named fields as an interface work area in the ABAP program using the TABLES statement. Declaring an identically-named field using a TYPES reference to the data type in the ABAP Dictionary is insufficient for data to be transferred between the screen and the ABAP program.

To avoid naming conflicts between screen fields, work areas in programs, and database tables, it is often worth defining your own ABAP Dictionary structure for screens, containing all of the input/output fields you want to use for one or more screens of a program or for a package. The work areas that you declare with TABLES in the ABAP program then function exclusively as an interface between the program and the screen. If necessary, you can assign values between program fields and the interface work area.

The advantage of referring to ABAP Dictionary data types is that both the screen fields and the fields in the ABAP program are updated automatically if the data type changes.

Local program fields

PROGRAM demo_dynpro_input_output.

DATA: input TYPE i,
output TYPE i,
radio1(1) TYPE c, radio2(1) TYPE c, radio3(1) TYPE c,
box1(1) TYPE c, box2(1) TYPE c, box3(1) TYPE c, exit(1) TYPE c.

CALL SCREEN 100.

MODULE init_screen_100 OUTPUT.
CLEAR input.
radio1 = 'X'.
CLEAR: radio2, radio3.
ENDMODULE.

MODULE user_command_0100 INPUT.
output = input.
box1 = radio1.
box2 = radio2.
box3 = radio3.
IF exit NE space.
LEAVE PROGRAM.
ENDIF.
ENDMODULE.

The next screen number of screen 100 is 100 (statically-defined). Its layout is as follows:

The part of the element list relevant for the screen fields is as follows:

Name	Type	defLg	Format
INPUT	I/O	9	INT4
OUTPUT	I/O	11	INT4
RADIO1	Radio	1	CHAR
BOX1	Check	1	CHAR
RADIO2	Radio	1	CHAR
BOX2	Check	1	CHAR
RADIO3	Radio	1	CHAR
BOX3	Check	1	CHAR
EXIT	Check	1	CHAR
	OK	20	OK

The screen fields OUTPUT, BOX1, BOX2, and BOX3 cannot accept user input.

The length of INPUT is such that the user can enter a nine-digit integer without thousand separators. However, the display in the OUTPUT field contains up to two thousand separators. Had we left the length of INPUT at 11 digits, a runtime error could have occurred.

The screen flow logic is as follows:

PROCESS BEFORE OUTPUT.
MODULE init_screen_100.

PROCESS AFTER INPUT.
MODULE user_command_0100.

The entries in the input fields are passed to the ABAP program in the PAI event, and assigned to the output fields in the dialog module USER_COMMAND_100. The next time the screen appears, the screen fields have been filled appropriately. The input fields are set in the PBO dialog module INT_SCREEN_100. If the user selects the screen field EXIT (value ‘X’), the program ends.

Screen fields with Dictionary reference

PROGRAM demo_dynpro_dictionary.

TABLES demo_conn.

DATA wa_spfli TYPE spfli.

CALL SCREEN 100.

MODULE init_screen_100 OUTPUT.
CLEAR demo_conn-mark.
MOVE-CORRESPONDING wa_spfli TO demo_conn.
CLEAR wa_spfli.
ENDMODULE.

MODULE user_command_0100 INPUT.

IF demo_conn-mark = 'X'.
LEAVE PROGRAM.
ENDIF.

MOVE-CORRESPONDING demo_conn TO wa_spfli.

SELECT SINGLE
cityfrom airpfrom cityto airpto fltime deptime arrtime
INTO CORRESPONDING FIELDS OF wa_spfli
FROM spfli
WHERE carrid = wa_spfli-carrid AND connid = wa_spfli-connid.

ENDMODULE.

The statically-defined next screen for screen 100 is 100. It uses components of the structure DEMO_CONN, copied from the ABAP Dictionary, and looks like this:

The structure DEMO_CONN exists in the ABAP Dictionary specially for screens that use the flight data model. It contains the components of the database table SPFLI, but also a component MARK. MARK uses the domain S_FLAG, which may only have the values SPACE and X. On the above screen, the ABAP Dictionary text for MARK has been overwritten with ‘Cancel’. For all other fields, the ABAP Dictionary texts have been retained. The input attribute of some of the fields has been switched off in the Screen Painter.

Users can enter values for the airline and flight number. Automatic field checks against check tables in the ABAP Dictionary, field help, and input help are automatically available. The field checks are performed automatically before any of the dialog modules in the ABAP program are called. Users cannot enter values for the airline that do not exist in the check table SCARR, values for the flight number that are not in SPFLI, or values for MARK other than SPACE and X. There is no need to program any of these checks in the ABAP program.

The screen flow logic is as follows:

PROCESS BEFORE OUTPUT.
MODULE init_screen_100.

PROCESS AFTER INPUT.
MODULE user_command_0100.

The module USER_COMMAND_100 in the ABAP program reads data from the database table with the key fields specified (and checked) on the screen, and sends them back to the screen in the PBO module INIT_SCREEN_100. The work area DEMO_CONN, defined using the TABLES statement, serves as an interface between the program and the screen. Meanwhile the data from the database is processed in the work area WA_SPFLI. If the user selects the screen field ‘Cancel’ (value ‘X’), the program ends.

Processing Screen

2009-06-10T19:57:00.000+05:30

There are two ways of calling a screen. You can either use a transaction code, or the CALL SCREEN statement in an ABAP program. When you call a screen, the PROCESS BEFORE OUTPUT event (PBO) is called, and the corresponding event block in the screen flow logic is processed. The screen itself is then displayed until the user triggers the PROCESS AFTER INPUT (PAI) event by choosing a function. In between, there may be field or input help processing. The corresponding event blocks in the flow logic are processed, if they exist. The main purpose of event blocks in the screen flow logic is to call dialog modules in the ABAP program and to provide the ABAP program with data.

User Actions on Screens

Calling ABAP Dialog Modules

Input Checks

Field Help, Input Help, and Dropdown Boxes

Modifying Screens Dynamically

Screens

2009-06-10T19:55:00.000+05:30

Screens are the most general type of user dialog that you can use in ABAP programs. You do not define them in ABAP programs, but instead in the Screen Painter. A screen consists of the input/output mask and the flow logic. You can define screens for any program with type 1, M, or F.

The screens in a single ABAP program can be combined to form screen sequences. You can call single screens or screen sequences either using a transaction code from outside the ABAP program, or by using the CALL SCREEN statement in the corresponding ABAP program. When you call a screen or screen sequence, the screen flow logic takes control of the ABAP program execution. You can define screen sequences dynamically by setting the next screen attribute for a screen dynamically in the ABAP program.

A screen consists of the input/output mask and the flow logic. The screen flow logic is divided into the Process Before Output (PBO) event, which is processed before the screen is displayed, and the Process After Input (PAI) event, which is processed after a user action on the screen.

The following diagram shows the place of screens between the GUI status and the ABAP program:

The screen flow logic calls dialog modules in the ABAP program, either to prepare the screen for display (PBO event) or to process the user's entries (PAI event). Screens are dynamic programs, and have their own data objects, called screen fields. These are linked to the input/output fields that appear on the screen itself. When the screen is displayed, and when it finishes processing, the system passes data between the screen fields and data objects in the ABAP program. Data is copied between identically-named fields.

Each screen has a GUI status, containing a menu bar, standard toolbar, and an application toolbar. Like screens, GUI statuses are independent components of the ABAP program. You create them in the ABAP Workbench using the Menu Painter. You assign GUI statuses to screens dynamically in your ABAP programs. Each screen is linked to the current GUI status by a special screen field into which the corresponding function code is placed whenever the user chooses a function. The screen passes the function code to the ABAP program just like any other screen field. You can then read it in the program.

ABAP User Dialogs

2009-06-10T19:54:00.000+05:30

This section describes the dialogs that you can use in ABAP to communicate with program users. It explains how to pass data between user dialogs and ABAP programs, how to define user dialogs within your programs, and how to process user input.

Currently, ABAP programs with type 1 (executable programs), M (module pools), and F (function groups) can contain their own user dialogs. In the future, it is planned to allow classes in ABAP Objects also to have screens.

Screens

Selection Screens

Lists

Switching Between Dialog Screens and List Display

Messages

Reduce the Database Load

2009-06-10T19:53:00.000+05:30

Unlike application servers and presentation servers, there is only one database server in your system. You should therefore aim to reduce the database load as much as possible. You can use the following methods:

Buffer Tables on the Application Server

You can considerably reduce the time required to access data by buffering it in the application server table buffer. Reading a single entry from table T001 can take between 8 and 600 milliseconds, while reading it from the table buffer takes 0.2 - 1 milliseconds.

Whether a table can be buffered or not depends its technical attributes in the ABAP Dictionary. There are three buffering types:

Resident buffering (100%) The first time the table is accessed, its entire contents are loaded in the table buffer.

Generic buffering In this case, you need to specify a generic key (some of the key fields) in the technical settings of the table in the ABAP Dictionary. The table contents are then divided into generic areas. When you access data with one of the generic keys, the whole generic area is loaded into the table buffer. Client-specific tables are often buffered generically by client.

Partial buffering (single entry) Only single entries are read from the database and stored in the table buffer.

When you read from buffered tables, the following happens:

An ABAP program requests data from a buffered table.

The ABAP processor interprets the Open SQL statement. If the table is defined as a buffered table in the ABAP Dictionary, the ABAP processor checks in the local buffer on the application server to see if the table (or part of it) has already been buffered.

If the table has not yet been buffered, the request is passed on to the database. If the data exists in the buffer, it is sent to the program.

The database server passes the data to the application server, which places it in the table buffer.

The data is passed to the program.

When you change a buffered table, the following happens:

The database table is changed and the buffer on the application server is updated. The database interface logs the update statement in the table DDLOG. If the system has more than one application server, the buffer on the other servers is not updated at once.

All application servers periodically read the contents of table DDLOG, and delete the corresponding contents from their buffers where necessary. The granularity depends on the buffering type. The table buffers in a distributed system are generally synchronized every 60 seconds (parameter: rsdisp/bufreftime).

Within this period, users on non-synchronized application servers will read old data. The data is not recognized as obsolete until the next buffer synchronization. The next time it is accessed, it is re-read from the database.

You should buffer the following types of tables:

Tables that are read very frequently

Tables that are changed very infrequently

Relatively small tables (few lines, few columns, or short columns)

Tables where delayed update is acceptable.

Once you have buffered a table, take care not to use any Open SQL statements that bypass the buffer.

The SELECT statement bypasses the buffer when you use any of the following:

The BYPASSING BUFFER addition in the FROM clause

The DISTINCT addition in the SELECT clause

Aggregate expressions in the SELECT clause

Joins in the FROM clause

The IS NULL condition in the WHERE clause

Subqueries in the WHERE clause

The ORDER BY clause

The GROUP BY clause

The FOR UPDATE addition

Furthermore, all Native SQL statements bypass the buffer.

Avoid Reading Data Repeatedly

If you avoid reading the same data repeatedly, you both reduce the number of database accesses and reduce the load on the database. Furthermore, a "dirty read" may occur with database tables other than Oracle. This means that the second time you read data from a database table, it may be different from the data read the first time. To ensure that the data in your program is consistent, you should read it once only and then store it in an internal table.

Sort Data in Your ABAP Programs

The ORDER BY clause in the SELECT statement is not necessarily optimized by the database system or executed with the correct index. This can result in increased runtime costs. You should only use ORDER BY if the database sort uses the same index with which the table is read. To find out which index the system uses, use SQL Trace in the ABAP Workbench Performance Trace. If the indexes are not the same, it is more efficient to read the data into an internal table or extract and sort it in the ABAP program using the SORT statement.

Use Logical Databases

SAP supplies logical databases for all applications. A logical database is an ABAP program that decouples Open SQL statements from application programs. They are optimized for the best possible database performance. However, it is important that you use the right logical database. The hierarchy of the data you want to read must reflect the structure of the logical database, otherwise, they can have a negative effect on performance. For example, if you want to read data from a table right at the bottom of the hierarchy of the logical database, it has to read at least the key fields of all tables above it in the hierarchy. In this case, it is more efficient to use a SELECT statement.

Minimize the Search Overhead

2009-06-10T19:52:00.002+05:30

You minimize the size of the result set by using the WHERE and HAVING clauses. To increase the efficiency of these clauses, you should formulate them to fit with the database table indexes.

Database Indexes

Indexes speed up data selection from the database. They consist of selected fields of a table, of which a copy is then made in sorted order. If you specify the index fields correctly in a condition in the WHERE or HAVING clause, the system only searches part of the index (index range scan).

The primary index is always created automatically in the R/3 System. It consists of the primary key fields of the database table. This means that for each combination of fields in the index, there is a maximum of one line in the table. This kind of index is also known as UNIQUE.

If you cannot use the primary index to determine the result set because, for example, none of the primary index fields occur in the WHERE or HAVING clause, the system searches through the entire table (full table scan). For this case, you can create secondary indexes, which can restrict the number of table entries searched to form the result set.

You specify the fields of secondary indexes using the ABAP Dictionary. You can also determine whether the index is unique or not. However, you should not create secondary indexes to cover all possible combinations of fields.

Only create one if you select data by fields that are not contained in another index, and the performance is very poor. Furthermore, you should only create secondary indexes for database tables from which you mainly read, since indexes have to be updated each time the database table is changed. As a rule, secondary indexes should not contain more than four fields, and you should not have more than five indexes for a single database table.

If a table has more than five indexes, you run the risk of the optimizer choosing the wrong one for a particular operation. For this reason, you should avoid indexes with overlapping contents.

Secondary indexes should contain columns that you use frequently in a selection, and that are as highly selective as possible. The fewer table entries that can be selected by a certain column, the higher that column’s selectivity. Place the most selective fields at the beginning of the index. Your secondary index should be so selective that each index entry corresponds to at most five percent of the table entries. If this is not the case, it is not worth creating the index. You should also avoid creating indexes for fields that are not always filled, where their value is initial for most entries in the table.

If all of the columns in the SELECT clause are contained in the index, the system does not have to search the actual table data after reading from the index. If you have a SELECT clause with very few columns, you can improve performance dramatically by including these columns in a secondary index.

Formulating Conditions for Indexes

You should bear in mind the following when formulating conditions for the WHERE and HAVING clauses so that the system can use a database index and does not have to use a full table scan.

Check for Equality and Link Using AND

The database index search is particularly efficient if you check all index fields for equality (= or EQ) and link the expressions using AND.

Use Positive Conditions

The database system only supports queries that describe the result in positive terms, for example, EQ or LIKE. It does not support negative expressions like NE or NOT LIKE.

If possible, avoid using the NOT operator in the WHERE clause, because it is not supported by database indexes; invert the logical expression instead.

Using OR

The optimizer usually stops working when an OR expression occurs in the condition. This means that the columns checked using OR are not included in the index search. An exception to this are OR expressions at the outside of conditions. You should try to reformulate conditions that apply OR expressions to columns relevant to the index, for example, into an IN condition.

Using Part of the Index

If you construct an index from several columns, the system can still use it even if you only specify a few of the columns in a condition. However, in this case, the sequence of the columns in the index is important. A column can only be used in the index search if all of the columns before it in the index definition have also been specified in the condition.

Checking for Null Values

The IS NULL condition can cause problems with indexes. Some database systems do not store null values in the index structure. Consequently, this field cannot be used in the index.

Avoid Complex Conditions

Avoid complex conditions, since the statements have to be broken down into their individual components by the database system.

Minimize the Number of Data Transfers

2009-06-10T19:52:00.001+05:30

In every Open SQL statement, data is transferred between the application server and the database system. Furthermore, the database system has to construct or reopen the appropriate administration data for each database access. You can therefore minimize the load on the network and the database system by minimizing the number of times you access the database.

Multiple Operations Instead of Single Operations

When you change data using INSERT, UPDATE, and DELETE, use internal tables instead of single entries. If you read data using SELECT, it is worth using multiple operations if you want to process the data more than once, other wise, a simple select loop is more efficient.

Avoid Repeated Access

As a rule you should read a given set of data once only in your program, and using a single access. Avoid accessing the same data more than once (for example, SELECT before an UPDATE).

Avoid Nested SELECT Loops

A simple SELECT loop is a single database access whose result is passed to the ABAP program line by line. Nested SELECT loops mean that the number of accesses in the inner loop is multiplied by the number of accesses in the outer loop. You should therefore only use nested SELECT loops if the selection in the outer loop contains very few lines.

However, using combinations of data from different database tables is more the rule than the exception in the relational data model. You can use the following techniques to avoid nested SELECT statements:

ABAP Dictionary Views

You can define joins between database tables statically and systemwide as views in the ABAP Dictionary. ABAP Dictionary views can be used by all ABAP programs. One of their advantages is that fields that are common to both tables (join fields) are only transferred once from the database to the application server.

Views in the ABAP Dictionary are implemented as inner joins. If the inner table contains no lines that correspond to lines in the outer table, no data is transferred. This is not always the desired result. For example, when you read data from a text table, you want to include lines in the selection even if the corresponding text does not exist in the required language. If you want to include all of the data from the outer table, you can program a left outer join in ABAP.

The links between the tables in the view are created and optimized by the database system. Like database tables, you can buffer views on the application server. The same buffering rules apply to views as to tables. In other words, it is most appropriate for views that you use mostly to read data. This reduces the network load and the amount of physical I/O in the database.

Joins in the FROM Clause

You can read data from more than one database table in a single SELECT statement by using inner or left outer joins in the FROM clause.

The disadvantage of using joins is that redundant data is read from the hierarchically-superior table if there is a 1:N relationship between the outer and inner tables. This can considerably increase the amount of data transferred from the database to the application server. Therefore, when you program a join, you should ensure that the SELECT clause contains a list of only the columns that you really need. Furthermore, joins bypass the table buffer and read directly from the database. For this reason, you should use an ABAP Dictionary view instead of a join if you only want to read the data.

The runtime of a join statement is heavily dependent on the database optimizer, especially when it contains more than two database tables. However, joins are nearly always quicker than using nested SELECT statements.

Subqueries in the WHERE and HAVING Clauses

Another way of accessing more than one database table in the same Open SQL statement is to use subqueries in the WHERE or HAVING clause. The data from a subquery is not transferred to the application server. Instead, it is used to evaluate conditions in the database system. This is a simple and effective way of programming complex database operations.

Using Internal Tables

It is also possible to avoid nested SELECT loops by placing the selection from the outer loop in an internal table and then running the inner selection once only using the FOR ALL ENTRIES addition. This technique stems from the time before joins were allowed in the FROM clause. On the other hand, it does prevent redundant data from being transferred from the database.

Using a Cursor to Read Data

A further method is to decouple the INTO clause from the SELECT statement by opening a cursor using OPEN CURSOR and reading data line by line using FETCH NEXT CURSOR. You must open a new cursor for each nested loop. In this case, you must ensure yourself that the correct lines are read from the database tables in the correct order. This usually requires a foreign key relationship between the database tables, and that they are sorted by the foreign key.

Minimize the Amount of Data Transferred

2009-06-10T19:51:00.000+05:30

Data is transferred between the database system and the application server in blocks. Each block is up to 32 KB in size (the precise size depends on your network communication hardware). Administration information is transported in the blocks as well as the data.

To minimize the network load, you should transfer as few blocks as possible. Open SQL allows you to do this as follows:

Restrict the Number of Lines

If you only want to read a certain number of lines in a SELECT statement, use the UP TO ROWS addition in the FROM clause. This tells the database system only to transfer lines back to the application server. This is more efficient than transferring more lines than necessary back to the application server and then discarding them in your ABAP program.

If you expect your WHERE clause to return a large number of duplicate entries, you can use the DISTINCT addition in the SELECT clause.

Restrict the Number of Columns

You should only read the columns from a database table that you actually need in the program. To do this, list the columns in the SELECT clause. Note here that the INTO CORRESPONDING FIELDS addition in the INTO clause is only efficient with large volumes of data, otherwise the runtime required to compare the names is too great. For small amounts of data, use a list of variables in the INTO clause.

Do not use * to select all columns unless you really need them. However, if you list individual columns, you may have to adjust the program if the structure of the database table is changed in the ABAP Dictionary. If you specify the database table dynamically, you must always read all of its columns.

Use Aggregate Functions

If you only want to use data for calculations, it is often more efficient to use the aggregate functions of the SELECT clause than to read the individual entries from the database and perform the calculations in the ABAP program.

Aggregate functions allow you to find out the number of values and find the sum, average, minimum, and maximum values. Following an aggregate expression, only its result is transferred from the database.

Data Transfer when Changing Table Lines

When you use the UPDATE statement to change lines in the table, you should use the WHERE clause to specify the relevant lines, and then SET statements to change only the required columns.

When you use a work area to overwrite table lines, too much data is often transferred. Furthermore, this method requires an extra SELECT statement to fill the work area.