BC ABAP Programming PHẦN 8 ppt

BC - ABAP Programming SAP AG Filling an Initial Screen using SPA/GPA Parameters 1074 December 1999 Filling an Initial Screen using SPA/GPA Parameters To fill the input fields of a called transaction with data from the calling program, you can use the SPA/GPA technique. SPA/GPA parameters are values that the system stores in the global, user- specific SAP memory. SAP memory allows you to pass values between programs. A user can access the values stored in the SAP memory during one terminal session for all parallel sessions. Each SPA/GPA parameter is identified by a 20-character code. You can maintain them in the Repository Browser in the ABAP Workbench. The values in SPA/GPA parameters are user-specific. ABAP programs can access the parameters using the SET PARAMETER and GET PARAMETER statements. To fill one, use: SET PARAMETER ID <pid> FIELD <f>. This statement saves the contents of field <f> under the ID <pid> in the SAP memory. The code <pid> can be up to 20 characters long. If there was already a value stored under <pid>, this statement overwrites it. If the ID <pid> does not exist, double-click <pid> in the ABAP Editor to create a new parameter object. To read an SPA/GPA parameter, use: GET PARAMETER ID <pid> FIELD <f>. This statement fills the value stored under the ID <pid> into the variable <f>. If the system does not find a value for <pid> in the SAP memory, it sets SY-SUBRC to 4, otherwise to 0. To fill the initial screen of a program using SPA/GPA parameters, you normally only need the SET PARAMETER statement. The relevant fields must each be linked to an SPA/GPA parameter. On a selection screen, you link fields to parameters using the MEMORY ID addition in the PARAMETERS or SELECT-OPTIONS statement. If you specify an SPA/GPA parameter ID when you declare a parameter or selection option, the corresponding input field is linked to that input field. On a screen, you link fields to parameters in the Screen Painter. When you define the field attributes of an input field, you can enter the name of an SPA/GPA parameter in the Parameter ID field in the screen attributes. The SET parameter and GET parameter checkboxes allow you to specify whether the field should be filled from the corresponding SPA/GPA parameter in the PBO event, and whether the SPA/GPA parameter should be filled with the value from the screen in the PAI event. When an input field is linked to an SPA/GPA parameter, it is initialized with the current value of the parameter each time the screen is displayed. This is the reason why fields on screens in the R/3 System often already contain values when you call them more than once. When you call programs, you can use SPA/GPA parameters with no additional programming overhead if, for example, you need to fill obligatory fields on the initial screen of the called program. The system simply transfers the values from the parameters into the input fields of the called program. However, you can control the contents of the parameters from your program by using the SET PARAMETER statement before the actual program call. This technique is particularly useful if you want to skip the initial screen of the called program and that screen contains obligatory fields. SAP AG BC - ABAP Programming Filling an Initial Screen using SPA/GPA Parameters December 1999 1075 If you want to set SPA/GPA parameters before a program call, you need to know which parameters are linked to which fields on the initial screen. A simple way of doing this is to start the program that you want to call, place the cursor on the input fields, and choose F1 followed by Technical info. The Parameter ID field contains the name of the corresponding SPA/GPA parameter. Alternatively, you can look at the screen definition in the Screen Painter. The technical information for the first input field of the booking transaction TCG2 looks like this: Airline Booking number Flight number Flight date Technical info. Parameter ID CAR The SPA/GPA parameter for the input field Company has the ID CAR. Use this method to find the IDs CON, DAY, and BOK for the other input fields. The following executable program is connected to the logical database F1S and calls an update transaction: REPORT BOOKINGS NO STANDARD PAGE HEADING. TABLES SBOOK. BC - ABAP Programming SAP AG Filling an Initial Screen using SPA/GPA Parameters 1076 December 1999 START-OF-SELECTION. WRITE: 'Select a booking', / ' '. SKIP. GET SBOOK. WRITE: SBOOK-CARRID, SBOOK-CONNID, SBOOK-FLDATE, SBOOK-BOOKID. HIDE: SBOOK-CARRID, SBOOK-CONNID, SBOOK-FLDATE, SBOOK-BOOKID. AT LINE-SELECTION. SET PARAMETER ID: 'CAR' FIELD SBOOK-CARRID, 'CON' FIELD SBOOK-CONNID, 'DAY' FIELD SBOOK-FLDATE, 'BOK' FIELD SBOOK-BOOKID. CALL TRANSACTION 'BOOK'. The basic list of the program shows fields from the database table SBOOK according to the user entries on the selection screen. These data are also stored in the HIDE areas of each line. If the user selects a line of booking data by double-clicking, the system triggers the AT LINE-SELECTION event and takes the data stored in the HIDE area to fill them into the SPA/GPA parameters of the initial screen of the transaction. Then it calls the transaction. Since you do not suppress the initial screen using AND SKIP FIRST SCREEN, the initial screen may appear as follows: SAP AG BC - ABAP Programming Filling an Initial Screen using SPA/GPA Parameters December 1999 1077 Airline Booking number Flight number Flight date LH 2402 01/20/1995 00010001 If you would use the AND SKIP FIRST SCREEN option with the CALL TRANSACTION statement, the second screen would appear immediately, since all obligatory fields of the first screen are filled. BC - ABAP Programming SAP AG ABAP Database Access 1078 December 1999 ABAP Database Access Application Presentation Database ABAP ABAP ABAP ABAP This section describes how ABAP programs communicate with the central database in the R/3 System. Accessing the Database in the R/3 System [Page 1079] Open SQL [Page 1082] Native SQL [Page 1161] Logical Databases [Page 1210] Contexts [Page 1273] Programming Database Changes [Page 1312] SAP AG BC - ABAP Programming Accessing the Database in the R/3 System December 1999 1079 Accessing the Database in the R/3 System Berechtigungskonzept [Page 508] In the R/3 System, long-life data is stored in relational database tables. In a relational database model, the real world is represented by tables. A table is a two-dimensional matrix, consisting of lines and columns (fields). The smallest possible combination of fields that can uniquely identify each line of the table is called the key. Each table must have at least one key, and each table has one key that is defined as its primary key. Relationships between tables are represented by foreign keys. Standard SQL SQL (Structured Query Language) is a largely standardized language for accessing relational databases. It can be divided into three areas: • Data Manipulation Language (DML) Statements for reading and changing data in database tables. • Data Definition Language (DDL) Statements for creating and administering database tables. • Data Control Language (DCL) Statements for authorization and consistency checks. Each database has a programming interface that allows you to access the database tables using SQL statements. The SQL statements in these programming interfaces are not fully standardized. To access a specific database system, you must refer to the documentation of that system for a list of the SQL statements available and their correct syntax. The Database Interface To make the R/3 System independent of the database system with which you use it despite the differences in the SQL syntax between various databases, each work process on an application server has a database interface. The R/3 System communicates with the database by means of this interface. The database interface converts all of the database requests from the R/3 System into the correct Standard SQL statements for the database system. To do this, it uses a database-specific component that shields the differences between database systems from the rest of the database interface. You choose the appropriate layer when you install the R/3 System. BC - ABAP Programming SAP AG Accessing the Database in the R/3 System 1080 December 1999 Native SQL Module Native SQL Module Open SQL Modules (Table module, buffer management) Open SQL Modules (Table module, buffer management) Database-specific layer Database-specific layer Native SQL Open SQL Standard SQL (dynamic, embedded) R/3 System programs Database interface Relational database Application programs Application programs ABAP Dictionary ABAP Dictionary There are two ways of accessing the database from a program - with Open SQL or Native SQL. Open SQL Open SQL statements are a subset of Standard SQL that is fully integrated in ABAP. They allow you to access data irrespective of the database system that the R/3 installation is using. Open SQL consists of the Data Manipulation Language (DML) part of Standard SQL; in other words, it allows you to read (SELECT) and change (INSERT, UPDATE, DELETE) data. Open SQL also goes beyond Standard SQL to provide statements that, in conjunction with other ABAP constructions, can simplify or speed up database access. It also allows you to buffer certain tables on the application server, saving excessive database access. In this case, the database interface is responsible for comparing the buffer with the database. Buffers are partly stored in the working memory of the current work process, and partly in the shared memory for all work processes on an application server. Where an R/3 System is distributed across more than one application server, the data in the various buffers is synchronized at set intervals by the buffer management. When buffering the database, you must remember that data in the buffer is not always up to date. For this reason, you should only use the buffer for data which does not often change. You specify whether a table can be buffered in its definition in the ABAP Dictionary. SAP AG BC - ABAP Programming Accessing the Database in the R/3 System December 1999 1081 Native SQL Native SQL is only loosely integrated into ABAP, and allows access to all of the functions contained in the programming interface of the respective database system. Unlike Open SQL statements, Native SQL statements are not checked and converted, but instead are sent directly to the database system. When you use Native SQL, the function of the database-dependent layer is minimal. Programs that use Native SQL are specific to the database system for which they were written. When writing R/3 applications, you should avoid using Native SQL wherever possible. It is used, however, in some parts of the R/3 Basis System - for example, for creating or changing table definitions in the ABAP Dictionary. The ABAP Dictionary The ABAP Dictionary, part of the ABAP Workbench, allows you to create and administer database tables. Open SQL contains no statements from the DDL part of Standard SQL. Normal application programs should not create or change their own database tables. The ABAP Dictionary uses the DDL part of Open SQL to create and change database tables. It also administers the ABAP Dictionary in the database. The ABAP Dictionary contains metadescriptions of all database tables in the R/3 System. Only database tables that you create using the ABAP Dictionary appear in the Dictionary. Open SQL statements can only access tables that exist in the ABAP Dictionary. Authorization and Consistency Checks The DCL part of Standard SQL is not used in R/3 programs. The work processes within the R/3 System are logged onto the database system as users with full rights. The authorizations of programs or users to read or change database tables is administered within the R/3 System using the R/3 authorization concept. Equally, transactions must ensure their own data consistency using the R/3 locking concept. For more information, refer to Programming Database Updates [Page 1312] BC - ABAP Programming SAP AG Open SQL 1082 December 1999 Open SQL Open SQL consists of a set of ABAP statements that perform operations on the central database in the R/3 System. The results of the operations and any error messages are independent of the database system in use. Open SQL thus provides a uniform syntax and semantics for all of the database systems supported by SAP. ABAP programs that only use Open SQL statements will work in any R/3 System, regardless of the database system in use. Open SQL statements can only work with database tables that have been created in the ABAP Dictionary. In the ABAP Dictionary, you can combine columns of different database tables to a database view (or view for short). In Open SQL statements, views are handled in exactly the same way as database tables. Any references to database tables in the following sections can equally apply to views. Overview Open SQL contains the following keywords: Keyword Function SELECT Reads data from database tables INSERT Adds lines to database tables UPDATE Changes the contents of lines of database tables MODIFY Inserts lines into database tables or changes the contents of existing lines DELETE Deletes lines from database tables OPEN CURSOR, FETCH, CLOSE CURSOR Reads lines of database tables using the cursor Return Codes All Open SQL statements fill the following two system fields with return codes: • SY-SUBRC After every Open SQL statement, the system field SY-SUBRC contains the value 0 if the operation was successful, a value other than 0 if not. • SY-DBCNT After an open SQL statement, the system field SY-DBCNT contains the number of database lines processed. Client Handling A single R/3 System can manage the application data for several separate areas of a business (for example, branches). Each of these commercially separate areas in the R/3 System is called a client, and has a number. When a user logs onto an R/3 System, they specify a client. The first column in the structure of every database table containing application data is the client field (MANDT, from the German word for client). It is also the first field of the table key. Only universal system tables are client-independent, and do not contain a client name. By default, Open SQL statements use automatic client handling. Statements that access client- dependent application tables only use the data from the current client. You cannot specify a condition for the client field in the WHERE clause of an Open SQL statement. If you do so, the system will either return an error during the syntax check or a runtime error will occur. You SAP AG BC - ABAP Programming Open SQL December 1999 1083 cannot overwrite the MANDT field of a database using Open SQL statements. If you specify a different client in a work area, the ABAP runtime environment automatically overwrites it with the current one before processing the Open SQL statement further. Should you need to specify the client specifically in an Open SQL statement, use the addition CLIENT SPECIFIED directly after the name of the database table. This addition disables the automatic client handling and you can use the field MANDT both in the WHERE clause and in a table work area. Reading data [Page 1084] Changing data [Page 1135] [...]... arranging the data from the database 1 084 December 1999 SAP AG BC - ABAP Programming Reading Data ABAP program ABAP program INTO clause INTO clause SELECT clause SELECT clause ORDER BY clause ORDER BY clause HAVING clause HAVING clause } GROUP BY clause GROUP BY clause WHERE clause WHERE clause FROM clause FROM clause Clause Description SELECT [Page 1 087 ] The SELECT clause defines the structure... this: 10 98 December 1999 SAP AG BC - ABAP Programming Specifying a Target Area In each loop pass, a new packet is sorted into the internal table Single fields as target area: DATA: AVERAGE TYPE P DECIMALS 2, SUM TYPE P DECIMALS 2 SELECT AVG( LUGGWEIGHT ) SUM( LUGGWEIGHT ) INTO (AVERAGE, SUM) FROM SBOOK WRITE: / 'Average:', AVERAGE, / 'Sum :', SUM The output is: December 1999 1099 BC - ABAP Programming. .. is: 1092 December 1999 SAP AG BC - ABAP Programming Defining Selections The internal table ITAB contains the columns of the database table SPFLI to be read The DISTINCT addition in the SELECT clause means that the statement only reads those lines that have different contents in both of these columns The result is a list of possible routes December 1999 1093 BC - ABAP Programming SAP AG Specifying a... database table This is always necessary if the table from which you want to read occurs more than once in the FROM clause You must define the alias name in the FROM clause 1 088 December 1999 SAP AG BC - ABAP Programming Defining Selections In the SELECT clause, you can use the AS addition to specify an alias name for each column The alias column name is used instead of the real name... [Page The WHERE clause specifies which lines are to be read by 11 08] specifying conditions for the selection GROUP BY [Page The GROUP-BY clause produces a single line of results from 1116] groups of several lines A group is a set of lines with identical values for each column listed in December 1999 1 085 BC - ABAP Programming SAP AG Reading Data HAVING [Page 1119] ORDER BY... in the SELECT clause are Dictionary types These Dictionary types must be able to be converted into the ABAP data types of the corresponding elementary components of the target area For a table of data types, refer to Data Types in the ABAP Dictionary [Page 105] 1094 December 1999 SAP AG BC - ABAP Programming Specifying a Target Area Specifying a Flat Work Area You can specify a flat work area regardless... the WHERE and HAVING clauses These are called subqueries [Page 1124] You can decouple the INTO clause from the SELECT statement by reading from the database using a cursor [Page 11 28] 1 086 December 1999 SAP AG BC - ABAP Programming Defining Selections Defining Selections The SELECT clause defines the structure of the result set (selection) that you want to read from the database Names Names Single... the corresponding key, SY-SUBRC is set to 0, otherwise to 4 Reading Several Lines To read a several entries from the database, use the following: SELECT [DISTINCT] WHERE December 1999 1 087 BC - ABAP Programming SAP AG Defining Selections If you do not use DISTINCT ( is then empty), the system reads all of the lines that satisfy the WHERE condition If you use DISTINCT, the system excludes... field names, the field names must also be listed in the GROUP BY clause The aggregate functions do not then apply to all of the selected lines, but to the individual groups of lines December 1999 1 089 BC - ABAP Programming SAP AG Defining Selections Specifying Columns Dynamically You can also specify dynamically as follows: SELECT () The parentheses must include the name of an internal... structure is used implicitly as the target area in the SELECT loop Since the names are the same, it is possible to overlook the fact that you are working with an ABAP data object here and not the database table itself 1096 December 1999 SAP AG BC - ABAP Programming Specifying a Target Area Internal table as target area DATA: BEGIN OF WA, CARRID TYPE SPFLI-CARRID, CONNID TYPE SPFLI-CONNID, CITYFROM TYPE SPFLI-CITYFROM, . filled. BC - ABAP Programming SAP AG ABAP Database Access 10 78 December 1999 ABAP Database Access Application Presentation Database ABAP ABAP ABAP ABAP This section describes how ABAP programs. definition in the ABAP Dictionary. SAP AG BC - ABAP Programming Accessing the Database in the R/3 System December 1999 1 081 Native SQL Native SQL is only loosely integrated into ABAP, and allows. more information, refer to Programming Database Updates [Page 1312] BC - ABAP Programming SAP AG Open SQL 1 082 December 1999 Open SQL Open SQL consists of a set of ABAP statements that perform