Special Edition Using SAP R/3, Third Edition

More documents

Recommendations

Info

Special Edition Using SAP R/3, Third Edition - CH 3 - Exploring R/3 Architecture Page 12 of 26 Application Methodology Between the network of database servers and the front-end or presentation servers of an SAP R/3 multitier client/server system is the network of business applications that control the logic of the business transactions. The extensive range of applications is illustrated by the list in Chapter 4, "Introducing R/3 Software Architecture." The programs of these business applications are interpreted by an R/3 runtime system installed on every application server. SEE "The SAP R/3 Applications," p. 64 Business Transactions A business transaction is a unit of work that makes sense to those concerned with the activities of the business. The business transaction has to be carried on a computer system. The combined business requirements and computer constraints dictate the logical functions of a transaction. Data Consistency A business transaction must not corrupt data. For example, a value entered in one type of unit must not be interpreted as if it were something different unless the system can operate a conversion procedure from one to another, and back again, if necessary. A supplier’s address must not appear in different forms if it refers to the same location. The delivery service might be able to recognize their equivalence, but the computer system tends to regard two differing addresses as references to separate locations. While a transaction is taking place, a data object that is undergoing an update should be reserved exclusively for the user controlling the transaction. Until that transaction is complete, no other user should be allowed access to the critical data object. Furthermore, until the transaction is complete, it should be possible for the user to backtrack through all the steps and undo any of the data entries or changes he made. The database should be capable of returning to how it was before the transaction began. Business Requirements A computerized business transaction should be at least as subtle as the manual procedure it replaces. If you are creating an order for manufacturing, you should reserve the materials required at the same time. If you are posting items in financial accounting, it makes sense to post credit and debit items together. Dynpros for Dialog Steps The SAP mechanism for controlling the steps of a business transaction is the dynamic program, or dynpro. It presents the user with screens that make sense in the context of the work being done, and it makes sure that the logical data requirements of the business application are correctly met. SAP Logical Units of Work file://J:\prodinfo\MEMBERS\MA\ir057.html 3/23/01
Special Edition Using SAP R/3, Third Edition - CH 3 - Exploring R/3 Architecture Page 13 of 26 Modern database systems are fast. They cannot wait for a user to complete data entry. A database step has to be completed as a single operation so that the database can go on to process the next item, probably on behalf of a different user. By contrast, the logical unit of work (LUW) of a typical SAP application involves many database operations, as well as a host of interactions with the user and perhaps other systems. A SAP LUW is executed entirely or not at all--there is no interim stage. An SAP business transaction can consist of one or more logical units of work. An SAP LUW can span several dialog steps, each corresponding to a database transaction or LUW, which is the only way a database can be updated. The end of an SAP LUW is marked by a COMMIT WORK instruction or by the completion of the corresponding database update. Runtime Environment The R/3 runtime system is written in the ANSI-C language, and the R/3 application programs are written in ABAP/4. Dynpros are interpreted, not compiled. The runtime environment for R/3 applications is made up of the two processors necessary to interpret the dynpros. User Sessions A user logs on, calls on a series of transactions, and then logs off. During this session, you can perform more than one sequence of actions by opening additional sessions, which appear on separate windows in the user interface screen. Within each session, you can perform the actions in any suitable order and suspend and later resume processing. This multiple-session arrangement allows you to work on other activities if you must wait for processing resources or data. If you know the transaction code, you can open a new session where the activity can be processed. Otherwise, you can open a session from the system menu and identify what work you want to perform there. The Application Dispatcher The R/3 runtime system appears to the operating system as an aggregate of parallel processes. Each application includes a central dispatcher that allocates work to a number of work processes. A work process can consist of one or more task handlers. Figure 3.2 illustrates this concept. FIGURE 3.2 Each R/3 application has a dispatcher for its work processes. There are special work processes for the following types of activities: Interactive dialog processing Updating the database in response to changed documents file://J:\prodinfo\MEMBERS\MA\ir057.html 3/23/01
Page 1 and 2: Special Edition Using SAP R/3, Thir
Page 11: Special Edition Using SAP R/3, Thir

Special Edition Using SAP R/3, Third Edition

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?