SAP System Technology

The first section of this chapter introduced the business application components of the mySAP.com environment, as well as the mySAP.com Workplace system. These components are implemented using SAP's software technology. The focus of this section is to introduce the SAP's software architecture and to define some commonly used terms. This is an important foundation for the rest of this book on IT infrastructure solutions.

Technology Implementation Map

The SAP Business Technology Map (http://service.sap.com) illustrates how SAP Business Technology effectively and comprehensively covers the ERP system's life cycle. It provides best practice support for companies of any size and direction. Its goal is to get customers to focus on lowest cost of ownership while providing the openness and flexibility needed. The sections in the Business Technology Map that are addressed (in part) in this book include sizing, manageability, performance, availability, security, and scalability.

Multi-Tier Computing Architecture

The SAP R/3 system is structured in a three-tier client/server architecture from a software perspective, with each tier having a distinct function (see Figure 1-7). In this architecture, the presentation tier provides the interface to the user, the application tier processes the business logic, and the database tier stores the business data. The SAP system architecture supports heterogeneous environments and provides a high degree of system scalability and flexibility. With the introduction of the Internet middleware, SAP systems are now considered to be structured in a multi-tier architecture.

The presentation tier, typically installed on a PC, provides the SAP Graphical User Interface (SAPGUI). The interface is also available through a web browser. In this case, an additional middleware tier transforms the SAPGUI DIAG protocol into HTTP. The access is via TCP/IP and consumes very little network bandwidth. Essential for WAN links, SAP has the lowest network bandwidth demand of all ERP solutions.

The application tier executes the business logic, responsible for processing client transactions, print jobs, running reports, coordinating access to the database, and interfacing with other applications—the heart of the SAP R/3 system. Because the application logic can be executed in parallel, the workload can be distributed between multiple servers if the system load exceeds the capacity of a single machine.

The database stores both the business-generated data and also the SAP application programs, which are loaded into the SAP application servers from the database at runtime. SAP supports several database platforms, so the customer is free to determine the vendor. The database license is part of the SAP contract, although price differences exist between each database. The database software is delivered with the SAP installation media. In general, each SAP system can deploy only one database instance. All business and application data associated with a single SAP system is located in one database. Therefore, the server executing the database is the component with the highest demands on reliability, availability, and performance and ultimately determines the scalability of the entire SAP system. (In theoretical terms, the SAP R/3 system is considered a single server queuing network model.)

Depending on system workload and available computing power, the software tiers are executed on separate servers or consolidated onto fewer ones. The presentation tier is always considered distributed to the user's workplace. Development and test systems, as well as small production systems, commonly consolidate database and application instances onto one server (central system or two-tier). Large productive installations typically deploy a separate database server and multiple application instances on separate servers for increased scalability. For demo purposes, however, it is possible to combine all of the SAP software tiers onto one laptop computer.

The SAP Kernel Architecture

There are two important terms to differentiate for SAP systems: kernels and releases. The SAP release is the collection of business programs, usually written in ABAP^® (SAP's own business programming language), that are stored in the relational database. These ABAP programs are the business and functional logic of the relevant SAP system. They are independent of the underlying operating system and server platform.

SAP Kernel, Instance, and Work Processes

The SAP kernel, on the other hand, is a collection of executables and tools that enable the SAP system to process the business logic. The sum of SAP kernel processes started or stopped as a whole is called an SAP instance. Each SAP system can deploy multiple instances, typically one instance per server box. There are several situations, however, where it makes sense to run multiple instances per single server box.

Each SAP instance consists of one dispatcher and multiple work processes. The dispatcher distributes requests to free work processes. There are different kinds of work processes, dedicated to specific tasks (see Figure 1-8):

• Dialog work processes (D) are responsible for carrying out the online user transaction load. A dialog process can handle the requests of several users. However, a sufficient number of dialog processes must be available to prevent user requests from waiting for a free dialog process. At least two dialog work processes are required for each SAP R/3 instance.

• Batch work processes (B) carry out background tasks that don't require an online response, for example, data loading from a file.

• Update work processes (V) perform the actual updates to the database, asynchronously to the dialog and batch processes.

• Spool work processes (S) support print spooling. More than one spool process is supported per SAP R/3 instance with SAP R/3 release 4.0 and above.

• The gateway work process (G) provides communication between applications on the same or on an external system (for example, between an SAP R/3 and an R/2 system). Only one gateway process is needed per SAP R/3 instance.

The work processes described belong to the SAP application instance, of which there can be many in one single SAP system. There are two additional processes, however, that are unique to each SAP system:

• The enqueue server (E) and the enqueue table help to manage the locks on database updates to guarantee data consistency as seen from the business process level, even across database transactions.

• The message process (M) is responsible for communication between the various application servers. Users logging on to the system are assigned (by the message process) to the application server with the lowest load. However, this load distribution mechanism is at logon time only. If an application server goes down, the message process routes the new logon requests to the remaining application servers, providing a basic level of availability.

The instance running the enqueue and message work processes (along with dialog, batch, and the others) is called the Central Instance (CI). A configuration with a single central instance executed together with the database on one single machine is called a central system (i.e., two-tier system). All of the application instances require the proper functioning of the Central Instance. Because there is only one CI possible per SAP system, it is a single point of failure, and is therefore subject to high-availability solutions described later in this book.

The SAP System Architecture

From SAP's point of view, the three software tiers of database, application, and presentation are parts of one unit. In practice, only the application and database servers typically located in the data center are considered the SAP system. The presentation server, typically an SAPGUI application running on the user's workstation or PC, is often mislabeled as “client” or assumed equivalent to a “user.”

The easiest configuration is a Central System where both the database and the SAP application tier are executed on one single server. The network and SAP R/3 profile configuration management becomes relatively easy in this scenario. A central system needs fewer resources compared with a distributed system due to the reduction of network communication.

When the SAP R/3 application logic runs on a separate application server, or sets of servers, this configuration is called the distributed (client/server) model. There are many combinations of software configurations possible, with three common ones listed here:

• Standard— The database server executes the database management software, plus the SAP R/3 central instance, along with update processes, and some dialog and batch. The update work processes represent a significant load on the database host, so this is only appropriate for smaller transaction loads.

• Tuned— The update processes are moved off from the database server, distributed onto multiple application servers. The distribution is required primarily for redundancy but also has a potential performance benedit. In this case, the enqueue and message work processes represent less than 10% additional load, typically.

• High-End— When every ounce of processing power must be dedicated to the database, even the Central Instance can be moved off onto an SAP R/3 application server.

The initial intention of most enterprises is to deploy one single central SAP system for the entire organization. However, as time goes by, a multitude of independent SAP systems sprouts because different business units deploy different business processes and have different maintenance, geographical, and legal considerations, for example. In most cases, a separate human resources HR system is the first spin-off. Communication between these different systems is via the standard ALE and RFC interfaces provided by SAP.

The Database Server

Although SAP software is generally independent of any one particular relational database management system (RDBMS), there are some important software architecture concepts that apply to each database.

Just like SAP software, each RDBMS has a kernel, or a set of executables that enable the database application to run. These kernel files are compiled specifically for each server OS platform. The actual data stored in the database is logically stored as rows within relational tables. Physically, however, the data is stored in data files on disks, configured with a file system or as raw disks (discussed further in Chapter 4).

Changes to the data are tracked by a log writer process and stored in log files. At some point, the changes stored in the log files are flushed out to the database data files by the database writer process.

Transactions that are being processed but not yet committed as final are stored in the database rollback (or equivalent) tables or table areas (spaces). If a transaction aborts for any reason, the database can then be rolled back to a consistent state. Data needed for temporary use, such as for table joins, are written onto the disks in temporary storage. To access data quickly, index tables are used to reference the actual data. Often, logs, roll, temp, index, and data areas are each kept on separate disks for performance reasons. More information about the database architecture and its impact on disk systems is covered in Chapter 4.

Because the database server stores all the business data, it is the most critical system (including its disks) in any one SAP system. It needs protection from failure, from disasters, and needs to be scalable to avoid performance problems when processing activity increases.

The SAP System Landscape

Every SAP implementation project goes through deployment phases of some sort. There are several types of systems used to implement a project. These should at least be dedicated software deployment layers, if not on physically separate servers:

• Training, Evaluation, and Sandbox Systems— used for user training, gaining experience in mySAP.com and playground for feasibility studies for customer-specific requirements; usually small systems with small databases.

• Development System (DEV)— for customization of the mySAP.com systems and development of new components and functionality; usually small systems with small databases. It can be on different OS and HW platform, however, similar OS ease the management.

• Test and Quality Assurance System (Test/QA)— enables extended testing of upgrades/transports prior to implementation in the production system. These tests can cover OS upgrades, SAP upgrades and patches, new system drivers, interface setups, and so on. These are smaller than the production system but in a ratio that allows forecasting the performance impact. The data used is a copy of the production system to run tests with real, large quantities of data.

• Production System (PROD)— system with live data for production use.

The Change and Transport System (CTS) transports configuration changes as well as upgrades, patches, and newly developed components in a controlled manner between the layers of the system landscape (i.e., from DEV to Test/QA to PROD). This requires a file share available to all of the systems within the SAP landscape.

Figure 1-9 shows the typical SAP system landscape. The normal SAP project starts with a development system to set up, configure, and sometimes customize SAP software for a particular company's business processes. A test system is used to verify the development code before going into production. In some cases, a separate integration system is used to consolidate the changes of multiple development teams. Most of the mySAP.com application components (SAP BW, SAP APO, etc.) use development, test, and production systems in the complete landscape.

The minimum recommended configuration is a three-system landscape. However, due to budgetary reasons sometimes a different setup can be chosen. Development and Test/QA systems can be combined on one server. This is the case for the preconfigured Ready-To-Run packages from SAP, which are more cost sensitive. In any case, it is still useful to have a minimum of three logically separate systems, although there may be fewer physical servers.

Figure 1-10 shows a sample landscape with a few mySAP.com application components and two separate SAP R/3 systems. Not all Development and Test/QA systems possible are shown, however. The main point is that there are potentially many different server boxes (and storage) required to support a full mySAP.com environment.