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 15 of 26<br />
FIGURE 3.7 One or more work processes; each serves a spool for a printer.<br />
The ABAP/4 Data Dictionary<br />
The R/3 runtime environment is based on two processors: one for ABAP/4 and one for the dynpros.<br />
Both continually refer to the ABAP/4 data dictionary, which stores definitions of all R/3 data<br />
structures. Semantic and technical information stored in the dictionary constitute the universe of data<br />
used by the R/3 system.<br />
Figure 3.8 indicates that work processes have to be assigned the tasks of updating the database on<br />
which the ABAP/4 programs depend.<br />
FIGURE 3.8 One or more work processes specialize in updating the database.<br />
FIGURE 3.8 One or more work processes specialize in updating the database.<br />
Database Updates from the Transaction Log Records<br />
A dialog program can supervise many dialog steps. Each step generates a log record that is not<br />
processed until after the dialog part is complete. Therefore any database changes resulting from the<br />
dialog part of the transaction are not physically realized until the associated log records are processed.<br />
If the user interrupts a transaction during the dialog phase, or if the transaction fails for any other<br />
reason, there are no database changes to reverse because none were made.<br />
Synchronous Updating<br />
If the updating process is in synch with the dialog, the user has to wait for each update to be<br />
completed before committing the next. High throughput rates are possible if system resources can be<br />
made available.<br />
If you need fast interaction with users working under a heavy processing load, you should uncouple<br />
the dialogs from database updates to institute asynchronous updating.<br />
Multiple Component Updating<br />
If you want to use asynchronous updating, the dialog elements of transactions are separated from the<br />
actual updating of the database. This allows dialogs to proceed quickly, regardless of what has to<br />
happen in relation to the database. The accelerating effect is most noticeable when entering large<br />
volumes of data.<br />
The work destined to be performed in updating the database is taken from the log of the transactions.<br />
Each log entry record carries all the data needed to perform the changes, along with the names of the<br />
update routines that have to be invoked. These entries are complete work elements in themselves and<br />
are referred to as update components. Each is treated as a separate data object and is assigned<br />
individually by the dispatcher to an update work process.<br />
Primary Update Components (U1)<br />
file://J:\prodinfo\MEMBERS\MA\ir057.html 3/23/01