Special Edition Using SAP R/3, Third Edition
Special Edition Using SAP R/3, Third Edition
Special Edition Using SAP R/3, Third Edition
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
<strong>Special</strong> <strong>Edition</strong> <strong>Using</strong> <strong>SAP</strong> R/3, <strong>Third</strong> <strong>Edition</strong> - CH 3 - Exploring R/3 Architecture Page 13 of 26<br />
Modern database systems are fast. They cannot wait for a user to complete data entry. A database step<br />
has to be completed as a single operation so that the database can go on to process the next item,<br />
probably on behalf of a different user.<br />
By contrast, the logical unit of work (LUW) of a typical <strong>SAP</strong> application involves many database<br />
operations, as well as a host of interactions with the user and perhaps other systems.<br />
A <strong>SAP</strong> LUW is executed entirely or not at all--there is no interim stage. An <strong>SAP</strong> business transaction<br />
can consist of one or more logical units of work. An <strong>SAP</strong> LUW can span several dialog steps, each<br />
corresponding to a database transaction or LUW, which is the only way a database can be updated.<br />
The end of an <strong>SAP</strong> LUW is marked by a COMMIT WORK instruction or by the completion of the<br />
corresponding database update.<br />
Runtime Environment<br />
The R/3 runtime system is written in the ANSI-C language, and the R/3 application programs are<br />
written in ABAP/4. Dynpros are interpreted, not compiled.<br />
The runtime environment for R/3 applications is made up of the two processors necessary to interpret<br />
the dynpros.<br />
User Sessions<br />
A user logs on, calls on a series of transactions, and then logs off. During this session, you can<br />
perform more than one sequence of actions by opening additional sessions, which appear on separate<br />
windows in the user interface screen. Within each session, you can perform the actions in any suitable<br />
order and suspend and later resume processing.<br />
This multiple-session arrangement allows you to work on other activities if you must wait for<br />
processing resources or data. If you know the transaction code, you can open a new session where the<br />
activity can be processed. Otherwise, you can open a session from the system menu and identify what<br />
work you want to perform there.<br />
The Application Dispatcher<br />
The R/3 runtime system appears to the operating system as an aggregate of parallel processes. Each<br />
application includes a central dispatcher that allocates work to a number of work processes. A work<br />
process can consist of one or more task handlers. Figure 3.2 illustrates this concept.<br />
FIGURE 3.2 Each R/3 application has a dispatcher for its work processes.<br />
There are special work processes for the following types of activities:<br />
Interactive dialog processing<br />
Updating the database in response to changed documents<br />
file://J:\prodinfo\MEMBERS\MA\ir057.html 3/23/01