LESSON 5 DATA BASE DIALOG

LESSON 5 DATA BASE DIALOG

Database tables are administered in the ABAP Dictionary. There you can find current information about a database table's technical attributes. Database tables that have been created in the database using the same line type and name are called transparent tables in the ABAP Dictionary.There are a couple of different ways in which you can navigate to transparent tables in the ABAP Dictionary:

Choose Tools->ABAP Workbench->Development->Dictionary to call the ABAP Dictionary directly and insert the name of the transparent table in the appropriate input field, or

Navigate directly to the ABAP Dictionary from the ABAP Editor while editing the program: This can be done by double -clicking on the name of the transparent table in the FROM clause of the SELECT statement.

You can search for database tables in several different ways:

Application hierarchy and the Repository Information System: You may choose application components from the application hierarchy and branch directly to the information system. There you can search for database tables according to their short texts (among other criteria).

If you have the name of a program that accesses the database table:

Input field on a screen; If you know of a program that contains a screen with input fields connected to the table you are looking for, choose F1->Technical info. and then navigate to to the ABAP Dictionary by double -clicking on the technical name of the screen field. This is often a field in a structure. Double -click on the data element and then use the where-used list function to search for transparent tables according to the field type.

Debugger: If you know the name of a program that accesses the database table that you are looking for, you can start this program in debugging mode and set a breakpoint at the SELECT statement.

Editor: Look for the SELECT statement

Object List in the Object Navigator: Pick out the subroutines that encapsulate the database accesses.

If you know of a structure field in the ABAP Dictionary.

Double-click on the data element and then use the where -used list function to search for transparent tables according to the field type.

As soon as you navigate to the definition of a database table in the ABAP Dictionary, information about all of the table's technical attributes is available.

The following information is of interest for enhancing the performance of database accesses:

Key Fields: If the lines requested from the database are being retrieved according to key fields, the Database Optimizer can perform access using a primary index. Checkboxes are on for all key fields.

Secondary Indexes: You may also use secondary indexes to select specific lines. These are displayed in a dialog box whenever you choose the 'Indexes' pushbutton. You can choose an index from the dialog box by simply double -clicking on it. The system then displays a screen with additional information about that index.

You use the Open SQL statement SELECT to read data from the database.

Underlying the SELECT statement is a complex logic that allows you to access many different types of database table.

The statement contains a series of clauses, each of which has a different task:

The SELECT clause specifies

Whether the result of the selection is to be a single line or several lines.

The fields that should be included in the result.

Whether the result may contain two or more identical lines.

The INTO clause specifies the internal data object in the program into which you want to place the selected data.

The FROM clause specifies the source of the data (database table or view).

The WHERE clause specifies conditions that selection results must fulfill. Thus, it actually

determines what lines are included in the results table.

For information about other clauses, refer to the keyword documentation in the ABAP Editor

for the SELECT statement.

Open SQL statements are a subset of Standard SQL that is fully integrated in the ABAP language.

They allow you to access the database in a uniform way from your programs, regardless of the database system being used. Open SQL statements are converted into database-specific SQL statements by the database interface .

The SELECT SINGLE* statement allows you to read a single line from a database table. To ensure that you read a unique entry, all of the key fields must be filled by the WHERE clause. The informs the database interface that all columns in that line of the database table should be read. If only a specific cross-section of columns is desired, a structure can be inserted instead.

The name of a structure to which you want the database interface to copy a data record is inserted after the INTO clause. The structure should have a structure identical to the columns of the database table being read and be left-justified.

If you use the CORRESPONDING FIELDS OF addition in the INTO clause, you can fill the target work area component by component. The system only fills those components that have identical names to columns in the database table. If you do not use this addition, the system fills the work area from the left-hand end without any regard for its structure.

If the system finds a table entry matching your conditions, SY-SUBRC has the value 0.

The SINGLE addition tells the database that only one line needs to be read. The database can then terminate the search as soon as it has found that line. Therefore, SELECT SINGLE produces better performance for single -record access than a SELECT loop if you supply values for all key fields.

If you do not use the addition SINGLE with the SELECT statement, the system reads multiple records from the database. The field list determines the columns whose data is to be read from the database.

The number of lines to be read can be restricted using the WHERE clause. The restrictions contained in the WHERE clause should either be made according to the database table's key fields or according to a secondary index. Further information about key fields and secondary indexes can be found in the ABAP Dictionary. For example, double -clicking on the database table included in the FROM clause will take you directly to the Dictionary.

You may only enter the names of the database table fields you want to be read in the WHERE clause.

Multiple logical conditions can be added to the WHERE clause using AND or OR.

The database delivers data to the database interface in packages. The ABAP runtime system copies the data records to the target area line by line using a loop. It also provides for the sequential processing of all of the statements between SELECT and ENDSELECT.

SY-SUBRC = 0 if the system was able to select at least one entry. After the SELECT statement is executed in each loop pass, the system field SY-DBCNT contains the number of lines read. After the ENDSELECT statement, it contains the total number of lines read.

The addition INTO TABLE causes the ABAP runtime system to copy the contents of the database interface directly to the internal table itab. This is called an array fetch.

Since an array fetch is not logically a loop, no ENDSELECT statement is used.

SY-SUBRC = 0 if the system was able to read at least one table entry.

For further information about array fetch and internal tables, refer to the Internal Tables unit of this course.

The program must contain a data object with a suitable type for each column that is required from a database table. For reasons of program maintenance, you must use the corresponding Dictionary objects to assign types to the data objects. The INTO clause specifies the data object into which you want to place the data from the database table. There are two different ways to do this:

Flat structure: You define a structure in your program that has the fields in the same sequence as the field list in the SELECT clause. Then you enter the structure name in the INTO clause. The contents are copied by position. The structure field names are disregarded.

Single data objects: You enter a set of data objects in the INTO clause.

If you use the INTO CORRESPONDING FIELDS clause, the data is placed in the structure fields that have the same name.

Advantages of this construction:

The structure does not have to be structured in the same way as the field list and does not need to be left-justified

This construction is easy to maintain, since extending the field list does not require other changes to be made to the program, as long as there is a field in the structure that has the same name and type.

Disadvantages of this construction:

INTO CORRESPONDING FIELDS is more runtime-intensive than INTO. The runtime may therefore be longer.

If you want to place data into internal table columns of the same name using an array fetch, use INTO CORRESPONDING FIELDS OF TABLE .

The SAP authorization concept recognizes a large number of different authorizations. These are all managed centrally in the user master record for every user.

Authorizations are not directly assigned to users, but stored in work center descriptions (profiles).

These profiles are generated using the Profile Generator, which administers the profiles as activity groups.

Users can belong to one or more activity groups and are then assigned the authorizations contained in those activity groups.

Release 4.6 contains a large number of pre-defined activity groups. You can use these as is or copy and tailor them to your specific needs.

You should carry out an authorization check before accessing the database. The AUTHORITYCHECK statement first checks whether the user has the authorization containing all the required values. You then check the code value in the system field SY-SUBRC. If this value is 0, the user has the required authorization and the program can continue. If the value is not 0, the user does not possess the required authorization and you should display a message and take the appropriate action.

All data in the SAP system must be protected from unauthorized access by users who do not explicitly have permission to access it.

The system administrator assigns user authorization when maintaining user master data. During this process, you should determine exactly which data users are allowed to access and what kind of access should be allowed.

This is carried out by an authorization object composed of the fields 'Activity' and 'Airline carrier' that has to be addressed both during the authorization assignment process and whenever your program performs an authorization check.

Authorization objects simply define the combination of fields that need to be addressed

simultaneously and serve as templates for both authorizations and authorization checks. They are organized into object classes in order to make it easier to find and administer them; one object class or several may exist in each application. You call the authorization object maintenance transaction from the 'Development' menu in the ABAP Workbench. A complete list of all development objects, sorted according to class and including their corresponding fields and documentation, is part of this transaction.

When making authorization checks in programs, you specify the object and values the user needs in an authorization to be able to access the object. You do not have to specify the name of the authorization.

Important: The Authority-Check statement performs the authority check and returns an appropriate return code value in SY-SUBRC. When checking this return code, you can specify the consequences of a missing authorization (for example: terminate the program or display a message and skip some lines of code).

You must specify all fields of the object in an AUTHORITY-CHECK, otherwise you receive a return code not equal to zero. If you do not want to carry out a check for a particular field, enter DUMMY after the field name.

The most important return codes for AUTHORITY-CHECK are:

0: The user has an authorization containing the required values.

4: The user does not have the required authorization.

8: The check could not successfully be carried out since not all fields of the object were

specified.

The keyword documentation for AUTHORITY-CHECK contains a complete list of return codes.

You can only specify a single field after the FIELD addition, not a selection table. There are function modules which carry out the AUTHORITY-CHECK for all values in the selection table.

If reusable components that encapsulate complex data retrieval are available , then you must use them. There are four techniques available for doing this.

Methods of global classes

Methods of business objects

Function modules

Logical databases are data retrieval programs delivered by SAP that return data in a hierarchically logical sequence.

You can find information on the various techniques in the Reuse Components unit.

Views are application-specific views of different ABAP Dictionary tables. Views can contain a selection of fields from a single very large table or fields from several different tables.

Views allow you to gather information from the fields of different tables and present it to users in the form they require when working with the R/3 System.

Views are mainly used for programming with ABAP and for F4 online help.

If there are no components available that are suitable for your purposes, you can carry out complex database access using ABAP-OPEN- SQL statements. To do this you have to compare the merits of various techniques, as using an unsuitable technique can result in considerable performance problems.

LESSON 4 ABAP DATA OBJECTS AND STATEMENTS

ABAP DATA OBJECTS AND STATEMENTS

ypes describe the attributes of

1. Input and output fields on screens,
2. Data objects and

Interface parameters: Type checks are performed each time a function or subroutine is called according to how the interface parameter is typed. Type conflicts are already identified during the editing process and appropriate syntax errors displayed.

Local types are used in programs

1. If only technical attributes are needed and no semantic attributes are required, and
2. If the types are only used locally within a program.

Global types ( = ABAP Dictionary types) are used

If you intend to use the types externally

(for example, for typing the interface parameters of global functions or with those data objects in the program that serve as the interface to the database or the presentation server), If you need semantic information as well (for example, on screens with input and output fields).

More information on storing semantic information centrally can be found in this unit.

Elementary Dictionary types are called Data Elements. They contain semantic as well as technical information (technical type, length, number of decimal places).

A data element can contain the following semantic information:

Field Label: This text appears on screens and selection screens to the left next to the input or output fields. A field label can have one of three possible lengths. You must select one of the different field labels when you create a screen.

Field Documentation: The field documentation tells the user what information should be entered in the field. The user gets the field documentation for an input or output field where the cursor is positioned by pressing function key F1.

Search Help: A data element can be linked to a search help. This search help defines the value help provided by function key F4 or the corresponding icon.

You can find more information on elementary ABAP Dictionary types

for screen fields : Using F1 -> Technical info. or by double-clicking on the output field next to the data element label

for local types in programs or data objects : By double-clicking on the type

Technical types and technical domains may be directly assigned to data elements. If you want more information on other data elements referencing the same domain, you can navigate to the domain from the data element by double -clicking on its name and then executing the function Where-used list.

You can search for data elements by using the application hierarchy and the Repository Information System.

In the application hierarchy, select the components to be scanned.

Go to the Information System.

Choose ABAP Dictionary --> Basic objects --> Data elements and restrict the search.

If you go to the Information System from the application hierarchy, the development classes of the selected application components are automatically entered.

You can also go directly to the Information System. If you do not select a development class, the entire Repository is scanned.When defining simple types or variables, you can refer to a pre-defined type. For more information refer to the keyword documentation on TYPES or DATA.

1. C Character
2. N Numeric Text
3. D Date (YYYYMMDD)
4. T Time (HHMMSS)
5. X Byte (heXadecimal)
6. I Integer
7. P Packed Number
8. F Floating Point Number
9. STRING Character String
10. XSTRING String of Bytes (X String)

Assign data object types by referring your object to either a built-in ABAP type, a user defined type or an ABAP Dictionary object.

If a variable v2 refers to variable v1 using the addition LIKE ( DATA v2 LIKE v1. ), then v2 inherits its type from v1.Up to Release 4.0B, you could only refer to Dictionary types using LIKE. Only structure fields could be used as elementary types up to that point. Only flat structures were provided as structure types.Elementary data objects appear in the program object list under the 'Fields' node.From the object list, you can use the right mouse button to navigate to the part of the source code where the data object is defined.You can use the Where-used list function to display all lines of source code where the data object is used.

Rules for naming data objects:

A name can consist of 30 characters maximum (letters, numbers, or symbols).

The following symbols ARE NOT allowed: ( ) + . , :

SPACE is a predefined field.

For compatibility reasons, it is still possible to construct data objects in the DATA statement without first having to define the type locally in the program with a TYPES statement. Default values are also defined in addition to the type information for the following generic types:

With data types P,N,C, and X you may enter a length (in bytes) in parentheses after the type name.If no length is entered, the default length for this data type is used. You can find the standard lengths in the keyword documentation for TYPES and DATA.

With data type P you can use the DECIMALS addition to determine the number of decimal places that should be used (up to a maximum of 14). If this addition is missing, the number of decimal places is set to zero.If no type is entered, then the field is automatically a type C field.

You define constants using the ABAP keyword CONSTANTS. The VALUE addition is required for constants. It defines their value.ABAP recognizes two types of literals: number literals and text literals. The latter is always enclosed in inverted commas (').Whole numbers (with preceding minus sign if they are negative) are stored as number literals with either type I (up to and including nine digits) or type P (ten or more digits).

All other literals (character, numbers with decimal places, floating point numbers) are stored as text literals wit h data type C. If a literal is assigned to a variable that does not have type C, then a type conversion is carried out. The conversion rules are described in the keyword documentation about MOVE.If you want to include an inverted comma (') in a text literal, you must enter it twice.

You can create translatable text literals, or text symbols, for all ABAP programs. Use the Program object types dialog box to get to the maintenance screen for the text symbols.

When a program is started, the program context is loaded into a storage area of the application server and made available for all the data objects.Each elementary field comes as standard with an initial value appropriate to its type. You can set a start value for an elementary field yourself using the VALUE addition. After VALUE you may only specify a fixed data object.You can copy the field contents of a data object to another data object with the MOVE statement. If the two data objects have different types, the type is automatically converted if there is a conversion rule. If you want to copy the field contents of variable var1 to a second variable var2, you can choose one of two syntax variants:

. MOVE var1 TO var2.

. var2 = var1.

The CLEAR statement resets the field contents of a variable to the initial value for the particular type.You can precede calculations with the COMPUTE statement. This statement is optional. You can use either of the following two syntax variants to calculate percentage occupancy using the variable v_occupancy for 'current occupancy'‚ v_maximum for 'maximum occupancy'‚ and v_percentage for 'percentage occupancy':

. COMPUTE v_percentage = v_occupancy * 100 / v_maximum.

. v_percentage = v_occupancy * 100 / v_maximum.

You can find detailed information on the operations and functions available in the keyword documentation on COMPUTE.IF and CASE statements allow you to make case distinctions:

CASE ... ENDCASE:

. Only one of the sequences of statements is executed.

. The WHEN OTHERS statement is optional.

IF ... ENDIF:

. The logical expressions that are supported are described in the keyword documentation about IF.The ELSE and ELSEIF statements are optional.If the logical expression is fulfilled, the following sequence of statements is executed.If the logical expression is not fulfilled, the ELSE or ELSEIF section is processed. If there is no ELSE or no further ELSEIF statement, the program continues after the ENDIF statement.You can include any number of ELSEIF statements between IF and ENDIF. A maximum of one of the sequences of statements will be executed.You can trace the field contents of up to eight data objects in debugging mode by entering the field names on the left side or by creating the entry by double -clicking on a field name.You can change field values at runtime by overwriting the current value and choosing the 'Change' icon.

From Release 4.6, you are allowed to set up to 10 watchpoints and link them using the logical operators AND and OR. Watchpoints are breakpoints that are field-dependent. You can create the following types of watchpoints:

Variable value: The system stops processing once the logical condition is fulfilled. The 'Comparison field' flag is not selected and the value is inserted at 'Comp. field/value'.

Variable1 variable2: The system stops processing once the logical condition is fulfilled. The 'Comparison field' flag is selected and variable2 is inserted at 'Comp. field/value'.

Variable: The system stops processing each time the variable's value changes.

You can define structured data objects (also called structures) in ABAP. This allows you to combine variables that belong together into one object. Structures can be nested. This means that other structures or even tables can be sub-objects of your original structure.

There are two different kinds of structures in ABAP programs:

. Structures defined using DATA TYPE .

These kinds of structures serve as the target fields for database accesses or for calculations performed locally within the program. You can declare these types of structures either in the ABAP Dictionary or locally within your program. For more information on how to declare local structures, refer to the keyword documentation on TYPES.

Structures defined using TABLES .

These types of structures are technically administered in their own area. From Release 4.0,TABLES structures only need to be used as interface structures for screens.

Fields of a structure are always addressed with -.

The MOVE-CORRESPONDING TO statements transports values field by field between structures and . This only works if the components have identical names.The system looks for all fields in whose names also occur in and transports field - to - in all cases where it finds a match.All other fields remain unchanged.

You can trace the field contents of a structure by entering the name of the structure in the left column. The field view of the structure is displayed if you double -click on this entry.You must define the following information in order to fully specify a table type:

Line Type: You can store the information about the required columns, their names and types, by defining a structure type as line type.

Key: A fully specified key must define: Which columns should be key columns? In what order?

Should the key uniquely specify a record of the internal table (unique key)? Unique keys cannot be defined for all the table types.

Table Kind: There are three table kinds: standard tables, sorted tables and hashed tables. The estimated access type is mainly used to choose the table type.

Access type defines how ABAP accesses individual table entries. There are two different types of data access in ABAP, access using the index and access using a key.

Access using the index involves using the data record index that the system maintains to access data.

Example : Read access to a data record with index 5 delivers the fifth data record of your internal table (Access quantity: one single data record).

Access using a key involves using a search term, usually either the table key or the generic table key, to access data.Another internal table attribute is the table type. Internal tables can be divided into three table types according to the way they access data:

Standard tables maintain a linear index internally. This kind of table can be accessed using either the table index or keys.

Sorted tables are sorted according to key and saved. Here too, a linear index is maintained internally. This kind of table can also be accessed using either the table index or keys.

Hashed tables do not maintain a linear index internally. Hashed tables can only be accessed using keys.

Which table type you use depends on how that table's entries are normally going to be accessed. Use standard tables when entries will normally be accessed using the index, use a sorted table when entries will normally be made using keys, and use hashed tables when entries will exclusively be made with keys.

Table types can be defined locally in a program or centrally in the ABAP Dictionary.To define a table -type data object or an internal table, specify the type as a global table type or a local table type.

You can perform the following operations on single records in internal tables:

. APPEND appends the contents of a structure having the same type as the line to an internal table.

This operation can only be used with standard tables.

. INSERT inserts the contents of a structure having the same type as the line in an internal table.

This causes a standard table to be appended and a sorted table to be inserted in the right place; a hashed table is inserted according to the hashing algorithm.READ copies the contents of a line of the internal table to a structure having the same type as the line.

. MODIFY overwrites a line of the internal table with the contents of a structure having the same type as the line.

. DELETE deletes a line of the internal table.

. COLLECT inserts the contents of a structure having the same type as the line in an internal table into an internal table in compressed form.. This statement may only be used for tables whose non key fields are all numeric. The numeric values are added for identical keys.

n You can find detailed information about the ABAP statements described here in the keyword documentation for the relevant ABAP keywords.

n You can perform the following operations on sets of records in internal tables:

. LOOP ... ENDLOOP The LOOP places the lines of the internal table in the structure

specified in the INTO clause one-by-one. The structure must have the same type as the line of the internal table. All single -record operations can be executed within the loop. In this case the system provides the information about the line to be edited in the single -record operation.

. DELETE deletes the lines of the internal table that satisfy the condition .

. INSERT copies the contents of several lines of an internal table to another internal table.

. APPEND appends the contents of several lines of an internal table to another standard

table.

n You can find detailed information about the ABAP statements described here in the keyword documentation for the relevant ABAP keywords.

n You can perform the following operations on internal tables:

. SORT You can sort tables by any column or columns in ascending or descending order

Sorted tables cannot be resorted.

. CLEAR Sets the contents of the internal table to the right initial value for the column type.

. REFRESH works like CLEAR.

. FREE Deletes the internal table and releases the memory allocated to the table.

n You can add lines to a standard ta ble by first filling a structure with the required values and then appending it to the internal table with the APPEND statement. This statement is only meaningful with standard tables.

n Use the INSERT statement to insert lines in sorted and hashed tables.

n INSERT works like an APPEND in standard tables.

n You can read and edit the contents of an internal table with a LOOP statement. In this example, one line is copied each time from internal table it_flightinfo to structure wa_flightinfo. The fields of the structure can then be edited. A list is built here from the fields with a WRITE statement.

n If you want to change the contents of the internal table, first change the value of the structure fields within the loop and then overwrite the line of the internal table with the MODIFY statement.

n With the INDEX addition you can restric t access to certain line numbers. You may only perform index operations on index tables. Both standard and sorted tables are supported here.

n The above example shows the syntax for loop editing that only scans the first five lines of the internal table.

n The example below shows the syntax for reading the third line of the internal table.

n With the WHERE addition you can restrict access to lines with certain values in key fie lds. Key operations are supported for all table types. Key access to sorted or hashed tables is more efficient than key access to standard tables.

n The above example shows the syntax for loop editing that only scans the lines of the internal table whose 'carrid' field has the value 'LH'. The sorted table is most suitable for this type of editing. Loop editing with the WHERE addition is supported for sorted and standard tables.

n The example below shows the syntax for reading a line of the internal table with a fully specified key. The return code sy-subrc is set to zero if the internal table contains this line. The hashed table is most suitable for single -record access by key. This type of access is supported for all table types.

Note that all the key fields must be defined in key accesses with the WITH TABLE KEY addition. It is easy to confuse this addition with the WITH KEY addition, which already permitted key access to standard tables prior to Release 4.0, when it was not yet possible to define key columns explicitly.

n You can trace the contents of an internal table in debugging mode by choosing 'Table' and entering the name of the internal table.

n Internal tables can be defined with or without a header line. An internal table with header line consists of a work area (the header line) and the actual body of table, both of which are addressed with the same name. How this name is interpreted depends on the context in which it is used. For example: at MOVE the name is interpreted to mean the header line, while at SORT it is interpreted as the table body.

n You can declare an internal table with a header line using the addition WITH HEADER LINE.

n In order to avoid confusion, it is recommended that you create internal tables without header lines.

However, in internal tables with header lines you can often use a shortened syntax for certain

operations.

n A number of ABAP statements support a return code. Various exceptions are detected, depending on the statement. If such an exception occurs, a value is stored in field sy-subrc and the function for the statement is terminated. The keyword documentation for the particular statement describes the exceptions that are supported and their values. When you start a program, a structure named sy is automatically provided as data object. This structure contains various fields that are filled by the system.. You can access these fields from the program. One of the fields of this structure is field subrc. You therefore do not have to create a data object for the return code.

n In this example a line should be read from internal table itab with key access. There is no line with the required key at runtime. The Basis function for the READ statement is therefore terminated and the value 4 is placed in field sy-subrc. Field sy-subrc is queried in the program immediately after the READ statement.

n There is a special dialog type called the user message for error situations. Messages are triggered with the MESSAGE statement.

n Messages can be found in table T100. They are organized according to language, a two-digit ID, and a three-digit number.

n Messages can contain up to 4 variables, identified as &1, &2, &3, and &4. If you want to output the character & and do not want to use it as a variable, double it, for example: 'This is a message with an &&'.

n In message long texts use &v1&, &v2&, &v3&, and &v4& for their corresponding variable.

n You can create your own messages using ID numbers that begin with Y (for the head office) or Z (for branch offices).

n Send messages with the MESSAGE statement. The language for messages in table T100 is automatically set to the user's logon language. You can define the message ID following the parameter MESSAGE-ID in the REPORT statement. The message ID is now set for the entire report.

Enter the message number at the MESSAGE statement.

n Enter the message type directly in front of the three-digit message number; this letter determines how the report user reacts to dialog messages (see next slide).

n Set values for variables (up to a maximum of four) following the parameter WITH. Fields and literals are also allowed. The field at level i thus replaces message variable &i. If the variables in the message are identified with & or $, these placeholders are supplied with values independent of the position of the fields of the message statement.

n In addition to using message ID with the REPORT statement, you can also add a different message ID to the command MESSAGE by entering the ID in parenthesis directly after the message number.

This deviant message ID is only valid for a single message, however. Example: MESSAGE

E004(UD).

n Use the following syntax, whenever you want to send a dynamic message: MESSAGE ID

TYPE NUMBER WITH .

n System fields SY-MSGID, SY-MSGTY and SY-MSGNO are supplied with the message ID, message type, and message number respectively and system fields SY-MSGV1 to SY-MSGV4 with the fields for the placeholders.

n There are six different types of message: A, X, E, I, S or W. The runtime behavior of the messages depends on the context. The letters have the following meaning:

A Termination Processing is terminated, the user must restart the transaction

X Exit Like a termination message, but with short dump

MESSAGE_TYPE_X E Error Runtime behavior depends on context

W Warning Runtime behavior depends on context

I Information Processing is interrupted, the message is displayed in a dialog

box and the program is continued when the message has been confirmed

with ENTER.

S Set The message appears in the status bar on the next screen.

n You can find a program for testing the runtime behavior in the sample programs of the

documentation. You can find the sample programs with transaction code ABAPDOCU or in the Editor with the ‘Information’ icon and radio button ABAP Docu and Examples.

 

 

LESSON 3 ABAP WORK BENCH AND TOOLS

ABAP WORK BENCH CONCEPTS AND TOOLS

The R/3 System has a modular software architecture that follows software -oriented client/server principles.The R/3 System allocates presentation, applications, and data storage to different computers. This serves as the basis for the scalability of the R/3 system.

The lowest level is the database level. Here data is managed with the help of a relational database management system (RDBMS). In addition to master data and transaction data, programs and the metadata that describe the R/3 System are stored and managed here.

ABAP programs run at the application level, both the applications provided by SAP and the ones you develop yourself. ABAP programs work with data called up from the database level and store new data there as well.

The third level is the presentation level (SAPGUI). This level contains the user interface, in which an end user can access an application, enter new data and receive the results of a work process.

The technical distribution of software is independent of its physical location on the hardware.

Vertically, all levels can be installed on top of each other on one computer or each level on a separate computer. Horizontally, application and presentation level components can be divided among any number of computers. The horizontal distribution of database components, however, depends on the type of database installed.

ABAP programs are processed on the application server. The design of the user dialogs and the database dialogs is therefore of particular importance when writing application programs.

Bla Box

The user is primarily interested in how his or her business transaction flows and in how data can be input into and displayed from the transaction. Technical details, such as whether a single program is running or multiple programs are called implicitly, or the technical differences between the kind of screens being displayed, are usually less important to the user. The user does not need to know the precise flow of the ABAP program on the application server. Users see the R/3 System with application servers and database as a black box.

There are, however, three technically distinct screen types (screens, selection screens, and lists) that offer the user different services. It is the developer's job to determine which type of user dialog is most suitable to the user's needs.

When the user performs a user action (choosing Enter, a function key, a menu function or a pushbutton, for example), control is handed over from the presentation server to the application server and certain parts of the ABAP program are processed. If further user dialog is triggered within the ABAP program, the system sends a screen to the presentation server and control is once again handed over to the presentation server.

In this part of the unit, the user has chosen to start a program where an airline ID can be entered on the initial selection screen. The program subsequently uses this information to retrieve the 'Long name of airline' and the 'Local currency of airline' from the database and display them for the user in list form.

Whenever a user logs on to the system, a screen is displayed. From this screen, the user can start a program by using its menu path.

If the user has triggered a program with a user action, then the program context is loaded on the application server. The program context contains memory areas for variables and complex data objects, information on the screens for user dialogs and ABAP processing blocks. The runtime system gets the program information from the Repository, which is a special part of the database.

The sample program has a selection screen as the user dialog, a variable and a structure as data objects and one ABAP processing block. The list that is used to display the data is created dynamically at runtime.

The subsequent flow of the program is controlled by the ABAP runtime system.

Since the program contains a selection screen, the ABAP runtime system sends it to the presentation server at the beginning of program processing. The presentation server controls the program flow for as long as the user fills in the input fields.

Selection screens allow users to enter selection criteria required by the program.

As soon as the user has finished entering data on the selection screen, he or she can trigger further processing by choosing 'Execute'. All data input on the selection screen is the automatically placed in its corresponding data object in the program and the ABAP runtime system resumes control of processing. Our sample program contains only one ABAP processing block. The runtime system triggers sequential processing of this ABAP processing block.

If the entries made by the user do not have the correct type, then an error message is automatically triggered. The user must correct his/her entries.

The ABAP processing block contains a read access to the database that has been programmed into it.

The program also passes the database information about which database table to access and which line in the table to read.

The database returns the requested data record to the program and the runtime system ensures that this data is stored in the appropriate data objects. Normally a structure is the target field when a single record is accessed. The structure contains variables for all fields requested from the database.

The layout of the subsequent list display has also been programmed into the processing block. After all processing has ended, the runtime system sends the list screen to the presentation server.

When the user starts the program, the program context is loaded first. This time, however, our sample program contains three processing blocks, a selection screen, and a screen, and a variable and two structures as its data objects.

Since the program contains a selection screen, the ABAP runtime system sends it to the presentation server at the beginning of program processing.

As soon as the user has finished entering data on the selection screen, he or she can trigger further processing by choosing 'Execute'. All data input on the selection screen is then automatically placed in its corresponding data object in the program and the ABAP runtime system resumes control of processing. The runtime system then triggers sequential processing of the ABAP processing block that comes after the selection screen.

The ABAP processing block contains a read access to the database that has been programmed into it. The program also passes the database information about which database table to access and which line in the table to read.

The database returns the requested data record to the program and the runtime system ensures that this data is stored in the appropriate data objects. Normally a structure is the target field when a single record is accessed. The structure contains variables for all fields requested from the database.

The ABAP processing block now triggers screen processing. This is often expressed simply by saying 'The program calls the screen'. However, in reality, each screen possesses its own processing block that is sequentially processed before the runtime system sends the screen to the presentation server (Process Before Output). This allows screens to be used in a very flexible manner.

After the screen's processing block has been processed, the ABAP runtime system sends the screen to the presentation server. During this process, data is transported into the screen's fields from a structure that serves as an interface for the screen.

Once the user performs a user action (choosing Enter, a function key, a menu function or a pushbutton, for example), control is handed over to the runtime system on the application server again. The screen fields are transported into the structure that serves as the screen's interface and a special processing block belonging to the screen is triggered. This processing block is always processed immediately following a user action (Process After Input).

After the 'Process After Input' processing block has been processed, the sample program continues processing the ABAP processing block that called the screen in the first place.

The database contains, along with the Repository, application and customizing tables that are usuall client-specific.

The Repository contains all development objects, for example, programs, definitions of database tables and global types. Development objects are therefore also known as Repository objects.

Repository objects are not client-specific. They can therefore be viewed and used in all clients.

All development objects created with the development tools found in the ABAP Workbench are classified as Repository objects and are stored centrally in the R/3 Repository.

The R/3 Repository is a special part of the SAP system's central database.

The Repository is organized according to application. Each application is further divided into logical subdivisions called development classes.

Repository objects are often made up of sub-objects that are themselves Repository objects.

Each Repository object must be assigned to a development class when it is created.

You can use the Repository Information System to search for Repository objects according to various criteria.

You can view the Repository structure in the application hierarchy. You can navigate to the application hierarchy from the initial screen using Tools -> ABAP Workbench -> Overview -> Application Hierarchy. (Transaction SE81).

The application components are displayed in a tree structure in the application hierarchy. Expanding a component displays all the development classes that are assigned to that component.

You can select a sub-tree and navigate from the application hierarchy to the Repository Information System. The system then collects all development classes for the sub-tree selected and passes them to the Information System.

You can use the Repository Information System to search for specific Repository objects. Search criteria are available for the various kinds of Repository objects.

You can navigate to the Repository Information System using

The Information system pushbutton in the application hierarchy

The menu path Tools -> ABAP Workbench -> Overview -> Information System

Transaction SE84 in the command field.

The ABAP Workbench contains different tools for editing Repository objects. These tools provide you with a wide range of assistance that covers the entire software development cycle.

The most important tools for creating and editing Repository objects are:

ABAP Editor for writing and editing program code

ABAP Dictionary for processing database table definitions and retrieving global types

Menu Painter for designing the user interface (menu bar, standard toolbar, application toolbar, function key assignment)

Screen Painter for designing screens (dynamic programs) for user dialogs

Function Builder for displaying and processing function modules (routines with defined interfaces that are available throughout the system)

Class Builder for displaying and processing central classes

There are two different ways to go about using these tools:

Either you call each individual tool and edit the corresponding Repository objects.

You must then call the next tool for the next set of objects...

Or you work with the Object Navigator: This transaction provides you with a tree-like overview of all objects within a development class or program.

The Object Navigator screen is divided into two areas:

An area for displaying an object list as a hierarchy

The object window, in which objects can be displayed and edited.

You can hide the hierarchy area using the 'Close browser' pushbutton.

You can display the object list for the object currently displayed in the object window using the 'Object list' icon.

You can select functions from a context menu in both screen areas. You are only given a choice of those functions that are relevant to displaying or editing the object on which the cursor is positioned.

Right-click with the mouse to display the context menu. (Left-click if you have set up your mouse for left-handers).

Repository objects are organized in a hierarchy:

Each application component consists of multiple development classes

Each development class can contain several different kinds of Repository objects:

programs, function groups, ABAP Dictionary objects, ...

Each Repository object can consist of different object types:

Programs can contain: global data, types, fields, events, ...

Function groups can contain: global data, function modules, ...

You can enter the type of object list and the object name in the upper part of the hierarchy area. The object list is then displayed in the hierarchy area.

Double-clicking on a sub-object in an object list displays the object list for the selected object in the hierarchy area.

Double-clicking on an object that does not have an object list displays that object in the object window.

You can use the icons to navigate by history or hierarchy between the object lists.

You can add object lists that you edit frequently to your favorites.

You can use the context menu to display objects from an object list. The system then automatically selects the correct tool for processing the object selected.

If the object you require from the object list is not available in the system, you can create it by double-clicking. This is called forward navigation.

There are various ways of starting a program:

You can start a program from the Object Navigator object list using the context menu or using the 'Test' icon.

If the program has a transaction code, then this can be added to a menu. Then all you have to do is click on the menu option with the mouse.

You can add programs to the favorites list on the initial screen. Programs can also be made available using the activity groups on the initial screen. Then all you have to do is select the program in the hierarchy on the initial screen.

You can determine the functional scope by executing the program.

On any screen, you can access information about the program name and the screen number using System -> Status. A standard selection screen has the screen number 1000.

You can access information on the field name and field type for any field on the screen using F1 -> Technical Info.

You can display an overview of the program objects using the program object list in the Object Navigator.

The hierarchy only shows those object types for which objects exist.

You can display the objects in the Object Navigator details window by double -clicking or using the context menu.

If you start a program from the Object Navigator object list using the context menu, then you have two options.

Choose Execute -> Direct to execute the program directly.

Choose Execute -> Debugging to execute the program in the debugging mode.

Starting the program in the debugging mode allows you to execute the program line by line using the 'Single Step' icon. You can display up to eight variables. To trace the variable values, enter the field names in the left input field. You can also see this entry by double -clicking on the field name in the code displayed.

You can set a breakpoint by double -clicking in front of a line of source code in the debugging mode. If you then click on the 'Continue' icon, the program will be executed up to the point where the next breakpoint is defined.

You can find information on content-related breakpoints in the ABAP Statements and Data Declarations unit.

ABAP programs are made up of individual statements.

Each statement ends with a period.

The first word in a statement is called a keyword.

Words must always be separated by at least one space.

Statements can be indented.

Statements can take up more than one line.

You may have multiple statements in a single line.

Consecutive statements with identical initial keywords can be condensed into one chained statement.

In chained statements, the initial part of the statement containing the keyword must be followed by a colon.

Individual elements that come after the colon must always be separated by commas.

Blank spaces are allowed before and after all punctuation (colons, commas, periods).

Be aware that the system still considers the individual parts of a chained statement to be complete statements that are independent of one another.

There are two ways to insert comments into a program:

A star (*) in column 1 allows you to designate the whole line as a comment.

Quotation marks (") in the middle of a line designate the remainder of the line as a comment.

You can display detailed information on single objects in the Editor by double -clicking:

Double -clicking on the name of a database table displays the database table definition using the ABAP Dictionary in the object window of the Object Navigator.

Double -clicking on a field name displays the part of the program source code where the data object is defined.

Double -clicking on a screen number displays the screen using the Screen Painter in the object window of the Object Navigator.

Use the Back function to get back to the program source code display in the Editor.

You can also set a breakpoint in any line of source code in the Editor. Then start the program without selecting the debugging mode. The program will now be executed up to the point where the breakpoint is defined. At this point, the debugging mode is started.

There are various ways of navigating to keyword documentation for an ABAP statement:

F1 on a keyword displays the documentation for the statement on which the cursor is positioned.

The Information icon displays a dialog box offering you various views of the keyword

documentation.

If you need more precise information on parts of the source code, you can analyze the source code.

The following slides explain the most important statements in the sample program.

There are various statements that you can use to define data objects.

The TABLES statement always refers to the global type of a flat structure that is defined in the ABAP Dictionary. The structure type for the data object in the program is taken from the Dictionary. The data object name is identical to the name of the structure type. They are normally used as an interface to the screen.

The DATA statement is usually used to define local data objects. The data object type is specified using the TYPE addition.

The PARAMETERS statement defines not only an elementary data object, but also an input field on the standard selection screen that is processed at the start of the program.

When you activate a program, an internal load version is generated. A selection screen is generated from the PARAMETERS statement. When the program starts, memory areas are made available for the data objects.

You can find further information on data objects in the unit entitled ABAP Statements and Data Declarations, or in the keyword documentation.

The SELECT statement ensures that data is read from the database. In order to read a record from a database table, the following information must be passed to the database:

From which database table is the data read? (FROM clause)

How many lines are read? The SINGLE addition shows that only one line is read.

Which line is read? The WHERE clause shows which columns of the database table have which values. For a SELECT SINGLE, the condition must be formulated so that one line is specified unambiguously.

The data supplied by the database is put into local data objects. The INTO clause specifies the data objects into which you want to copy the data. In this example, the data is copied to the components of the same name in structure wa_sbc400.

The statement CALL SCREEN calls a screen.

A screen must be created using the Screen Painter tool.

A screen is an independent Repository object, but belongs to the program.

You can define input fields on a screen that refer to the ABAP Dictionary. Screens automatically perform consistency checks on all input and provide any error dialogs that may be needed. Thus, screens are more than just templates for entering data, they are, in fact, dynamic programs (dynpros).

The statement TABLES declares a structure object that serves as an interface for the screen. All data from this structure is automatically inserted into its corresponding screen fields when the screen is called by the CALL SCREEN statement. Data entered by the user on the screen is transferred to its corresponding fields in the program after each user action (after choosing Enter, for example).

ABAP contains statements (WRITE, SKIP, ULINE) that allow you to create a list.

WRITE statements display field contents, formatted according to their data type, as a list.

Consecutive WRITE statements display output in the same output line. Output continues in the next line when the present one is full.

You can place a position entry in front of any output value. This allows you to determine carriage feed (/), output length (l) and where a column begins (p). More detailed information about formatting options can be found in the keyword documentation under WRITE.

List output can be displayed in color.

The complete list appears automatically at the end of the processing block.

The first project is to extend an existing program. As no extensions are allowed in the program and modifications are to be avoided, the first step is to copy the program and then change it.

You must allocate changes to existing programs to a project in the system, just as you would for creating copies of programs or creating new programs. Therefore the following slides deal first with how a project is represented in the R/3 System.

Projects are always implemented in a development system and then transported to the next system. A decisive criterion for the combination of projects is therefore which Repository objects need to be transported together because of their dependencies. More detailed information on project organization is available in the unit entitled Software Logistics and Software Adjustment .

Repository objects are automatically linked to correction and transport systems when they are assigned to a transportable development class (not $TMP).

After development has ended, Repository objects are transported into the test systems or production systems by way of certain prescribed pathways.

The ABAP Workbench tool Workbench Organizer (WBO) organizes all development tasks pertaining to Repository objects.

Each project requires the following information:

Name of the Project Manager?

What functional scope is to be covered by the object? Which Repository objects are to be changed or created?

What is the timeframe for the project?

Names of the project participants?

The trainer is the Project Manager.

Programs need to be developed for each topic. (These are the trainer's sample programs and the exercise groups' exercises)

This project is to be completed by 3:00 p.m. on Friday.

The user names of the participants

At the beginning of a development project, the project manager must create a change request. The project manager assigns all project team members to the change request. The Workbench Organizer assigns a project number to the change request (K9. Example: C11K900001). is the system number.

Next, the Workbench Organizer (WBO) creates a task for each employee assigned to the change request. From now on whenever an employee allocates a Repository object to that change request, the Repository object will automatically be filed away in that employee's task. Thus all Repository objects that an employee works on during a development program are collected within his or her task folder.

When changing a Repository object, a developer assigns it to a change request. Unlike the logical functional divisions that separate different development classes, change requests are project-related.

Thus, although a program always belongs to only one development class, it can, at different times, belong to different change requests.

When development is finished, the developer carries out a final quality check and releases the task.

The objects and object locks are passed from the task to the change request. However, all employees assigned to the change request can still make changes to the object because the Workbench Organizer will automatically create a new task should the need arise.

When the project is complete, the Project Manager checks the consistency of the request and the Project Manager releases the change request. The locks on the objects in the request are released.

The Repository objects are then exported to the central transport directory.

The objects are not imported automatically into the target system. Instead, the system administrator uses the transport control program tp at the operating system level. Afterwards, the developers check the import log.

Program names beginning with Y or Z, or with SAPMZ or SAPMY, are reserved for customer developments. You can also have a namespace reserved for customer developments. Detailed information on customer namespaces for various Repository objects is available in the SAP Library under Basis Components -> Change and Transport System(BC-CTS) -> BC Namespaces and Naming Conventions.

You can copy a program from the object list of a development cla ss or program. To do so, simply place your cursor on the name of the program you want to copy and click with the right mouse button. Choose Copy. The system displays a dialog box where you can enter a new name for your copy. Confirming your entries using the appropriate pushbutton in the application toolbar causes the system to display a dialog box where you can select the sub-objects that you want to copy with the program. Thus, you should decide which sub-objects you want to copy with the program BEFORE you begin the copy procedure. After you confirm these entries, the system displays yet another dialog box where you can save Repository objects.

If you are copying a program that contains includes, another dialog box is displayed before this one, where you can choose which includes you want to copy and enter new names for them.

Assign the program to a development class, in order to be able to save it. Your name is automatically entered into the system as the person responsible for the new program copy. Check all entries to see if they are correct and then choose Save.

All Repository objects that are created or changed must be assigned to the change request for their corresponding project. For this training course, the trainer has created a change request for the project 'Exercises for Participants on Course BC400 as of May 8, 2000'. Each group has a task within this change request. Assign all of your Repository objects (development classes, programs, and so forth) to this change request.

You can display all change requests in which you have a task using the 'Own requests' pushbutton.

You can adjust the short text (= title) as follows:

Double click on program object types in the Object Navigator object list.

Choose attributes.

Click on the 'Change' icon.

If the original language of the source program is not identical to your logon language, a dialog box appears to ask you whether you want to change the title in the original language or if you want to change the original language.

Now you can adjust the title.

The altered title appears as short text next to the program name in the Object Navigator object list.

In order to adapt the source code, navigate to the Editor (context menu).

To adapt the list, supplement a ULINE statement and a WRITE statement. You can find further information on these statements in the keyword documentation.

You can carry out a syntax check after you have changed the source code.

You can change a screen using the Screen Painter. To change the layout, first use the context menu for the screen in the object list to navigate to the Screen Painter and then from there use the 'Layout' icon to navigate to the graphic Layout Editor.

This contains an icon for creating input/output fields with reference to global types. Enter a structure type that is defined in the ABAP Dictionary. All fields for this structure type are displayed for selection. You cannot select fields that are already contained on the screen. This is shown by a small padlock next to the field.

The tool for displaying and maintaining global types is called the ABAP Dictionary. You can find more detailed information on global types in the ABAP Statements and Data Declarations unit.

A syntax check started from the Editor always relates to the current contents of the Editor.

As soon as you have saved the program, this source code is visible throughout the system. You can use the context menu to carry out a syntax check that encompasses all program components. Starting the program from the object list context menu ensures that the active version is started.

n As soon as you have activated the program, the active version can be executed throughout the system.

You can run an extended program check for activated programs using the context menu or the menu option. These checks are considerably more extensive than the syntax check.