After you complete this chapter, you should be able to answer the following questions:
R/3 is an integrated suite of applications designed to handle the data processing for large corporations. It was developed in Germany by the company named SAP (an acronym for Systems Applications and Products for data processing).
| TIP |
When you see the word SAP by itself, it is pronounced "ess-ay-pea." When it is combined with another word, it is pronounced sap, as in "tree sap." You should never say "sap" when referring to the company SAP. Always pronounce it as "ess-ay-pea." Saying "sap" is the surest way to say, "I don't know anything about SAP." |
Within R/3 is a runtime environment and an integrated suite of application programs written in SAP's 4GL-ABAP/4. These application programs are designed to meet the data processing needs of very large businesses. R/3 and its predecessor R/2 are particularly popular with the manufacturing sector.
R/3 is the system in which your ABAP/4 programs will run. Logically, it looks like Figure 1.1.
The sole purpose of an R/3 system is to provide a suite of tightly integrated, large-scale business applications. A few of these can be seen at the top of Figure 1.1. The standard set of applications delivered with each R/3 system are the following:
These applications are called the functional areas, or application areas, or at times the functional modules of R/3. All of these terms are synonymous with each other.
Traditionally, businesses assemble a suite of data processing applications by evaluating individual products and buying these separate products from multiple software vendors. Interfaces are then needed between them. For example, the materials management system will need links to the sales and distribution and to the financial systems, and the workflow system will need a feed from the HR system. A significant amount of IS time and money is spent in the implementation and maintenance of these interfaces.
R/3 comes prepackaged with the core business applications needed by most large corporations. These applications coexist in one homogenous environment. They are designed from the ground up to run using a single database and one (very large) set of tables. Current production database sizes range from 12 gigabytes to near 3 terabytes. Around 8,000 database tables are shipped with the standard delivery R/3 product.
This is important for you, as an ABAP/4 programmer, to know because these applications are all written entirely in ABAP/4. These are the applications you must understand to be a proficient developer in R/3.
For example, assume you know ABAP/4 and you have been asked to write a financial report summarizing debits and credits by fiscal year for each vendor in the enterprise. You might know how to code in ABAP, but would you know how to begin to solve such a request?
Or perhaps your job entails new development in ABAP/4. You are asked to design a system that provides stock quotations to potential buyers. If you do not know the financial and sales and distribution systems, you won't know if you are creating something that already exists in R/3. Nor can you know if there are R/3 tables that already contain data similar to or identical to the type of data you want to store. These applications are highly integrated. A developer who takes the approach "I'll build my own tables and keep my own copies of the data," might soon find his data is redundant and must be routinely synchronized with the rest of the database. He has built an application that does not take advantage of the highly integrated nature of the R/3 environment.
I only point this out because many developers who wish to become independent consultants think that learning ABAP/4 is all they need to develop in the R/3 system. It is certainly a great start, but it is only the start. The importance of training in a functional area can be overlooked or unknown to those interested in becoming proficient ABAP/4 consultants. Obviously, much of this learning can and will be done on the job. However, I hope to illustrate the point that learning the ABAP/4 language is only the beginning of a long journey into SAP. If you desire to be successful as an independent consultant, you will eventually need to acquire functional area knowledge.
| TIP |
You can learn about the functional areas by reading the R/3 online reference (R/3 menu path Help->R/3 Library). It contains tutorials and information for all of the functional areas. If you have access to a system with IDES data (International Demo and Education System), you can work through the R/3 Library exercises as well. For availability of training courses, contact SAP (http://www.sap.com) or Lambton College (http://www.lambton.on.ca). |
In a Windows environment, you will sign on to R/3 either by choosing a menu path from the Start menu, or by double-clicking on an R/3 icon, such as the one shown below in Figure 1.2.
Figure 1.2 : The R/3 icon on the desktop.
The R/3 system will prompt you for a user ID and password. The logon screen appears in Figure 1.3. You will fill in these two fields and then press Enter.
Figure 1.3 : The R/3 logon screen prompts you for a password.
The R/3 system will then display a copyright screen, and when you press Enter, the system will display the R/3 main menu as shown in Figure 1.4.
Figure 1.4 : The R/3 main menu.
From the main menu, you can go to three conceptual areas in the R/3 system:
In the Applications area, you initiate transactions for the functional areas within R/3. To access these, from the R/3 main menu choose one of the following: Logistics, Accounting, Human Resources, or Information Systems.
In the Basis area, you can run transactions that monitor the R/3 system itself. To access the Basis area, from the main menu choose the menu path Tools->Administration. Here you will find many performance, tuning, and database administration tools.
The Development Workbench is used to create and test ABAP/4 programs. As an ABAP/4 programmer, you will spend most of your time within the Workbench. To access the Development Workbench, choose the menu path Tools->Development Workbench. However, your code will most probably read or update application data, and so it will be destined to become part of the application area. With that in mind, let's have a look within an Applications area first.
For our example, imagine that you are a clerk working in an accounts payable department. A vendor calls to say his address has changed. You put a bookmark in the magazine article you were reading (A Criminologist's View of the Problems with Creative Accounting) and proceed to update his address in the R/3 system. First, you reach the Accounts Payable menu by choosing the menu path Accounting->Financial Accounting->Accounts Payable (see Figure 1.5).
Figure 1.5 : The menu path to update a vendor master record (part 1).
You then bring up the vendor master record maintenance transaction by choosing the menu path Master Records->Change (see Figure 1.6). You will see the Change Vendor: Initial screen.
Figure 1.6 : The menu path to update a vendor master record (part 2).
From the Initial screen shown in Figure 1.7, you type his vendor number, tickmark the Address check box, and press the Enter key. You will then see the Address screen (see Figure 1.8).
Figure 1.7 : The Vendor Master Update Transaction: Initial Screen.
Figure 1.8 : The Vendor Master Update Transaction: Address Screen.
You change his address and press the Save button (see Figure 1.9).
Figure 1.9 : Saving changes to the vendor's address.
Upon saving, the system returns you to the Change Vendor: Initial Screen. It also displays a success message within the status bar located at the bottom of the screen (see Figure 1.10).
Figure 1.10: The Initial Screen gives verification that the address change was made.
This transaction is representative of many of the transactions in the R/3 system. Most master data transactions have a similar look and feel.
Figure 1.11 shows the main menu again, with the important screen areas identified.
Figure 1.11: Important elements of an R/3 screen.
Every R/3 screen contains these elements:
| TIP |
If you position your mouse pointer over any button and let it rest there for a few seconds, R/3 will display a tool tip describing its function. In R/3 it is called quick info. It contains a brief description of the button and the function key assigned to it. |
You can turn most screen elements on and off. If your screen does not look or behave like the one described in this chapter, follow the instructions in the next section to correct it.
The icon with three colored circles in the upper right-hand corner of the R/3 window is called the Interface Menu. With it, you can customize user interface settings such as screen colors, font sizes, and cursor behavior. To accomplish this, click once on the icon in the upper right-hand corner of the R/3 window (see Figure 1.12). A menu will appear; click on the Options menu item.
Figure 1.12: The Interface Menu with the Options menu item highlighted.
Click on the General tab and change your settings to match those shown in Figure 1.13. Doing so will ensure that your user interface will look and behave as described in this book.
Figure 1.13: The General Interface options.
Turn on all of the toolbars (tickmark them all) and set Quick Info to Quick. Tickmark the first and last of the message check boxes as shown. Click Apply.
| TIP |
You must click the Apply or OK button before choosing another tab. If you do not, your changes will not take effect. |
Click on the Colors In Lists tab and tickmark the Lines In Lists check box as shown in Figure 1.14. Click OK to return.
Figure 1.14: Tickmarking the Colors In Lists check box.
The Lines In Lists option turns on or off the display of horizontal and vertical lines in your report output. It should be checked so that you will see the effect of the line graphic statements you will code later in this book.
| TIP |
Display all function key (or f-key) settings by right-clicking anywhere in the screen area. This works on all screens. Function keys 1 through 12 are the top row of keys on your keyboard. Function keys 13 through 24 are those same keys with the Shift key held down. For example, F13 is Shift+F1. For f-keys 25 through 36, use Ctrl instead of Shift. For 37 though 48, use Alt. For f-keys higher than 48, hold down Ctrl and type the key number on the numeric keypad. For example, for F50, hold down Ctrl and type 50 on the numeric keypad. |
In the Standard toolbar is an input area called the Command Field. Here you can enter system commands. For a list of the commands you can enter here, put your cursor in the command field and press the F1 key.
This field is most often used to start a new transaction.
| NOTE |
For now, think of a program as a transaction. The two are roughly equivalent. When you start a transaction, you are starting a program. |
Instead of choosing a menu path to start a transaction, you can enter its transaction code into the command field. A transaction code is a 3 or 4 character code associated with a transaction-you can use it to start the transaction without using a menu path. Every transaction has a transaction code (also called a tcode).
To find the transaction code for any transaction, you would invoke the transaction and then choose the menu path System->Status. The System:_Status screen will be displayed. The transaction code appears in the Transaction field.
For example, from the R/3 main menu, choose the menu path Accounting->Financial Accounting->Accounts Payable. You will see the Accounts Payable screen. From here, choose the menu path Master Records->Display. You will see the Display Vendor: Initial Screen. Choose the menu path System->Status. You will see the System:_Status screen. In the Transaction field is the transaction code for this screen: FK03.
Now that you have the transaction code, you can start this transaction from any screen by entering in the command field /n followed by the transaction code.
For example, return to the main menu (click the Cancel button twice and then click the Back button). In the command field type /nfk03, then click the Enter key. You will immediately see the Display Vendor: Initial Screen.
| TIP |
On any screen, you can find the transaction code of the current transaction. To do this, choose the menu path System->Status. |
Basis is like an operating system for R/3. It sits between the ABAP/4 code and the computer's operating system. SAP likes to call it middleware because it sits in the middle, between ABAP/4 and the operating system.
| NOTE |
The predecessor to R/3 is R/2. R/2 is mainframe-based, and SAP ported it to the client/server environment. To do this, SAP created Basis. Creating Basis enabled the existing ABAP/4 code to run on other platforms. |
If you turn back to Figure 1.1, you can see Basis sitting between ABAP/4 and the operating system. ABAP/4 cannot run directly on an operating system. It requires a set of programs (collectively called Basis) to load, interpret, and buffer its input and output.
Basis, in some respects, is like the Windows environment. Windows starts up, and while running it provides an environment in which Windows programs can run. Without Windows, programs written for the Windows environment cannot run.
Basis is to ABAP/4 programs as Windows is to Windows programs. Basis provides the runtime environment for ABAP/4 programs. Without Basis, ABAP/4 programs cannot run. When the operator starts up R/3, you can think of him as starting up Basis. Basis is a collection of R/3 system programs that present you with an interface. Using this interface the user can start ABAP/4 programs.
To install Basis, an installer runs the program r3inst at the command-prompt level of the operating system. Like most installs, this creates a directory structure and copies a set of executables into it. These executables taken together as a unit form Basis.
To start up the R/3 system, the operator enters the startsap command. The Basis executables start up and stay running, accepting requests from the user to run ABAP/4 programs.
ABAP/4 programs run within the protective Basis environment; they are not executables that run on the operating system. Instead, Basis reads ABAP/4 code and interprets it into operating system instructions.
ABAP/4 programs do not access operating system functions directly. Instead, they use Basis functions to perform file I/O and display data in windows. This level of isolation from the operating system enables ABAP/4 programs to be ported without modification to any system that supports R/3. This buffering is built right into the ABAP/4 language itself and is actually totally transparent to the programmer.
Basis makes ABAP/4 programs portable. The platforms that R/3 can
run on are shown in Table 1.1.
| AIX SINIX | IBM SNI SUN | Win 3.1/95/NT | DB2 for AIX |
| SOLARIS HP-UX | Digital HP | OSF/Motif | Informix-Online |
| Digital-UNIX | Bull | OS/2 | Oracle 7.1 |
| Macintosh | ADABAS D | ||
| Windows NT | AT&T Compaq | Win 3.1/95/NT | Oracle 7.1 |
| Bull/Zenith | OSF/Motif | SQL Server 6.0 | |
| HP (Intel) SNI | OS/2 | ADABAS D | |
| IBM (Intel) | Macintosh | ||
| Digital (Intel) | |||
| Data-General | |||
| OS/400 | AS/400 | Win95 OS/2 | DB2/400 |
For example, if you write an ABAP/4 program on Digital UNIX with an Informix database and an OSF/Motif interface, that same program should run without modification on a Windows NT machine with an Oracle database and a Windows 95 interface. Or, it could run on an AS/400 with a DB2 database using OS/2 as the front-end.
SAP also provides a suite of tools for administering the Basis system. These tools perform tasks such as system performance monitoring, configuration, and system maintenance. To access the Basis administration tools from the main menu, choose the path Tools->Administration.
Here are some examples of Basis administration tools:
Basis is designed to run in a client/server configuration.
Client/server is two programs talking to each other (see Figure 1.15).
Figure 1.15: The essence of client/server.
Here we see Program 1 asking Program 2 for some information. Program 1 is the client and Program 2 is the server. Program 2 serves Program 1 with the information it requested. This is different than a main program calling a subroutine and returning. A program that calls a subroutine transfers control to the subroutine and cannot perform any processing until the subroutine returns control.
With client/server, the client and server programs are independent processes. If the client sends a request to the server, it is free to perform other work while waiting for the response.
Figure 1.16 shows the three standard client/server configurations. R/3 can be tailored to run in any of these configurations.
Figure 1.16: One-, two-, and three-tiered client/server configurations.
When the client and server programs both run on the same computer, the configuration is referred to as single-tier client/server. (A tier is the boundary between two computers.) When they run on different computers, the configuration is referred to as two-tier client/server.
A program can function as both a client and a server if it both requests information and replies to requests. When you have three programs in communication, such as is shown in Figure 1.16, the configuration is called three-tier client/server.
The client/server configuration enables the R/3 system to spread its load across multiple computers. This provides the customer with the ability to scale the processing power of the system up or down by simply adding another computer to an existing configuration, instead of replacing a single computer that performs all of the processing, such as that which occurs in the mainframe world.
SAP based the architecture of R/3 on a three-tier client/server model. The R/3 system architecture appears in Figure 1.17.
Figure 1.17: The R/3 system architecture.
The presentation server is actually a program named sapgui.exe. It is usually installed on a user's workstation. To start it, the user double-clicks on an icon on the desktop or chooses a menu path. When started, the presentation server displays the R/3 menus within a window. This window is commonly known as the SAPGUI, or the user interface (or simply, the interface). The interface accepts input from the user in the form of keystrokes, mouse-clicks, and function keys, and sends these requests to the application server to be processed. The application server sends the results back to the SAPGUI which then formats the output for display to the user.
An application server is a set of executables that collectively interpret the ABAP/4 programs and manage the input and output for them. When an application server is started, these executables all start at the same time. When an application server is stopped, they all shut down together. The number of processes that start up when you bring up the application server is defined in a single configuration file called the application server profile.
Each application server has a profile that specifies its characteristics when it starts up and while it is running. For example, an application sever profile specifies:
The application server exists to interpret ABAP/4 programs, and they only run there-the programs do not run on the presentation server. An ABAP/4 program can start an executable on the presentation server, but an ABAP/4 program cannot execute there.
If your ABAP/4 program requests information from the database, the application server will format the request and send it to the database server.
The database server is a set of executables that accept database requests from the application server. These requests are passed on to the RDBMS (Relation Database Management System). The RDBMS sends the data back to the database server, which then passes the information back to the application server. The application server in turn passes that information to your ABAP/4 program.
There is usually a separate computer dedicated to house the database server, and the RDBMS may run on that computer also, or may be installed on its own computer.
During installation, the servers can be configured in four ways (see Figure 1.18).
Figure 1.18: Possible R/3 system configurations.
In a three-tier client/server configuration, the presentation servers, applications servers, and database server all run on separate machines. This is the most common configuration for large systems, and is common in production.
In the distribution presentation configuration, the application and database servers are combined on one computer and the presentation servers run separately. This is used for smaller systems, and is often seen on a development system.
In the two-tier client/server configuration, the presentation and application servers are combined and the database server is separate. This configuration is used in conjunction with other application servers. It is used for a batch server when the batch is segregated from the online servers. A SAPGUI is installed on it to provide local control.
When all servers are combined onto a single machine, you have a central configuration. This is rarely seen because it describes a standalone R/3 system with only a single user.
The simplest definition of an R/3 system is "one database." In one R/3 system, there is only one database. To expand the definition, R/3 is considered to be all of the components attached to that one database. One R/3 system is composed of one database server accessing a single database, one or more application servers, and one or more presentation servers. By definition, it is all of the components attached to one database. If you have one database, you have one system. If you have one system, you have one database. During an implementation, there is usually one system (or one database) assigned to development, one or more systems designated for testing, and one assigned to production.
The term R/3 system landscape denotes a description of the number of systems within an SAP installation and how they are designated, such as development, test, or production.
When you hear someone say the word instance, most of the time, that person will be referring to an application server. The term instance is synonymous with application server.
The term central instance refers to the database server. If an application server and database server both reside on the same machine, the term central instance refers to the computer on which both reside.
In the most general terms, an instance is a server. It is a set of R/3 processes providing services to the R/3 system.
The components of an application server are shown in Figure 1.19. It consists of a dispatcher and multiple work processes.
Figure 1.19: Application server architecture.
All requests that come in from presentation servers are directed first to the dispatcher. The dispatcher writes them first to the dispatcher queue. The dispatcher pulls the requests from the queue on a first-in, first-out basis. Each request is then allocated to the first available work process. A work process handles one request at a time.
To perform any processing for a user's request, a work process needs to address two special memory areas: the user context and the program roll area. The user context is a memory area that contains information about the user, and the roll area is a memory area that contains information about the programs execution.
A user context is memory that is allocated to contain the characteristics of a user that is logged on the R/3 system. It holds information needed by R/3 about the user, such as:
When a user logs on, a user context is allocated for that logon. When they log off, it is freed. It is used during program processing, and its importance is described further in the following sections.
A roll area is memory that is allocated by a work process for an instance of a program. It holds information needed by R/3 about the program's execution, such as:
Each time a user starts a program, a roll area is created for that instance of the program. If two users run the same program at the same time, two roll areas will exist-one for each user. The roll area is freed when the program ends.
| NOTE |
When speaking to a Basis consultant, you might hear the term roll area used to refer to all roll areas for one user or even all roll areas on one application server. You usually can determine the intended meaning from the context in which it is used. |
Both the roll area and the user context play an important part in dialog step processing.
A dialog step is any screen change (see Figure 1.20).
Figure 1.20: Changing from the Initial Screen to the Address Screen can be considered a dialog step.
| NOTE |
A dialog step is used by Basis consultants as the unit of measure for system response time. |
A dialog step is the processing needed to get from one screen to the next. It includes all processing that occurs after the user issues a request, up to and including the processing needed to display the next screen. For example, when the user clicks the Enter key on the Change Vendor: Initial Screen, he initiates a dialog step and the hourglass appears, preventing further input. The sapmf02k program retrieves the vendor information and displays it on the Change Vendor: Address screen, and the hourglass disappears. This marks the end of the dialog step and the user is now able to make another request.
There are four ways the user can initiate a dialog step. From the SAPGUI:
It is important for an ABAP/4 programmer to know about dialog steps because they form a discrete unit of processing for an ABAP/4 program.
An ABAP/4 program only occupies a work process for one dialog step. At the beginning of the dialog step, the roll area and user context are rolled in to the work process. At the end of the dialog step, they are rolled out. This is illustrated in Figure 1.21.
Figure 1.21: Roll-in/roll-out processing.
During the roll-in, pointers to the roll area and user context are populated in the work process. This enables the work process to access the data in those areas and so perform processing for that user and that program. Processing continues until the program sends a screen to the user. At that time, both areas are rolled out. Roll-out invalidates the pointers and disassociates these areas from the work process. That work process is now free to perform processing for other requests. The program is now only occupying memory, and not consuming any CPU. The user is looking at the screen that was sent, and will soon send another request.
When the next request is sent from the user to continue processing, the dispatcher allocates that request to the first available work process. It can be the same or a different work process. The user context and roll area for that program are again rolled in to the work process, and processing resumes from the point at which it was left off. Processing continues until the next screen is shown, or until the program terminates. If another screen is sent, the areas are again rolled out. When the program terminates, the roll area is freed. The user context remains allocated until the user logs off.
In a system with many users running many programs, only a few of those programs will be active in work processes at any one time. When they are not occupying a work process, they are rolled out to extended memory and only occupy RAM. This conserves CPU and enables the R/3 system to achieve high transaction throughput.
| NOTE |
ABAP/4 programs do not have the capability to intercept many common Windows events. The events that generate a lot of messages such as key presses, focus changes, and mouse movements are not passed to ABAP/4 programs. As a result, there is no way of performing some of the functions that are found in other Windows programs. For example, in ABAP/4, you cannot validate the contents of a field when the user presses the Tab key. You must instead wait until the user initiates a dialog step. |
The messages exchanged between the presentation server and the application server are in an SAP proprietary format. The SAPGUI accepts the screen information sent from the application server and formats it appropriately for the platform it is running on. This enables different end-user hardware platforms to connect to a single application server. For example, an OS/2 PC and a Windows PC can both connect to the same application server at the same time.
Each work process has four components (see Figure 1.22).
Figure 1.22: The components of a work process.
Each work process is composed of the following:
All requests pass through the task handler, which then funnels the request to the appropriate part of the work process.
The interpreters interpret the ABAP/4 code. Notice that there are two interpreters: the ABAP/4 interpreter and the screen interpreter. There are actually two dialects of ABAP/4. One is the full-blown ABAP/4 data processing language and the other is a very specialized screen processing language. Each is processed by its own interpreter.
The database interface handles the job of communicating with the database.
There are seven types of work processes. Each handles a specific
type of request. The type of work processes and the types of requests
that they handle are shown in Table 1.2.
| D (Dialog) | Dialog requests |
| V (Update) | Requests to update data in the database |
| B (Background) | Background jobs |
| S (Spool) | Print spool requests |
| E (Enqueue) | Logical lock requests |
| M (Message) | Routes messages between application servers within an R/3 system |
| G (Gateway) | Funnels messages into and out of the R/3 system |
The term logon client has nothing to do with Client/Server-it is completely different. The logon client refers to the number that the user types in the Client field on the logon screen (see Figure 1.23).
Figure 1.23: The user enters the logon client on the logon screen in the Client field.
The number entered here by the user corresponds to a set of rows within each client-dependent table within the database.
There are two types of tables in an R/3 database: client-dependent and client-independent. A table is client-dependent if the first field is of type CLNT. The length will always be 3, and by convention, this field is always named mandt. If the first field is not of type CLNT, the table is client-independent. An example of a client-dependent table is shown in Figure 1.24. Figure 1.25 is an example of a client-independent table.
Figure 1.24: This table is client-dependent because the first field is of type CLNT.
Figure 1.25: This table is client-independent, because the first field is not type CLNT.
Figure 1.26 shows how this field affects the user.
Figure 1.26: The effect of client-dependence.
In Figure 1.26, the user logs on to client 800 and runs the program shown. This program selects rows from table lfa1 and writes out lfa1-lifnr. When this program is run, only two rows are selected: only those where mandt equals 800. This happens automatically because the first field in the table is of type CLNT. There are five rows in the table, but the program writes out only those rows where mandt equals 800. If the user were to log on to client 700 and run the same program, three rows of data would be found and written out. If the user were to log on to client 900, only one row of data would be found.
The logon client mechanism divides the rows within a client-dependant table into distinct groups. To access a different set of data, the user logs on and specifies a different client number.
| NOTE |
The user master records (containing R/3 user IDs) are client-dependent. Therefore, to gain access to a client, the security administrator must create a new user ID for you within that client. |
Developers and testers use the logon client mechanism to create and access multiple, independent sets of data within a single table.
For example, assume two typical, asocial programmers are working on an enhancement to the billing system. Jim is modifying the update transaction and Jane is creating a new report to go with Jim's modifications.
Jane sets up data for her test run, executes her report and obtains output. Jim works in the next cubicle, but due to his antisocial tendencies is blissfully unaware that his transaction uses the same tables as Jane's report. He runs his transaction and updates the data. Jim got what he wanted, but Jane then modifies her code and runs her program again. Her output differs from the last run, and the differences many not result from her changes, but rather they may result from Jim's changes. What we have here is a failure to communicate.
If the tables used by Jim and Jane's programs were client-dependent, they could each log in to separate clients, set up independent sets of data, and test their programs without ever talking to each other. They could perform all of their testing in the comfort of their cubicles and in isolation from their coworkers.
To make their tables client-dependant, they only need mandt as the first field and the R/3 system will take care of the rest. When records are added to the table, the system automatically moves the current logon client into the mandt field when the record is send to the database. Their Open SQL select statements will only return rows where the client number in the table is equal to the their current logon client number. The Open SQL database statements insert, update, modify, and delete also provide automatic client handling.
If the tables involved are all client-dependent, there can be more than one group of testers working at a time in one test system. Two teams of testers can test divergent functionality in the same set of programs at the same time provided they log on to different logon clients. The updates done by one team will not change the data belonging to the other team.
A training client could also exist on the test system. The students could log on to one client and the testers could log on to another. Both would run the same set of programs, but the programs would access independent sets of data.
| NOTE |
The average R/3 installation has three systems: development, test, and production. By default, each system comes with three clients installed: 000, 001, and 066. It is common to have from three to six clients in the development and test systems, but rarely will you see more than one client in production. |
ABAP/4 code is portable between databases. To access the database in an ABAP/4 program you will code SAP's Open SQL. Open SQL is a subset and variation of ANSI SQL. The ABAP/4 interpreter passes all Open SQL statements to the database interface part of the work process (see Figure 1.27). There, they are converted to SQL that is native to the installed RDMS. For example, if you were running an Oracle database, your ABAP/4 Open SQL would be converted by the database interface to Oracle SQL statements.
Figure 1.27: The database interface component of the work process.
If you use Open SQL, your SQL statements will be passed to the database interface. Using Open SQL has three main advantages. All of these advantages are implemented via the database interface.
The first advantage is the fact that your SQL statements will be portable between databases. For example, if for some reason your company wanted to switch from an Oracle to an Informix database, it could change the database, and your ABAP/4 code would continue to run without modification.
Secondly, the database interface buffers information from the database on the application server. When data is read from the database, it can be stored in buffers on the application server. If a request is then made to access the same records, they would already be on the application server, and the request is satisfied from the buffer without having to go to the database. This buffering technique reduces the load on the database server and on the network link between the database and application servers, and can speed up database access times by a factor of 10 to 100 times.
The third advantage of using Open SQL is automatic client handling. With Open SQL, the client field is automatically populated by the database interface. This gives your development and testing teams many advantages, such as the ability to perform multiple simultaneous testing and training on a single database without interference from each other.
| Can I copy an existing client to a new client? | |
| The Basis consultant can do this for you using a client copy utility. Each development system normally has at least a reference client and a working client. Your "goodÓ data is kept in the reference client. It is copied to create the working client. If you corrupt the working client, the Basis consultant can restore it to its original state by copying the reference client again. | |
| Can I write a program that reads data from a client other than the client I am currently logged on to? | |
Yes. You can add the keywords client specified to any Open SQL statement. For example, to read data in client 900, you could code:
select * from tbl client specified where mandt = '900'. However, you should realize that this should only be done if you are writing a system program. It is never done in an application program; they should always be client-independent. If you need to transmit data between two production clients, you should implement the data transfer via ALE. |
The Workshop provides you two ways for you to affirm what you've learned in this chapter. The Quiz section poses questions to help you solidify your understanding of the material covered and the Exercise section provides you with experience in using what you have learned. You can find answers to the quiz questions and exercises in Appendix B, "Answers to Quiz Questions and Exercises."
Are the tables in Figures 1.28 through 1.31 client-dependent or client-independent?
Figure 1.28: Is this table client-dependent or client-independent?.
Figure 1.29: Is this table client-dependent or client-independent?.
Figure 1.30: Is this table client-dependent or client-independent?.
Figure 1.31: Is this table client-dependent or client-independent?.
© Copyright, Macmillan Computer Publishing. All rights reserved.
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}