ch01.htm

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

<TR VALIGN=TOP><TD WIDTH=192>G (Gateway)</TD><TD WIDTH=192>Funnels messages into and out of the R/3 system
</TD></TR>
</TABLE>
</CENTER>
<H3><A NAME="UnderstandingtheLogonClient">
Understanding the Logon Client</A></H3>
<P>
The term <I>logon client</I> has nothing to do with Client/Server-it
is completely different. The <I>logon client</I> refers to the
number that the user types in the Client field on the logon screen
(see Figure 1.23).
<P>
<A HREF="javascript:popUp('f1-23.gif')"><B>Figure 1.23: </B><I>The user enters the logon client on the
logon screen in the Client field</I>.</A>
<P>
The number entered here by the user corresponds to a set of rows
within each client-dependent table within the database.
<H3><A NAME="UnderstandingClientDependentandClientIndependentTables">
Understanding Client-Dependent and Client-Independent Tables
</A></H3>
<P>
There are two types of tables in an R/3 database: <I>client-dependent</I>
and <I>client-independent</I>. A table is client-dependent if
the first field is of type <TT>CLNT</TT>. The length will always
be 3, and by convention, this field is always named <TT>mandt</TT>.
If the first field is not of type <TT>CLNT</TT>, 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.
<P>
<A HREF="javascript:popUp('f1-24.gif')"><B>Figure 1.24: </B><I>This table is client-dependent because
the first field is of type CLNT</I>.</A>
<P>
<A HREF="javascript:popUp('f1-25.gif')"><B>Figure 1.25: </B><I>This table is client-independent, because
the first field is not type CLNT</I>.</A>
<P>
Figure 1.26 shows how this field affects the user.
<P>
<A HREF="javascript:popUp('f1-26.gif')"><B>Figure 1.26: </B><I>The effect of client-dependence</I>.</A>
<P>
In Figure 1.26, the user logs on to client <TT>800</TT> and runs
the program shown. This program selects rows from table <TT>lfa1</TT>
and writes out <TT>lfa1-lifnr</TT>. When this program is run,
only two rows are selected: only those where <TT>mandt</TT> equals
<TT>800</TT>. This happens automatically because the first field
in the table is of type <TT>CLNT</TT>. There are five rows in
the table, but the program writes out only those rows where <TT>mandt</TT>
equals <TT>800</TT>. If the user were to log on to client <TT>700</TT>
and run the same program, three rows of data would be found and
written out. If the user were to log on to client <TT>900</TT>,
only one row of data would be found.
<P>
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.<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>
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.</BLOCKQUOTE>

</TD></TR>
</TABLE>
</CENTER>
<P>
Developers and testers use the logon client mechanism to create
and access multiple, independent sets of data within a single
table. 
<P>
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.
<P>
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.
<P>
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.
<P>
To make their tables client-dependant, they only need <TT>mandt</TT>
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 <TT>mandt</TT> field when
the record is send to the database. Their Open SQL <TT>select</TT>
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 <TT>insert</TT>, <TT>update</TT>, <TT>modify</TT>,
and <TT>delete</TT> also provide automatic client handling.
<P>
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.
<P>
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.<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>
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.</BLOCKQUOTE>

</TD></TR>
</TABLE>
</CENTER>
<P>
<H2><A NAME="UsingSAPsOpenSQL"><FONT SIZE=5 COLOR=#FF0000>
Using SAP's Open SQL</FONT></A></H2>
<P>
ABAP/4 code is portable between databases. To access the database
in an ABAP/4 program you will code SAP's <I>Open SQL</I>. 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.
<P>
<A HREF="javascript:popUp('f1-27.gif')"><B>Figure 1.27: </B><I>The database interface component of the
work process</I>.</A>
<P>
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.
<H3><A NAME="Portability">
Portability</A></H3>
<P>
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.
<H3><A NAME="BufferingDataontheApplicationServer">
Buffering Data on the Application Server</A></H3>
<P>
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.
<H3><A NAME="AutomaticClientHandling">
Automatic Client Handling</A></H3>
<P>
The third advantage of using Open SQL is <I>automatic client handling</I>.
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.
<H2><A NAME="Summary"><FONT SIZE=5 COLOR=#FF0000>
Summary</FONT></A></H2>
<UL>
<LI>R/3 supports multiple hardware platforms, operating systems,
and databases.
<LI>In addition to allowing native SQL, ABAP/4 provides Open SQL.
Using Open SQL makes your code portable, faster, and provides
automatic client handling.
<LI>The logon client enables multiple independent groups of data
to be stored in the same table. The data you access depends on
the client number you entered when you logged on.
</UL>
<H2><A NAME="QampA"><FONT SIZE=5 COLOR=#FF0000>
Q&amp;A</FONT></A></H2>
<TABLE>
<TR VALIGN=TOP><TD WIDTH=48><CENTER><B>Q</B></CENTER></TD><TD><B>Can I copy an existing client to a new client?</B>
</TD></TR>
<TR VALIGN=TOP><TD WIDTH=48><CENTER><B>A</B></CENTER></TD><TD>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 &quot;good&Oacute; 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.
</TD></TR>
<TR VALIGN=TOP><TD WIDTH=48><CENTER><B>Q</B></CENTER></TD><TD><B>Can I write a program that reads data from a client other than the client I am currently logged on to?</B>
</TD></TR>
<TR VALIGN=TOP><TD WIDTH=48><CENTER><B>A</B></CENTER></TD><TD>Yes. You can add the keywords <I>client specified</I> to any Open SQL statement. For example, to read data in client 900, you could code:

<BLOCKQUOTE>
<PRE>
select * from <I>tbl</I> client specified where mandt = '900'.
</PRE>
</BLOCKQUOTE>
<P>
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.
</TD></TR>
</TABLE>
<H2><A NAME="Workshop"><FONT SIZE=5 COLOR=#FF0000>
Workshop</FONT></A></H2>
<P>
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, &quot;Answers to Quiz Questions and Exercises.&quot;
<H3><A NAME="Quiz">
Quiz</A></H3>
<OL>
<LI>Choose the menu path Tools-&gt;Administration, Monitoring-&gt;System
monitoring-&gt;User overview. What is the transaction code for
this transaction?
<LI>What is the transaction code for the R/3 main menu? (The main
menu is the first menu displayed after logon.)
<LI>What is the transaction code for the menu path Tools-&gt;Development
Workbench?
<LI>If there are three R/3 systems in your current system landscape,
how many databases are there?
<LI>If an R/3 system has two application servers, how many instances
does it have? 
<LI>What is Open SQL? 
<LI>What advantages does Open SQL offer over native SQL? 
<LI>Which part of the work process is used to implement Open SQL?
<LI>When is a roll area allocated, when is it de-allocated, and
what does it contain?
<LI>When is a user context allocated, when is it de-allocated,
and what does it contain?
<LI>When does the roll-out occur, and why does it occur?
</OL>
<H3><A NAME="Exercise">
Exercise 1</A></H3>
<P>
Are the tables in Figures 1.28 through 1.31 client-dependent or
client-independent?
<P>
<A HREF="javascript:popUp('f1-28.gif')"><B>Figure 1.28: </B><I>Is this table client-dependent or client-independent?</I>.</A>
<P>
<A HREF="javascript:popUp('f1-29.gif')"><B>Figure 1.29: </B><I>Is this table client-dependent or client-independent?</I>.</A>
<P>
<A HREF="javascript:popUp('f1-30.gif')"><B>Figure 1.30: </B><I>Is this table client-dependent or client-independent?</I>.</A>
<P>
<A HREF="javascript:popUp('f1-31.gif')"><B>Figure 1.31: </B><I>Is this table client-dependent or client-independent?</I>.</A>

<P>
<CENTER>
<P>
<HR size=4>
<A HREF="gla01.htm" tppabs="http://pbs.mcp.com/ebooks/0672312174/ch01/gla01.htm"><IMG SRC="../button/previous.gif" tppabs="http://pbs.mcp.com/ebooks/0672312174/button/previous.gif" BORDER="0"></A>
<A HREF="../index.htm" tppabs="http://pbs.mcp.com/ebooks/0672312174/index.htm"><IMG SRC="../button/contents.gif" tppabs="http://pbs.mcp.com/ebooks/0672312174/button/contents.gif" BORDER="0"></A> 
<A HREF="../ch02/ch02.htm" tppabs="http://pbs.mcp.com/ebooks/0672312174/ch02/ch02.htm"><IMG SRC="../button/next.gif" tppabs="http://pbs.mcp.com/ebooks/0672312174/button/next.gif" BORDER="0"></A> 
</P>

<P>&#169; <A HREF="../copy.htm" tppabs="http://pbs.mcp.com/ebooks/0672312174/copy.htm">Copyright</A>, Macmillan Computer Publishing. All
rights reserved.
</CENTER>
</BODY>
</HTML>