The Architecture of SAP ERP E-Book

Jochen Boeder

• Herausgeber: tredition
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Englisch

Seitenzahl: 333

Veröffentlichungsjahr: 2014

Beschreibung

This book - compiled by software architects from SAP - is a must for consultants, developers, IT managers, and students working with SAP ERP, but also users who want to know the world behind their SAP user interface.

Leseprobe

Jochen Boeder, Bernhard Gröne Sagar Joshi, Sathish Karthik R, Wolfram Kleis, Sushil Kumar

Copyright © 2013 by SAP AG, Dietmar-Hopp-Allee 16, 69190 Walldorf, Germany Authors: Jochen Boeder, Bernhard Gröne, Sagar Joshi, Sathish Karthik R, Wolfram Kleis & Sushil Kumar Cover photo: Andreas Huppert (http://hupperts.de/) Publisher: tredition GmbH, Hamburg ISBN: 978-3-8495-7662-2

All Rights Reserved. No parts of this publication may be reproduced, stored in retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except under permission of the publisher and the authors in writing.

All diagrams in this book have been created by the authors.

The authors and publisher have taken care in the preparation of this book, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for incidental or consequential damages in connection with or arising out of the use of the information contained herein.

This publication contains references to the products of SAP AG or an SAP affiliate company. SAP, R/3, ABAP, BAPI, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP BusinessObjects Explorer, StreamWork, SAP HANA, the Business Objects logo, BusinessObjects, Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, Sybase, Adaptive Server, Adaptive Server Enterprise, iAnywhere, Sybase 365, SQL Anywhere, Crossgate, B2B 360° and B2B 360° Services, m@gic EDDY, Ariba, the Ariba logo, Quadrem, b-process, Ariba Discovery, SuccessFactors, Execution is the Difference, BizX Mobile Touchbase, It’s time to love work again, SuccessFactors Jam and BadAss SaaS, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany or an SAP affiliate company.

All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary.

SAP AG is neither the author nor the publisher of this publication and is not responsible for its content. SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.

Bibliografische Information der Deutschen Nationalbibliothek (Cataloging-in-Publication Data):

ISBN: 978-3-8495-7662-2

A catalog record for this book is available from the Deutsche Nationalbibliothek in the Deutsche Nationalbibliografie; for detailed bibliographic data see http://dnb.d-nb.de.

Typeset by the authors in Book Antiqua 10 using Microsoft Word 2010.

Table of Contents

Foreword

Preface

1

Architecture of SAP ERP

1.1

SAP ERP Overview

1.1.1    

SAP ERP Operations

1.1.2    

SAP ERP Financials

1.1.3    

SAP ERP Human Capital Management

1.2

SAP ERP and SAP Business Suite

1.3

Technical Architecture of SAP ERP

1.3.1    

Three Tier Client Server Architecture

1.3.2    

Transaction Concept

1.3.3    

ABAP

1.3.4    

Customizing and Extending the System

1.3.5    

Integration Concepts

1.3.6    

System Landscapes

2

SAP ERP Powered by SAP HANA

2.1

SAP HANA Architecture Overview

2.1.1    

In-Memory Database

2.1.2    

Columnar Data Storage

2.1.3    

Data Structures and Compression for Columnar Tables

2.1.4    

Efficient Write Operations on Columnar Tables

2.1.5    

SAP HANA Database Architecture Overview

2.2

SAP NetWeaver ABAP on SAP HANA

2.3

Application-Level Optimizations for SAP HANA

2.4

SAP HANA Live

3

SAP ERP Operations

3.1

Introduction to SAP ERP Operations

3.1.1    

Master Data and Reuse

3.1.2    

Integration with SAP Business Suite

3.2

Material Master

3.2.1    

Architecture Overview

3.2.2    

The View Concept of Material Master

3.2.3    

Database Design of Material Master

3.2.4    

General Functions

3.3

Business Partner Master Data

3.3.1    

Partner Determination

3.4

Sales and Distribution

3.4.1    

Architecture Overview

3.4.2    

Integration Architecture

3.4.3    

Pricing

3.4.4    

Availability Check

3.5

Production Planning

3.5.1    

Master Data

3.5.2    

Integration Architecture

3.5.3    

Planning Functions

3.5.4    

Production Execution

3.6

Materials Management

3.6.1    

Procurement of Materials

3.6.2    

Procurement of Services

3.6.3    

Integration Architecture

3.6.4    

Pattern-Based User Interface

3.7

Logistics Execution

3.7.1    

Architecture Overview

3.7.2    

Integration Architecture

3.7.3    

Inbound Delivery Processing

3.7.4    

Outbound Delivery Processing

3.7.5    

Transportation Management

3.7.6    

Warehouse Management

3.8

Quality Management

3.8.1    

Quality Planning

3.8.2    

Quality Inspection

3.8.3    

Quality Control

3.8.4    

Quality Notification

3.8.5    

Quality in Procurement Processing

3.8.6    

Quality Certificate Processing

4

SAP ERP Financials

4.1

Introduction to SAP ERP Financials

4.1.1    

Architecture Overview

4.1.2    

Financial Accounting

4.1.3    

Management Accounting

4.1.4    

Financial Supply Chain Management

4.1.5    

Treasury

4.1.6    

Accounting Interface

4.1.7    

Deployment

4.2

Recording Financial Transactions Using the Accounting Interface

4.2.1    

Create Interface

4.2.2    

Post Interface

4.3

Financial Accounting

4.3.1    

The Financial Accounting Document

4.3.2    

Financial Interface

4.3.3    

Document Posting

4.3.4    

New General Ledger Accounting

4.3.5    

Document Processing with New General Ledger

4.3.6    

Sub-Ledger Processing

4.3.7    

Clearing

4.3.8    

Tax Accounting

4.3.9    

Periodic Processing

4.3.10  

Asset Accounting

4.3.11  

Special Purpose Ledger

4.4

Management Accounting

4.4.1    

Management Accounting Overview

4.4.2    

Profitability Analysis

4.4.3    

Profit Center Accounting

4.5

Financial Supply Chain Management

4.5.2    

SAP Biller Direct

4.5.3    

SAP Credit Management

4.6

Treasury

4.6.1    

SAP Treasury and Risk Management:

4.6.2    

SAP Cash and Liquidity Management

4.6.3    

In-House Cash

5

SAP ERP Human Capital Management

5.1

Introduction to SAP ERP HCM

5.2

HCM Core Applications

5.2.1    

Personnel Administration

5.2.2    

Personnel Development

5.2.3    

Organizational Management

5.2.4    

Personnel Time Management

5.2.5    

Payroll

5.2.6    

Appraisals, Evaluation, and Survey Engine

5.3

SAP ERP HCM Extension Applications

5.3.1    

Talent Management Overview

5.3.2    

Career and Succession Management

5.3.3    

Compensation Management

5.3.4    

Performance Management

5.3.5    

SAP E-Recruiting

5.3.6    

Enterprise Learning

5.4

SAP ERP HCM Service Delivery Applications

5.4.1    

Self-Service Applications

5.4.2    

HCM Processes and Forms

5.4.3    

Employee Interaction Center

6

Appendix

6.1

SAP ERP Operations – Appendix

6.1.1    

Material Master

6.1.2    

Sales and Billing

6.1.3    

Production Planning

6.1.4    

Materials Management

6.1.5    

Logistics Execution

6.1.6    

Quality Management

6.2

SAP ERP Financials – Appendix

6.2.1    

Accounting Interface

6.2.2    

Financial Accounting

6.2.3    

Financial Supply Chain Management

6.2.4    

Treasury

6.2.5    

Debit Credit in Financial Accounting

6.3

SAP ERP HCM – Appendix

6.3.1    

PA Infotype Customization Tables

6.3.2    

PD Infotype Customization Tables

6.3.3    

Software Components in SAP ERP HCM

6.3.4    

PD Objects in SAP ERP HCM and Organizational Management

6.3.5    

PD Objects in SAP E-Recruiting

6.4

Diagram Legend

6.4.1    

Block Diagram

6.4.2    

Activity Diagram

6.4.3    

Class Diagram

6.5

Further Reading

6.6

References

6.7

Authors and Editors

6.8

Table of Figures

6.9

Index

Foreword

The software product SAP® ERP has become the software backbone of today’s global business. With this product, SAP architects and developers have succeeded in implementing functional and quality requirements that many companies around the world have been looking for. SAP® ERP and its predecessor SAP R/3® were the main reason for success and growth of SAP in the last 20 years.

SAP coined the term “business standard software” for this type of enterprise software. Business standard software combines standardization and flexibility in order to cover the requirements of many companies and organizations. On the one hand, SAP delivers standardized processes and standardized software. On the other hand, the software’s flexibility allows tailoring the processes to the individual company’s needs. A number of concepts have been developed and combined in SAP ERP to allow both, standardization and flexibility.

When I was chief architect of SAP ERP in 2005, we extended this concept of “standardization and flexibility” to the management of SAP ERP releases. From 2005 on, there is a “standardized” stable core release of SAP ERP, which can be extended with new functionality by installing enhancement packages. Companies can decide on feature level, which new function of an enhancement package they want to activate and use. This is flexibility.

In companies’ IT landscapes, SAP ERP has become center of an ecosystem of integrated software applications. Also, many products and solutions use SAP ERP functionality via interfaces, either directly or indirectly. In addition, the in-memory technology of SAP HANA will impact future business software. Therefore, basic knowledge about the architecture concepts of SAP ERP and SAP ERP on HANA - as described in this book - is a prerequisite to develop new products in time and ready for the market.

Documenting architecture is much more than just abstracting source code in various types of diagrams. Source code and data type definitions contain no information about development or architecture decisions, and it is very hard to recognize business abstractions in the implementation. This book provides these reasons and business abstractions and fills the gap between user documentation and implementation.

Gordon Mühl Head of Architecture Communication and Chief Architect of SAP ERP 2005 SAP AG

Preface

Do you know what organizations as different as the car manufacturer BMW, the food producer Nestle, the National Australia Bank, the online marketplace eBay, Coca Cola, the Oxford University Press, and the chemical company BASF have in common with 248.000 others?

They all run their business with Enterprise Resource Planning (ERP) software from SAP. With 64.000 employees and yearly revenue of 13.2 billion Euro, SAP – which stands for Systems, Applications and Products in Data Processing – is the market leader in enterprise application software [SAP13].

All this began in 1972 when five former IBM employees – Dietmar Hopp, Hans-Werner Hector, Hasso Plattner, Klaus Tschira and Claus Wellenreuther – launched the company SAP. Their vision: to develop business standard software for real-time data processing. In 1973 they finished the first accounting software. This software forms the basis for the continuous development of other software modules in what later came to be known as the R/1 System. During the 1980s, the R/2 system was shaped and sold. In 1992 SAP’s global success started with the general release of the SAP R/ 3 system. Its client/server concept, the uniform structure of graphical interfaces, consistent use of relational databases and the ability to run on computers from different manufacturers meets with tremendous approval. 9000 SAP R/3 installations in 1996 increased to 36 000 installations in the year 2000 (see also [Mei99]).

In 2003 the product SAP R/3 was renamed to SAP Enterprise Resource Planning (SAP ERP). The product is available in 37 languages, in 120 countries, on more than 8 different database management systems, supporting more than 10 different operating systems. SAP ERP is enhanced by products for customer relationship management (SAP CRM), supply chain management (SAP SCM), and supplier relationship management (SAP SRM) which together form the SAP Business Suite.

Nowadays around 74% of all business transactions worldwide touch at the one or the other point in time an SAP system. For this reason we think that it is time to describe how this software works.

About this Book

Software architecture has been defined as “the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them” [BCK06]. Within this book we describe the software architecture of SAP ERP and focus on the “structure”, “software elements” and “relationships” which make its business functionality work. We will explain for example the interaction of different software parts to make a payroll run or how different software components are integrated when processing a quotation which becomes a sales order which then leads to production and delivery.

Surely you cannot expect to learn all details of these applications that embrace 229 million lines of code in the latest release SAP ERP 6.0 EhP7. Nevertheless, you will learn a lot about core business processes of today’s companies and how the software architecture of SAP ERP addresses them. The appendix provides more technical details and references to further literature.

This book includes a large number of architecture diagrams visualizing structure, components, and interfaces. All architecture diagrams show models following the TAM (Technical Architecture Modeling) notation which is SAP’s UML-compliant standard for visualizing software architecture (see appendix 6.4).

This book is divided in six parts:

•   

Part 1 – “Architecture of SAP ERP”, provides an architecture overview of SAP ERP and its main components as well as a short introduction to the technology they use.

•   

Part 2 – “SAP ERP Powered by SAP HANA” introduces the SAP HANA technology and how it is used to accelerate some SAP ERP functionality.

•   

Part 3 – “SAP ERP Operations” describes how sales, production, logistics, and quality management work from software perspective

•   

Part 4 – “SAP ERP Financials” explains the core modules and components involved in financial and management accounting

•   

Part 5 – “SAP ERP Human Capital Management” describes concepts of the core HR functions and their implementation

•   

Part 6 – “Appendix” provides additional technical information for each SAP ERP component, such as concrete program names or database tables.

This book focuses on the business application part of SAP ERP. This means we will not discuss the architecture and technologies of the underlying SAP NetWeaver® infrastructure, such as SAP NetWeaver® Application Server, SAP NetWeaver® Portal, and SAP NetWeaver® Process Integration.

However, a reader will require some basic knowledge of SAP technology, such as the SAP NetWeaver® Application Server, the ABAP™ programming language, or the Enqueue mechanism. Therefore, these technology topics will be introduced first (see chapter 1.3).

Who Should Read This Book?

This book is written for everyone interested in the conceptual architecture of SAP ERP:

Students/scientists will get to know how the complex world of current business processes is mapped to and executed by software systems. This may be interesting for students of computer science as well as for student of economics.

Consultants who are working on SAP implementation projects and need to get insight in how SAP ERP works. This book does not tell how to set relevant customizing settings to adapt business processes, but tells the structure of SAP ERP in principle and how the different components work together to execute business processes.

CIOs and IT managers who already run SAP ERP and always wanted to know what it does and how it works. This book is not a user manual explaining how to work with a specific screen but introduces the basic functions of SAP ERP and how they are executed in the system.

Acknowledgements

The documentation of software architecture has a long tradition at SAP. More than twenty years ago, in 1990, work on the first architecture bluebooks about the SAP R/3 basis system started. Since then, an impressive number of internal technical reports about products and technology from SAP were written by skilled writers with deep technical and architectural backgrounds. This book relies on their work.

Our big thanks go to the four authors, Sagar Joshi, Sathish Karthik R, Wolfram Kleis, and Sushil Kumar, for their excellent work and strong commitment to make this book reality. We also thank the board members Vishal Sikka and Gerhard Oswald as well as senior management at SAP, especially Uma Rani and Gordon Mühl, who support our long-term goal to spread the SAP ERP architecture knowledge.

We owe a debt of gratitude to the many experts and reviewers who helped to collect and correct all the architectural facts of a software system grown over more than a decade:

Vinodh A R, Richa Agarwal, Martin Arzt, Edwin Bach, Volker Barth, Andreas Baur, Stefan Bäuerle, Christian Behrens, Artur Berlinger, Martin Beykirch, Robert Bieber, Holger Bohle, Rüdiger Buck-Emden, Peter Buendgen, Sidhartha Chakravarty, Srikanth Chandru, Puspen Chattopadhyay, Thomas Christ, Uwe Dieckbreder, Iris Dopfer-Hirth, Hagen Eck, Sven-Eric Eigemann, Holger Ulrich Eisele, Dietmar Engelmann, Michael Eyd, Thomas Fritzsche, Vishwanath G, Dieter Gietl, Matthias Grimm, Thomas Gruber, Thomas Haertlein, Jörg Heitmann, Peter Himmighoefer, Manfred Hirn, Steffen Hoffmann, Ralf Humbert, Kannan K R, Andreas Kasper, Reiner Kastner, Andreas Kemmler, Thomas Kessler, Marcel Kieser, Volker Kleinhenz, Wolfram Kleis, Christian Klensch, Arndt Koester, Alla Korchminskaya, Hari Krishna K, Wolfgang Kuhn, Aruna Kumari S, Sundaresan LN, Michael Lang, Thomas Lehnecke, Seshatalpasai Madala, Biraj Mandavilli, Ankush Mane, Andreas Martin, Andreas Mirbach, Klaus Moser, Alexander Mueller, Klaus Mueller, Ravi Murthy, Ralf Müller, Ursula Nani, Frank Nuxol, Bernd Oberdorf, Vidya Omprakash, Carsten Pluder, Kartik R, Uma Rani T M, Susanne Richter, Sven Richter, Gerhard Rupp, Vijaya Sarathi Durvasula, Friedrich Schattmaier, Horst Schnörer, Martin Scholz, Juergen Alfred Seyfried, Andreas Siebel, Ralph Stadter, Tobias Stein, Thomas Steiner, Sreeram Subram N, Scott Sun, Balaji Sundaram S., Silke te Uhle, Winfried Teltscher, Georg Tewes, Marco Valentin, Shrikant Varma, Rolf Walthemathe, Pranav Wankawala, Lai Wei, Olaf Wellm, and Markus Wolf.

A special thank you to Andreas Huppert (//hupperts.de/) for providing the cover photo.

The Editors

Jochen Böder, Bernhard Gröne SAP AG

1   Architecture of SAP ERP

Authors: Jochen Böder, Bernhard Gröne

1.1   SAP ERP Overview

Figure 1-1: Overview of SAP ERP.

SAP ERP1 – earlier named SAP R/3 - is SAP’s software for enterprise resource planning. It supports all core business processes and functions required by today’s enterprises and embraces SAP ERP Operations, SAP ERP Financials, and SAP ERP Human Capital Management, complemented by common corporate services. Industry-specific enhancements make the software fit requirements specific for one industry, such as automotive, healthcare, high tech, retail or insurance.

1.1.1    SAP ERP Operations

SAP ERP Operations is SAP’s core solution for procuring, selling, producing, stocking, shipping, and transporting material2. It contains the following functions:

•   

Sales and distribution (SD), which includes the creation of sales orders, checking the availability of the requested products, price calculation, and finally delivery and billing

•   

Materials management (MM), which includes the creation of purchase orders for procuring material and services from external vendors, verifying incoming invoices, and managing the inventory

•   

Production planning (PP), which includes planning the production of the materials and execution

•   

Logistics execution (LE), which controls and organizes the movement of material

•   

Quality management (QM), which includes quality planning, quality inspection, and quality control during sales, production, and procurement

These functions are closely integrated using database integration. This ensures reliable business processes across the different SAP ERP Operations components based on consistent data. Based on the same mechanism, SAP ERP Operations communicates with SAP ERP Financials. All components share the same material master data.

The functional scope of SAP ERP Operations can be extended by integrating it with the other SAP Business Suite applications, such as SAP Customer Relationship Management, SAP Supply Chain Management, and SAP Supplier Relationship Management.

1.1.2    SAP ERP Financials

SAP ERP Financials is SAP’s core solution for financial accounting, controlling, financial supply chain management, and treasury functions. SAP ERP Financials consists of the following application components:

The financial accounting (FI) component records, classifies, and summarizes the financial transactions of a company. For this purpose, financial accounting provides general ledger, accounts payables and receivables, and asset accounting. Financial accounting records business transactions, such as customer invoice, vendor invoice, payment, and clearing, as financial documents. Based on transaction figures/balances in these documents, financial accounting periodically generates the balance sheet as well as profit and loss financial statements, which are then reported to the government, investors, and other interested parties.

The management accounting (CO) component is used for internal accounting within a company to prepare operating data such as product costing, cost of goods sold, overheads, and actual costing of inventory. This operative data is used for the business analysis of the company and to support management decisions.

The financial supply chain management (FSCM) component processes accounts receivables and accounts payables to help ensure a smooth inflow of funds. In addition, it contains collection management, dispute management, online payment facilities for customers (biller direct) and vendors (payer direct), and credit management to check on credit awarded to a customer.

Treasury applications from SAP help ensure proper cash flow and liquidity of the company for smooth day-to-day operations. Funds, derivatives, securities, loans, financial stocks, and market risks are also managed within the treasury applications.

1.1.3    SAP ERP Human Capital Management

SAP ERP Human Capital Management (SAP ERP HCM) is the SAP solution for managing the people working for an organization. SAP ERP HCM is part of SAP ERP, but it can be deployed separately from the other SAP ERP solutions to protect sensitive employee data.

SAP ERP HCM is split into three layers. The foundation consists of the SAP ERP HCM core components, which implement the core HR processes, such as organizational management, personnel administration, payroll, personal development, and time management. They provide data and functions that are reused by SAP ERP HCM extension components, which support additional processes such as e-recruiting and enterprise learning. On top reside the SAP ERP HCM service delivery components, which enable users to interact with the SAP ERP HCM components via different channels and media – for example, self-services, employee interaction center, and online forms.

The SAP ERP HCM data model is based on “infotypes.” One infotype defines the data structure for semantically related data, which is stored together on the database and also displayed together on the user interface. Infotypes support the time-dependent storage of data, which is important in HCM processes.

HCM processes are typically country-specific and have to comply with many legal requirements. Infotypes support different country-specific variants of user interface (UI) logic. Also, the business logic can be extended for processing country-specific logic. In payroll, country-specific payroll drivers have been introduced to provide corresponding payroll runs.

1.2   SAP ERP and SAP Business Suite

Over time SAP ERP got support by a collection of enterprise applications specifying on certain use cases. This collection is the SAP Business Suite (see figure 1-1). Its most prominent members are the following:

•   

SAP CRM (Customer Relationship Management) supports all processes involving direct customer contact throughout the entire customer relationship life cycle – from market segmentation, sales lead generation and opportunities to post-sales and customer service. SAP CRM includes business scenarios such as field sales and service, Internet Sales and Service and the Customer Interaction Center.

•   

SAP SRM (Supplier Relationship Management) is a comprehensive approach to managing the flow of information between a company and its suppliers. Purchasing data is consolidated and classified to develop efficient procurement strategies that lead to more effective negotiations with suppliers and lower costs.

•   

SAP SCM (Supply Chain Management) provides the planning, fulfillment, regulation, and tracking of supply chain activities in order to add value, build competitiveness, strengthen logistics, match supply with demand, and measure performance.

•   

SAP BW (Business Information Warehouse) provides data warehousing functions, a business intelligence platform, and a suite of business intelligence tools. These tools enable businesses to integrate, transform, and consolidate relevant business information in SAP BW. SAP BW facilitates the reporting, analysis and distribution of this information. On the basis of this analysis, businesses can make well-founded decisions and determine target-oriented activities. With the comprehensive predefined information models delivered for different roles in a business (BI Content), SAP BW increases the usability of analysis functions and facilitates a quick and cost-effective implementation. SAP BW is a core component of SAP NetWeaver.

•   

SAP GRC (Governance & Risk Compliance) offer organizations with solutions that address risk management, corporate governance and regulatory compliance.

•   

SAP MII (Manufacturing Integration and Intelligence) provides a direct connection between shop-floor systems and business operations. It ensures that all data that affects manufacturing is visible in real time – including information about orders, materials, equipment status, costs, and product quality.

Many more systems integrate with SAP ERP that are not bundled in the SAP Business Suite, such as mobile device integration or cloud applications. Of course many non-SAP systems also integrate with SAP ERP, using public interfaces defined by SAP. Refer to section 1.3.5 for an overview of the technologies used for integration.

1.3   Technical Architecture of SAP ERP

The runtime and design time environment of SAP ERP is the technology platform SAP NetWeaver. All parts of SAP ERP are developed using the SAP NetWeaver Application Server ABAP (formerly known as SAP Basis) which provides a specific design time environment for developing business applications and a robust runtime environment for operating them.

In addition the following SAP NetWeaver infrastructure components are used together with SAP ERP (see figure 1-2):

•   

SAP NetWeaver Process Integration is a messaging middleware for integrating SAP ERP processes with processes running on other SAP applications or legacy software.

•   

SAP NetWeaver Portal to provide role-based views on business functionality and information provided by multiple applications. It allows implementing a company intranet portal which integrates functionality from SAP ERP, such as employee self-services for address maintenance and vacation requests as well as purchasing.

•   

SAP NetWeaver Business Warehouse to provide data warehouse capabilities for business data extracted from SAP ERP

•   

The SAP Solution Manager is a tool to set up, manage and monitor the system landscape. Many administrative and operational tasks can be done using this tool, which is aware of all three dimensions. Among others, SAP Solution Manager offers the following services:

   ○   

Documentation of technical landscape and business processes

   ○   

Implementation support including downloading and installing software updates for SAP software,

   ○   

Global rollout templates and workflow-based management of changes.

   ○   

Monitoring system availability and key processes

   ○   

Central application incident management

   ○   

Offering secure remote access for SAP support consultants

SAP Solution Manager is the backbone of SAP support services and therefore part of each SAP system landscape.3

In the following we give a short introduction to the technical architecture of SAP ERP with focus on the SAP NetWeaver Application Server ABAP. Readers who want to dig deeper into this topic, find details about the technical architecture of SAP R/ 3 and SAP Basis at [Buc99].

Figure 1-2: SAP ERP Running on SAP NetWeaver Infrastructure

During software development, the main purpose of software architecture is to guarantee that the resulting software fulfills given quality requirements (see [BCK06]). Among the qualities which made SAP ERP a tremendous success, scalability, robustness, portability and adaptability are crucial ones. They rely to a large extent on the underlying SAP technology.

•   

Scalability and robustness are given by using the three tier client/server architecture. In a nutshell, data is stored in a central database system, while processing is performed in an open number of application servers that communicate with the user interface (UI) clients. This cluster architecture allows for scalability to a high degree (see chapter 1.3.1).

•   

Portability is ensured by abstracting the SAP NetWeaver Application Server from the underlying operating systems and databases. Aspects such as transactions and enqueues (logical locks) are managed on application server level, not on database level (see chapter 1.3.2).

•   

Efficient development is supported by the tailored programming language ABAP that abstracts from technical details and allows focusing on business logic. A built-in transportation mechanism allows transferring software changes from one system to another, such as from development system to test system to productive system.

With SAP ERP Operations, SAP ERP Financials, and SAP ERP Human Capital Management, business functionality has been separated in components which however share one common database. By this, all business processes are integrated with each other. This enables for example sales processes to trigger financial processes and vice versa.

1.3.1    Three Tier Client Server Architecture

While the predecessor system SAP R/2 used mainframe architecture, SAP R/3 (and thereby SAP ERP with its underlying SAP NetWeaver Application Server) uses a scalable three tier client-server architecture.

Figure 1-3 shows the overall architecture. In the client layer, a generic user interface player such as the SAP GUI or a WWW Browser interacts with the user. The graphical user interfaces are typically form-based with a number of extensions (for example file transport to and from the user’s machine).

The actual business data is exclusively processed in the application layer. Application servers keep user sessions, cache database data, but can also be used for administrative or development tasks. Interactive sessions are called dialog sessions, but other roles of sessions are also possible within one application server: Batch or scheduled job processing (without user interaction), RFC (Remote Function Call) / Web service handling (interaction with other systems), or Update Task (see chapter 1.3.2).

The database layer finally implements a common database shared among all application servers. This database also includes metadata and source code of all programs.4 No data processing aside from store, search and retrieve is happening at the database layer.

One of the major advantages of this cluster architecture is scalability. If more computing power is required or the number of concurrent users increases, the administrator just has to add an application server to the system. Since the programs are located in the central database, only a basic machine-dependent installation procedure is necessary on a new machine. After registering the machine in the cluster using the message server, it quickly becomes a further application server of the system.

Figure 1-3: Three Tier Client-Server Architecture of SAP ERP5

Please note that the programming model differs significantly from the technical client-server architecture: Data processing is done exclusively on application servers, the same is true for the implementation of user interaction. A database abstraction together with a data dictionary (DDIC) integrates all database operations in the programming language used on the application server. This language is called ABAP (see chapter 1.3.3), and is compiled at run-time when a program is started for the first time. The user interface is abstracted as well: Here, the Dynpro (“Dynamic Program”) concept allows building graphical form-based user interfaces quickly that use the data types from the data dictionary (DDIC) and integrate with the ABAP Programs. Web Dynpro is similar, but uses a WWW browser as generic UI client. Furthermore, ABAP programs are single threaded.

With this technical architecture application developers can focus on applications, while basic tasks such as database connection handling or network communication are covered by the SAP NetWeaver Application Server.

1.3.2    Transaction Concept

As a consequence of the three tier architecture, a number of sessions on various application servers need access to shared data on one common database. This is typically solved on database level with a transaction concept and locks. Due to performance reasons, it was not reasonable to span a single database transaction over multiple dialog steps6 within one session. In addition, using automatic database locks lead to longer lock duration than necessary from business side, which could lead to massive performance problems in larger installations.

Figure 1-4: Enqueue Server and Update Task

The solution was to lift the transaction and lock mechanism from database level to the SAP NetWeaver Application Server: Transactions are called Logical Unit of Work (LUW), modifying database operations are handled by the Update Task, Locks, called Enqueues, are handled by an Enqueue Server and have to be used by convention, not automatically.

By convention, applications register modifying database operations in the update task by using the ABAP statement call function in update task. In case an application needs exclusive access to a shared resource (such as a record in a database table) it acquires a logical lock (Enqueue). With the commit work statement, the applications request closing the LUW; the update task performs all registered database operations and then informs the enqueue server which releases the logical locks. Consequently, a rollback work statement discards all registered database operations and releases the logical locks as well.

Figure 1-4 shows the system7 with focus on the transaction concept. Please note that the number of applications and update tasks varies, while only one database management system and only one enqueue server are allowed in the system.

Figure 1-5: Enqueue Server and Update Task: Typical Sequence

In figure 1-5, the difference between Enqueues and (automatic) database locks becomes obvious: While an enqueue can be set at the start of a series of dialog steps, the records in the database will be locked in the end, when the update tasks performs the database operations that had been registered before.

1.3.3    ABAP

The majority of software that makes an SAP ERP system, be it on the business level or on framework level, is written in ABAP (Advanced Business Application Programming). The roots of ABAP are in a macro assembler language used in R/2 to create reports. Until now, the language has undergone many iterations and enhancements, for example the support of object oriented programming (ABAP Objects). In general, ABAP is optimized to work on database tables, for example by sharing a common data dictionary to use the database types in the applications and vice versa, or by offering tables as local variables on application level (called internal tables).

In contrast to library-oriented languages such as C/C++ or Java, ABAP provides a wide set of statements and modifiers to integrate a big number of framework features directly in the programming language.

Examples of Framework features in the ABAP Language

Move-Corresponding allows copying a subset of fields among two different records (with different types!). At execution time, it checks for each field of the source record whether a field with same name exists at the destination record, and copies the selected content only, leaving the rest untouched. The advantage is that the record types can be extended without having to touch the code.

Call Function … Destination … implements a remote function call (RFC, see below). It uses the same syntax as the call of a function module; the additional keyword “Destination” is used to identify the remote system via customization settings.

There are several books about the programming language ABAP, for example [Kel05] and [HeJ11].

1.3.4    Customizing and Extending the System

As standard software, SAP ERP has to be adapted to the specific situation of an enterprise, including its organization structure or locations. The general term for configuring the system is customizing8, defined as “the entries made by the customer to implement an SAP System”.

Several thousands of parameters control the behavior of the SAP ERP system. They are stored in a special set of tables, the so-called IMG tables (IMG stands for Implementation Guide). A separate set of user interface transactions can be used to set the parameters, i.e. customize the system.

To extend an SAP ERP system with own functionality, a number of technologies have been offered since the first SAP R/3 releases. The recommended one is called BAdI (Business Add-In). BAdIs are a mechanism for planned extensibility9. Planned means that the developer of the standard software already anticipates that others may want to change or enhance the standard behavior at certain points in the application. BAdIs are used to plug in custom behavior either in an additive way or by replacing the standard behavior. The purpose can be to implement a custom variant of some calculation or to override a default strategy.

1.3.5    Integration Concepts

From a software perspective it is a characteristic of business processes that business data is continuously changed by different process steps. To manage this, the different software parts which implement the process steps have to communicate or phrased differently – the software components have to be integrated. SAP ERP uses multiple integration concepts offered by the underlying SAP NetWeaver infrastructure.

For application-to-application (A2A) communication between the different subcomponents, database integration is used. In database integration, the sending and receiving components share database tables. To transfer data, the sending component creates records in these tables, which then triggers follow-up processing in the receiving component. The sending component creates the records in the transfer tables within the same logical unit of work (LUW) as it stores the business data processed in the transaction. This makes database integration very reliable. Data transfer only happens when the business transaction can be processed successfully (see chapter 1.3.2).

In principle all SAP ERP components share one common database. However, it is possible to deploy SAP ERP HCM on a separate system with its own database. SAP ERP Financials, SAP ERP Operations, and SAP ERP Corporate Services typically run on one system.

In a typical deployment scenario, the SAP ERP Operations share one system with a common database with SAP ERP Financials. But in distributed deployment scenarios, SAP ERP Operations and SAP ERP Financials also use the same master data, such as material, customer, and vendor. Typically SAP ERP HCM is operated on a separate system and integrated with SAP ERP Financials using the application link enabling (ALE) integration technology and IDoc.

At a customer site, an SAP ERP system doesn’t stand isolated from the rest of the world. As explained in chapter 1.2, SAP ERP integrates with SAP Business Suite, but also with other software systems. A number of technologies are available as well.

The basic technology to communicate with an SAP ERP system is called RFC (Remote Function Call). A programmer marks an ABAP Function Module as enabled to be called remotely. The interface of the function module is exhibited as a remote interface. It can be called from any RFC client10 that can authenticate against the called SAP ERP system.

BAPI (Business Application Programming Interface) is a standardized programming interface that enables external applications to access business processes and data in an SAP ERP system. BAPIs are defined in the business object repository (BOR) as methods of SAP business object types that carry out specific business functions. BAPIs are implemented as RFC-enabled function modules and are created in the Function Builder of the ABAP Workbench.

IDoc (Intermediate Document) is a standard SAP format for electronic data interchange between systems. An IDoc type can contain multiple message types, for example both purchase order and order confirmation. IDocs are used for example in Electronic Data Exchange (EDI) or in data distribution in a system group.

ALE (Application Linking and Enabling) supports distributed, yet integrated processes across several SAP systems using IDocs and RFC calls.

Enterprise Services are SOAP-based Web services which provide access to the business functionality of SAP systems. Enterprise services are structured according to a harmonized enterprise model based on process components, business objects and global data types11.

SAP ERP provides synchronous and asynchronous A2A and B2B12 enterprise services. Synchronous services are point-to-point, whereas asynchronous services are mediated through SAP NetWeaver Process Integration which supports exactly-once-in-order and forward error handling. Business object events and delta update mechanisms are provided for several scenarios.

Lately SAP introduced the infrastructure hub SAP NetWeaver Gateway which provides access to SAP ERP using REST-based OData services. Especially mobile applications use OData services to access SAP ERP functionality13.

1.3.6    System Landscapes

Several dimensions have to be considered to derive the system landscape and the number and role of server machines (physical or virtual ones) used in a typical SAP ERP installation.

First of all, an SAP ERP system provides the so-called clients. A client is an organizational unit identified by an ID (three digits, e.g. 001). When users log on to the system, they have to select the client to work on. Clients have separate business data, users and authorizations, but they share the same programs and database structure. Companies can, for example, set up separate clients for business tasks, for testing, or for education. There are also preconfigured clients, such as the reference client (000), which is reserved for settings and data delivered by SAP.

First dimension is the structure of a single SAP ERP system, which is typically set up as a cluster of servers. As described in chapter 1.3.1, SAP ERP scales with the number of application servers. Therefore the server instances of an SAP ERP system can be installed on separate machines: one database host and one or more application server hosts, depending on the role and the expected load. As figure 1-3 shows, software is deployed centrally via the database; only the kernel has to be installed on each application server host separately.

Second dimension is the role of the SAP ERP system in the Software Lifecycle