Special Edition Using SAP R/3, Third Edition
Special Edition Using SAP R/3, Third Edition
Special Edition Using SAP R/3, Third Edition
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
<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 12 of 26<br />
Application Methodology<br />
Between the network of database servers and the front-end or presentation servers of an <strong>SAP</strong> R/3<br />
multitier client/server system is the network of business applications that control the logic of the<br />
business transactions. The extensive range of applications is illustrated by the list in Chapter 4,<br />
"Introducing R/3 Software Architecture." The programs of these business applications are interpreted<br />
by an R/3 runtime system installed on every application server.<br />
SEE "The <strong>SAP</strong> R/3 Applications," p. 64<br />
Business Transactions<br />
A business transaction is a unit of work that makes sense to those concerned with the activities of the<br />
business. The business transaction has to be carried on a computer system. The combined business<br />
requirements and computer constraints dictate the logical functions of a transaction.<br />
Data Consistency<br />
A business transaction must not corrupt data. For example, a value entered in one type of unit must<br />
not be interpreted as if it were something different unless the system can operate a conversion<br />
procedure from one to another, and back again, if necessary. A supplier’s address must not appear in<br />
different forms if it refers to the same location. The delivery service might be able to recognize their<br />
equivalence, but the computer system tends to regard two differing addresses as references to separate<br />
locations.<br />
While a transaction is taking place, a data object that is undergoing an update should be reserved<br />
exclusively for the user controlling the transaction. Until that transaction is complete, no other user<br />
should be allowed access to the critical data object. Furthermore, until the transaction is complete, it<br />
should be possible for the user to backtrack through all the steps and undo any of the data entries or<br />
changes he made. The database should be capable of returning to how it was before the transaction<br />
began.<br />
Business Requirements<br />
A computerized business transaction should be at least as subtle as the manual procedure it replaces.<br />
If you are creating an order for manufacturing, you should reserve the materials required at the same<br />
time. If you are posting items in financial accounting, it makes sense to post credit and debit items<br />
together.<br />
Dynpros for Dialog Steps<br />
The <strong>SAP</strong> mechanism for controlling the steps of a business transaction is the dynamic program, or<br />
dynpro. It presents the user with screens that make sense in the context of the work being done, and it<br />
makes sure that the logical data requirements of the business application are correctly met.<br />
<strong>SAP</strong> Logical Units of Work<br />
file://J:\prodinfo\MEMBERS\MA\ir057.html 3/23/01