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 22 of 26 Cache Content The exact contents of a client cache are determined by the client company use profile. The cache is managed by the R/3 runtime system database services. Thus, individual applications just need to read from the cache buffers; they do not have to be concerned with their management. When a change is made to any data element in the client cache, the message servers respond immediately by declaring the update to the buffers of all the other applications. Dynamic Management of Client Caches When a client/server network is first installed and configured, it is not necessary to specify which application functions should be installed on which application servers. The first time a transaction is called, the corresponding module pool of programs is dynamically loaded from the database into the cache buffer of the next available application server, so this module pool is available to all users of this server. The cache is maintained under the control of a least recently used (LRU) condition, which ensures that the memory is used to best effect. Distributed Applications In a client/server environment that can call upon a very large library of standard business functions and a correspondingly extensive system of databases, it’s inevitable that large amounts of data will move between the distributed applications and their supporting servers. Efficient mechanisms have been developed to do this without the intervention of any user. Dialog-Free Data Input to R/3 Probably the first large parcel of information to be input to your R/3 system without the intervention of a dialog with the user will be the legacy records of your business as it was before the R/3 system went live. Although a user does not have to be involved, the R/3 system accepts mass imports of data as if they were generated by a series of transactions. Therefore, the system performs all the checks and updates it needs to ensure that the data is consistent and properly stored in the efficient data structures of the R/3 records. Exactly the same ABAP/4 programs are active as when the data is entered by a user. Batch data communications (BDC) or batch input is a standard system that works along the same lines. The effect is to simulate a normal user dialog. The system automatically supplies the data for what would be user display screens from a special dataset, and any error situations that occur during the BDC session are logged. The BDC dataset is created by a specific program written in a language such as C to accept the incoming data and store it in appropriate data formats selected from the standard data structures declared in the ABAP/4 data dictionary. This ensures that the new data is recognized by all R/3 applications and can be used by them when needed. 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 23 of 26 The preferred method of conditioning incoming data is to use a special ABAP/4 database interface that uses ABAP/4 Native SQL to access the legacy database. Electronic Data Interchange Methods Suppose that your company needs to exchange data with a business partner that is not fully integrated in your R/3 system and is using hardware and software that is not directly compatible with it. You can use the R/3 open EDI interface to exchange normal business documents and messages with specialized EDI subsystems from a variety of vendors. R/3 offers two methods for handling EDI: A direct interface with the relevant R/3 application Messages passed for manual handling IDocs (Intermediate EDI Documents) The international standards EDIFACT and ANSI X12 are used to create fields for application data in IDoc intermediate documents, which also provide encoded fields using International Standards Organization (ISO) codes for data such as units of measurement. Users can define how they want EDI to be applied. For example, a user can be informed by email, and certain situations can be monitored so that manual intervention can be mandated under specified conditions. Application Link Enabling (ALE) The IDoc (intermediate document) method is used in the ALE concept, which allows an R/3 system to grow by interacting with other systems through asynchronous links that exchange documents carrying messages and application data set out according to predefined business rules. SEE "Facilities Online," p. 503 Relationships with Production Technical Subsystems Two elements are required to link R/3 with a production-related technical subsystem: A component of R/3 An SAP component installed in the technical subsystem to perform the functions of a transceiver, which interprets the output of a control or monitoring device and transmits to it a signal to initiate some action, such as resetting a recording instrument or opening a valve The two components are linked by standard communications channels that are predefined in the R/3 element. Conversations with technical subsystems are always controlled by R/3, which initiates and uncouples the linkage when it is no longer active. It ensures that the data read from the R/3 database file://J:\prodinfo\MEMBERS\MA\ir057.html 3/23/01
Page 1 and 2: Special Edition Using SAP R/3, Thir
Page 21: 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?