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).
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.
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.
SAP based the architecture of R/3 on a three-tier client/server model. The R/3 system architecture appears in Figure 1.17.
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.
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 components of an application server are shown in Figure 1.19. It consists of a dispatcher and multiple work processes.
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.
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).
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:
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.
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.
/*в общем, дальше мне надоело всё это копировать, поэтому, продолжение в оригинале:
http://freebooks.by.ru/view/Abap4in21day/index.htm*/