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 14 of 26 Background batch processing Spooling Management of locks A work process can link directly to a database, which can be in another computer and can entail routing via shared communications services. All other data traffic, such as communications to the SAP GUI and to other programs, is routed through the dispatcher. Advanced Program-to-Program Communications An Advanced Program-to-Program Communications (APPC) server is built in to the dispatcher that can recognize and respond to communications requests submitted by the work processes. It relays these requests to the SAP gateway, which is also integrated into the dispatcher to serve as the R/3 system interface for the supported interface protocols, such as TCP/IP and LU6.2. In this role, it resembles a transaction monitor. Figure 3.3 summarizes these possibilities. FIGURE 3.3 Communications and central database services. When user interaction with a dynpro needs to be processed, the dispatcher places it in a queue for the next available interactive work process. When one is available, it executes exactly one dialog step and then makes itself available to process the next item in the queue. The processing of this one dialog step generates output messages that include a response screen that is sent back to the mode from which the user input originated. The user can work with several modes in separate windows (see Figure 3.4). FIGURE 3.4 One or more batch work processes support the dynpros. A work process can conduct more than one activity. Each activity within the work process is coordinated by a task handler that activates the dynpro processor or the ABAP/4 processor as necessary to service the request for application logic processing, such as dialogs, database updates, and background processes (see Figure 3.5). FIGURE 3.5 One or more work processes supervise dialogs. The number of work process resources in use at any moment is a function of the workload anticipated by the system controller. The use of multiple modes by the user allows work to progress. Even if delays are experienced in any activity being conducted on behalf of one mode, the user can set up or reactivate another. Figure 3.6 shows that one work process is devoted to controlling the security of individual processes through the R/3 enqueue services, which provide a comprehensive lock-management facility. (This is discussed in the section "Enqueue Central Lock Management," later in this chapter.) Other work processes are allocated to the management of print spooling functions (see Figure 3.7). FIGURE 3.6 One work process handles enqueue lock management. 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 15 of 26 FIGURE 3.7 One or more work processes; each serves a spool for a printer. The ABAP/4 Data Dictionary The R/3 runtime environment is based on two processors: one for ABAP/4 and one for the dynpros. Both continually refer to the ABAP/4 data dictionary, which stores definitions of all R/3 data structures. Semantic and technical information stored in the dictionary constitute the universe of data used by the R/3 system. Figure 3.8 indicates that work processes have to be assigned the tasks of updating the database on which the ABAP/4 programs depend. FIGURE 3.8 One or more work processes specialize in updating the database. FIGURE 3.8 One or more work processes specialize in updating the database. Database Updates from the Transaction Log Records A dialog program can supervise many dialog steps. Each step generates a log record that is not processed until after the dialog part is complete. Therefore any database changes resulting from the dialog part of the transaction are not physically realized until the associated log records are processed. If the user interrupts a transaction during the dialog phase, or if the transaction fails for any other reason, there are no database changes to reverse because none were made. Synchronous Updating If the updating process is in synch with the dialog, the user has to wait for each update to be completed before committing the next. High throughput rates are possible if system resources can be made available. If you need fast interaction with users working under a heavy processing load, you should uncouple the dialogs from database updates to institute asynchronous updating. Multiple Component Updating If you want to use asynchronous updating, the dialog elements of transactions are separated from the actual updating of the database. This allows dialogs to proceed quickly, regardless of what has to happen in relation to the database. The accelerating effect is most noticeable when entering large volumes of data. The work destined to be performed in updating the database is taken from the log of the transactions. Each log entry record carries all the data needed to perform the changes, along with the names of the update routines that have to be invoked. These entries are complete work elements in themselves and are referred to as update components. Each is treated as a separate data object and is assigned individually by the dispatcher to an update work process. Primary Update Components (U1) file://J:\prodinfo\MEMBERS\MA\ir057.html 3/23/01
Page 1 and 2: Special Edition Using SAP R/3, Thir
Page 13: Special Edition Using SAP R/3, Thir

Special Edition Using SAP R/3, Third Edition

Create successful ePaper yourself

Delete template?

Save as template?