Overview

Hi All,
As many readers of this blog are requesting about SAP R/3 and ABAP overview concepts. Today we will see overview of SAP R/3 and ABAP.

SAP R/3 is the market leader for integrated business administration systems. It integrates all business processes of a company and provides modules for finance, human resources, material management, etc. SAP R/3 is based on a (second party) relational database system which serves as an integration platform for all components of SAP R/3. The database system manages the SAP database which stores all business data of a company (e.g., customer and supplier information, orders,), all of SAP R/3-internal control data, an SAP R/3 data dictionary, and the code of all application programs. Virtually no data are stored outside this SAP database, thereby avoiding the use of a _le system. Describing the whole system in detail is beyond the scope of this paper. In the following, we will focus on the properties of SAP R/3 which are most relevant for performance tuning. In particular, we focus on the SAP R/3 interface to the relational database system back-end.

Architecture of SAP R/3

SAP R/3 is based on a three-tier Client/server-architecture with the following layers

1. The presentation layer. It provides a graphical user interface (GUI) usually running on PCs that are connected with the application servers via a local (LAN) or a wide-area network (WAN).

2. The application layer. It comprises the business administration \know-how" of the system. It processes pre-defined and user-defined application programs such as OLTP and the implementation of decision support queries. Application servers are usually connected via a local area network (LAN) with the database server.

3. The database layer. It is implemented on top of a (second party) commercial database product that stores all data of the system, as described above. In a small company that uses SAP R/3, the application servers and the database system could be installed on the same middle-range machine and users would enter business transactions or issue decision support queries using their PCs. Such a configuration, however, is not practical for large companies with a very high volume of data and transactions. In such companies, all application servers and the database system would be installed on separate dedicated machines. To this end, SAP R/3 has been ported to a large variety of hardware and operating system platforms, and it is also operational on a number of commercial RDBMSs.

ABAP4 Overview

Applications of the SAP R/3 system are coded in the programming language ABAP/4 (Advanced Business Application Programming Language)

Except for a small kernel, actually the entire R/3 system is coded in ABAP/4. ABAP/4 is a so-called Fourth Generation Language (4GL) whose origins can be found in report/application generator languages. For this reason, ABAP/4 programs are often called reports. In the course of the R/3 evolution, ABAP/4 was augmented with procedural constructs in order to facilitate the coding of more complex business application programs. For example,ABAP/4 contains language constructs to program so-called \Dynpros" which are dialog programs with a graphical user interface including the logic for validating and processing user entries. Recently, SAP has extended its ABAP programming language with object-oriented features, sometimes referred to as ABAP Objects.

ABAP/4 is an interpreted language, which makes it very easy to integrate new ABAP/4 application programs into the system. Like ordinary data, all ABAP/4 application programs are managed by the R/3 data dictionary and the program code is stored in the SAP database. Also, SAP R/3 includes a

Software development workbench for developing new application code.

As sketched in Figure 2, ABAP/4 provides commands that allow accessing the database via two different interfaces: Native SQL and Open SQL.

The Native SQL interface can be addressed by so-called EXEC SQL commands. It allows the user to access the SAP database directly without using the SAP-internal data dictionary. The advantage is, that the database system-specific properties and services (e.g., non-standard SQL statements like optimizer hints or specialized operators like cube) can be fully exploited and additional overhead by SAP R/3 is avoided. However, using the Native SQL interface incurs some severe drawbacks:

(1) The EXEC SQL commands may be database system specific which renders non-portable ABAP/4 programs.

(2) By circumventing the SAP-internal data dictionary, EXEC SQL commands cannot access encapsulated relations (containing encoded/clustered

data that can only be interpreted using the transformations maintained in the data dictionary).
(3)Native SQL reports are potentially unsafe because Native SQL directly reads database relations, and the implementer of a Native SQL report might overlook intrinsic business process interpretations which are otherwise carried out implicitly by SAP R/3's application programs; that is, bypassing SAP R/3's data dictionary requires expert knowledge about the rules and dependencies of the system. Safe and portable ABAP/4 reports can be written by relying exclusively on ABAP/4's Open SQL commands. Consequently, with very few exceptions the entire R/3 system shipped by SAP is programmed using Open SQL.