U
PGRADING
LICENSE, DISCLAIMER OF LIABILITY, AND LIMITED WARRANTY
The CD-ROM that accompanies this book may only be used on a single PC. This license does not permit its use on the Internet or on a network (of any kind). By purchasing or using this book/CD-ROM package(the “Work”), you agree that this license grants permission to use the products contained herein, but does not give you the right of ownership to any of the textual content in the book or ownership to any of the information or products contained on the CD-ROM. Use of third party software contained herein is limited to and subject to licensing terms for the respective products, and permission must be obtained from the publisher or the owner of the software in order to reproduce or network any portion of the textual material or software (in any media) that is contained in the Work.
INFINITY SCIENCE PRESS LLC (“ISP” or “the Publisher”) and anyone involved in the creation, writing or production of the accompanying algorithms, code, or computer programs (“the software”) or any of the third party software contained on the CD-ROM or any of the textual material in the book, cannot and do not warrant the performance or results that might be obtained by using the software or contents of the book. The authors, developers, and the publisher have used their best efforts to insure the accuracy and functionality of the textual material and programs contained in this package; we, however, make no warranty of any kind, express or implied, regarding the performance of these contents or programs. The Work is sold “as is” without warranty (except for defective materials used in manufacturing the disc or due to faulty workmanship);
The authors, developers, and the publisher of any third party software, and anyone involved in the composition, production, and manufacturing of this work will not be liable for damages of any kind arising out of the use of (or the inability to use) the algorithms, source code, computer programs, or textual material contained in this publication. This includes, but is not limited to, loss of revenue or profit, or other incidental, physical, or consequential damages arising out of the use of this Work.
The sole remedy in the event of a claim of any kind is expressly limited to replacement of the book and/or the CD-ROM, and only at the discretion of the Publisher.
The use of “implied warranty” and certain “exclusions” vary from state to state, and might not apply to the purchaser of this product.
U
PGRADING
SAP
®
M. SENS
I
NFINITYS
CIENCEP
RESSLLC
Hingham, Massachusetts New Delhi, India
This publication, portions of it, or any accompanying software may not be reproduced in any way, stored in a retrieval system of any type, or transmitted by any means or media, electronic or mechanical, including, but not limited to, photocopy, recording, Internet postings or scanning, without prior permission in writing from the publisher.
This book contains references to the products of SAP AG, Dietmar-Hopp-Allee 16, 69190 Walldorf, Germany. The names of these products are registered and/or unregistered trademarks of SAP AG. SAP AG is neither the author nor the publisher of this book and is not responsible for its content.
Publisher: David Pallai
I
NFINITYS
CIENCEP
RESSLLC
11 Leavitt Street Hingham, MA 02043 Tel. 877-266-5796 (toll free) Fax 781-740-1677
[email protected] www.infinitysciencepress.com
This book is printed on acid-free paper. M. Sens. Upgrading SAP®
ISBN: 978-1-934015-15-5
The publisher recognizes and respects all marks used by companies, manufacturers, and developers as a means to distinguish their products. All brand names and product names mentioned in this book are trademarks or service marks of their respective companies. Any omission or misuse (of any kind) of service marks or trademarks, etc. is not an attempt to infringe on the property of others. Library of Congress Cataloging-in-Publication Data
Sens, M.
Upgrading SAP/M. Sens. p.cm.
1. SAP R/3. 2. Business—Computer programs. 3. Client/server computing. 4. Management information systems. I. Title.
HF5548.4.R2S46 2008 650.0285' 53—dc22
2007050776 8 9 10 4 3 2 1
Our titles are available for adoption, license or bulk purchase by institutions, corporations, etc. For additional information, please contact the Customer Service Dept. at 877-266-5796 (toll free). Requests for replacement of a defective CD-ROM must be accompanied by the original disc, your mailing address, telephone number, date of purchase and purchase price. Please state the nature of the problem, and send the information to INFINITY SCIENCE PRESS, 11 Leavitt Street, Hingham, MA 02043.
The sole obligation of INFINITY SCIENCE PRESS to the purchaser is to replace the disc, based on defective materials or faulty workmanship, but not based on the operation or functionality of the product.
Chapter 1 Introduction 1 Chapter 2 What is SAP Software? 3 Chapter 3 SAP Layers and Architecture 7
3.1 SAP Client Server Architecture 7
3.2 OLTP Versus OLAP 10
3.3 SAP Installable Software Units 12
Chapter 4 SAP Software Logistics 15
4.1 SAP Development Objects 16
4.1.1 Object Classification 16 4.1.2 ABAP 17 4.1.3 Development Classes 20 4.1.4 Name-Ranges 21 4.1.5 Namespaces 22 4.1.6 Number Ranges 23 4.1.7 Development Locks 23 4.1.8 Development Keys 24 4.2 Data Tables 25 4.2.1 Table Types 26
4.2.2 Table Delivery Types 30
4.2.3 Table Data Classes 30
4.2.4 Indexes 31
4.2.5 Table Technical Settings 32
4.2.6 Table Logging 32
4.2.7 DBDIFF 33
4.3 Customizing Objects 34
4.4 Other Objects 35
4.5 Correction and Transport System 40
4.5.1 Transport Activities 41
4.5.2 Transport Management System 41
4.5.3 Transport Requests 43
4.5.4 Transport Tools 45
4.5.5 Transport Steps 46
4.5.6 DDIC Import 48
4.5.7 Activation and Distribution 50
4.5.8 Running the XPRA Job 52
4.6 Client Copies 53
4.6.1 Remote Client Copies 57
4.6.2 Multiclient Manager 59
4.7 Support Packages 59
4.7.1 Support Package Types 60
4.7.2 SAP Patch Manager 61
4.7.3 Conflict Resolution Transports 61
4.7.4 Support Package Import Phases 62
4.7.5 Support Packages in R/3 Enterprise 64
4.7.6 Support Package Stacks 66
4.7.7 Support Packages as of NetWeaver 7.0 67
4.7.8 Tables Used with SPAM 68
4.7.9 SPAM Queue Conflicts 68
4.7.10 SAP Download Manager 69
4.8 SAP Maintenance Optimizer 70
4.9 Industry Solutions and Add-Ons 72
4.9.1 Installation Using R3up 73
4.9.2 Installation Using SAINT 75
4.10 Enhancement Framework 76
4.11 Switch Framework 77
4.12 SAP Notes 79
4.13 Release Upgrades 80
4.14 SAP Kernel Patches 80
4.15 Enhancement Packs 81
4.16 Languages 82
Chapter 5 Reason for Upgrading 87
5.2 Maintenance Strategy 90
5.3 New Functionality 91
Chapter 6 Difference between Upgrade and Implementation 93
6.1 Implementation and Support 93
6.1.1 Business Process Support team 94
6.1.2 SAP Functional Support team 95
6.1.3 SAP ABAP Support team 95
6.1.4 SAP Basis/Technology Support team 95
6.1.5 Remaining Tasks 95
6.1.6 Required Number of Staff 96
6.1.7 SAP Customer Competency Center 96
6.2 Technical Upgrade Only 98
Chapter 7 Hardware-Related Items 99
7.1 Supported Hardware Platforms 99
7.2 Increased Complexity of System Landscapes 100
7.3 Server and Database Consolidation 101
7.4 MCOD 102
7.5 MCOS 104
7.6 Sizing for the New Release 105
7.6.1 Key Performance Indicators 107
7.6.2 Used Software Components 108
7.6.3 Number of Concurrent Users 108
7.6.4 Database Growth pattern 109
7.6.5 Application Availability 109
7.6.6 Location of Users 110
7.7 Preparations on Hardware and Software 110
7.7.1 OS/DB Migration 111
7.7.2 OS/DB Upgrade 113
7.7.3 SAPGUI and ITS 113
7.7.4 Third-Party Products 115
Chapter 8 Upgrade Technology 117
8.1 Technical Objective 117
8.2 Delta Upgrade 118
8.4 Upgrade Key 121
8.5 SAP Upgrade Assistant (Classic) 122
8.6 SAP Upgrade Assistant (New) 125
8.7 Other Upgrade Tools 125
8.8 SAPUp and SAPJUp 126
8.9 Add-Ons and Industry Solutions 128
8.10 Add-Ons and Industry Solutions (as of ERP 6.0) 132
8.11 BIND_PATCH 133 8.12 Plug-In Additions 136 8.13 Languages 136 8.14 User Modifications 137 8.14.1 Preserve Modifications 137 8.14.2 SPDD 138 8.14.3 SPAU 140
8.14.4 Transporting Modification Adjustments 143
8.14.5 Modification Assistant 144
8.15 Upgrade Directory 146
8.16 Upgrade Log Files 147
8.17 TOOLIMPORT 148
8.18 Cleaning the System 149
8.19 Shadow Tables 150 8.20 Repository Switch 151 8.21 Table Conversion 155 8.22 ICNV 160 8.23 DDIC Substitution 163 8.24 ACT – Activation 164 8.25 Kernel Switch 165
8.26 Upgrade Downtime Strategy 167
8.27 System Switch Upgrade 169
8.28 TABIM 174
8.29 XPRA – Report After Put 175
8.30 Preparation Steps 176
8.30.1 Saving Wage Types 176
8.30.2 Extension of Database Size 176
8.30.3 Reuse of Variants 177
8.31 Post Steps 178
8.31.1 Generate ABAP Load 178
8.31.2 Generate ABAP Query Reports (R/3 4.0B) 179 8.31.3 Solve P Errors in LONGPOST.LOG 180
8.31.4 Adjust Authorizations 180
8.31.5 Removal of “Obsolete” Tablespaces 181
8.31.6 New General Ledger 181
8.31.7 Install Optional SAP J2EE Engine 182
8.31.8 Reset the Upgrade 182
8.31.9 Maintain Shadow Instance 183
8.31.10 Upgrade Elapse Time 183
8.32 CBU (Customer-Based Upgrade) 184
Chapter 9 Unicode Conversion 187
9.1 Conversion Process 188
9.2 Unicode Preparation 189
9.3 Database Conversion 192
9.4 Unicode System Requirements 192
9.5 Unicode Kernel 193
9.6 Combined Upgrade and Unicode Conversion 193
Chapter 10 Upgrade Project Management 197
10.1 ASAP for Upgrade 198
10.2 DSDM for SAP 199
10.3 Project IMG for Upgrade 201
10.4 Project Organization and Roles 202
10.5 Business Case 203
10.6 Budget Planning and Cost Calculation 206
10.7 Project Runbook 208
10.8 Testing 208
10.8.1 Business Process Testing 209
10.8.2 Component Testing 209
10.8.3 Integration Testing 210
10.8.4 Stress and Performance Testing 211
10.8.5 Runbook Testing 211
10.8.6 Automatic Testing 212
10.9.1 System Landscape Scenarios 215
10.9.2 Cross-Release Transports 220
10.9.3 Show System Information 221
10.10 Process Owners—SAP CCC 221
10.11 BC Sets 222
10.12 Business Engineer 224
10.13 ABAP and Other Objects 224
10.14 Authorizations 225
10.15 Issues During Upgrade 228
10.16 Actions to do Before Upgrade 229
Chapter 11 Third-Party Tools 231
11.1 Monitoring Tools 231
11.2 Transport Tools 233
11.3 Interface Tools 234
11.4 Tax Calculation Tools 234
11.5 Other Tools 234
Chapter 12 SAP New Dimensions Products 237
12.1 Business Information Warehouse 237
12.1.1 BW Alpha Conversion 238
12.1.2 BW Business Content 239
12.1.3 BW-Specific Upgrade 241
12.1.4 SAP BI Lock Server 242
12.1.5 BI Accelerator 242
12.2 SRM (Supplier Relationship Management) 243 12.3 CRM (Customer Relationship Management) 245
12.4 SCM (Supply Chain Management) 247
12.4.1 SCM Middleware 247
12.4.2 SCM Upgrade 249
12.5 Process Integration 250
Chapter 13 SAP NetWeaver Java AS 253
13.1 Deploy Options 254
13.2 Java Startup and Control Framework 257
13.3 Java Trace and Log Files 259
13.5 Automatic Startup of Java Instance 260
13.6 Java Managers and Services 261
13.7 Java Configuration Management 264
13.8 Java-Specific Filesystems 265
13.9 Java Database Access 265
13.10 Java Patch Management 266
13.11 SAP NWDI—Java Change Management 267
13.12 SAP Visual Composer 269
13.13 SAP NetWeaver Composition Environment 271
13.14 Adobe Document System 271
13.15 CTS+ 272
Chapter 14 Support Tools 275
14.1 ASU (Application Specific Upgrade) 275
14.2 SAP Solution Manager 276
14.3 SEP (Support Enablement Package) 279
14.3.1 RBE (Reverse Business Engineer) 280
14.3.2 SAP CDOP 281
14.3.3 SAP TDMS (Test Data Migration System) 282
14.4 LAW (License Audit Workbench) 283
14.5 Upgrade Roadmap 283
14.6 ARIS for NetWeaver and RBEplus 284
14.7 Assessment with IntelliCorp 285
14.8 Additional Information Resources 285
14.9 Upgrade Coaching 286
Chapter 15 The Direction of SAP 287
15.1 Roadmaps 287
15.2 SAP xApps 288
15.3 eSOA 289
15.4 BPP (Business Process Platform) 291
15.5 BPEL (Business Process Execution Language) 292
15.6 New Roles and Responsibilities 293
15.7 User Interfaces 293
15.8 On-Demand Computing 294
15.9 SAP Adaptive Computing Infrastructure 294
15.11 Downtime Prevention 298
15.12 Future Trends 299
Appendix A: List of SAP R/3 “Object Identifiers” 301 Appendix B: ASAP of Upgrade Roadmap 305 Appendix C: Additional Web Resources 311 Appendix D: About the CD-ROM 313
Index 315
This book contains references to the products of SAP AG, Dietmar-Hopp-Allee 16, 69190 Walldorf, Germany. The names of these products are registered and/ or unregistered trademarks of SAP AG. SAP AG is neither the author nor the publisher of this book and is not responsible for its content.
Chapter
1
I
NTRODUCTION
T
oday, more than 12 million people in 120 countries that work for 36,200 companies are using SAP® on a regular basis. This represents somewhere around 100,600 SAP installations, which had to be built, configured, and, after a while, upgraded to the next release. This process is known as “Upgrading SAP.”“Upgrading SAP” provides a complete overview of the upgrade process from one SAP release to the next. In addition, it explains the use of all relevant SAP upgrade tools. Besides a technical description of the SAP NetWeaver® Application Server (AS), it also puts some attention on the people aspect of such upgrade project and the management of it. “Upgrading SAP” is not only about IT, it is also about the question of how to leverage new opportunities and functionality of new SAP releases.
Examples in this book are based on various SAP products and releases, such as SAP NetWeaver 2004, 7.0 (also known as 2004S), 7.1, and SAP Business Suite 2005 with ERP, BI, CRM, SCM, and SRM. The intent is to inform a broad audience with sufficient information to make any SAP upgrade project a success. Conceived as both a teaching book and a manual, this book brings together all the techniques, background information, notes, tips, and tricks needed for any SAP upgrade project.
After a brief introduction to the subject of SAP upgrades in Chapters 1 and 2, Chapter 3 deals with the overall architecture of SAP software. It is used to give some insight on where all things fit. Chapter 4 provides a technical overview of SAP development and deployment tools. Chapter 5 briefly describes why an
organization should upgrade its SAP software. It can be used to construct a business case for any company to convince senior management on the benefits of upgrading. Chapter 6 tries to bring people to the next level; from implementation to upgrade-oriented thinking. Chapter 7 shows the various hosting options for everything related to the question of what infrastructure is required to host my SAP system. Chapter 8 deals with the upgrade process itself. All the tools and technology are described in detail. Chapter 9 is about the Unicode conversion, which might be part of your upgrade project. Chapter 10 is about project management and SAP upgrades. It describes the management of a SAP landscape during the upgrade project. Chapter 11 provides an overview of third- party software that is relavant to an SAP upgrade. Chapters 12, 13, and 14 deal with the other SAP software products, components, and support tools. And finally, Chapter 15 takes a look at what the future might bring.
The names of the individual SAP products are subject to changes quite often. It is for this reason that names like R/3, ERP, and ECC are used for the same product. The same applies for XI and PI, for BW and BI, and for Web AS, WAS, and AS; and for SAP NetWeaver 2004S and NetWeaver 7.0.
Chapter
2
W
HAT
IS
SAP S
OF TWARE
?
T
here are several definitions of SAP Software. When people refer to SAP, they mean SAP R/3®, the ERP software package. When SAP released R/3 back in 1992, it was still clear what people meant by SAP software. Besides the mainframe software R/2®, R/3 was the only software SAP shipped in those days. Times have changed. SAP currently delivers a wide range of software and business solutions and packages. The solutions are so-called vertical business oriented, which means that SAP creates solutions for an entire business column, like the food or the telecommunications industry. Within such an industry, SAP offers different packed solutions. Each type of business does share common business processes like finance, product development, procurement, sales and Human Capital Management. For each of these processes, SAP delivers accommodated solutions, which are part of the so-called mySAP.com® family of products.Figure 2.1: SAP business solutions and components. ©Copyright SAP AG.
All of these business solutions are based on one or more SAP components or software packages: SAP R/3, BW (Business Warehouse), APO (Advanced Planning and Optimization), EBPro (Enterprise Buyer Professional), and CRM (Customer Relationship Management).
Figure 2.2: SAP NetWeaver 2004S and mySAP Business Suite 2005.
With the release of SAP NetWeaver, SAP has repositioned their high-end products into three main streams: mySAP™ Business Suite, SAP NetWeaver, and SAP Industry Solutions. The first stream contains all products and components like ERP (formerly known as R/3), CRM, SRM, and SCM (formerly known as APO). The SAP NetWeaver stream represents all integration software like Portals, PI (formerly known as XI), and BI. It should be seen as the software glue that connects everything. The Industry Solutions are all add-on software packages that are specific to a certain industry.
As we will see in later chapters, SAP NetWeaver will become the software technology stack that runs all business packages. Besides acting as the runtime platform for these business packages, SAP NetWeaver has also taken care of the integration between the various packages and the presentation to the enduser.
Other software shipped by SAP includes SAP BusinessOne for small-sized businesses and SAP All-in-One for medium-sized businesses. SAP All-in-One is based on the same technology foundation as SAP NetWeaver and Business Suite.
The SAP NetWeaver solution has evolved from SAP R/2back in the ’80s. The mainframe based R/2 was replaced with R/3, based on Open Systems architecture in the mid-’90s. The next step was mySAP ERP 2005 that made use of Webservices and was based on an enterprise SOA solution with composite applications.
Figure 2.3: Evolution from SAP R/2 to mySAP ERP 2005. ©Copyright SAP AG. Both SAP R/2 and R/3 were based on Modules. Each module included specific transactions to run certain business processes. SAP R/2 included modules like RF (Finance), RV (Sales), RK (Controlling), and RM (Materials Management). And R/3 included modules like FI-CO (Finance and Controlling), MM (Materials Management), SD (Sales and Distribution), PS (Project System), PM (Plant Maintenance), QM (Quality Management), PP (Production Planning), and HR (Human Resources). Both R/2 and R/3 were shipped with a language to create reports called ABAP. In R/3 this language became a complete 4GL language with all kinds of options and a rich syntax. Reporting could also be done via Logical Databases in both R/2 and R/3.
In mySAP ERP 2005 (ERP 6.0, also known as ECC 6.0) the modules were replaced by Business Scenarios and individual transactions are embedded in workflow like Business Packages. Functionality of modules and transactions that reside in the programs became more open and easier to access from outside through the use of Web services.
Chapter
3
SAP L
AYERS
AND
A
RCHITECTURE
I
n this chapter, SAP applications are discussed from a technical perspective. Currently, SAP supports four different technical architectures. The SAP BusinessOne Engine, which is the foundation of the SAP SMB Business Solutions and was acquired from a company called TopManage. The second technical architecture is the foundation of SAP Enterprise Portals, which was acquired from a company called TopTier1.The third technical architecture is the foundation for all ABAP-based applications like ERP (R/3), CRM, SCM Server, BI, and SRM. This architecture is based on what we know as the SAP Web Application Server and use to be known as the SAP Basis layer or BC Component. The upgrade process and technology discussed in this book refers only to products based on this architecture. The fourth and last architecture is based on SaaS (Software as a Service) and marketed as SAP Business By Design. This business solution is accessable via the Internet and meant for small companies and is hosted by SAP.
3.1
SAP CLIENT SERVER ARCHITECTURE
Like most ERP applications developed in the ’90s, SAP based their ERP solution on client/server technology. Within a client/server-technology-based application, the business application or coding runs on an application server. The presentation
1 SAP Enterprise Portal 5.0 Technology has been replaced by version 6.0, which is based on a renewed SAP J2EE Engine 6.40 in NetWeaver 2004 and with SAP J2EE Engine 7.00 in NetWeaver 2004S.
of the business application to the end user is done on the presentation server. This presentation server normally runs on a PC. Besides the application and presentation server, a third server is part of this architecture—the database server. The database server is used to store all application data.
The communication between these three servers is established by either a network connection or through IPC (Inter-Process Communication). SAP uses various network protocols to maintain connections to its partners. DIAG (Dynamic Information and Access Gateway) protocol is used between SAPGUI and the SAP application servers. For communication between SAP and other applications, an RFC (Remote Function Call) protocol based on IBM CPI-C is used. Other protocols used are Berkeley LPD for printing, HTTP(s) for browser-based communication, and database protocols like SQL*Net for traffic between SAP application servers and Oracle database servers.
Figure 3.1: Different software tiers (layers) of SAP.
The SAP NetWeaver Application Server, or NW AS for short, is based on a small set of executables and tools, which are known as the SAP Kernel. These executables form the so-called SAP instance. Each SAP instance consists of a dispatcher process and a set of work processes, which run ABAP programs and screen definitions. The SAP dispatcher manages all the requests and distributes them between all available work processes. This architecture is known as client/ server TP-monitor (Transaction Processing).
There are different types of work processes; Dialog work processes, which are responsible for processing interactive dialog or screen transactions; Batch work
processes, which are responsible just for all batch load or batch activities; Spool work processes, which are assigned to all print activities; Update work processes, which are used to process asynchronously database updates; and the Enqueue work process, which manages all SAP table lock and enqueue activities.
Next to these work processes, certain other processes are active, like the message-server processes, which manage all communication between the various dispatcher processes in a multiserver configuration; and the Gateway process, which manages all external communication.
Figure 3.2: SAP NetWeaver application server. ©Copyright SAP AG. Figure 3.2 shows the dispatcher and work processes. Each work-processes does have its own dedicated connection to the RDBMS—whether it’s a Dialog, Batch, Spool, Update, or Enqueue work process. The communication between all the processes runs through shared-memory segments and IPC. The communication with the outside world goes through either the DIAG (Dynamic Information and Action Gateway) protocol for SAPGUI or the RFC (Remote Function Call) protocol when communication needs to be made between different SAP applications or other applications.
Since SAP Web AS 6.10, a couple of new communication protocols are supported: HTTP, SMTP, and FTP. These protocols can be used in order to make SAP applications Web and eBusiness enabled.
A relatively new feature of SAP NW AS, and available since version 6.20, is the SAP J2EE engine (aka AS Java), which offers a complete Java 2 Enterprise Edition runtime environment. This engine is acquired from a Bulgarian-based company called In-Q-My Technologies. This J2EE engine is already in use as the foundation for the IPC (Internet Pricing & Configurator) middleware engine, which is part of the SAP CRM (Customer Relationship Management) suite.
The SAP J2EE engine is a Java-class runtime environment, which offers resource utilization management, like a database connection pool, HTTP session management, and CPU session management; in that respect, we can compare the SAP J2EE engine with any other application server engine like IBM’s CICS, BEA’s Tuxedo, or SAP’s on ABAP engine with the dispatcher process. There are many more J2EE engines out there, like IBM’s WebSphere, BEA’s Weblogic, Sun’s iPlanet, Alaire’s JRun2, and noncommercial packages like JBoss and TomCat.
In order to dispatch all different types of communication requests between the various engines, SAP has developed the ICM (Internet Connection Manager). This process runs as a separate identity on the machine and intercepts all HTTP, FTP, SMTP, and Java requests, and dispatches them to the correct handler. Either the SAP ABAP engine or the J2EE engine will process these requests. The ICM input request includes either a BSP (Business Server Page) request, which is forwarded to the ABAP Engine, or includes a JSP (Java Server Page) request, which is forwarded to the J2EE Engine. The response in both cases is formatted in HTML. Therefore, the SAP Web AS can be seen as a Web server with the task of processing business logic. The J2EE engine can process JSP and JavaServlet requests. Running Enterprise JavaBeans (EJB) has been added to the 6.30 release. Both the ABAP and J2EE engine have full access to their own space (schema) in the database, but not to each space. Therefore, data cannot be exchanged between these engines via the database. Any communication between ABAP and Java is implemented using JCo, which is an RFC server for Java. The JCo engine is part of any SAP NetWeaver AS Java 6.40 or higher.
The J2EE engine can also be installed separately for the SAP Web AS. In case the application only needs Java to process, a full installation of the ABAP engine is not required, and vice versa. In both normal operations of SAP BW 3.5 or R/3 Enterprise 4.7, the installation of just the SAP Web AS without the SAP J2EE engine is sufficient. Both installations can also be extended with a so-called Web dispatcher in order to implement Web load distribution or load balancing.
3.2
OLTP VERSUS OLAP
There are two major types of business applications to distinguish: OLTP (Online Transaction Processing) and OLAP (Online Analytical Processing). SAP offers applications that fit either in the OLTP bucket or in the OLAP bucket.
SAP Application Description OLAP or OLTP
SAP R/3 / ERP (ECC) ERP application OLTP
SAP BW / BI Business Intelligence OLAP
SAP SRM B2B Procurement OLTP
SAP CRM B2C & B2B Sales OLTP SAP APO / SCM Planning & Forecasting OLAP
SAP SEM Finance reporting OLAP / OLTP
SAP eRecruiting Staff recruitment OLTP
SAP cProjects Team collaboration OLTP
SAP EM Event Management OLTP
SAP Solution Manager System management OLTP The characteristics of the two types of applications are as follow:
OLTP
Actions: updates; insert and select statements Data model: simple relational data model
Optimizing: optimized for short-read (look-up) operations and updates Size: average database size, no historical data
OLAP
Actions: select statements for reporting, inserts for data loading Data model: complex (star scheme) relational data model
Optimizing: optimized for long-running (reports) read operations Size: large database size with historical data (time oriented)
The data in an OLAP system is stored in so-called “data cubes,” which are an implementation of a star scheme. All SAP OLAP-oriented applications do have one or more of these star schemes, which are called “InfoCubes.”
The core of InfoCubes are “facts,” such as sales orders, financial postings, or work orders. Dimensions like time, place, locations, and regions surround facts. In order to complete the reporting, you can add extra information to the cube in terms of master data, texts, or hierarchies. Each item has its own database table. The InfoCubes consists of one or more fact tables, dependent on the level of compression. Each row (a fact) in this table points to one or more (up to a maximum of 16)3 dimension tables. A row in the dimension table can point to one or more master data records.
The major advantage of such a data model is the query performance you can obtain from such a structure—especially when queries are based on one of the dimensions. Looking at differences between the two models, there are not really any consequences for the way upgrades are performed on such an application.
3.3
SAP INSTALLABLE SOFTWARE UNITS
Various deployment options are being released by SAP. As of SAP NetWeaver 2004S, SAP refers to Usage types. All components are being deployed on top of the SAP Application Server (SAP AS for short), which is based on either ABAP or Java or a combination of both. The unit of deployment is a Usage Type. Therefore, a Usage Type defines the role that a system plays in a scenario. The usage type represents the capabilities offered by a system, including a set of installed (technical) software components. Usage types represent the new structuring element for SAP software on a technical level.
Figure 3.4: Installable software units. ©Copyright SAP AG.
The SAP software infrastructure can be divided into three building blocks: the NetWeaver AS with various Usage Types, the various clients, and the standalone engines.
This results in a broad variety of different installation options. It’s possible to create a SAP server instance with just the ABAP stack (also known as single stack). This can be used for mySAP ERP 2005, for example. But it’s also possible to deploy both ABAP and Java on a dual-stack-based installation that is used for SAP BI and BI-Java. In later chapters the deployment option MCOS (Multiple Components on One System), also known as embedded installations, is described.
Figure 3.5: Technical component view of a dual-stack system. ©Copyright SAP AG. From a technical view, a dual-stack installation is based on two Application server engines connecting to a single database. In such a configuration, the ABAP stack is leading and responsible for the startup of the Java stack (SAP J2EE engine). The ABAP dispatcher starts the J2EE engine through the Startup Framework (JControl). In Figure 3.5 we see two building blocks—the left running ABAP work processes and the right the Java work processes. Each set of work processes is controlled through its own dedicated dispatcher. All browser-based traffic (http, https) is routed through the ICM processes. The communication between the ABAP and Java stack is tunneled through the Java Connector (JCo) system, which is embedded in the Java stack. Both ABAP and Java engine have their own logical database, known as database schema. However it’s physically just one database. As of SAP AS 7.00, each ABAP work process can also run a Java VM instance, also known as the Virtual Machine Container (VMC).
The ABAP Virtual Machine is the core of the SAP AS ABAP. Each instance consists of one or more work processes. Each ABAP work process (AVM—ABAP Virtual Machine) has various building blocks. The TaskHandler that reads the work requests from the shared request queue. The ABAP dispatcher process fills the shared request queue. Once a request is read from the queue, the TaskHandler sends the work either to the Dynpro processors, in case it’s a DYNA screen request, or to the ABAP processor if it’s an ABAP code request. Both engines use the same DBIF Database interface to access the database. The DBSL Database Software Layer is platform dependant and is responsible for the translation between OpenSQL and, for example, OCI on Oracle or ODBC on Microsoft. New is the VMC mechanism, which offers the ability to run Java code in the same address space as the ABAP VM. This embedded JVM mechanism has significant performance advantage over the regular SAP J2EE engine, which runs as a separate engine in its own memory space. The VMC is used to implement the SAP IPC (Internet Pricing Configurator).
Figure 3.6: Building blocks of ABAP work process.
As of now, the VMC facility will only be used by SAP-shipped software and is not meant to be used by partners or customers. The VMC is implemented using a pool of JVM instances that can be dynamically attached to AVM instances by sharing a common memory address space. This is a very fast method of switching between runtime engines.
TIP More information on the VMC can be found in SAP Note 854170—Activating the component “VM Container.” Please have a look at the attached PDF in this note.
Chapter
4
SAP S
OF TWARE
L
OGISTICS
A
ll changes to the software and customizing, which need to be promoted through an SAP application landscape, are managed through a process known as “Software Logistics.” This SAP term includes all processes and tools that are used to deploy, update, promote, and remove application objects or complete components.There are several processes, procedures, and tools available to the customer in order to achieve this. The most common tool is TMS (formerly known as CTS— Change and Transport System) and it is embedded in the SAP Basis layer.
All programs, screens, menus, texts, master data, transaction data, and configuration data reside in tables. These tables are stored in a relational database, which is hosted by a relational database management system or RDBMS. SAP supports various RDBMS vendors like Oracle, Microsoft SQLServer, IBM DB2 (several versions), SAPDB/MaxDB (formerly known as Adabas/D), and Informix4 (acquired by IBM). The development of programs, screens, and menus for SAP configuration is just changing the content of tables. Therefore, the promotion of these changes through a SAP landscape is just a copy process of table data from one system to another system, or from one client to another client.
4 Informix database support is only available under special conditions
Figure 4.1: Database tables in SAP.
In case an ABAP program is developed in system D01 and needs to be promoted to the test system A01, a set of tools is used to extract the data from the table that keeps all the ABAP programs (SAP stores all ABAP programs in table REPOSRC). This extraction is downloaded into two separate flat-files at the operating system level and copied from D01 to the A01 system. On the A01 system, the data is uploaded and inserted in the appropriate tables. A similar process is followed for other types of development or configuration data.
4.1 SAP
DEVELOPMENT
OBJECTS
In order to manage all these different objects like ABAP programs, reports, screens and table structures, SAP has organized these objects in classes. Each object is identified by its “Object-Identifier”, which consist of two parts:. The first part is the so-called “PGMID” and the second is the “Object Type”. The “Object Identifier” is used to classify all objects in the SAP system.
4.1.1 Object Classification
The link between objects and their object identifiers is kept in table TADIR, which is better known as the “Object Directory.” This “Object Directory” is used by the Transport Workbench to prepare objects for transportation between SAP systems.
SAP has grouped their object identifiers in two main groups: “Whole-” and “Sub-”object identifiers. “Whole” object identifiers are referring to one or more objects that can be transported to another SAP system as a single identity. For example, we can take the “Whole” object “R3TR PROG” object identifier that consists of several sub-objects.
LIMU REPS - ABAP Report Source Code Text LIMU REPT - ABAP Report Description LIMU VARI - ABAP Report Variant
We can transport these individual sub-objects separately, however, if we want to transport them together, we just include R3TR PROG into the transport.
There are two “Whole-” object identifiers: R3TR, which refer to transportable objects and R3OB, which are application objects. All “sub-” object identifiers start with LIMU. The combination of the PGMID, object type, and object name is unique in the system and stored in table TADIR. For example, ABAP program RSPFPAR is stored in its own unique row in TADIR as “R3TR PROG RSPFPAR.”
A complete list of supported object identifiers in SAP R/3 can be found in Appendix A, however, SAP BW does have additional object identifiers that are unknown to R/3.
TIP In table TADIR, you will find a PGMID that is called “HEAD” and object type “SYST” and object name “<your database SID.” When you have to reinitialize the Transport Organizer with SE06 or STMS after a database refresh using one of SAP’s system copy guides, this particular row in table TADIR is adjusted.
4.1.2 ABAP
ABAP is a programming language that is shipped with all SAP software products based on the SAP NetWeaver ABAP AS. The history of ABAP is almost the same as the history of SAP AG itself. ABAP was created as a “reporting” language for SAP R/2, the predecessor of SAP R/3, in the late 1970s. ABAP stood for “Allgemeiner
Berichts- und Aufbereitingsprozessor,” which in English means “General Reporting
and Preparation Processor.” With the release of SAP R/3 in 1992, SAP also released a new evolved ABAP/4, which stood for “Advanced Business Application Programs/fourth generation language.” SAP R/1 and SAP R/2 were both programmed in Assembler/370 and at that time ABAP was basically a sequence of assembler macros and instructions. In order to overcome some shortages of ABAP, SAP developed ABAP/3, which was a third-generation language extension of ABAP and offered the ability to create business programs and dialog controlled transactions.
The programming language ABAP/4 is accessed through the ABAP Workbench, which allows developers to create programs, screens, and menus. The business functionality of R/3, BW, CRM, SRM, and APO is entirely written in ABAP/4. The combination of ABAP/4 language, the ABAP Workbench, and the scalability of the SAP Basis Kernel helped some companies decide to use it as their enterprise development platform. SAP has evolved this to the “standalone” SAP Web Application Server as a runtime platform for general applications.
SAP still implements improvements on their ABAP AS. Even now a lot of development effort has been shifted into the Java AS space. ABAP supports object
orientation and is therefore called “ABAP Objects.” The latest development includes the support of Web browser–based applications and server-side scripting. SAP answered to the increasing demand for so-called xSP-based Web servers (x Server Pages, like ASP = Microsoft Active Server Pages and JSP = Sun Java Server Pages) with BSP (Business Server Pages). BSP allows developers to combine HTML with ABAP coding and generate HTML output for Web browsers. Both server-based scripting through BSP and client-based scripting through JavaScript is supported.
ABAP code is written in the ABAP Editor, which is part of the ABAP (or Developers) Workbench and stored as ABAP source code in table D010S for SAP Basis release up to 4.6C or table REPOSRC for releases as of 6.10. After the program is written, it is generated (or compiled) to executable code. This executable code (also known as report load) is stored in the tables D010L, D010Q, and D010Y for SAP Basis release up to 4.6C or table REPOLOAD for releases as of 6.10.. However, this load is not directly executed by the CPU, but rather through the ABAP Virtual Machine, which resides in the SAP Kernel. This process is more or less similar to the Java language, where the Java source code is compiled by the “javac” compiler into a platform-neutral class (Java byte code) format that is interpreted by the Java Virtual Machine (jre or java). There is a significant difference between the two byte-code formats; SAP uses Little- and Big-Endian formats to store their compiled coding. Therefore, ABAP report loads cannot be exchanged between a machine, which supports Little Endian (such as Alpha or Intel) and a machine that supports Big Endian (such as SPARC, HP-PA, and PowerPC). In case a database is exchanged between these kinds of machines, all ABAP report loads need to be regenerated.
After the generation of the ABAP source code, the resultant ABAP loads are stored in three different tables. The ABAP load consists of four tables in the database: D010LINF, D010L, D010Q, and D010Y. The table D010Y is no longer used as of SAP releases above 4.6. Table D010L or REPOLOAD contains the actual ABAP load, tables D010Q and D010Y contain the line references or the symbol table of the generated program. Table D010LINF contains general information about the load, such as the last time of change and the size of the data in D010L, D010Q, and D010Y. When you run your application servers (dialog instances) in a mixed environment on Intel CISC machines and UNIX RISC machines, you will have double growth in these load tables: both Little- and Big-Endian data will be stored.
Every time an ABAP program is changed, it needs to be regenerated before it can be used. If a program has not been generated in advance, the ABAP Virtual Machine will do this on the fly. However, this will impact the end-users response time. During one of the upgrade phases, better know as Repository Switch, the entire library of ABAP programs is changed. However, the ABAP report load is not changed, therefore, all ABAP programs need to be regenerated after the upgrade.
Figure 4.2: Edit, compile, and run an ABAP program.
TIP The compilation phase of ABAP programs is known under two terms: generation and activation. Both terms are used by SAP.
When you perform an OS/DB migration using the R3load toolset, the ABAP load tables are not copied over. After the migration, you have to run SGEN to populate them again. It’s also possible to delete all entries from this table in case of an inconsistency:
(1) Be sure all users are of the system
(2) Delete all ABAP loads (for Oracle RDBMS): SQL> truncate table SAPR3.D010L; SQL> truncate table SAPR3.D010Q; SQL> truncate table SAPR3.D010Y; SQL> truncate table SAPR3.D010LINF;
(3) Run transaction SGEN to regenerate all ABAP loads
As of SAP Basis release 6.10 and above, the ABAP Source and Load tables have been changed. The ABAP source is stored in table REPOSRC and all ABAP load is stored in REPOLOAD. Therefore you remove the load inconsistency by just delete all rows from table REPOLOAD only, using “truncate table” statement. More information can be found in SAP Note 668560.
4.1.3 Development Classes
All objects in the SAP system are grouped in Development Classes. Through this mechanism, development objects that have a logical relationship can be easily managed. Assume your company will develop certain functionality in SAP for business usage, which consists of several ABAP programs, screens, transactions, and tables. All these different objects can be assigned to one single development class. This applies for both SAP objects and for all customer and partner objects.
Development classes, which are identified by their unique name, can be created using transaction code SE80 in the Development Workbench. After a “new” development class has been defined, newly created objects can be assigned to it. It’s relatively easy to exchange all development objects belonging to one single development class between two SAP systems. Third-party development objects, for example, certain industry-specific programs, are delivered with their own development class. SAP has extended this mechanism by the introduction of Name Spaces.
Development classes are stored in table TDEVC and because there is a maintenance dialog available, they can be maintained using SM30. The TDEVC table has the following structure (most important fields):
Field Type (dimension) Description
DEVCLASS CHAR (30) Name of Development Class INTSYS CHAR (10) Integration system, obsolete CONSYS CHAR (10) Consolidation system, obsolete CTEXT CHAR (60) Description of development class AS4USER CHAR (12) User/Creator of development class NAMESPACE CHAR (10) Name space of development class
COMPONENT CHAR (20) SAP Component
The development class “$TMP” is a special development class, which contains “local” objects. These objects are not assigned to a “regular” development class and therefore can not be transported to another SAP system. The “$TMP” development class is normally used to perform quick development of programs. However, you can assign “local” objects to a regular development class, so transportation of these objects to other SAP systems is possible.
Since the release of SAP Web Application Server 6.10, SAP has renamed the development class into “Development Package” or just “Package.” However, a package is more than just a new name for development classes. Packages can contain other packages as well. Packages are more or less object-oriented development classes.
TIP Assume you’re performing an upgrade of an SAP instance, which is a copy of another SAP instance, and you need to adjust an object during the upgrade, which is part of a non-existing development. You cannot use TMS during the upgrade; however, ABAP report RSWBODVC (as of SAP R/3 release 4.6) offers the ability to create missing development classes.
4.1.4 Name-Ranges
To make distinction between objects developed by SAP or by its customers, SAP has introduced the concept of name-ranges. Name-ranges are reserved naming conventions, which is used for object-names. Objects, for instance tables or ABAP programs that starts with the letter Z, do belong do the customer. All objects that start with letter Y are reserved for either customers or SAP partners. All other objects are belonging to SAP.
Name-Range Description Example Object
Y* SAP partners Table YINVOICE
Z* Customer development ABAP ZTEST
A* – X* SAP developments ABAP RSUSR003
When you create a “new” object in the name-ranges Y* and Z*, you only need to have a developer access-key, which can be obtained from the SAP Service Marketplace. For objects in the name-range A*-X*, you also need an object-key. SAP uses this to keep track of all changed objects that are part of SAP standard delivered objects. Both developer- and object-keys are stored in SAP tables DEVACCESS and ADIRACCESS.
Name-range also does exist for customizing tables and generated reports. These individual name-ranges are stored in table TRESC, which has the following structure:
Field Type (dimension) Description
OBJECT CHAR (4) Object type like REPS or TABU TABNAME CHAR (30) Name of customizing table FIELDNAME CHAR (30) Field in table
KEYLOW CHAR (30) Name-range, like Y* and Z* IGNOREFLAG CHAR (1) Can name-range be ignored?
GENFLAG CHAR (1) Generation flag
LASTNAME CHAR (12) Name of last editor
For the upgrade, it’s important to know whether an object is a customer-development object or if it’s delivered by SAP. The upgrade will preserve all customer-developed objects during the upgrade and restore it afterward. This means custom-created developments are not destroyed.
4.1.5 Namespaces
Namespaces are identifiers assigned exclusively by SAP that enable SAP customers, SAP Partners, and SAP itself, to develop objects, components, and software products without the risk of name clashes.
SAP namespaces need to be registered with SAP first before they can be used. This is done online using the following URL: http://service.sap.com/namespace. When you deploy software (ABAP programs, screens, or tables) from third-party vendors, it is possible that this software comes with its own namespace. The namespace identifier is included as an object in the transport request as well. All installed namespaces, including SAP’s own namespaces, are stored in table
TRNSPACE, which has the following layout:
Field Type (dimension) Description
NAMESPACE CHAR (10) Namespace name
ROLE CHAR (1) Role of namespace
LICENSE CHAR (20) License key
EDITFLAG CHAR (1) Modifications allowed
SSRCFLAG CHAR (1) SSCR dialog box
SAPFLAG CHAR (1) SAP standard delivered
GEN_ONLY CHAR (1) Only generated objects allowed Since the introduction of namespaces in SAP R/3 4.0B, a significant number of namespaces have been registered with SAP. Some known namespaces are:
Namespace Owner Description
/BMC/ BMC Software BMC Patrol (Trak) objects
/SAPDMC/ SAP A.G. Legacy Data Migration Workbench
/BI0/ SAP A.G. SAP BW standard objects
/BIC/ SAP A.G. SAP BW customer objects
/VIRSA/ SAP A.G. Virsa (SAP GRC)
An object with the name ZTEST, which belongs to a namespace /XYZ/, needs to be identified with “/XYZ/ZTEST.”
4.1.6 Number Ranges
The SAP R/3 database is a large collection of all kinds of documents: purchasing order documents, contracts, HR records, goods movement letters, sales order documents, etc.
These different documents are uniquely identified by a document number. This document number is just a sequential number that is generated by SAP or assigned by an external source, for example, the end user of some application.
Number ranges within SAP are implemented using Number Range Objects, which are basically kinds of counters. Every time a new document is created, for example, a sales order document using transaction VA01, SAP will use this counter to assign a unique number to this document and increase the value of this counter by one.
For each document in the system, SAP has its dedicated Number Range Objects residing in table NRIV. This NRIV table is client specific, which means you can have the same sales order document number in the database, but each belongs to its own client. The table NRIV has the following structure:
Field Type (dimension) Description
CLIENT (MANDT) CLNT (CHAR (3) ) SAP logon client
OBJECT CHAR (10) Name of Number Range Object
SUBOBJECT CHAR (6) Number range subobject value
NRRANGENR CHAR (2) Number Range version
TOYEAR NUMC 4 Fiscal year for document
FROMNUMBER CHAR (20) Start range
TONUMBER CHAR (20) End range
NRLEVEL NUMC 20 Current number
EXTERNIND CHAR (1) External number range
The maintenance of Number Range Objects is done at two levels as part of the general customizing through IMG (Implementation Management Guide) using transaction SPRO or using transaction SNRO. Transaction SNRO includes all Number Range Objects. A number range is assigned to a particular fiscal year and contains both a start and end value. If the flag EXTERNIND is set to ‘X,’ SAP will not create a new document number for you, but leaves this up to the user to fill in. Playing around with number ranges can be quite dangerous. Changed values might lead to the creation of duplicate document numbers.
4.1.7 Development Locks
SAP uses a few flags and tables to store Development Locks. These locks are used to protect objects against overwrites and protect the SAP system against
duplicate objects. The TLOCK table contains all locks that are used for objects that reside in Transport Requests. As soon as a developer creates an object, an entry is added to the TADIR table. When, during its creation, the object is also added to a transport request, another entry is added to the TLOCK table. All tables that are in maintenance status are listed in table TLOCK. Only when an object is released in TMS will the TLOCK entry will be removed.
When another developer tries to change an object, which resides in an unreleased transport request so it has its own entry in table TLOCK, the developer will get an error message.
Table TLOCK has the following structure:
Field Type (dimension) Description
OBJECT CHAR (4) Object type (PROG, TABL)
HIKEY CHAR (120) Key used in CTS
LEN INT (10) Length of CTS key
EDTFLAG CHAR (1) Special editor required
TRKORR CHAR (20) Request/Task
AUTHOR CHAR (12) Creator of object
LOKEY CHAR (120) Key used in CTS
If we create a new ABAP program called ZTEST, the OBJECT field will contain value “PROG” and HIKEY will contain a text similar to “ZTEST yyyyyyyyyyyyyyyy.”
The second most important lock in the SAP system is the “Repair Flag.” This flag resides in table TADIR in field SRCDEP. The repair flag is set to ‘X,’ when an object is changed in an SAP system that has not been marked as a “development” system. SAP uses this mechanism to protect “Consolidation” (quality assurance) and “Integration” (production) systems against modifications. When the repair flag is set to an object in the SAP production system, it will protect this object against overwrites from outside like transports and Support Packages. The repair flag can be removed using transaction SE03.
There is a phase in the upgrade process that checks whether there are objects locked in transport requests and whether the system contains repair flags. For the transport locks it checks table TLOCK and for repair flags it checks table TADIR.
4.1.8 Development Keys
In order to develop something in SAP, two keys are required: the object key, which is bound to a certain SAP-shipped object, and a developer key. The object key is only required for SAP objects. This means that customer objects are excluded from this mechanism. Developer keys are required for any developer working on the system. The object keys are bound to each object, listed in table TADIR, and stored in table ADIRACCESS:
Field Type (dimension) Description
PGMID CHAR (4) Object ID (as in TADIR)
OBJECT CHAR (4) Object type (as in TADIR)
OBJ_NAME CHAR (40) Object name (as in TADIR) ACCESSKEY CHAR (20) Modification key from SAP
This mechanism is put in place as an extra hurdle to manage all changes to standard SAP objects. This table might be of help to check what objects have been changed in the SAP system. The developer keys are stored in another table called
DEVACCESS.
Table DEVACCESS has the following layout:
Field Type (dimension) Description
UNAME CHAR (12) User name (as in USR02)
ACCESSKEY CHAR (20) Developer key from SAP
TIP If you want to prevent any development in your system, you just delete all entries from table DEVACCESS. However, you have to be sure no new keys can be obtained from the SAP Service Marketplace.
Deleting all entries from table ADIRACCESS, after the upgrade, will prevent developers from modifying standard SAP again.
4.2 DATA
TABLES
Data is organized at different levels within the SAP software. Whether it’s R/3, BW, APO, or CRM, these components are following the same structure. All SAP data is stored in database tables. These tables are organized at development-view level and from a technical-view level.
4.2.1 Table Types
There are several types of tables that SAP supports. These table types are: Transparent tables
Pooled tables Clustered tables
And besides these three table types, SAP also supports: Structures
Views Appends
Let us first concentrate on the “physical” table types. These are tables containing rows (or records) that are stored in the database. An average SAP R/3 instance has more than 10,000 tables in the database. Most of them are transparent tables.
A fourth table type would be INDX tables that were introduced with the HR module in SAP R/3. INDX tables are actually transparent tables, but have an extra logical structure on top. This structure is unique to SAP HR and can only be interpreted as such.
Transparent tables – are tables that have a 1:1 relationship between the SAP Dictionary and the underlying database. If you look at the table definition in transaction SE11, you will see exact the same layout compared with what you see with, for example, SQLPLUS in Oracle.
Figure 4.4: SAP transparent table mechanism.
Pooled tables – These “logical” tables can be viewed by transaction SE11 or SE16, but cannot be accessed directly using SQLPLUS or any other database tool. If you look at the table using any database tool, you will only see the “table pool” that
contains “pooled tables.” The DBSL is responsible for accessing these tables from within ABAP programs. This means that an ABAP program does not experience the difference between a “transparent table,” “pooled table,” or a “clustered table.” The difference is only noticed when the table is accessed using database tools like SQLPLUS or ODBC.
The mechanism of “pooled tables” was introduced by SAP to support a large number of tables. In the early days of SAP R/3, not all RDBMS vendors were able to support a large number of tables. This was because all customizing of SAP R/3 lies in tables and the number of rows per table can be very small. Therefore, SAP designed a mechanism to combine these small tables into bigger tables. An example of this is the ATAB table, which you can access using SQLPLUS. This ATAB table contains hundreds of small customizing and control tables, such as AT01 and DDSYN.
The structure of a table pool is as follows:
Field Type (dimension) Description
TABNAME CHAR (10) Pooled table name
VARKEY CHAR (n) Maximum key length
DATALN INT2 (5) Length of VARDATA row
VARDATA RAW (n) Pooled table data itself
All the pooled tables are listed in field TABNAME. Data that belongs to that particular table is stored in field VARDATA, which is a RAW data field. RAW data fields normally can not be accessed using a database tool like SQLPLUS.
Clustered tables – are similar to pooled tables in the sense that they are also not accessible using database tools like SQLPLUS at the RDBMS level. The SAP DBSL layer takes care of the proper access by ABAP programs. Clustered tables are “logical” tables that are grouped together in a “table cluster” or just “cluster.” Clustering of tables is supported by most of the RDBMS vendors and it’s therefore not a SAP-specific mechanism like “pooled tables.”
Tables that are clustered do have a common set of keys and therefore “clustered tables” and “table clusters” share a set of data fields.
Field Type (dimension) Description
CLKEY1 CHAR (*) First key field
CLKEY2 CHAR (*) Second key field
………. ………. ………..
CLKEYN CHAR (*) Last key field
PAGENO INT2 (5) Number of next page
TIMESTMP CHAR (14) Time stamp field
PAGELN INT2 (5) Length of VARDATA row
VARDATA RAW (*) Other fields data
Figure 4.6: SAP Clustered table mechanism.
An example of a table cluster is the RFBLG table, which is used by the FI module in SAP R/3. It contains the table BSEG that contains all financial posting documents.
Figure 4.7: Relationship between BSEG and RFBLG.
Performance of accessing data is the main reason to put tables in a cluster. It requires a significantly lower number of disk I/Os to access data and therefore it’s purely a performance gain.
However, there are also drawbacks to pooled and clustered tables. You cannot access them directly from the RDBMS level. This means that if you want to use “external” (third-party or custom written) programs to access this data, you have to use ABAP instead or you have to start considering converting the data.
SAP allows you to convert certain pooled and clustered tables to transparent tables in order to make them more open. However, first read the appropriate OSS notes before you start using transaction SE14 to do this job.
During upgrades it can happen that pooled and clustered tables are converted into transparent tables. Since the first release of SAP R/3 back in 1992, SAP has reduced the number of pooled and clustered tables significantly. Modern SAP tools like BW, CRM, APO, and SRM do not contain pooled or clustered tables at the application level.
Besides “real” tables, SAP also supports “virtual” tables, such as views, structures, and appends.
Views – are data access objects, which offer a certain view to one or more tables. Views are constructed using SQL statements like:
CREATE VIEW V_T000 AS SELECT MANDT, NAME FROM T000;
This view, V_T100, will only show the fields MANDT and NAME of table T000.
Structures – are memory-only structures that are runtime bound. This means that the table structure is created at the initialization step of an ABAP program and is destroyed at the end. Structures are used to organize and map data in
programs, which does not have to be stored permanently. Structures are often used in combination with “internal” tables. Internal tables are tables that only exist in memory and can be compared with an ARRAY in Pascal of BASIC or a STRUCT in C.
As of SAP AS 6.40 ABAP, a new concept of Shared Memory Object was introduced. This shared object is basically a Structure that can be shared between work processes and therefore is not destroyed at the termination of the ABAP program.
Appends – are additional fields added to existing tables. Appends can be added to tables by using include constructions.
4.2.2 Table Delivery Types
Table Delivery Types is a mechanism to protect tables against changes, overwrites, and deletions that occur during upgrades and Support Packages. Each table has a Delivery Type, which is an attribute that tells the Software Logistics tool how to treat this table. These are the table delivery types to consider:
Table Delivery Types Description Example Table
‘A’ – Application Table Protected against SAP import, only insertions
MARA, USR02, EKKO, KNA1
‘S’ – System Table Maintenance by SAP only CCPROF ‘W’ – System Table Maintenance by SAP only DD02L ‘E’ – Control table SAP and customer do have
different name ranges
ATR1 ‘C’ – Customizing table Maintenance by customer,
SAP will not change entries in this table
T001, TVKO
‘G’ – Customizing table Protected against SAP import, only insertions
RFCDES
With “by SAP,” we mean SAP Support Packages or SAP Release upgrades. The Delivery Type attribute is stored in table field DD02L.CONTFLAG.
4.2.3 Table Data Classes
The “data class” determines the link between the SAP database table and its “physical” or “technical” location. Each table has a so-called TABART attribute, which assigns the table to a data class. The following data classes (or TABARTs) exist in an SAP R/3 system:
TABART name Description TABART name Description
APPL0 Master data SAUS Exchange tables
APPL1 Transaction data SDIC ABAP DDIC tables
APPL2 Customizing data SDOCU Documentation tables SLDEF Repository switch SLOAD Report load tables SPROT Spool and log tables SSRC Source tables TEMP Temporary tables USER1 User-defined tables USER2 User-defined tables USER3 User-defined tables
Field DD02L.CONTFLAG contains the value, which assigns each table to a certain data class. The TABART (data class) itself is stored in table DDART and the relationship between a table and the storage container in the database is stored in TA<DB> for tables and IA<DB> for indexes. An SAP R/3 system running on Oracle uses tables TAORA and IAORA to store the link between TABARTs and Oracle tablespaces.
TIP When a developer creates its own table in SE11, it’s possible to specify the TABART of this new table. The TABART will determine in which tablespace the table is created; it’s therefore important to set a project standard that guides developers to use the correct data classes and thus tablespaces or devspaces.
When an additional tablespace is created with a tool like SAPDBA, or BRTOOLS in Oracle, it will also create a new TABART for you. The name convention for this is USERnn, where “nn” is a sequential number between 0 and 99.
TABARTs are also used by the R3load tool, which is part of the OS/DB Migration kit and used during upgrade phase EU_IMPORT.
4.2.4 Indexes
In order to improve access times to the data in the database, it’s possible to create and use indexes. A table might have one or more indexes defined. However, an index can only be defined for one table only.
An index is a separate information container, which has its own name and table spaces and contains certain key fields that are sorted. There are two types of indexes: primary and secondary indexes. The “main” purpose of secondary indexes is to increase the performance on “transparent” tables during DML operations.
Indexes are maintained per individual tables by transaction SE11 → Indexes.
TIP SAP software is shipped with a large number of indexes defined. Only add additional indexes when it’s absolutely required. Indexes might decrease performance when bulk inserts or updates are done on the database. SAP BW offers the ability to drop all indexes for an InfoCube before the data loads and rebuilds them afterward.
4.2.5 Table Technical Settings
Besides TABART assignments, tables also have other technical settings as well. Important settings are “Table Category,” which is used for table size growth and “Table Logging.” This “table logging” can be used to capture all row changes per table. Especially for customizing tables, it can be practical to use table logging. It is not recommended to use it for application (master and transactional) tables because of the large number of rows.
Technical table settings are stored in DDIC table DD09L. This table contains the following structure (only the important fields are shown here):
Field Type (dimension) Description
TABNAME CHAR (30) Table name (like in DD02L)
TABKAT CHAR (2) Table size category
TABART CHAR (5) Table data class (like in DDART) PUFFERUNG CHAR (1) Table buffering indicator
PROTOKOLL CHAR (1) Is table logging on?
TRANSPFLAG CHAR (1) Converted to transparent table?
ACTFLAG CHAR (1) Activation flag
BUFALLOW CHAR (1) Table buffering allowed?
The “Size category” field is used to indicate the growth rate of the table. Tables that will grow fast need to be stored in large table spaces like PSAPBTABD or PSAPSTABD. The PBUFFERUNG and BUFALLOW fields are used to control the table buffering mechanism of SAP. To increase the query performance of the SAP application, you can switch on memory buffering for certain tables. Table buffering settings of tables can be changed using transaction SE11 Technical Settings.
4.2.6 Table Logging
An import flag (DD09L.PROTOKOLL), which is set per table in the SAP system, is the “table logging” option. This option allows you to track all changes performed on a certain table. Before this option can be used, the instance parameter “client/ rec” needs to be set. Support values are:
client/rec value Description
OFF Table logging switched OFF for entire system Nnn Table logging switched ON for this client nnn nnn, mmm, ppp Table logging switched ON for these clients ALL Table logging switched ON for entire system
