After completing this section, you should be able to explain the SAP software portfolio, basic architecture, and glossary.

SAP was founded in 1972 as a private partnership and is today the largest software manufacturer in Europe. In the early days, SAP developed programs for payroll and accounting for mainframes. Instead of storing data mechanically on punch-hole cards as their ex-employer IBM did, SAP relied on online dialog via screen and keyboard. Therefore, SAP called their software a real-time system. In those days, software was usually developed individually for customers; however, right from the beginning, SAP designed their software to resell it to other customers. So, SAP was a pioneer in creating standard software.

In 1973, the R/1 financial accounting software was created in this way and introduced a new way of data processing, which is known as OLTP today. A key advantage in those days was that a single system could handle many tasks, such as order entry, material requirements planning, and invoicing. It eliminated multiple data storage and the separate maintenance of data. From a technical point of view, a database became necessary. In the following years, SAP became a leading provider of commercial standard software on IBM and Siemens mainframes.

In the early 1990s, SAP introduced R/3, the third version of their commercial standard software, which was planned for IBM AS/400, but also ran successfully on UNIX workstations and servers with an Oracle database. The client/server architecture that SAP created for R/3 was platform-independent, and remains in use today, as well as the vision to create standard software with a single source of data.

While SAP added more software to their software portfolio, the existing data structures were not optimal to support concurrent OLTP and OLAP workload. Based on the SAP software, different databases were required, and these databases had to be distributed across multiple systems to deliver the best results. Data between these databases needed to be synchronized and updated over time.

Meanwhile, SAP developed SAP HANA, an in-memory database that is best suited for concurrent OLAP and OLTP workload. SAP can therefore now realize a vision for a digital data core where all data is stored only once by using high-end Intel and IBM Power servers. The data can be retrieved fast enough to provide real-time visibility into all mission-critical business processes and processes around customers, suppliers, workforce, Big Data, and the Internet of Things.

Figure 1.1: SAP software history

SAP R/3 was created to run on various proprietary operating systems with different file systems. In R/2, SAP already created a reporting language that was extended to a platform-independent language called ABAP (Advanced Business Application Programming), in which the R3 software and all subsequent SAP software was written.

Besides the interpreter that executes the ABAP code, SAP needed to store the program code. Because SAP could not rely on file system standards as they existed in those days, SAP decided to use the database also as a store for the program code.

Figure 1.2: Generic SAP architecture

The runtime environment that abstracts the database and the operating system is often referred to as follows:

The foundation of much SAP software is still SAP NetWeaver Application Server ABAP (or NetWeaver AS ABAP). It consists of the runtime environment (kernel) plus basic functions already written in ABAP, such as:

SAP ECC and SAP S/4HANA are both written in ABAP and are interpreted by the same runtime or SAP kernel. The latter requires HANA as a database, so that the runtime operates with HANA only. From the operating system layer, an administrator would not see any difference between the two applications. SAP uses the AnyDB term for all supported non-HANA databases such as Oracle, Db/2, MaxDB, or SAP ASE.

An exchange of the database can be achieved by exporting the data and importing it into the new database with specialized SAP tools. It is called a heterogeneous migration and requires full testing. While the application should be ready for immediate use due to platform independence, any operating system or database-specific performance optimization is likely to be lost.

Figure 1.3: Example of ABAP stack: SAP ECC (R/3)

The SAP Basis administrators are responsible for SAP Base and the runtime environment (the dark blue boxes in the previous figure), while the business departments are responsible for the business applications (the light blue boxes in the previous figure).

The following figure shows how the SAP application can scale. SAP assigns a three-letter identifier, such as P01, to all dispatchers, no matter whether they run on the same or different operating system instances. Each dispatcher is numbered sequentially (from 00 to 99) and runs a couple of well-defined work processes. Typically, the instance with the lowest number runs the work process that communicates with the database and with other organizational processes.

Figure 1.4: ABAP solution architecture

The instance numbers determine the communication ports of the processes that belong to an instance. The two most important processes, which run only on the instance that communicates with the database, are the Message Server (MS) and the Enqueue Server (E). The Message Server acts as a communication channel between the application servers and handles the load distribution. The Enqueue Server controls the lock mechanism for the database.

These concepts might seem similar to Java, which they are, but they were created much earlier. SAP also created SAP NetWeaver Application Server Java, with the same architecture as the Application Server ABAP, but it is rarely used now.

For SAP architectures, consider the distinction between 2-tier and 3-tier architectures. A 3-tier architecture consists of the following components:

Tier 2 and 3 can both run on the same operating system instance on large Unix servers. In this case, SAP considers it as Tier 2 architecture.

The most common communication standards for SAP systems to exchange data are as follows:

Now you should have a basic understanding of the SAP software core. Be aware that the terminology can be confusing; for example, non-SAP people use kernel and RFC to mean different things.

Today, only two major applications in an SAP landscape follow this model: S/4HANA and BW/4HANA, which together with SAP HANA databases build the so-called digital core, the heart of every SAP landscape. Other applications are developed in a modern fashion and communicate with SAP over the well-defined interfaces.

Newer SAP applications are mostly container-based or even cloud-based only.

These applications are grouped into the following categories and are not necessarily based on the ABAP architecture:

Figure 1.5: SAP portfolio