ch01.htm

这个是sap开发语言abap的教育文档

it to provide local control.
<P>
When all servers are combined onto a single machine, you have
a <I>central</I> configuration. This is rarely seen because it
describes a standalone R/3 system with only a single user.
<H3><A NAME="DefininganRSystem">
Defining an R/3 System</A></H3>
<P>
The simplest definition of an R/3 system is &quot;<I>one database.</I>&quot;
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.
<P>
<IMG SRC="../button/newterm.gif" tppabs="http://pbs.mcp.com/ebooks/0672312174/button/newterm.gif">
<P>
The term <I>R/3 system landscape</I> denotes a description of
the number of systems within an SAP installation and how they
are designated, such as development, test, or production.
<H3><A NAME="DefininganRInstance">
Defining an R/3 Instance</A></H3>
<P>
<IMG SRC="../button/newterm.gif" tppabs="http://pbs.mcp.com/ebooks/0672312174/button/newterm.gif">
<P>
When you hear someone say the word <I>instance</I>, most of the
time, that person will be referring to an application server.
The term instance is synonymous with <I>application server</I>.
<P>
The term <I>central instance</I> refers to the database server.
If an application server and database server both reside on the
same machine, the term <I>central instance</I> refers to the computer
on which both reside.
<P>
In the most general terms, an <I>instance</I> is a <I>server</I>.
It is a set of R/3 processes providing services to the R/3 system.
<H2><A NAME="ApplicationServerArchitecture"><FONT SIZE=5 COLOR=#FF0000>
Application Server Architecture</FONT></A></H2>
<P>
The components of an application server are shown in Figure 1.19.
It consists of a dispatcher and multiple work processes.
<P>
<A HREF="javascript:popUp('f1-19.gif')"><B>Figure 1.19: </B><I>Application server architecture</I>.</A>
<P>
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. 
<P>
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.
<H3><A NAME="UnderstandingaUserContext">
Understanding a User Context</A></H3>
<P>
<IMG SRC="../button/newterm.gif" tppabs="http://pbs.mcp.com/ebooks/0672312174/button/newterm.gif">
<P>
A <I>user context</I> 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:
<UL>
<LI>The user's current settings
<LI>The user's authorizations
<LI>The names of the programs the user is currently running
</UL>
<P>
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.
<H3><A NAME="UnderstandingaRollArea">
Understanding a Roll Area</A></H3>
<P>
<IMG SRC="../button/newterm.gif" tppabs="http://pbs.mcp.com/ebooks/0672312174/button/newterm.gif">
<P>
A <I>roll area</I> 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:
<UL>
<LI>The values of the variables
<LI>The dynamic memory allocations
<LI>The current program pointer
</UL>
<P>
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.<P>
<CENTER>
<TABLE BORDERCOLOR=#000000 BORDER=1>
<TR VALIGN=TOP><TD WIDTH=600><B>NOTE</B></TD></TR>
<TR VALIGN=TOP><TD WIDTH=600>
<BLOCKQUOTE>
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.</BLOCKQUOTE>

</TD></TR>
</TABLE>
</CENTER>
<P>
Both the roll area and the user context play an important part
in dialog step processing. 
<H3><A NAME="UnderstandingaDialogStepBR">
Understanding a Dialog Step<BR>
</A></H3>
<P>
<IMG SRC="../button/newterm.gif" tppabs="http://pbs.mcp.com/ebooks/0672312174/button/newterm.gif">
<P>
A <I>dialog step</I> is any screen change (see Figure 1.20).
<P>
<A HREF="javascript:popUp('f1-20.gif')"><B>Figure 1.20: </B><I>Changing from the Initial Screen to the
Address Screen can be considered a dialog step</I>.</A><P>
<CENTER>
<TABLE BORDERCOLOR=#000000 BORDER=1>
<TR VALIGN=TOP><TD WIDTH=600><B>NOTE</B></TD></TR>
<TR VALIGN=TOP><TD WIDTH=600>
<BLOCKQUOTE>
A dialog step is used by Basis consultants as the unit of measure for system response time.</BLOCKQUOTE>

</TD></TR>
</TABLE>
</CENTER>
<P>
<P>
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 <TT>sapmf02k</TT> 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.
<P>
There are four ways the user can initiate a dialog step. From
the SAPGUI:
<UL>
<LI>Press Enter.
<LI>Press a function key.
<LI>Click on a button on the screen.
<LI>Choose a menu item.
</UL>
<P>
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. 
<H3><A NAME="UnderstandingRollInRollOutProcessing">
Understanding Roll-In/Roll-Out Processing</A></H3>
<P>
<IMG SRC="../button/newterm.gif" tppabs="http://pbs.mcp.com/ebooks/0672312174/button/newterm.gif">
<P>
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 <I>rolled in</I> to the work process. At the end of
the dialog step, they are <I>rolled out</I>. This is illustrated
in Figure 1.21.
<P>
<A HREF="javascript:popUp('f1-21.gif')"><B>Figure 1.21: </B><I>Roll-in/roll-out processing</I>.</A>
<P>
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.
<P>
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.
<P>
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.
<P>
<CENTER>
<TABLE BORDERCOLOR=#000000 BORDER=1>
<TR VALIGN=TOP><TD WIDTH=600><B>NOTE</B></TD></TR>
<TR VALIGN=TOP><TD WIDTH=600>
<BLOCKQUOTE>
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.</BLOCKQUOTE>

</TD></TR>
</TABLE>
</CENTER>
<H3><A NAME="DiscoveringHowtheDataIsSenttothePresentationServer">
Discovering How the Data Is Sent to the Presentation Server
</A></H3>
<P>
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.
<H3><A NAME="UnderstandingtheComponentsofaWorkProcess">
Understanding the Components of a Work Process</A></H3>
<P>
Each work process has four components (see Figure 1.22).
<P>
<A HREF="javascript:popUp('f1-22.gif')"><B>Figure 1.22: </B><I>The components of a work process</I>.</A>
<P>
Each work process is composed of the following:
<UL>
<LI>A task handler
<LI>An ABAP/4 interpreter
<LI>A screen interpreter
<LI>A database interface
</UL>
<P>
All requests pass through the task handler, which then funnels
the request to the appropriate part of the work process.
<P>
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.
<P>
The database interface handles the job of communicating with the
database.
<H3><A NAME="UnderstandingtheTypesofWorkProcesses">
Understanding the Types of Work Processes</A></H3>
<P>
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.<BR>
<P>
<CENTER><B>Table 1.2&nbsp;&nbsp;Types of Work Processes and the
Types of Requests they Handle</B></CENTER><CENTER>
<TABLE BORDERCOLOR=#000000 BORDER=1>
<TR VALIGN=TOP><TD WIDTH=192><CENTER><B>WP Type</B></CENTER></TD><TD WIDTH=192><CENTER><B>Request Type</B></CENTER>
</TD></TR>
<TR VALIGN=TOP><TD WIDTH=192>D (Dialog)</TD><TD WIDTH=192>Dialog requests
</TD></TR>
<TR VALIGN=TOP><TD WIDTH=192>V (Update)</TD><TD WIDTH=192>Requests to update data in the database
</TD></TR>
<TR VALIGN=TOP><TD WIDTH=192>B (Background)</TD><TD WIDTH=192>Background jobs
</TD></TR>
<TR VALIGN=TOP><TD WIDTH=192>S (Spool)</TD><TD WIDTH=192>Print spool requests
</TD></TR>
<TR VALIGN=TOP><TD WIDTH=192>E (Enqueue)</TD><TD WIDTH=192>Logical lock requests
</TD></TR>
<TR VALIGN=TOP><TD WIDTH=192>M (Message)</TD><TD WIDTH=192>Routes messages between application servers within an R/3 system
</TD></TR>