upgrading sap

CONTENTS i

UPGRADING

SAP®

ii CONTENTS

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.

CONTENTS iii

UPGRADING SAP®

M. SENS

INFINITY SCIENCE PRESS LLCHingham, Massachusetts

New Delhi, India

Copyright 2008 by INFINITY SCIENCE PRESS LLC. All rights reserved.

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

INFINITY SCIENCE PRESS LLC11 Leavitt StreetHingham, MA 02043Tel. 877-266-5796 (toll free)Fax 781-740-1677info@infinitysciencepress.comwww.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 20070507768 9 10 4 3 2 1Our 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.

CONTENTS

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

v

vi CONTENTS

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.1 Withdrawn from Maintenance 88

CONTENTS vii

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.3 Prepare 119

viii CONTENTS

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.30.4 Upgrade Breakpoints 178

CONTENTS ix

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 SAP Landscape Management 215

x CONTENTS

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.4 Java Control 260

CONTENTS xi

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.10 E2E Management 297

xii CONTENTS

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 1INTRODUCTION

Today, 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

1

2 UPGRADING SAP

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 2WHAT IS SAP SOFTWARE?

There 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.

3

4 UPGRADING SAP

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.

WHAT IS SAP SOFTWARE? 5

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.

6 UPGRADING SAP

Chapter 3SAP LAYERS AND ARCHITECTURE

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.

7

8 UPGRADING SAP

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

SAP LAYERS AND ARCHITECTURE 9

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.

10 UPGRADING SAP

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

2 Alaire has been acquired by Macromedia.


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.”

Figure 3.3: Technical layout of an SAP InfoCube. ©Copyright SAP AG.

12 UPGRADING SAP

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.

3 This is a restriction of the most common database engines.


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).

14 UPGRADING SAP

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 4SAP SOFTWARE LOGISTICS

All 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

15

16 UPGRADING SAP

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.

SAP SOFTWARE LOGISTICS 17

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

18 UPGRADING SAP

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.

20 UPGRADING SAP

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:


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

LASTDATE DATS Date of last change

22 UPGRADING SAP

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:


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:


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

24 UPGRADING SAP

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:


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:



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:


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.

Figure 4.3: Data table with its attributes.

26 UPGRADING SAP

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:


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.

Figure 4.5: SAP Pooled table mechanism.

28 UPGRADING SAP

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.


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

30 UPGRADING SAP

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.

32 UPGRADING SAP

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):


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


After the activation of the table logging option, SAP starts to store all data changes in table DBTABPRT (SAP R/3 releases up to 4.0B) or DBTABLOG (SAP R/3 releases 4.5A and higher). Only for tables where the technical setting “table logging” is switched are taken into account. Because the data can grow significantly, you should only use this option on customizing tables and user-master tables for security audit purposes. The contents of these tables can be viewed using report RSVTPROT or transaction SCU3. You can also use SCU3 to delete obsolete data from these tables. It is important to control the growth of these tables, especially before an upgrade to SAP R/3 4.7 Enterprise. The structure of DBTABLOG will change; therefore, a conversion is required.

4.2.7 DBDIFF

There are tables in the database that are not known to the SAP Data Dictionary and therefore cannot be accessed by SAP through ABAP OpenSQL. These tables are listed in table DBDIFF. Examples of such tables are D010S (ABAP Source up to 4.6C) and MLICHECK (table with the license key information for SAP releases up to 7.00). After a “fresh” install of SAP, the ABAP program RADBDIF is executed; this program checks whether the table DBDIFF is consistent. Table DBDIFF has the following layout:


OBJNAME CHAR (30) Name of DB object (table, view…)

DBSYS CHAR (10) Name of RDBMS (e.g., Informix)

OBJTYPE CHAR (4) Table, view, index …etc.

DIFFKIND NUMC (2) Type of inconsistency

SOURCE CHAR (40) ABAP to create DB object

The DIFFKIND field indicates the reason for the difference between the DD (Data Dictionary) and the DB (Database):

01 – Mandatory in database, not in dictionary 02 – Mandatory in dictionary, not in database 04 – Field type(s) difference between database and dictionary 08 – Other definition (fields, sequence) in dictionary compared in database 60 – Secondary index needs to be created before the primary index 61 – Table without indexes 99 – Optional object, should not be checked by RADDBDIF Tables like D010S, D010L, D010Q, and MLICHECK are known to the database,

but not known to the SAP dictionary and therefore DIFFKIND has value “01”. DIFFKIND value “99” is applicable for tables that reside in the database for RDBMS management reasons, such as table MSSQL_LOGIN_INFO on Microsoft

34 UPGRADING SAP

SQLServer or table PLAN_TABLE on Oracle and DB/2. For maintenance of the DBDIFF table, SAP created the DBDIFFVIEW object, which can be edited through transaction SM30.

4.3 CUSTOMIZING OBJECTS

Besides physical objects like ABAP programs, screens, and tables, SAP also contains logical objects like “Customizing Objects.” Customizing objects are implemented through several mechanisms, for example, through views or logical transport objects (individual table rows or keys).

All customizing objects can be viewed by using transaction SOBJ, which offers you the ability to see what tables are attached to the object. The information that SOBJ uses is stored in several tables: OBJH (Object Header), OBJT (Object Text elements), and OBJM (Object Method functions).

Table OBJH contains all relevant information for customizing objects (only the most important fields are shown here):


OBJECTNAME CHAR (30) Name of customizing object

OBJECTTYPE CHAR (1) Type of object

CLIDEP CHAR (1) Is object client specific?

LANGDEP CHAR (1) Is object language specific?

ALEDEP CHAR (1) Is object ALE specific?

OBJCATEG CHAR (4) Object category

TRCOMPLETE CHAR (1) Object transport must be complete

TRDISJUNCT CHAR (1) Object is disjunct to other objects

The following Customizing object types are known to the SAP system:

OBJECTTYPE Description

C View cluster (transaction oriented)

L Logical transport object

S Table with text

T Individual transaction object

V View

D Dummy object (SAP internal usage)

The most common customizing object is that of the type “view,” which means that when you want to configure the controlling areas in your SAP R/3 system,


using transaction SPRO (Customizing IMG), you’re basically maintaining view V_TKA01_GD. This customizing object links to the following customizing tables T001, TKA00, TKA01, TKA02, TKVS, and TKVST. The table TKA01 is marked as being the primary table. Tables that are created by the customers themselves using transaction SE11 are also listed in here as type “S.”

Figure 4.8: Customizing object embedded in IMG.

The fields CLIDEP, LANGDEP, and ALEDEP indicate how these customizing objects need to be treated by client copies, language imports and ALE distributions. The field OBJCATEG classifies all objects in categories: CUST (client-dependent customizing), CUSY (client independent or cross-client customizing), APPL (application object), and SYST (system or workbench object).

INFO The content of the SAP delivery clients 000 and 001 are affected by upgrades. SAP only adds or changes values within client 000. See SAP Note 129260 for more details.

4.4 OTHER OBJECTS

Next to tables, ABAP programs and screens, a SAP system also has several other objects. Objects are managed through the Development Workbench and in particular the Object Browser under transaction SE80. These other objects are:

Search Helps and MatchCode Object – which is a special dictionary object for helping end users find certain documents in the system. SAP, however, has stopped using match codes in their applications. The new search facilities are based on “Search Helps” and the introduction of an external search and index tool called

36 UPGRADING SAP

T-Rex should eliminate the need for embedded search objects. Search Helps are objects that are connected to screen input fields and direct the end user to press F4. This shows a small dialog box that offers the ability to enter the search criteria.

Figure 4.9: Search Helps are implemented as F4 in input fields.

The objects can be accessed through transaction SE11. Data Model – Under transaction SD11 a case tool resides that offers the ability

to create and edit data models according to the ERD-schema technique.

Figure 4.10: SAP graphics view of ERD data modeler. ©Copyright SAP AG.

Screen – All dialog screens in SAP are identified as objects. A screen is created or maintained through transaction SE51 (SAP Screen Painter). Each screen consists of one or more screen numbers, which are connected to each other using the screen flow. The ABAP coding is connected to screen numbers using PAI (Process After Input) and PBI (Process Before Input) modules. These modules are event-handlers written in ABAP and are triggered after a user response.


Figure 4.11: SAP Screen Painter. ©Copyright SAP AG.

Function Module – Is a piece of ABAP code that can be called from other programs by using the statement “CALL FUNCTION.” Function modules are created and maintained through transaction SE37 and contain various attributes. The possible attributes are:

� Normal Function module: Can be called with “CALL FUNCTION” statement � Remote Function module: This function can be called from within another system

using “CALL FUNCTION … USING DESTINATION.” � Update Function module: This function code is executed by a UPD or UP2

process asynchronously. This option has four suboptions: � Start Immediately: Function module is directly executed � Start Immediately, No restore: Same as above, except for restart option � Start delayed: This is a so-called V2 update � Collective Run: This is a so-called V3 update Menu – SAP offers a large number of menus, which can be created and

maintained through transaction SE41 (SAP Menu Painter). The created menu items can be used to start certain ABAP programs and transactions.

Text Element – is an object that can be assigned to a location on a screen. By creating different translations for one text element, SAP offers the ability to make screen language independent. Text elements can be created and maintained using transaction SE32. The transaction SE63 is used for translations.

Message – are the text messages, which are shown at the bottom of the SAPGUI screen in case of an information notification, warning or error message. All messages are grouped into “Message Classes” and can be maintained using transaction SE91. There are four types of messages:

38 UPGRADING SAP

Figure 4.12: SAP Menu Painter. ©Copyright SAP AG.

� Information: Just to inform the user, such as “P.O. 354825 has been created.” � Warning: Just to inform the user of a “small” issue. � Error: To inform the user about a recoverable error. For example, a wrong data

entry. � Abort: A serious error from which SAP cannot recover from. For example, a

situation around an application or database server that is down. BSP – Business Server Pages are SAP solution for server-side scripting. The

BSP is a “dynamic” HTML extension that is using the “ABAP Personality” of the SAP Web Application Server 6.10 or higher. The following example displays five times the text “hello world” on the Web browser:

<%@page language=”abap”%> <html> <body> <center> <% do 5 times. %> <font size=<%=sy-index%>> Hello World! <br> </font> <% enddo. %> </center> </body> </html>

The page is shown at http://<hostname>:8080/sap/bc/mypage, which is exported from the SAP system using transaction SICF to the ICMan (Internet Connection


Manager). The BSP pages are objects that are created and maintained through transaction SE80 – Object Browser. The page is written in HTML and all ABAP code is added using “<% %>” tags.

SAP also supports Java and Web DynPro for the server-side scripting and supports JavaScript for client-side scripting.

Web Dynpro - As of SAP NetWeaver 7.0, the ABAP language has been extended with Web Dynpro for ABAP. This extension fulfills the requirement to create screen-based, event-driven applications that ease the development cycle of user interfaces. The Web Dynpro technology is based on the screen painter with additional options and adopted from the Java community. The screens (type R3TR WDYN) are built using transaction SE80 → Object “Web dynpro” and interpreted by the Dynpro processor. The Web Dynpro for ABAP is based on the MVC (Model-View-Controller) development paradigm.

Figure 4.13: SAP Web Dynpro builder. ©Copyright SAP AG.

Once in Web Dynpro, a user screen is painted and ABAP coding can be generated or is added to the various screen elements. The “Web Dynpro for Java” code is built using the SAP Development Studio, which is the IDE (Integrated Development Editor) for Java in SAP, where in ABAP the code is developed through the ABAP Workbench instead.

40 UPGRADING SAP

4.5 CORRECTION AND TRANSPORT SYSTEM

The Correction and Transport System (CTS) is a toolkit that is available in all SAP Components that are based on the ABAP engine. The CTS is used to manage all development object changes and corrections in the SAP system. It is used to promote these changes in a controlled fashion through a so-called SAP system “landscape.” It keeps track of all development objects and configuration changes by putting them into change or development requests. The CTS toolkit can be divided into two components. The first component is called CTO (Change and Transport Organizer) and is located in R/3 and accessible through transactions, such as SE01, SE03, SE06, and SE09. The second component is called Transport Tools that consists of several executables like tp and R3trans, which are located at the operating-system level.

Figure 4.14: SAP CTS, CTO, and TMS. ©Copyright SAP AG.

The CTO contains three different organizers, each with its own transaction-code. Besides these three, other transaction-codes are available to manage CTO activities:

SE01 – Transport organizer. SE03 – Configuration of the CTO. SE06 – Creation of a unique SAP instance. SE09 – Workbench organizer: This utility can be used to manage transport

requests, which do contain development objects, such as ABAP programs, screens, text, and messages.

SE10 – Customizing organizer: This utility can be used to manage transport requests, which do contain customizing settings.

Since SAP R/3 4.0A, SAP has added new functionality to the CTS toolkit, called TMS (Transport Management System) and can be accessed through transaction STMS.


4.5.1 Transport Activities

A variety of tasks are related to CTS. This goes from setting up a system landscape to the promotion of changes through such a system landscape. A system landscape consists of multiple SAP component systems like R/3 or BW, which are logically linked. The functional meaning of such a landscape is the division of a development, a test, and a production environment or system. This setup should guarantee the consistency of all development activities.

All transport activities are closely related to both ABAP development and business configuration. Each new development object or configuration change is captured in a so-called transport request. A transport request is a container of objects that contain objects (ABAP programs, screens, menus, texts, messages, table definitions, or structures) or configuration data.

In order to keep the production system reliable, a variety of tools are available to promote changes from development to the test system and to the production system. These tools offer the ability to setup a change management and control process and should prevent objects being promoted from development to other systems without the correct approvals.

4.5.2 Transport Management System

The Transport Management System, or TMS for short, is a set of tools and procedures that take care of promoting changes and new developments through a SAP system landscape. In order to fulfill this task a certain deployment setup is developed by SAP. A TMS setup is based on a so-called “transport domain” concept. A transport domain is a group of SAP instances that can be managed centrally. The most common setup is to cluster all three SAP instances (development, acceptance, and production) within one single transport domain.

The transport domain is managed through a “domain controller,” which can be any machine within the landscape. The most common place to put this functionality would be the SAP development instance. Besides a “transport domain controller,” a second instance can be set up as being a “backup domain controller.” In the case of a system or hardware failure on the domain controller, transports can still be executed.

In case transports from different landscapes are managed through one single system, a transport domain can consists of multiple system landscapes. The transport requests itself are transported through files, which are stored in the “transport directory.” All SAP systems that share the same transport directory belong to the same “transport group.” For UNIX-based SAP systems, the transport directory resides in “/usr/sap/trans,” which can be NFS exported/imported to other systems in the transport group.

The “transport domain,” “domain controller,” and “transport group” all refer to the physical environment. However, at the logical level, we do have “transport routes.” Transport routes define the route transport requests follow through a SAP

42 UPGRADING SAP

landscape. The simplest transport route runs from development to acceptance and further on to production.

Figure 4.15: One transport domain with two transport groups.

The transport layers are part of the TMS setup that can be accessed through transaction code STMS.

Figure 4.16: Standard transport route for three system landscapes.

INFO The “official” SAP terminology for a development system is “Integration System,” for acceptance systems it’s called “Consolidation System,” and a production system is called a “Delivery System.”


4.5.3 Transport Requests

A Transport Request (also known as a Correction) is a container with “tasks.” A task is a container with “objects.” An object can be a table definition, an ABAP program, a screen definition, a text translation, or a customizing setting.

Figure 4.17: Relationships between request, task, and objects.

Each request has at least one task, but it can have more. Each task has at least one object, however, it can also have more. All Transport Requests and Tasks are stored in a single table. This table, E070, has the following structure:


TRKORR CHAR (20) Request/Task number

TRFUNCTION CHAR (1) Request or Task?

TRSTATUS CHAR (1) Status of request in CTS

TARSYSTEM CHAR (10) Target system

AS4USER CHAR (12) Owner of request

AS4TEXT CHAR (120) Description of request

A request or task number has the following naming convention: <SID>K9nnnnn; where <SID> is the SAP System Identifier of the system where the request is created. This is usually the development system. The “nnnnn” is a sequential number that is stored in table E070L. Table E070L contains only two fields, from which field TRKORR contains the last released number.

TIP In some cases it’s nice to make a distinction between Transport Requests belonging to Project #1 and Project #2. By modifying the value specified in field E070L.TRKORR, it possible to manipulate the Transport Request numbers. For example,: all transports D01K900001 until D01K901000 belong to Project #1 and all transports D01K901001 until D01K902000 belong to Project #2. Bear in mind that both projects should run in sequential order and therefore cannot run in parallel.

44 UPGRADING SAP

The objects that reside in a task are stored in table E071. Table E071 has the following structure (only important fields are shown

here):


TRKORR CHAR (20) Task number

A4POS NUMC 6 Position of object in list

PGMID CHAR (4) Object ID (as in TADIR)

OBJECT CHAR (4) Object type (as in TADIR)

OBJ_NAME CHAR (20) Name of object

Transport Requests can be created upfront by transaction SE01 or on-the-fly when a “new” development object is created or an existing one is changed. With transaction SE03, certain attributes of Transport Requests can be modified.

Before objects can be transported through the SAP system landscape, both tasks and the Transport Request first need to be released. During the “release” function, under transaction SE01, a co- and datafile are created.

Figure 4.18: The initial screen of transaction SE01. ©Copyright SAP AG.


The creation of both files is done by tp, which calls R3trans to extract the data from the database and writes it to the locations “/usr/sap/trans/data” and “/usr/sap/trans/cofiles.”

Figure 4.19: Files are created once a Transport Request is released.

4.5.4 Transport Tools

The STMS transaction is just a user-friendly shell on top of all kinds of transport tools. The transport tools are responsible for all export and import activities during the transport process. These tools also play an important role during the upgrade of your SAP system. Two major programs form the Transport tools: “tp” and “R3trans.” “TP,” which stands for “Transports and Programs,” is an executable on the operating system level. This is the primary program doing all uploads, imports, and exports of objects like programs, add-ons, language imports, loading support packages, and upgrades. In other words, every object that is changed, deleted, or added to any of the SAP instances in your landscape is performed by “tp.”

TIP It’s important for the Transport Tools tp and R3trans to work with the correct RDBMS shared library, which is vendor specific, such as dboraslib for Oracle and dbadb2slib for DB2. The Transport Tools can find this library by using a LIBPATH environment variable:

OS Variable Name Variable Value

AIX LIBPATH /usr/sap/SID/SYS/exe/run

HP-UX SHLIB_PATH /usr/sap/SID/SYS/exe/run

Solaris (SunOS) LD_LIBRARY_PATH /usr/sap/SID/SYS/exe/run

Linux LD_LIBRARY_PATH /usr/sap/SID/SYS/exe/run

The “tp” program uses different methods for this. Either it connects to the database itself or it uses R3trans for this. Or, as a last option, it uses ABAP programs in the SAP system to perform its job.

46 UPGRADING SAP

Figure 4.20: Three methods of “tp” accessing the database.

The “tp” program calls R3trans directly via a fork() system call. ABAP programs are started indirectly by using “sapevt.” The “sapevt” program triggers the RDDIMPDP (Import Dispatcher) ABAP program, which should be scheduled in the SAP system waiting for an event. The RDDIMPDP program is scheduled in the SAP system using the RDDNEWDP program.

4.5.5 Transport Steps

When an import is done for a particular transport request, regardless of its contents the following steps are performed on the target (or receiving) system:

Step 1. Command File Import – During this step, the information about the transport request itself is loaded into the target system. Updates are done on tables E070 and E071.

Step 2. DDIC Import – During this step, information about the layout or structure of the new tables, or table structure changes is loaded in the SAP system and stored in tables like DD01L, DD02L, DD03L, and DD04L. If the transport request does not have table information included, this step is skipped.

Step 3. Activation – During this step, all new tables or table changes are activated. If the transport request does not have table information, this step is skipped.

Step 4. Main Import – During this phase, rows or records are loaded from the transport request data file into the relevant tables in the target SAP system by using R3trans. This phase will also import the ABAP source (which resides in table REPOSRC) into the target system. This phase is skipped in cases where there are no data rows to load.

Step 5. Match Code Activation – This “special” phase is only performed if match code objects are included in the transport request.


Step 6. ADO Import – When application-defined objects, such as SAPScipt Forms, are included in the transport request, the import is performed during this phase.

Step 7. Version Management – During this phase, all version data is updated in the system. This provides the ability to back out to older versions of programs and definitions.

Step 8. XPRA – Execute Programs After Put / Import – In this phase, additional programs run in batches that modify data tables.

Step 9. Generate – During this phase all ABAP programs or function modules are generated or compiled from ABAP source code into ABAP byte code. This step is only executed when ABAP source code is included in the transport request.

It’s very easy to determine up front what steps will be executed for a transport request. By using “tp showbuffer” you can list all required steps per transport request.

Besides these nine main steps executed by “tp,” various other ABAP programs are executed during the import. These ABAP programs are executed by “tp” though the “sapevt” program.

Figure 4.21: “tp” calls “sapevt” to start ABAP programs.

Each transport request consists of two files: the cofile (control file) and the datafile. The cofile contains metadata about the transport request and the data file contains all data, such as ABAP source, screen definitions, and table row data. The “tp” tool uses the cofile to prepare the import of the transport request into the SAP system. The information in the cofile is used to determine the sequence of the ABAP programs. Two control tables within the SAP system, named TRBAT and TRJOB, are used as a communication channel between “tp” and the ABAP programs. The control tables contain certain values, which represent the steps that are performed in the SAP system during an import.

48 UPGRADING SAP

Function Code Job Name ABAP Program Description

X RDDDIC0L RDDDIC0L ADO export

J RDDMASGL RDDMASGL Mass activation

B RDDTACOL RDDTACOL TACOB activation

S RDDDIS0L RDDGENBB Distributor

N RDDGEN0L RDDGENBB Import conversion

M RDDMASGL RDDMASGL Mass activation for enqueue

Y RDDGEN0L RDDGENBB Matchcode conversion

O RDDGEN0L RDDGENBB Batch conversion

D RDDDIC1L RDDDIC1L ADO import

V RDDVERSL RDDVERSL Create version information

R RDDEXECL RDDEXECL XPRA execution

G RDDDIC3L RDDDIC3L ABAP generation (compilation)

The following ABAP programs can be distinguished: RDDDICnL, responsible for both table imports as ABAP compilations; RDDMASGL, which does the table activation; and RDDGENBB, which does all the data conversions.

4.5.6 DDIC Import

The DDIC (Data Dictionary) Import phase is used to import information over information, the so-called metadata. For example, if the transport request contains a new table, the information about the layout of this table is imported into the SAP system. Several tables in the SAP system contain information about each table.

Table Name Description

DD02L Table header information; fields are: tabname – Name of table as4local – is table activated? tabclass – Data class table belongs to (TRANSP, INTTAB, CLUSTER, POOL, VIEW,

APPEND) clidep – Whether table is client dependant or not buffered – Whether table is buffered in memory

DD02T Table texts; fields are: tabname – Name of table ddlanguage – Language key ddtext – Text itself


DD03L Field information; fields are: tabname – Name of table fieldname – Name of field keyflag – Whether field has a key checktable – Pointer to check table position – Relative position of field in table

DD01L Domain information; fields are: domname – Name of the domain datatype – Type of domain length – Length of domain in bytes

DD04L Data elements; fields are: rollname – Name of data element domname – Which domain the data element belongs

DD09L Table technical settings; fields are: tabname – Name of table tabkat – Category of the table tabart – Data class table protocol – Whether table logging is switched on

The SAP table relationship model on tables and it fields, can be illustrated as follows:

Figure 4.22: Relationship model for SAP tables.

50 UPGRADING SAP

4.5.7 Activation and Distribution

After the information about new tables is imported, or in cases where existing tables have been updated, the new table definition needs to be activated. Each table has three different objects in the SAP system: (1) the definition in the Data Dictionary, (2) a nametab object, and (3) a runtime object. The definition in the Data Dictionary was already described previously. The nametab object is information about the table that is used by the DBSL (Data Base Software Layer) to generate SQL code during ABAP program execution. The nametab itself consist of two tables, namely DDNTT (Table header) and DDNTF (Table fields). The runtime object is the “transparent” table in the SAP database. This object can be accessed with SQL statements.

The entire process of table activation, distribution, and conversion can be illustrated by the following example. This six-step example will show the activation of a table that is revised with an additional field, with and without data.

Figure 4.23: Table activation phase.

In step [1] the original table TAB01 (DDIC, nametab, and runtime object) is shown. In step [2] the table TAB01 is adjusted through transaction SE11 and an additional field is added. In step [3] the table is activated, which means an entry in the inactive nametab (table DDXTT and DDXTF) is created.

In step [4] the distributor will determine what conversion method to use: (1) conversion through shadow table QCM<tablename> and a conversion ABAP program or (2) just a drop/re-create or other SQL statement.


Figure 4.24: Table distribution phase.

The result of the “distribution” phase is stored in either table TATAF or TBATG (Table for Batch Conversions). In case TAB01 contains data that needs to be kept, a conversion will be performed, such as in step [5]:

Figure 4.25: Table conversion phase.

The conversion phase first renames the table TAB01 to QCMTAB01 and creates a new table TAB01 according to the new layout. Through an ABAP program, all data is read from table QCMTAB01 and after conversion inserted into table TAB01. After the process is finished, table QCMTAB01 is dropped and new indexes are created.

52 UPGRADING SAP

In case TAB01 is empty, the distributor will adjust the table in the database by using conventional SQL statements DROP TABLE/CREATE TABLE or ALTER TABLE. This looks like step [6], “Move nametab.”

Figure 4.26: Table Move nametab phase.

This “move nametab”-phase is executed by program “tp.”

4.5.8 Running the XPRA Job

The XPRA (Execute Report After Put) is a general set of ABAP programs that take care of master data or customizing data conversions, which are affected by the change of certain ABAP programs. This conversion is different from the table conversion related to table layout adjustments. The XPRA reports always run in a batch or background work process. The “tp” tool uses the RFC mechanism to see whether the job has completed successfully or not. Examples of XPRA reports are:

� Report RSA1XP04 ensures that the status information for connections to SAP BW systems is set to “inactive” in the RSASIDOC table.

� Report AGR_XPRA_REGENERATE_SAP_NEW is taking care of the SAP menu items after the upgrade to a higher version.

The execution of XPRA reports is an essential part of the elapse time of upgrades and the implementation of Support Packages. In cases where a severe error occurs and a descriptive SAP note tells you to ignore the message, you’re able to exclude the XPRA from the upgrade or Support Package. In order to do this you have to run ABAP report RSXPRAUP and enter the transport request, which contains this


XPRA. The name of the transport request can normally obtained from the error log .ELG.

INFO For more information on the subject of excluding XPRA programs, see SAP note 122597.

4.6 CLIENT COPIES

After a “new” SAP R/3 installation, the SAP system is only delivered with the so-called delivery clients: 000, 001, and 066.

The client “000” is empty, which means that there is no master or transaction data stored in this client. It is primarily used to manage Data Dictionary objects. In the past, this client was also used to apply Support Packages and to correct Data Dictionary changes through SPDD and SPAU.

Client 000 – SAP Reference Client

The “SAP Reference Client” is shipped by default in any SAP system and contains a copy of all default SAP customizing settings. It contains sample entries for organizational structures and other module-specific customizing. The SAP Reference Client contains settings like:

� Tables with default settings. (The content of these tables are independent of the organizational units.)

� No master or transaction data (application data) � Default settings for all customizing objects � Examples of organizational units (company codes, business area, sales

areas, purchase organizations, controlling areas, etc.) During SAP release upgrades, new default settings are written to this client,

which may overwrite or replace existing ones.

TIP You should not make changes to client 000 as it may be overwritten by applying Support Packages or during SAP release upgrades.

Client 001 – Production Preparation Client

The “Production Preparation Client” is identical to the client 000 “SAP Reference Client,” which means that table entries (rows) are similar. The only major difference between client 000 and client 001 is the existence of additional example customizing in client 001: tax rules, sample charts of accounts, and certain validation and substitution rules. Client 001 remains untouched during the implementation of Support Packages or a SAP release upgrade.

54 UPGRADING SAP

Client 066 – EarlyWatch Client

The “SAP EarlyWatch Client” is exclusively used by the “SAP Global Active Support” organization to run “GoLive” and “EarlyWatch” reports. This client only contains user-master records and authorization profiles.

To prevent customers from using client 000 and 001 for productive usage, SAP provides the ability to create new clients and copy client-specific content from one client to the other. SAP supports different methods to copy content between clients: per table basis, per group of tables, or through an entire client copy. When a client copy is done, SAP offers the ability to do this even between different SAP systems.

Figure 4.27: “Local” client copy versus “Remote” client copy.

The recommendation would be to leave all client numbers between 000 and 099 exclusively to SAP, and start numbering clients used by the customer at 100 and above.

A typical client layout would look like this:

Figure 4.28: SAP client landscape example.


This example with three SAP instances, named Development, Quality Assurance, and Production contains nine clients. There is a separation of clients for business configuration customizing, development of reports and transactions, development of interfaces, and testing. The “Gold Config” client contains the initial content before a new development life cycle is started. The QAS instance contains three clients for the acceptance process of development and customizing (test against production data), unit testing (both integration testing and data conversion testing), and a separate training client, if required. In some cases it is recommended to have a separate SAP instance for training purposes. And lastly we have the production instance with one single “production” client.

TIP In cases where the client numbers are kept the same throughout the landscape, such as 100-100-100, it is easier to refresh instances by making use of complete database copies.

For SAP applications that make use of InfoCubes, such as BW, SEM, or APO, it’s not possible to have multiple clients in one single SAP instance; therefore, it’s recommended to use:

Figure 4.29: SAP client landscape for InfoCube-based applications.

Also, for these systems, it’s important to keep the client numbers the same in case you would like to use “entire database copies” for system refreshes.

TIP When designing new InfoCubes, add the source-system info-object as field. In this case it’s possible to use one development and test client in BW for multiple development clients. Otherwise you have to run multiple BW systems in order to support multiple clients in R/3.

The client copy process itself consists of four major steps: (1) Manual preparation

This step is executed by the system engineer and consists of the addition of the new client to the client table, followed by the configuration and scheduling of

56 UPGRADING SAP

the client copy. The engineer also has to take care of the database in terms of space requirements.

(2) Initialization

When the client copy is actually started, it first creates a list of all tables that need to be copied. If table field DD02L.CLIDEP = “X”, the table will be copied unless the table is added to the client copy exception table by the system engineer. Also, a list of XPRAs is created that are executed after the copy process.

(3) Actual copy process

During this step, which can take hours, each row of the table belonging to the source client is copied over to the target client. So the copy is within the same table, only the client number (TABNAME.MANDT) is changed.

The SQL statement look likes this:

LOOP FOR ALL TABLES in DD02L do

IF DD02L.CLIDEP=’X’ and TABNAME not in ClientCopyExceptionTable do

LOOP FOR ALL ROWS in TABNAME where MANDT=SOURCENUMBER do

INSERT VALUE (TABNAME.MANDT = TARGETNUMBER ,

TABNAME.FIELD-A = TABNAME.FIELD-A ,

TABNAME.FIELD-B = TABNAME.FIELD-B ,

TABNAME.FIELD-C = TABNAME.FIELD-C ,

…………………….

)

ENDLOOP

ENDIF

ENDLOOP

So the copy process is a copy loop for rows into a copy loop for tables. (4) Postprocessing

During the “postprocessing” phase certain XPRA programs are executed.

Besides using the “internal” client copy method, which is based on SCC3 and SCCL, it’s also possible to use R3trans. However, it’s not recommended to use R3trans for “internal” client copies.

The client copy process is executed through transaction code SCC1, which will eventually execute reports RSCLICOP for SAP R/3 releases below 4.6C or RSCLCCOP for higher releases. The steps executed by a client copy are stored in table CCCFLOW. This table, CCCFLOW, contains several fields to control the process. The output logs of the client copy can be viewed using transaction code SCC3.


Tables can be excluded from the client copy process using report RSCCEXPT, which offers the ability to add tables to a list of tables that are skipped during the client copy process. There are tables you might consider excluding from the client copy like CDCLS, CDPOS, and CDHDR. These tables are used by the ALE engine.

INFO For more information on client copies, have a look at SAP Note 552711—Client Copy FAQs

4.6.1 Remote Client Copies

The process of a “Remote Client Copy” is similar to the “Local Client Copy” except for a few differences. First of all, there are multiple ways of doing a “remote” client copy. The first method is based on transaction SCC9 – Remote Client Copy. The second method works with R3trans.

The SCC9 Remote Client Copy function has significantly improved over time. This process uses an RFC connection between the source and target system. The initial release of the SCC9 functionality was only able to copy tables remotely in sequence. Later versions are able to copy tables in parallel.

Figure 4.30: Remote client copy using SCC9 RFC.

In order to run the SCC9 client copy over parallel RFC links, certain RFC groups need to be put in place.

The second option is to use R3trans instead of transaction SCC9. The R3trans method works slightly different. This method uses two command

files, one for export and one for import.

# R3trans export – called: exportclient100.r3t

export

client = 100

file = ‘/usr/sap/trans/data/clientexport100.dat’

use commandfile=’/usr/sap/trans/cofiles/<COMMANDFILE>’

58 UPGRADING SAP

Figure 4.31: Remote client copy using R3trans manually.

# R3trans import – called: importclient200.r3t

import

buffersync=yes

client = 200

file = ‘/usr/sap/trans/data/clientexport100.dat’

First export on source system: source-host> cd /usr/sap/trans/bin source-host> R3trans exportclient100.r3t copy over all files to target system; all logs are written to r3trans.log target-host> cd /usr/sap/trans/bin target-host> R3trans importclient200.r3t The tool R3trans can also be used to copy individual tables over from one

system or client to another.

# R3trans export – Called: EKPO (client 100 only) table copy

export

client = 100

file ‘/usr/sap/trans/data/tableEKPOcl100.dat’

select * from EKPO

TIP For more information on the various aspects of using R3trans to export clients or individual tables, please have a look at SAP Note 1942.


4.6.2 Multiclient Manager

As of SAP Web Application Server 6.40, SAP started to support the MPC facility. MPC, or Multiple Production Clients, offers you the ability to run multiple clients on one SAP system. Until SAP release 6.40, this option was not supported for production systems and was only used in non-production systems such as development, acceptance, and training.

The reason behind this strategy change is the so-called “ASP” (Application Service Provider) market, where different business applications from different companies are transparently hosted on a limited set of SAP instances. The ASP term is now also known as SaaS (Software as a Service).

In order to support ABAP programming in an MPC environment, SAP offers a set of tools and programs to prevent conflicts. Transaction MCLIMAN is one of them.

4.7 SUPPORT PACKAGES

Support Packages, also known as OCS (Online Correction Support), are a set of bug fixes that eliminate errors in the SAP system. SAP introduced Support Packages as of SAP R/3 release 3.0A as an addition to release upgrades. Since SAP R/3 3.0A, the delta upgrade has been replaced by the so-called “repository switch” method. However, applying Support Packages can be compared with a delta upgrade, although you don’t change the SAP release.

In the early days of Support Packages, when they were still called Hot Packages, SAP never added new functionality into it. Today, additional functionality may be added to a Support Package. The entire Euro Conversion kit was shipped through Support Packages.

Support Packages are bound to the SAP release and add-ons used in the system. Fixes in Support Packages, however, are not necessarily bound to SAP R/3 release; it can happen that a certain bug resides in several R/3 releases and therefore needs to be fixed in all those releases. This means that if you upgrade an R/3 4.6C Support Package level 20 system to R/3 4.72 Support Package level 5, you might partially downgrade the system.

Figure 4.32 illustrates the location of a certain bug fix in several different Support Package bundles, each belonging to a specific SAP R/3 release.

Individual bug fixes are also described in OSS notes, which are known as Source Code Corrections. These ABAP source code corrections can be applied manually using the SE38 ABAP editor. However, it’s more efficient to use “SNOTE – Note Assistant” or wait until SAP releases a new bundle of Support Packages.

60 UPGRADING SAP

Figure 4.32: Bug fixes can reside in several Support Packages.

4.7.1 Support Package Types

SAP has released several different kinds of Support Packages: Hot Packages (HP), Legal Change Packages (LCP) and Conflict Resolution Transports (CRT). Since SAP R/3 4.6A even more Support Packages have been introduced: SAP_BASIS, SAP_APPL, SAP_ABAP, and SAP_HRP. And last but not least, with the introduction of SAP R/3 4.7 Enterprise, the Support Package structure has changed again.

(1) Hot Packages – This type of Support Package was introduced in SAP R/3 3.0A and covers all functional and Basis modules. Has been replaced by SAP_APPL, SAP_BASIS, and SAP_ABAP.

(2) Legal Change Packages – This type of Support Package is only applicable for an R/3 system running the HR module. It was introduced in SAP R/3 3.1H and has been replaced by SAP_HRP packages.

(3) Conflict Resolution Transports – This Support Package is basically a fix for modifications of standard SAP. When a customer uses a certain R/3 add-on, such as IS-Oil or IS-Hospital (IS-Heath), these add-ons may modify certain core R/3 objects, such as adding additional screens, programs, or table fields. Normal Support Packages are not aware of these modifications and will overwrite them. CRTs are additional transports that need to be added to the Support Packages in order to prevent such overwrite.

(4) SAP_APPL – This Support Package type contain fixes for all SAP R/3 modules except HR (Human Resource).

(5) SAP_BASIS – This Support Package type contains only fixes that belong to the Basis layer, such as fixes for the Batch Engine, CCMS, and User Management.


(6) SAP_ABAP – This type of Support Package type contains only fixes that are related to the ABAP Development Workbench and other development tools; so all SE-related transactions.

(7) SAP_HRP – This Support Package type contains only fixes for the HR module and is therefore the successor of the LCP Support Package type.

4.7.2 SAP Patch Manager

The SAP Patch Manager, also known as SPAM, can be invoked by using transaction code SPAM. This tool is used to implement Support Packages in all ABAP-related SAP applications; whether it’s R/3, BW, CRM, or APO.

This toolset, as of now called SPAM, provides the ability to load all kinds of Support Packages from various sources, such as CD-ROMs, file systems, the Internet, and desktop into the SAP system. SPAM has a variety of tools to accommodate the load of Support Packages:

(1) EPS – Electronic Parcel Service, can be used to download Support Packages from OSS or the SAP Support Marketplace. The EPS stores all downloaded SAR (SAP archive format) files in “/usr/sap/trans/EPS/in.”

(2) SPAM Queue – This queue needs to be prepared before the actual load of the Support Package occurs. The queue can contain a mix of different Support Package types, such as SAP_BASIS, SAP_APPL, SAP_HRP, and CRTs.

TIP Always check the appropriate OSS notes on the exact SPAM Queue layout. There are restrictions around certain combinations of Support Packages. In other words: not all Support Packages can be combined in one queue.

(3) Import Tool – The actual tool that does the load of the Support Packages into the SAP system.

(4) SPAM Update Manager – This tool is used to patch the SAP Patch Manager itself.

TIP Always update your SAP Patch Manager with the latest SPAM update before you apply new Support Packages into your SAP system.

4.7.3 Conflict Resolution Transports

If your SAP system also contains add-on components, such as Industry Solutions, you need to take care of Conflict Resolution Transports, or CRTs for short. CRTs contain corrections on top of Support Packages that apply to add-on modifications made to standard SAP.

62 UPGRADING SAP

Figure 4.33 CRT prevents overwriting of add-on modifications.

Figure 4.33 illustrates the modification of Core R/3 by an add-on, such as IS-Oil. This “regular” Support Package, however, will overwrite this modification. To prevent that from happening, the CRT will correct this.

TIP Always check whether a system contains any add-ons by using transaction SE16, Table Browser, and then check the table “AVERS” (add-on version table). Also, check all OSS notes related to any add-on described in this table. SAP has introduced many more add-ons besides Industry Solutions.

As of SAP ERP2005 or ERP 6.0, all industry solutions are embedded in the core release of SAP. Therefore, CRTs are no longer required.

4.7.4 Support Package Import Phases

After downloading Support Packages from either a CD-ROM or the Internet (using the SAP Download Manager) into the EPS directory, the import queue can be defined. The import phases will use this import queue as the source for all Support Package imports. SPAM executes the following phases during the import of Support Packages:

(1) PROLOGUE – During this phase, certain checks are done, such as authorization checks, and a check if previous Support Packages are “confirmed.”

(2) CHECK_REQUIREMENTS – During this phase, the transport tool “tp” checks whether it is able to connect to the database.

(3) DISASSEMBLE – In this phase all EPS packages, located in “/usr/sap/trans/EPS/in,” are extracted into individual transport files (both co- and data-files) and stored in “/usr/sap/trans/cofiles” and “/usr/sap/trans/data.”


TIP Be sure that your “/usr/sap/trans” filesystem is large enough to hold both EPS and extracted co- and datafiles. Certain Support Package bundles can become very big.

(4) DISASSEMBLE_PATCH – During this phase, “tp” will create co-files of every datafile shipped with the Support Package. The exact statement is:

“ tp createcofile –s <datafile> ” (5) ADD_TO_BUFFER – In this phase, all transports shipped with the Support

Packages are added to the transport buffer. The exact statement is: “ tp addtobuffer <change request>” (6) TEST_IMPORT – During this phase, all open repairs and change requests are

checked for objects that will be replaced during the import. (7) IMPORT_OBJECT_LIST – During this phase, a list of all objects that are

shipped with the Support Packages are imported in the system. The list is used to check whether there are conflicts between modifications, add-ons, and these shipped objects.

(8) OBJECT_LOCKED_? – This phase checks if objects that will be replaced are locked in a transport request.

(9) SCHEDULE_RDDIMPDP – This phase will check whether RDDIMPDP is scheduled as a periodic job. If not, it will schedule this job.

(10) ADDON_CONFLICTS_? – In this phase, the list, created in “IMPORT_OBJECT_LIST,” is used to check for conflicts between import objects and any of the installed add-ons.

(11) SPDD_SPAU_CHECK – During this phase, a list of modification adjustments is made and stored in a table that is later presented in transactions SPDD (for Data Dictionary modifications) and SPAU (for ABAP modifications).

(12) DDIC_IMPORT – In this phase, “tp” will import all Data Dictionary objects into the system.

(13) DELETE_FROM_BUFFER – This phase will clean up import buffers. (14) AUTO_MOD_SPDD – During this phase, SPAM will check whether certain

Data Dictionary object modifications can be adjusted automatically. (15) RUN_SPDD? – This phase will prompt you in case adjustments need to be

made in transaction SPDD. (16) IMPORT_PROPER – This phase, with the longest elapse time, will do the

import of all Support Packages. This phase is primarily executed by “tp” and follows the same steps as an “ordinary” import request:

(a) Command File import (b) DDIC import (c) Activation (d) ADO imports (e) Conversions

64 UPGRADING SAP

(f ) Version updates (g) Execution of XPRAs (h) Generation of ABAP programs and screens (17) AUTO_MOD_SPAU – Same phase as AUTO_MOD_SPDD, except this time

it’s for ABAP programs and screens. (18) RUN_SPAU? – This phase will prompt you when modifications to ABAP

programs and screens need to be adjusted. However, due to the fact that ABAP objects can be handled with versions, you may ignore this phase and sort this out at a later stage.

(19) EPILOGUE – In this phase, some administration and control tables are updated with the correct version information.

After applying the Support Packages using SPAM, the administrator needs to “confirm” the patch queue. The only remaining task is to sort out the SPAU list.

Figure 4.34: Transaction SPAM (Support Package Manager). ©Copyright SAP AG.

4.7.5 Support Packages in R/3 Enterprise

SAP has changed the way modules are organized in R/3 Enterprise. Certain functionality has been moved from core R/3 into the so-called “Extensions.” These extensions are grouped into “Extension Sets.” Therefore, by disconnecting certain functionality from Core R/3, a new group of Support Packages is introduced as well.


Figure 4.35: Different Support Packages in SAP R/3 Enterprise.

Figure 4.35 shows the different component layers of an SAP R/3 4.7 Enterprise system. The second box illustrates the different Support Packages and their interrelationship with SAP R/3 4.7.

Besides these new extensions, the number of plug-ins has also been increased. Because applying Support Packages to an SAP R/3 Enterprise system has become more complex, SAP has developed the SPAM Queue Calculator. This tool will calculate the ideal combination of Support Packages in order to prevent conflicts.

The second new feature of SPAM in R/3 Enterprise is the “Support Package Shadow Import.” This feature will reduce the SAP application downtime caused by the import of Support Packages. The idea behind this feature is to import, activate, and convert all objects belonging to the Support Package into a shadow repository and, at the end of all phases, switch to the new coding.

Figure 4.36: SAP Support Package Shadow Import. ©Copyright SAP AG.

This new feature provides the ability to reduce SAP application downtime during import of Support Packages by about 60% when compared to the old

66 UPGRADING SAP

method. Downtime savings are achieved, especially when the Import Queue contains all kinds of CRTs for plug-ins and other add-ons. Due to this significant savings, SAP has decided to downgrade the functionality to SAP R/3 4.6C as well. This is shipped as part of a SPAM update.

The method is relatively easy and based on a set of tables that form the so-called “shadow repository” and are created in parallel to the existing “repository.” After the entire Support Packages are imported into the “shadow repository”, the system will switch from the “existing repository” to the new “shadow repository”. This switch is the only phase that requires application downtime. The method described here is similar to what we know from SAP release upgrades as the “Repository Switch.”

4.7.6 Support Package Stacks

The SP (Support Package) Stacks are sets of Support Packages and patches for the respective SAP release and must be used in the given combination. SAP recommends implementing these SP Stacks regularly. The technology for applying Support Packages and patches will not change. SP Stacks should be seen as an entity unto themselves – customers must obtain the minimum requirements and dependencies between individual components, and apply the Support Packages and patches specified in the SP Stack together. The intention of SP Stacks is to offer better mechanisms to apply support packages to complex systems that contain a lot of different components. Therefore, SP stacks are released synchronously.

Figure 4.37: SAP Support Package Stacks. ©Copyright SAP AG.


4.7.7 Support Packages as of NetWeaver 7.0

With the introduction of SAP NetWeaver 7.0, which is based on SAP Application Server 7.00, SAP introduced a new concept for deploying Support Packages. In the past, Support Packages were directly downloaded through the SAP Support Marketplace, either by Internet Explorer or by the SAP Download Manager. The only requirement was to have access to the download section. However, due to the complexity and number of different Support Packages, SAP has decided to control the download through the SAP Solution Manager. This is done through a tool called the Maintenance Optimizer.

Now that all the industry solutions are embedded in our SAP ECC 6.0 system, the number of components has grown significantly. The SAP ECC 6.0 component, which is the central core component of the SAP ERP 2005 Business Suite, consists of a core system (formerly known as R/3) and various add-ons and industry solutions. With the options of embedded installations (also known as MCOS – Multiple Components in One System) you can expand the installation functionality even more.

Figure 4.38: SAP ERP 2005 components. ©Copyright SAP AG.

Once these components are activated or added to the SAP system they become subject to patch and change management. The implementation of Support Packages to an SAP ECC 6.0 system can be quiet complex. Therefore, SAP has decided to help administrators in this task by supplying tools. Both the SAP Maintenance

68 UPGRADING SAP

Optimizer and the SAP SLM (Software Lifecycle Manager) are examples of such tools.

Figure 4.39: mySAP ERP 2005 Business Suite Support Package Stacks.

©Copyright SAP AG.

4.7.8 Tables Used with SPAM

The SAP Patch Manager uses various tables to keep track of progress, status of each step, and history of all applied patch bundles. The tables are in the PAT*-name range:

Table Name Table Description

PAT00 Patch steps

PAT01 Patch status

PAT02 Conflicts between patches and add-ons

PAT03 Patch directory

PAT07 Patch prerequisites

PAT09 Patch history

TEPSIN EPS bundle inbox

TIP These tables contain some nice information you can use in case of problems, however, it is strongly recommended not to change the contents of these tables yourself.

4.7.9 SPAM Queue Conflicts

Not all Support Packages can be combined in one single queue for import. The reason for this is caused by the way SPAM works. All import steps are performed in sequential order for all objects in the queue. This means that for all included Support Packages, all objects are first imported into the SAP system. Secondly, all objects are activated and at last all data for these objects is imported. So each step is only executed once, regardless of the number of Support Packages.


However, it is possible that changes or modifications to certain objects are included more than once. Assume we have a table TABX that is modified in SP1 by adding a new field to it. This extra field, however, is removed again in SP2. Because SP2 is applied after SP1, the table will lack the “new” field. As soon as the TABIM (table import) phase starts, it will first import all SP1-specific data and then import SP2-specific data. The SP1-specific TABIM phase, however, expects this “new” field to be there. So the “INSERT” statement will fail due to a missing table field.

Figure 4.40: Error in TABIM phase due to missing fields.

In this example the error occurs in the TABIM phase, although in most cases the error occurs in the ACT phases when there is an incompatibility between domain definitions, data elements, and table fields.

This can all be prevented upfront by importing all Support Packages in batches, which do not have conflicts. Information about possible conflicts between Support Packages can be found in the relevant OSS notes. Search for the term OCS or OSS to find all these relevant notes.

4.7.10 SAP Download Manager

There are several ways to obtain the Support Packages: (1) using transaction SPAM, (2) by connecting to the OSS SAP system in Walldorf, or (3) by requesting for the so-called OCS Bundle CD-ROMs. In order to save costs on CD-ROM media, SAP has introduced a third source for your OCS bundles: “The Internet.”

The SAP Download Manager is a J2SE (Java 2 Standard Edition) based tool that runs on your PC and connects to SAP through the Internet using HTTPS. You first need to add the requested OCS packages to the “download basket.”

70 UPGRADING SAP

This basket is part of the OCS Patch area on the SAP Service Marketplace. So first use the “ordinary” Microsoft Internet Explorer Web interface for selecting the packages and add them to the download basket, and use the separate SAP Download Manager to really download them to your PC. With the introduction of NetWeaver 7.0, this process has changed (see Section 4.8).

Figure 4.41: Screen-shot of SAP Download Manager.

Besides Support Packages and kernel patches, entire installation and upgrade kits can be obtained using the SAP Download Manager.

4.8 SAP MAINTENANCE OPTIMIZER

In order to keep the Total Cost of Ownership (TCO) low for implementing Support Packages and patches on the SAP NetWeaver and Business Suite, SAP has released a tool that helps to determine the right patch sets. As explained in the previous section, the number of components has dramatically increased and therefore the number of different patches has also increased. By using the SAP Maintenance Optimizer (MOP) the support team can locate the required patch files much easier.

The MOP is implemented as a component inside the SAP Solution Manager and deployed through a Support Package. The MOP tool is accessed through Transaction SOLUTION_MANAGER → Select Solution → Change Management


→ Support Package Stacks. This will show a screen with all the components in your landscape. The MOP is using the SAP Landscape Directory (SLD) to obtain this information. A properly installed and configured SLD is thus a requirement for using the MOP.

Figure 4.42: SAP Maintenance Optimizer in Solution Manager. ©Copyright SAP AG.

After the selection of the system, the MOP tool is invoked by pressing the “Maintenance Optimizer” button. This will bring up the guided procedure for obtaining the right Support Package.

Figure 4.43: SAP Maintenance Optimizer download wizard. ©Copyright SAP AG.

72 UPGRADING SAP

After the required patch files have been selected, the package needs to be confirmed and is checked by SAP against the license agreement. Once checked, the files appear in the Download Basket residing in the SAP Support Marketplace. As of this writing, the files can be downloaded using the regular process with the SAP Download Manager. This means that the files are not downloaded using the MOP tool. The tool is just used to prepare the download activity. Once done, the files are downloaded to the PC. From this moment onward the process of applying Support Packages is exactly the same as in the past.

4.9 INDUSTRY SOLUTIONS AND ADD-ONS

SAP covers both the horizontal and the vertical marketplace, which means it delivers functional software products for general businesses and for industry-specific businesses. This industry-specific functionality is implemented through IS-Solutions, which are additions to the standard “core” R/3. Known IS-Solutions are IS-Oil for the oil and gas industry, IS-Media for the media and publishing industry, and IS-Healthcare for hospitals.

List of IS-Solutions:

SAP for Aerospace and Defense SAP for Media SAP for Automotive SAP for Mill Products SAP for Banking SAP for Mining SAP for Chemicals SAP for Oil and Gas SAP for Consumer Products SAP for Pharmaceuticals SAP for Engineering and Construction SAP for Utilities SAP for Professional Services SAP for Healthcare SAP for Public Sector SAP for High Tech SAP for Retail SAP for Higher Education and

Research SAP for Service Providers SAP for Industrial Machinery and

Components SAP for Telecommunications SAP for Insurance There are two types of IS-Solutions: Solutions that modify the standard “core”

SAP and solutions that do not modify standard SAP. IS-Oil, which was one of the first IS-Solutions released by SAP, for example, does modify standard SAP. This means that standard SAP programs, screens, and tables are modified and/or overwritten by IS-Oil–specific coding. The result of this is that every time an upgrade is performed or Support Packages are loaded into the system, the system needs to take care of this exceptional situation. When loading Support Packages into the system, CRTs (Conflict Resolution Transports) are loaded with the Support Packages. During upgrades, the IS_SELECT phase will take care of this. However,


you still need a special upgrade-software kit, which does contain the new IS-Solution.

The second type is basically an add-on and is installed on top of the standard “core” R/3.

Figure 4.44: Two types of SAP IS-Solutions.

An example of the second type IS-Solution is IS-Utilities, which can be installed into an R/3 system that has been already used for several years. . With SAP ERP 6.0 it is possible to use multiple IS-Solutions in a single SAP system.

Next to IS-Solutions, SAP has released all kinds of add-ons to R/3 and other components. These add-ons are, for example, PI, or Plug-Ins, that are used for BW, APO, or SAP Enterprise Portals. Other add-ons are, for example, SAP EH&S (Environment Heath and Safety) for management of dangerous goods and SAP FS-CD (Financial Services Collections and Disbursements) for the insurance companies. The installation process is similar to IS-Solutions and may also modify standard SAP coding. Therefore, you need to know what add-ons are installed in your SAP system. As mentioned in previous sections, as of SAP ERP 6.0 all Industry Solutions are embedded in the system by default. However, it just becomes active after the Industry Solution is switched on.

TIP Use transaction code BAOV or look at table AVERS to see what IS-Solutions or add-ons are loaded on your system.

4.9.1 Installation Using R3up

The installation process of IS-Solutions differs from product to product; certain (recently released) solutions are installed using transaction code SAINT and other products, such as IS-Oil and IS-Utilities, use R3up (same tool as the R/3 Upgrade tool) to install.

The following phases are executed to install an IS-Solution using R3up:

Phase Description Log file

INITPUT Enter all parameters

DBCHK Determine RDBMS release DBINFO.LOG

74 UPGRADING SAP

RFCCHK RFC connection test RFCCHK.LOG

BATCHCHK Check Batch engine BATCHCHK.LOG

VERSCHK Check SAP release

ADDSPAREQ Prepare DB space check

EXECIS Check for installed IS-Solutions EXECIS.LOG

IS_CHK Display installed IS-Solutions ISOUT.LOG

READDATA Read software from CD-ROM

KEY_CHK Enter key from OSS note

PATCH_CHK Check status of Support Packages PATCHOUT.LOG

CLNT_CHK Client locked or updated? CLNTOUT.LOG

CNV_CHK Check TBATG conversations TBATGCHK.LOG

TRBATCHK Check if TRBAT is empty TRBATCHK.LOG

INTCHK Check if inactive nametab is empty DDXTnCHK.LOG

IS_READ Copy IS-Solution to /usr/sap/put

SPACECHK Check DB freespace DBINFO.LOG

FREECHK Check OS filesystem freespace

ISC_IMP Import IS command files ISC_IMP.LOG

IS_MERGE Check imported command files

JOB_RDDIT021 Merge add-on in table TODIR RDDIT021.LOG

REPACHK Check for open repairs REPACHK.LOG

ADJUSTCHK Determine DDIC object adjusted ADJUSTCHK.LOG

MODPROF Stop system and adjust profiles ALPUPDP.LOG

STARTR3 Start R/3 system

DDIC_yy Import of DDIC objects DDIC.ELG

JOB_UMOD20 Adjust BSEG table PSUMOD20.LOG

ACT_yy Activate new DDIC objects ACT.ELG

CON_yy Conversion of DDIC objects CONV.ELG

TABIM_yy Import entries in tables TABIM.ELG

ADOIM_yy ADO import, conv.matchcodes ADOIM.ELG

XPRA_yy Run XPRA reports XPRAS.ELG

JOB_RDDIT023 Update AVERS table PDDIT023.LOG

JOB_RSSPAM02 Load missing CRTs RSSPAM02.LOG

JOB_RDDIT020 Update AVERS table again PDDIT020.LOG

END Load end ENDCOMS.LOG


ENDCHK Test target system

MODPROFP Modify profiles and start system ALPUPDP.LOG

CHK_POSTUP Display P errors

SPAUINFO Display SPAU list

EXITINFO Display exit information

Most of the phases and their sequence are exactly the same as with a release upgrade.

4.9.2 Installation Using SAINT

Besides using R3up as an add-on installation tool, SAP also uses another tool to deploy add-ons. The transaction code SAINT will start the SAP Add-On Installation Tool, which is part of SPAM (SAP Patch Manager). When you patch the SPAM tool, you also patch the SAINT tool; therefore, it’s called a “SPAM/SAINT” patch.

Figure 4.45: SAINT SAP Add-On Installation Tool. ©Copyright SAP AG.

The SAINT tool is relatively easy to use. It offers an “installation” wizard that guides the engineer through the entire installation process. The steps the SAINT tool uses to import software into your SAP system are quite similar to the way Support Packages are imported.

76 UPGRADING SAP

4.10 ENHANCEMENT FRAMEWORK

SAP supports various methods for adjusting the software: customizing, enhancements, and modifications. Customizing is the process whereby the standard SAP software is parameterized. An enhancement adjusts an existing piece of SAP code so it is serving a business process better. A modification really changes a bit of standard SAP code and has a big drawback—every time SAP changes their code, the modification needs to be reviewed and changed (back) again.

The evolution of enhancements in SAP started with the ability to use “User Exit.” These are spots in the SAP code where a customer can add or adjust code by themselves. The code itself is embedded in the standard SAP workflow and does not touch SAP code, however, the location of code might change over time. A very well-known “User Exit” is MV45AZFF, which is used by SAP order processing.

Where an “User Exit” is based on the PERFORM statement, a “Customer Exit” is based on “Function Modules” and therefore has a better parameter interface defined. Another advantage is the ability to put all code in its own customer namespace, which is, by default, not overwritten during an upgrade.

Another option, introduced in SAP 4.6, is the Business Add-In. These BADIs are based on ABAP objects and provide the ability to have multiple versions.

As of SAP NetWeaver 7.0, a new paradigm has been introduced under the name “Enhancement Framework” that brings all enhancement techniques under one roof. This framework includes the following technologies:

� Source Code Enhancement � Function Group Enhancement � Class Enhancement � Kernel-BADI Enhancement

Figure 4.46: Evolution of enhancement technologies. ©Copyright SAP AG.


The Enhancement Framework tools have been embedded in the ABAP Workbench under transaction SE80 called “Enhancement Information System.” The ABAP objects language has been extended with two keywords to support the addition of enhancements in ABAP programs: ENHANCEMENT-POINT and ENHANCEMENT-SECTION.

Figure 4.47: Additional ABAP language statements for enhancements. ©Copyright SAP AG.

A new transaction, SPAU_ENH, provides the ability to keep, during the upgrade process, old “classic” BADI implementations and move them into the new “Enhancement Framework” concept. Therefore, existing BADI code can be kept and unchanged after the upgrade to NetWeaver 7.0, SAP ERP 6.0, or Business Suite 2005.

4.11 SWITCH FRAMEWORK

SAP also introduced the “Switch Framework” in NetWeaver 7.0. This new switch framework is used to implement Enterprise Extensions and Industry Extensions. The switch framework expands the capabilities of the Enhancement Framework by providing the ability to switch on sets of enhancements.

To make Switch Framework handling easier, and to better group the individual switch settings, SAP is also introducing business function sets and business functions. A business function set corresponds to an industry solution. Each

78 UPGRADING SAP

business function set is a group of business functions, and each business function group consists of a set of switch settings.

The following objects are subject to the Switch Framework: By package assignment � Appends, SI-, CI-includes for structures in DDIC � Fixed-value appends to domains � Secondary indexes � Append search helps � Enhancement implementations � Switch Business Configuration Sets (Switch BC Sets) By direct assignment � Screen elements and flow logic � Menu entries and functions � IMG nodes � Customizing By using the Switch Framework, you will be able to activate an entire Industry

Solution, such as IS-Oil or IS-Media. In some cases, it is also possible to activate multiple IS-Solutions in your system. However, there are some restrictions depending on the combination of the IS-Solutions. Once an IS-Solution is activated, it cannot be switched off. During the switch phase, all kinds of programs, data, and tables are generated. Two transactions are important here: SFW3 for the creation of a Business Function Set (BFS) and SFW5 to activate a Business Function Set.

Figure 4.48: Switch Framework architecture. ©Copyright SAP AG.


The combination of both Enhancement-Points and the Switch Framework enables customers to deploy different internal releases at the same time. As an example, a single development system can be used to hold various releases that are switched on or off. This means that certain release-specific objects are switched on in one system, but switched off in the other.

4.12 SAP NOTES

Bug fixes are collected in Support Packages. There is also an option to apply individual source code corrections. These corrections are described in SAP notes that can be found at http://service.sap.com/notes.

The implementation of individual SAP notes can be quite labor intensive. The source code needs to be changed manually using the SE38 ABAP Editor. Because you have to make these modifications to standard SAP code, you have to obtain an object key first through the SAP Service Marketplace. It’s recommended to use the “Modification” buttons in the SE38 ABAP Editor, which can be used to mark modifications in the ABAP source code. During upgrades and the implementation of Support Packages, transactions SPDD (Dictionary Objects) and SPAU (ABAP Objects) need to be performed in order to determine what to do with the modifications. It’s much more efficient when the modification browser can be used to support decisions in SPAU and SPDD.

The most efficient way of implementing SAP notes is by using the SAP NoteAssistant, which can be accessed through transaction SNOTE.

Figure 4.49 Apply SAP notes using NoteAssistant. ©Copyright SAP AG.

80 UPGRADING SAP

The SAP NoteAssistant provides the ability to connect to SAP, download the source code correction specified in the SAP Note, and apply this code automatically (including updates to the modification database). The SAP NoteAssistant is supported as of SAP R/3 4.5B, however, it’s only shipped as part of certain Basis Support Packages.

The following table shows which SAP releases require what Basis Support Package:

SAP Basis Release Minimum Precondition

4.5B SAPKH45B45

4.6B SAPKB46B33

4.6C SAPKB46C25

4.6D SAPKB46D14

6.10 SAPKB61027

6.20 SAPKB62013

INFO Additional information about the SAP NoteAssistant can be found in SAP Note 560756.

4.13 RELEASE UPGRADES

An SAP release upgrade is the most complex topic of the software logistics in SAP. During a SAP release upgrade, the entire repository of objects is replaced with a newer version. The techniques used during an upgrade are similar to the import of individual transports and the implementation of Support Packages.

4.14 SAP KERNEL PATCHES

The SAP Kernel is responsible for running all transactions in the system, interpreting the ABAP code, and accessing the data in the tables. The SAP kernel consists of various executables, which resides in the “/sapmnt/SID/exe” directory. In general, the SAP Kernel is downward compatible according to this scheme:

SAP Kernel Bundle SAP Basis release

SAP 3.1I_COM SAP R/3 3.1H and 3.1I

SAP 4.0B_COM SAP R/3 4.0B

SAP 4.0B_EXT SAP R/3 4.0B in extended maintenance

SAP 4.5B SAP R/3 4.5B


SAP 4.6D SAP R/3 4.6B and 4.6C

SAP 6.40 non-Unicode SAP Web AS 6.10 until 6.40 non-Unicode

SAP 6.40 Unicode SAP Web AS 6.10 until 6.40 Unicode

SAP 7.00 non-Unicode SAP AS 7.00 non-Unicode

SAP 7.00 Unicode SAP AS 7.00 Unicode

Each SAP Kernel bundle consists of several binaries, which all have their own patch level codes.

The exact patch level of a binary can be obtained through the “-V” option at the command prompt of the operating system:

$ cd /sapmnt/SID/exe $ ./disp+work –v ; SAP kernel (dispatcher + workprocesses) $ ./R3trans –v ; Transport tool $ ./tp –v ; Transport driver program $ ./icman –v ; Internet connection manager There are two types of SAP Kernels: Unicode and non-Unicode. It depends

on the character set used in the SAP database which of the two should be used. All new SAP installations are based upon the Unicode database, however, a lot of older SAP systems are still based on non-Unicode.

Another important part of the SAP Kernel is the dynamic link libraries (DLLs for Microsoft Windows and .o files for UNIX), such as “lib_dbsl” (Database-specific interface libraries), dboraslib for Oracle, dbmsslib for Microsoft SQLServer, and the rfclib32 for all RFC communication. In most cases when disp+work executable is upgraded, you also have to upgrade the “lib_dbsl.” In case the SAP JCo (Java Connector) is used on the SAP system, be sure that the latest copy of rfclib32 is used as well.

NOTE For the latest information on SAP Kernel patches, read SAP Note 19466. The SAP Kernels can be downloaded in .SAR (SAP Archive format) from http://service.sap.com/patches.

4.15 ENHANCEMENT PACKS

As of SAP ERP 2005, a new type of software deployment package is available, called an Enhancement Package. An Enhancement Package extends SAP ERP 2005 with new functionality that is normally released through SAP upgrades. To reduce the number of ERP releases, SAP has decided to keep the 2005 release as a core release up to at least 2010 and only add new functionality to the system through Enhancement Packs. So if a customer would like to leverage new functionality, it’s

82 UPGRADING SAP

no longer required to go through an entire upgrade process, but rather implement one or more Enhancement Packs instead.

Figure 4.50: mySAP ERP 2005 Enhancement Package strategy. ©Copyright SAP AG.

Enhancement Packages do not replace Support Packages. Support Packages are released to fix bugs and contain performance improvements. Enhancement Packages contain new functionality that is added to the ERP applications and can be licensed seperately. The functionality that has been added to the system through Enhancement Packages will become part of the next major SAP release. Implementing Enhancement Package is optional to the customer and need to be considered on a case-by-case basis.

Enhancement Packages are incremental, which means that if you do not have any installed in your system and you would like to install Number 2, it automatically installs Number 1. Due to the fact that Enhancement Packages are new functionality, which means new programs, screens, and DDIC objects, you have to implement Support Packages for these Enhancement Packages as well. This results in a much more complex Support Package strategy. To support customers with this, SAP has released tools like SLM (SAP Life-Cycle Manager) and the MOP (SAP Maintenance Optimizer). Tools like these should help to reduce the complexity and effort of applying Support Packages.

SAP will also release Enhancement Packages for other Business Suite components like CRM, SRM, PLM and SCM.

4.16 LANGUAGES

SAP applications based on the ABAP engine are multilanguage, which means that multiple languages can be used by end users. Depending on the release status, the SAP system supports up to 30 different languages. The language in which a dialog user works is specified during logon by making a selection on the logon screen. Alternatively, it can be specified by a system parameter or by a default setting in the user master record.


After a “fresh” install of an SAP system only German (DE) and English (EN) are available as languages. Additional languages need to be imported into the system using the Language management tool accessible through transaction SMLT.

The different languages are implemented as text elements, which are identified by a language key. All SAP support languages have their own unique language key that is specified in table T002:


SPRAS LANG (1) Language key

LASPEZ CHAR (1) Language specification

LAHQ CHAR (1) Degree of translation

LAISO CHAR (2) ISO 639 Language code

When an additional language needs to be installed in the system the language key needs to be available in this table. Through transaction SMLT, you will be able to select the appropriate language and add it to the list. For every language in the system, whether it’s imported or not, there is a line item in the overview screen of SMLT. By selecting this line, you can see all import details of this particular language. If the language has not been imported into the SAP system, this line will provide the ability to start loading the language.

Languages are imported by using R3load, up to SAP R/3 release 4.6C or by using R3trans as of SAP R/3 4.6C. The language import files are delivered as R3load or Transport files (co- and datafiles) on a CD-ROM. During the import phase in SMLT, you can specify the location of these installation files.

Figure 4.51: Initial screen of SMLT Language Management (SAP R/3 4.6C). ©Copyright SAP AG.

84 UPGRADING SAP

As already stated, languages are implemented as text elements. All text elements are stored in tables, with at least two fields: language key and text. So when a text is put on the screen it points to a row in a table, identified by a language key.

As mentioned before, table DD02L contains all table definitions in SAP. The table DD02T points back to DD02L, lists all relevant language fields, and contains all texts in different languages for all table names. Table DD02L points to DD02T, which contains (most important fields are shown here):


TABNAME CHAR (40) Name of table (as in DD02L)

DDLANGUAGE CHAR (2) Language key (as in T002)

DDTEXT CHAR (120) Text it self

For example, DD02T.TABNAME = ‘USR02,’ DD02T.DDLANGUAGE=’D’ and DD02T.DDTEXT=’Anmeldedaten.’

Text elements are available for all kinds of SAP tables: Master, Transaction, System, and Customizing tables. For example, the customizing table TVKO that contains all Sales Organizations is accompanied with table TVKOT for the text elements.

Although a table or ABAP program can have multiple text elements, one for each installed language, there is only one Master Language. The master language is the language where the objects are created and maintained in. The master language, which on most occasions is English or German, of each object is specified in table TADIR field MASTERLANG.

TIP Text elements, and therefore languages and translations, are stored in tables with (TVKOT) and without (DD02T) the client-specification field MANDT. Therefore, assume that languages are client independent.

The customer can decide whether it translates certain text elements using the Translation Workbench, which can be accessed using transaction SE63. The translation workbench is a tool for translating language-dependent texts. The tool can be used to translate additional texts in incompletely translated languages. For example, if you want to use the Danish language, but the language is not (yet) available from SAP, the option is to install the Danish language in SMLT, but without importing the language. The Danish language is completely supplemented with either English or German. The dialog user, who logs-on in Danish will only see English or German texts. This provides the ability to translate certain text elements into Danish yourself, for example, to cope with legal requirements. This could be done for “Dangerous Goods Movement” documents.

As of release 4.6C, SAP switched from R3load to R3trans for language imports. The reason for this is related to Support Packages. In SAP releases older than 4.6C,


you could not install “new” additional foreign languages to your system if there were already Support Packages applied.

Figure 4.52: Language import problem of SAP R/3 up to release 4.6B.

If you did so, the “new” language is only added in the “core” of the SAP system, all objects that were modified due to Support Packages will not have a proper translation. The solution to this problem is to include, in all Support Packages, the text element of all supported languages. During the normal implementation of Support Packages, SAP will only import those languages that are installed in the system. When an additional language is added to the system at a later stage, the SMLT tool will import missing text elements belonging to that “new” language and from the already applied Support Packages. In order to do this, the co- and datafiles of these Support Packages need to be available for accessing. A negative consequence of this “new” method is the increased size of each Support Package.

Figure 4.53: Language import option as of SAP R/3 4.6C.

TIP You do not have to keep all co- and datafiles online in order to add additional languages to your system. SMLT is able to disassemble all required files from the EPS package. Just store all required EPS packages in “/usr/sap/transEPS/in.”

86 UPGRADING SAP

Chapter 5REASON FOR UPGRADING

Different studies held among CIOs shows that most SAP R/3 implementations are initiated to replace old homegrown software. Besides making all the software Y2K compliant, and getting rid of homegrown applications, a third

reason has been to implement standard software like SAP R/3: Business Process Reengineering. A lot of companies used the implementation of ERP (Enterprise Resource Planning) software as a mechanism for reorganizing the company.

SAP R/3 upgrades are sometimes seen as complex and difficult projects. The process is sometimes even feared. Although it can be complex and difficult, an upgrade project is like all other projects—it’s all about skills, commitment from the business, and good project planning.

The reason behind an SAP upgrade project, whether it’s R/3, BW (Business Warehouse), CRM (Customer Relationship Management), or EBPro (Enterprise Buyer Professional), can be various, but in most cases it’s initiated due to the withdrawal of release support by SAP. On a few occasions it is related to functional requirements, for example, the new R/3 functionality that is only supported in a new or higher R/3 release. But it can also be driven by other SAP products, for example, the interface between SAP APO (Advanced Planner and Optimizer) in relation with SAP R/3.

87

88 UPGRADING SAP

ERP Software Implementation Cost percentage

Software licenses and maintenance 22%

Hardware 16%

Internal IT staff 23%

External IT staff (consultants) 21%

Other staff 14%

ERP Software Upgrade Cost percentage

Software licenses & Maintenance 11%

Hardware 17%

Internal IT-staff 44%

External IT-staff (Consultants) 14%

Other staff 19%

(36 respondents, average 750 named users); Annual maintenance = 16%–20% of license fee source: ICT Magazine 2005

5.1 WITHDRAWN FROM MAINTENANCE

One of the major reasons to upgrade the current SAP application is the approaching of the end-of-maintenance date. SAP regularly updates and announces changes to their maintenance schedules. It’s highly recommended to check this schedule often because end-of-support dates change frequently.

SAP supports various maintenance types. New names have been introduced recently.

“old” software maintenance name “new” software maintenance name

Standard Maintenance Mainstream Maintenance

Out of Maintenance/PassiveMaintenance

Customer-Specific Maintenance

Maintenance Extension Maintenance Extension

Customer Individual Maintenance Extension

MaxAttention with Solution Maintenance

The SAP software component product life cycle passes several phases, where each phase has its own different maintenance schedule for customers:

REASON FOR UPGRADING 89

Figure 5.1: SAP product support/maintenance life cycle. ©Copyright SAP AG.

Once an SAP application leaves the development phase, it’s released to a limited number of “ramp-up” customers. This phase is also known as “FCS (First Customer Shipment).” After this phase is finished, the product becomes GA (General Available) to all other customers. At this phase the products enter the “Mainstream Maintenance.”After Mainstream Maintenance an optional extension of maintenance is available to all customers. However, the support fee for “Maintenance Extension” is roughly 2–5% on top of the normal maintenance fee. After the “Regular Support” phase has ended, the “Customer-Specific Support” phase starts. This support is rather expensive and very limited and should therefore be avoided.

Figure 5.2: SAP support maintenance fee model. ©Copyright SAP AG.

Under pressure from various SAP user groups, such as ASUG (American SAP User Group), DSAG (Deutsche SAP Anwende Gruppe), and VNSG (Vereniging van Nederlandstalige SAP Gebruikers), SAP has agreed to simplify the extended maintenance offer for their customers and to clarify the cost structure for this extended maintenance.

90 UPGRADING SAP

The rules for getting “Maintenance Extension” from SAP have been simplified. For example, the restriction on SP stacks has been abandoned. Also, the Extended Maintenance Check from SAP has been withdrawn as a prerequisite.

5.2 MAINTENANCE STRATEGY

The SAP Release Strategy Guide is released twice a year with the latest updates on product roadmaps. This Adobe Acrobat PDF file, which can be obtained (free download) from http://service.sap.com/releasestrategy, contains an exact description of all SAP Business Solutions and their components, with respect to support, availability, and maintenance strategies. This guide will tell you, way up front, when certain products will be withdrawn from support and against what conditions the support can be extended. It also describes the best upgrade strategy to a newer release.

Figure 5.3: Long-term release and maintenance planning of SAP ERP.

©Copyright SAP AG.

Be careful with the interpretation of the maintenance strategy of SAP. Each SAP system consist of several components that all have their own end-of-maintenance dates, for example, SAP R/3 4.6C with IS-Oil running on Oracle 9.2.0.7 and IBM AIX 5.2. The end of maintenance for SAP R/3 4.6C is the first of January 2007, which includes IS-Oil 4.0B. The maintenance strategy for IS Solutions and other add-ons might differ as well. However, the standard maintenance for release

REASON FOR UPGRADING 91

4.6C can be extended with one more year, called “Extended Maintenance.” To get extended maintenance, the customer needs to contact his SAP account or support manager and ask for a so-called “MEC Questionnaire” and “MEC Audit trail”. In order to comply with certain support restrictions, additional Support Packages need to be applied to the system; in most cases up to the latest available SP level and a special SAP Basis EXT kernel needs to be applied.

To obtain the exact maintenance strategy for your entire SAP landscape, please refer to both the support matrix and the end-of-maintenance dates for each individual component. Also, do take interface tools, add-ons, and bold-ones into account.

Both operating system and database engines are also subject for maintenance extension. Such information needs to be checked with the respective supplier, for example, IBM for AIX and Oracle for the database.

5.3 NEW FUNCTIONALITY

An important consideration for release upgrades is the new functionality offered by the target release. SAP will support two types of upgrades in the future: Technology Upgrades and Functional Upgrades and a combination of both. A technology upgrade covers only the technical aspects of the application. An example of this is the upgrade of the “standalone” SAP Web Application Server 6.40 to 7.00 or an upgrade from SAP R/3 4.6C to R/3 Enterprise 4.7 without using the “new” Extension Sets.

The functional upgrade will become more common now that SAP has decided to disconnect the technology layer from the functional layer. For example, BW 3.1 can be upgraded to BW 3.2 using so-called BW_CONT (Business Warehouse Content) add-on packages that are loaded using transaction SAINT. The customer gets new or more functionality without having to upgrade the entire application stack. Another example is the upgrade of SAP CRM 5.0 to 5.2. Both releases are based on the same SAP AS 7.00 technology layer. So in this case only the CRM application is changed.

New functionality is quite a broad term. New functionality can reside in all kind of places in the application. Therefore, SAP releases white papers around new developments, way before the actual release of the product. For more information on new developments, please have a look at http://services.sap.com/developmentnews. In case the new product or version is released, SAP documents the new functionality in the so-called “Delta documentation.” These documents describe new functionality categorized per module and business process. The standard help pages of http://help.sap.com are also available for reading up on new products.

92 UPGRADING SAP

Figure 5.4: Help pages on various SAP products at help.sap.com. ©Copyright SAP AG.

Chapter 6DIFFERENCE BETWEEN AN UPGRADE

AND IMPLEMENTATION

There are many similarities between an SAP upgrade project and an SAP implementation project. In both cases an in-depth knowledge is required on business processes and how they are mapped in SAP R/3.

6.1 IMPLEMENTATION AND SUPPORT

For most companies, the implementation of SAP products is done by externally hired SAP consultants, which are hired through agencies and through IT consultancy companies. In some cases SAP implementations go live on the first of January, and then these consultants leave on the second of January, all knowledge taken with them. Although the project is more or less finished, the implementation and support is not. The question that comes to the table is: “Who is going to support the application?”

The SAP support function can be divided into several task clusters: � Business Process Support � SAP Functional Support � SAP ABAP and Interfaces Support � SAP Basis or Technology Support

93

94 UPGRADING SAP

The four groups are responsible for maintaining the SAP application over time. The way these groups are organized may differ per company. There are companies that are organized around a so-called SAP CCC (Customer Competency Center). Such SAP CCCs include these four task clusters into a single organization. Other companies are differently organized, for example, the SAP Basis group is part of a larger IT administration team.

An example organization is shown in Figure 6.1. This organization is lead by the company’s SAP CCC manager and consists of several SME (Subject Matter Expert) Groups. All SAP Basis-related tasks are part of a team with its own leader. The same applies for the ABAP team and the functional team. There is also room for a separate staff person that is responsible for the SAP R/3 test scenarios and all training activities for the company. To support the SAP CCC group, a support desk assists in all office related-work, license management, help desk activities, and meeting follow-ups.

Figure 6.1: SAP support organization. ©Copyright SAP AG.

During an implementation project or an upgrade project, the role of each task cluster is the same. Let’s take a look at the tasks or roles within each task cluster.

6.1.1 Business Process Support Team

This team preferably consists of people from the business. They need to be familiar with all processes used in the business, for example, a finance clerk, some one working in the warehouse, an HRM clerk, and a person from the procurement department. It does not make sense to hire external consultants for these jobs. First of all it’s an ongoing activity that never stops, and you need people that know all the ins-and-outs of the company.

DIFFERENCE BETWEEN AN UPGRADE AND IMPLEMENTATION 95

These people are responsible for the automation and information support to the business processes. They need to make clear what the business information requirements are, so they can be mapped and implemented in SAP.

If, for example, a new production plant will be implemented or an existing plant will start the production of a new product, these people need to take care of the requirements for implementation within SAP. This is not always an easy job to do.

6.1.2 SAP Functional Support Team

People from this team act in the middle of two groups. They are more or less IT-related people, but should have a strong feeling for the business processes. During the first implementation projects of SAP, most functional consultants (both external and internal) are usually module trained. However, most businesses are not organized in this way; therefore, consultants need to be skilled in complete business processes instead of just one or two SAP modules. SAP itself is also focusing more on complete business processes rather than individual modules. This team is primarily responsible for all customizing settings in the SAP application. They need to have all the knowledge that is required to map all business processes in SAP R/3.

6.1.3 SAP ABAP Support Team

The people from this team are responsible for all development objects in the SAP applications. Objects are ABAP programs, screens, menus, table definitions, structures, texts, messages, BDC sessions, CATT scripts, SAPScript forms, etc.

6.1.4 SAP Basis/Technology Support Team

The SAP Basis team is responsible for all technical- and infrastructure-related tasks that apply to the complete SAP application landscape. Tasks performed by this team are SAP System administration tasks, such as promoting transports through an SAP landscape, performance and workload analysis, and solving all kinds of other issues. Besides these typical SAP tasks, a lot of administrators also manage the RDBMS that is used by the SAP application to store all its information. Such activities are RDBMS performance analysis, securing data with backups, test restores, and managing the disk storage required for the database.

6.1.5 Remaining Tasks

There are several activities to support an SAP application, which does not really fit in one of the four task clusters as described before. Examples of such activities are authorizations, user management, education and training, and testing. Testing itself might take a lot of effort at the end. There are projects where testing can absorb 30% of the total project costs.

96 UPGRADING SAP

6.1.6 Required Number of Staff

For an average SAP landscape existing of four systems: Sandbox, Development, Quality Assurance, and Production, at least the following staff is required to manage the SAP application.

Management/Staff 2 FTE Functional Support 3 FTE ABAP Support 1 FTE Basis Support 2 FTE Test Support 1 FTE The exact staff figures might differ from company to company. On some

occasions ABAP programming-related activities are performed by SAP Basis engineers. The test tasks are part of the functional team, although you might need a certain critical mass of people in order to run and maintain a SAP R/3 landscape. This is what you would call a minimum staff configuration. The introduction of compliancy regulations, such as SoX, Basell-II, and FDA have resulted in more work for the support staff. For more complex SAP landscapes that are used by international enterprises, this number might increase significantly, especially when the application is used on a 24/7 global scale.

Why is the organization of the SAP Support team so important? Well, this organization will have to perform the upgrade. A well-trained, skilled, and organized staff is one of the major drivers for a successful upgrade project. However, they’re not completely on their own. An upgrade is technical, functional, and a business-driven activity. As of this writing, a support group can become certified against the CMM (Capability Maturity Model), which consists of several levels. A support organization, which is positively audited against CMM level 3 or lower, is able to provide the best-in-class support to the SAP application users. Such teams can be expanded temporarily with an upgrade coach.

6.1.7 SAP Customer Competency Center

SAP strongly recommends companies, and especially enterprises, to set up a so-called SAP CCC or SAP Customer Competency Center. Such a center is a group of people within the company who are responsible for the run and maintain activities of the SAP applications. The SAP CCC can be a virtual organization within the enterprise or a physical team that resides under the SAP CCC Manager. The primary function of an SAP Competency Center is interfacing between the company and SAP. The structure of this interface might differ from company to company.

An SAP Competency Center resides in the company and might cover several functions:

� Support Desk

DIFFERENCE BETWEEN AN UPGRADE AND IMPLEMENTATION 97

� Helpdesk � Application hotline � Basis hotline � Escalation management � Technical Support � Installation and upgrade service � System support � EarlyWatch reports/Go-live check, Health-check service � Contract Management � Internal software purchase and media distribution � User count and system measurements � Maintenance fees � Coordination of development requests � Information service � Information and newsletter dispatching � Training � Training and workshops Such a SAP Competency Center only makes sense in larger companies or

enterprises that have complex SAP landscapes.

Figure 6.2: Overview of SAP CCC in a company. ©Copyright SAP AG.

98 UPGRADING SAP

The setup of an SAP Competency Center is a joint effort between both SAP and the customer. It involves SAP’s GAM (Global Account Manager), GSM (Global Service Manager), and the customer. The size and what functions should reside in this SAP CCC are determined by the size of the SAP software contract:

� Small SAP software contract → up to 2 million EUR � Medium SAP software contract → 2–6 million EUR � Large SAP software contract → 6–20 million EUR � Enterprise SAP software contract → above 20 million EUR The distribution of media (CD-ROM and DVD), which contains the SAP

application software, is established by using the SAP CCC. It’s the responsibility of the SAP CCC to distribute the software to the correct Operating Company within the Enterprise.

Figure 6.3: Software media distribution through an SAP CCC (OC = Operating Company).

SAP will eventually force bigger enterprises to make use of such a Competency Center in order to increase efficiency with respect to service offerings from SAP to the entire customer enterprise. Please check all available documentation in the SAP Service Marketplace at http://service.sap.com/cccnet.

6.2 TECHNICAL UPGRADE ONLY

An upgrade project scope that is often considered by SAP users is the implementation of a “Technical Upgrade Only” approach. Such an approach consists of an upgrade that only includes a technical release change. The SAP release is upgraded to a higher version, but none of the new features of this new release will be implemented or used. This approach can be followed in case an upgrade budget is limited or in case the upgrade has to be performed in order to keep the SAP support and maintenance.

Chapter 7HARDWARE-RELATED ITEMS

Hardware and other infrastructure is an important item for SAP projects. Two phases can be distinguished during the life cycle of an SAP application: infrastructure deployment and support. During the infrastructure support

phase, demands or requirements can change. Thinking about adding more users and interfaces to the system or an SAP release upgrade? These demand changes need to be translated to extra infrastructure: more servers, more CPU capacity, more memory capacity, and, of course, more storage capacity (both disk and tape).

7.1 SUPPORTED HARDWARE PLATFORMS

The SAP Global Active Support organization supports a big variety of hardware and software platforms. Figure 7.1 illustrates the SAP Infrastructure support stack.

The technical infrastructure is shown in the two bars at the bottom of the stack. Both bars contain the software infrastructure, such as RDBMS and Operating System, and the hardware infrastructure.

On some occasions, SAP has withdrawn the support over time for certain components, such as Informix RDBMS, Tru64 UNIX Operating System, Compaq Alpha-based hardware, and the MIPS-based Siemens Reliant UNIX. New platforms are added to the list, such as Solaris for X64. Please check the SAP Service Marketplace for exact dates at http://service.sap.com/pam and http://service.sap.com/platforms.

99

100 UPGRADING SAP

Figure 7.1: SAP hardware and software support stack. ©Copyright SAP AG.

In cases where SAP is going to withdrawn its support for the platform that you use, consider a OS/DB migration as part of your upgrade project.

7.2 INCREASED COMPLEXITY OF SYSTEM LANDSCAPES

Besides SAP R/3, most companies make use of other SAP applications as well. These additional applications need to be hosted on (additional) infrastructure. This new demand leads to a more complex infrastructure that needs to be managed. Let’s take a look at a fictitious company that uses the following SAP applications: R/3 (ERP), Business Warehouse (BW/BI), Supplier Relationship Management (SRM), and Customer Relationship Management (CRM). This will add up to a total of 4 × 3 = 12 systems, because it’s still SAPs recommendation to have a three-system landscape per application. The connectivity with a multi-application environment can be seen in Figure 7.2.

To mitigate the increasing infrastructure costs related to the introduction of all these “new” SAP applications within the enterprise, consider one of the following options in the next section.

HARDWARE-RELATED ITEMS 101

Figure 7.2: SAP Application connected.

7.3 SERVER AND DATABASE CONSOLIDATION

There are several ways to manage these applications from an infrastructure perspective:

(1) Each application instance runs on top of dedicated hardware. This solution requires a maximum of 12 machines.

(2) The second option is to deploy multiple instances on one machine. This option saves “initial” hardware investment, but does not save significantly on storage costs and staff costs. Running multiple instances on one machine is more complex to manage. This option is known as “Server Consolidation Option 1.”

(3) The third option is the introduction of “partitioning” at the hardware level. In this scenario, a big enterprise server is logically divided into “virtual machines,” where each partition hosts its own SAP instance. This offers more flexibility to manage changing demands from the business or project, however, it isn’t necessarily cheaper in hardware and staff costs. Hardware vendors do offer solutions around “Capacity Upgrade on Demand,” where CPU and memory capacity are already built into the machine, but not yet activated. This option is known as “Server Consolidation Option 2.”

(4) The fourth option is consolidation at the database instance level by using separate database schemas per application. This option is known as “MCOD” or “All-in-One.”

(5) The fifth and final option is known as MCOS or Embedded installation. This option is based on the combined deployment of more than one Usage Type in the SAP NetWeaver AS. An example of this might be a system with both ECC and BI, each deployed in its own client.

102 UPGRADING SAP

During server consolidation exercises, certain things need to be checked first: can both applications be installed in the consolidated hardware; think of version mismatches, conflicts around shared libraries, and, of course, performance characteristics. An SAP application is very much CPU and memory bound. Shortage of CPU and memory will lead to significant performance issues. It’s the same issue with “partitioning,” although we work with “virtual machines” in combination with “work-loading management” (WLM), SAP applications still require a lot of CPU cycles and memory to work.

For database consolidation exercises, it’s important to know, whether the database schema technique used is appropriate for MCOD purposes.

7.4 MCOD

SAP has increased the number of application components significantly since the late ’90s. Besides R/3 and BW, several other applications have been developed to fulfill the requirements of SAP customers. Although most of these “new” applications are based on the same technology as SAP R/3/ERP and/or BW/BI, they are not an integrated part of one of these tools. They do require a separate database and need to be installed as a separate activity.

In order to reduce the complexity for both the installation process and the long-term support of these applications, SAP has introduced the MCOD concept. MCOD (Multiple Components in One Database) provides the ability to install several SAP applications in one database instance. Each SAP application (or component) resides under its own “dedicated” database schema.

Figure 7.3: SAP MCOD (Multiple Components in One Database).

Not all combinations are possible or supported by SAP. Whether a combination is technically possible is determined by usage of database schema names of certain


releases. SAP has introduced their new database schema names as of SAP Web Application Server 6.10. SAP applications based on the Basis Layer 4.6 and before, such as SAP R/3 4.6C and SAP BW 2.1C, still use the SAPR3 database schema. The database schema name needs to be unique within the database. Therefore, only one copy of SAP R/3 4.6C can exist in a database. However, you can add other (SAP Web AS 6.10 or higher based) applications to it. The SAP R/3 4.6C instances use SAPR3 as a schema name. All other applications use the combination SAPSID as a schema name.

SAP supports MCOD for the following products:

OLTP

SAP Web Application Server 6.10 and higher SAP R/3 4.6C SR2 SAP R/3 Enterprise 4.7 and higher SAP CRM 2.0C SR1* SAP CRM 3.0 and higher SAP EBP 2.0C SR1 SAP EBP 3.0 and higher SAP SRM 2.0 and higher SAP SCM 4.0 and higher SAP Knowledge Warehouse 5.0 and higher

OLAP

SAP BW 3.0A and higher SAP SEM 3.1A and higher SAP SCM 4.0 and higher If you want to combine OLTP and OLAP applications into one database

instance, the following RDBMSs are supported:

RDBMS product OLTP+OLAP in 1 DB Restrictions

IBM DB2 for OS/390 YES None

IBM DB2 for iSeries YES None

IBM DB2 for UDB YES

Informix NO N/A

Oracle YES 10g or higher

SAP DB YES None

104 UPGRADING SAP

It’s important to understand what the consequences are of such a deployment. In the MCOD situation, all components reside in a single database. That means that if you want to implement/convert Unicode, all components are affected by it. Second is the dependency between SAP releases and the database release. If you want to upgrade one of the components to a new release, which requires a higher RDBMS version, all other components are also affected.

TIP When you have to perform an upgrade on an SAP system, it’s important to know whether you’re working on a MCOD-based system. The R3up upgrade tool is able to determine this. When a restore is required of one of the components in the database, the entire database needs to be restored. More information can be obtained through the following link: http://service.sap.com/mcod.

7.5 MCOS

In addition to MCOD, SAP has developed an alternative way of consolidating SAP components on to one server. This option goes one step further compared to MCOD. With MCOD you have one database with different SAP systems. With MCOS you have one database and one SAP system. However, you do have multiple applications. The MCOS (Multiple Components in One SAP System) solution is based on the fact that the OLAP has moved into the Basis layer and most Business Suite components have their own name space. Therefore, it’s much easier to install an SAP system with multiple components. An option is to install an SAP Netweaver 2004S–based SAP ERP 2005 system and load the BI 7.0 content into this system. This results in a single SAP system with two SAP components active. The only restriction here is the fact that both components should reside in their own client. This restriction is caused by the way the ETL extractors are working.

Like MCOD, the MCOS (also known as an embedded installation) does have its restrictions as well. Similar to MCOD, the MCOS does have the same database restrictions (Unicode and release). But an extra dependency is the SAP version and Support Package level. The MCOS system is a single SAP system with more than one product installed. We only have one ABAP and Java stack to patch. The most important thing to bear in mind when considering putting ECC and BI in the same SAP system is the expected workload of the system.

INFO Restrictions and supported combinations are described in more detailed at SAP Note 855534.

In Figure 7.4 an SAP system is deployed with both SAP ECC 6.0 and BI 7.0 in one MCOS installation. Both ECC and BI have their own client and installed at the ABAP AS. Next to the ABAP AS usage type, another usage type named JAVA AS is deployed. This JAVA AS system runs the EP (Portals), VC (Visual Composer),


BI-Java (Web Dynpro for BI), and SLD (SAP Landscape Directory) components. Both ABAP and JAVA have their own database schema (MCOD) located in the database.

Figure 7.4: SAP system with MCOS at ABAP level and MCOD at database level.

7.6 SIZING FOR THE NEW RELEASE

The impact on the hardware element of SAP should not be underestimated. When hardware is currently oversized, which means that the current hardware can easily handle the workload of the current SAP application, an SAP release upgrade should not be problem. But always check before this assumption is taken.

The general assumption that is also expressed by SAP is that every new SAP release takes more computer resources, such as CPU, memory, and disk capacity.

SAP Upgrade Scenario

CPU increase Memory increase Storage increase

Min Max Min Max Min Max

4.6B → 4.6C 5% 10% 10% 30% 0% 10%

4.6C → 4.71 0% 5% 25% 25% 0% 0%

4.71 → 4.72 5% 10% 5% 10% 0% 5%

4.72 → ECC 5 5% 10% 5% 10% 5% 5%

Total 15% 35% 45% 75% 5% 30%

Average 25% 60% 18%

106 UPGRADING SAP

This table shows the increase of resource requirement per release upgrade. In case an upgrade is performed for source release 4.6C to target release ECC 5.0, the new resource consumption is the sum all of steps.

Figure 7.5: System resource requirements compared between R/3 releases. ©Copyright SAP AG.

There are two solutions to this problem on hardware capacity planning: the first one is to ask the hardware supplier to take care of this or, second, do it yourself. Both options have their advantages and disadvantages. When you do it yourself, you need to have a lot of knowledge about the SAP software products, the different components and their behaviors. Besides this in-depth knowledge on SAP software, you also need to have background information on all kinds of hardware products and their performance characteristics. Only in large companies this kind of knowledge available. The other option has drawbacks as well—the vendor might over- or undersize your hardware landscape due to commercial reasons.

There are several methods that can be used to estimate the hardware requirements. The three main sizing methods are:

� User based � Document or Transaction based � Load based (current utilization) The user-based method takes the number of defined (named) and concurrent

users on the system into consideration. SAP introduced a tool called CCUEVAL that provides the ability to measure the number of logged-on users on a frequent basis. Therefore, it’s relatively easy to use this method.

The second method is more complex to perform. This method is based on the total number of business documents, such as purchase orders, financial postings, goods movements, and sales orders, processed in the system per unit of time. By using transaction ST14 (Application Monitor), it is possible to see how many documents are created and edited in the system.


The last methodology is based on the overall load of the system. The load or utilization is not measured through user count or document count, but rather by monitor the system performance and utilization. This method requires monitor tools at the operating system level, such as TOP, NMON, SAR, or SAPOSCOL (which is integrated in CCMS:ST06). Also, external tools from vendors are available, such as “IBM Insight for SAP R/3 Analysis.”

In order to perform a hardware sizing estimate, the following information is needed:

1. Key performance indicators 2. Used software components 3. Number of concurrent users (per component and module) 4. Expected future requirements (storage and number of users) 5. Availability of the applications 6. Locations of the user community This list is also known as “Nonfunctional requirements.” This result should be used to select the best “fit for purpose” server model

to run your SAP software. A short list of server models should be created that eventually will be used for the procurement process.

Let’s take a closer look at the six information items required for a correct hardware sizing estimate.

7.6.1 Key Performance Indicators

Values specified in the list “Key Performance Indicators” are used as guidance for the hardware and server sizing estimate. They can also be used as input for SLA discussions between the SAP user community and the IT service provider. The values specified in the following table are “industry best practice”:

Performance Indicator Target Value Problem

Average Dialog Response Time (during office hours)

< 1.5 seconds Less work processes, less system resources, long-running reports in DIA, etc.

Roll-In/ Roll-out time < 20 milliseconds Rollbuffer or extended memory too small

Enqueue time < 5 milliseconds Enqueue service or network issues.

Processing time, CPU time Processing Time < 2 × CPU time

CPU bottleneck or problem with connection between DIA instances and DB

108 UPGRADING SAP

Database request time < 40% of (response time minus dispatcher wait time); 200–600 milliseconds

RDBMS problem; missing indexes; missing statistics; CPU bottleneck; RDBMS memory shortage; SQLNET

Time per DB request < 5 milliseconds see above

Direct reads < 2 milliseconds see above

Sequential reads < 10 milliseconds see above

Changes and commits < 25 milliseconds see above

7.6.2 Used Software Components

Besides knowing what response times we would like to have on our system, we also need to know what SAP modules and components are being used. Such a list is used for User- and Document/Transaction-based sizing. It very much differs whether you have 200 SD users rather than 200 FI users.

To determine the difference between the SAP functionality that is configured in the system and what is really used, you might consider using the RBE (Reverse Business Engineer) tool. This tool allows you to extract data from your SAP system history and create usage reports. These reports include data on created documents, used reports, and user numbers. The RBE tool is shipped as part of the SAP Solution Manager Enhancement package called “Support Enablement Package” (SEP). The SEP package is separately licensed. The RBE tool can also be licensed separate from the SEP package.

Alternatively, you can consider RBEplus from IBIS (see http://www.rbe-online.com) or the Application Life Cycle Management SuiteTM from IntelliCorp. This suite consists of various products that can be licensed separately and support you with the implementation of Support Packages and the determination of conflicts during upgrades. Information about this suite can be obtained through http://www.intellicorp.com.

Another option is to get some consultancy service through SAP itself. The System Landscape Optimization (SLO) group within SAP offers a service that includes an analysis of your SAP system and results in a report that describes what functionality is really used in the system and how often. This service can be obtained through your regular SAP account or by using http://service.sap.com/slo.

7.6.3 Number of Concurrent Users

There are two distinct user counts: named users (or defined users) and concurrent users (or active users). Named users are all the users that are defined on the system and have a so-called User Master Record. Concurrent users are users that are actually logged-on to the system. The number of concurrent users is a subset of the named users. The ratio between these two user counts may differ from system to


system. For example, SAP systems that are used for EES (Employee Self-Service) or CATS (Time Writing) have a high number of named users, but a rather low number of concurrent users. On the other hand, SAP systems that do make extensive use of interfaces (over one single User Account), have relatively low named users, but a rather high number of concurrent users.

7.6.4 Database Growth Pattern

Another important parameter for the sizing exercise is the life time expectation of the SAP application. What will be the future growth of the database size in two years from now? It’s important to know what the size of the database becomes for two reasons: storage costs are a significant part of the overall hardware costs, and thus the total support costs. The larger the database size, the larger the memory buffer has to be configured.

The size of the database is determined by two factors: the number of documents and the type of documents. The best tool you can use to determine the document growth pattern in your database is the SAP QuickSizer, which can be accessed through http://service.sap.com/quicksizer.

TIP It’s highly recommended to archive obsolete documents from the database before an upgrade is performed. This will improve the upgrade performance, and therefore the application unavailability substantially.

7.6.5 Application Availability

An important question that should be asked of the business before any hardware is ordered is what the required availability of the application should be. Availability is the opponent of downtime. There are two types of downtime: scheduled and unscheduled downtime. To manage and maintain applications, and its infrastructure, downtime is needed. This is what we call “scheduled” downtime. However, in case an application is unavailable outside this schedule it is called “unscheduled” downtime.

The “unscheduled” downtime can have several causes: hardware failures, software failures, and human errors.

� Hardware failures are related to faulty equipment and components and can be minimized by using fault-tolerant or high-available hardware infrastructure.

� Software failures are errors in SAP or the RDBMS software. It’s much more difficult to minimize these kinds of errors: preventive maintenance of software is one possible solution. Software patches, as soon as they’re released by the vendor should be applied to the system before any error occurs.

110 UPGRADING SAP

� Human errors are errors that are caused by mistakes of users and support engineers, for example, a transport request containing a table-deletion item by accident that is important to the production SAP system. These kinds of errors can only be solved by strict and well-documented procedures, sufficient staff, and training.

During a hardware sizing exercise, the availability of the application to the business is an important discussion item. If the SAP application is used for Internet sales, the unplanned downtime should be minimal. You could think of using high-availability clusters, managed through software such as IBM’s HACMP, HP MC/ServiceGuard, or Microsoft Cluster Server (MSCS). Besides hard- and software availability, you also have to concentrate on a backup, restore, and recovery architecture. These items are part of a bigger Business Continuity Plan (BCP). Such a plan includes both the infrastructure as well as the business recovery documentation and procedures.

Figure 7.6: Application architecture based on SLA and BCP.

7.6.6 Location of Users

For network bandwidth planning, it’s important to known upfront where the users are located. In a world where companies are globalizing their business, we will see an increase of global-enterprise-based SAP applications. The SAP user community is spread out across the globe. Besides network bandwidth implication, it also has an impact on the availability of the application. There is no real difference between in-office and out-of-office hours. Therefore, batchjob and backup planning become more difficult.

7.7 PREPARATIONS ON HARDWARE AND SOFTWARE

Besides the determination of the target release of the SAP software, it’s also required to see what the “new” hardware and software requirements are going to be. In most cases, the SAP target release is bound to a new release of the RDBMS database version and might also require a higher operating system release.


When the upgrade consists of a significant release jump, it is often needed to upgrade to new and more powerful hardware as well.

7.7.1 OS/DB Migration

There are circumstances where an existing platform, operating system, and RDBMS are no longer supported by the vendor and by SAP. In such a situation, the SAP System needs to be migrated to another platform. This migration process is also known as “Heterogeneous System Copy.” There are several possible scenarios:

(1) PLATFORM A → PLATFORM B

This migration takes place between two different hardware platforms, for example, a migration between an HP9000 based SAP system and an IBM pSeries machine, both running Oracle as RDBMS.

(2) VENDOR A → VENDOR B

This migration consists of replacing a Compaq Proliant server running an SAP system on Oracle with a new IBM x445 server with the same Oracle software. So, one server vendor is replaced by another.

(3) RDBMS A → RDBMS B

During this migration, an IBM pSeries machine using Oracle as RDBMS is migrated to IBM DB/2 UDB as RDBMS. The machine type remains the same.

(4) Any combination of the three scenarios.

A more complex scenario might be the migration of an SAP system running on an IBM pSeries AIX with Oracle as RDBMS to HP DL585 server SAP Central Instance and running its RDBMS on DB/2 for OS/390 on a zSeries mainframe.

Any of these four scenarios are treated by SAP as OS/DB migrations and need to be seen as separate projects. SAP has developed a single toolkit to support any of these four OS/DB migration scenarios. It consists of a toolkit around R3load and R3ldctrl. The R3load tool is able to download any SAP database, independent from RDBMS, to a number of flat files. These flat files can be transferred to a target system and loaded into the new RDBMS using another R3load. The migration of an SAP system from Oracle RDBMS to DB/2 for zSeries is illustrated in Figure 7.7.

During the first step, the “R3ldctrl” examines the SAP Data Dictionary and creates per data class (TABART) a structure file. This file contains, per table, a structure layout. Once these files are created, “R3load” uses these files as input and starts downloading all rows from each table to dump files. Multiple dump files can be created per TABART, depending on the amount of data. Besides these dump files, two other files are created, namely log files and status files.

112 UPGRADING SAP

Figure 7.7: The download of all data from SAP source system.

After the download of the entire database, all created files need to be transferred to the target machine, for example, by using FTP. In order to improve speed, several activities can be done in parallel.

Figure 7.8: The upload of all data into SAP target system.

The next step is the creation of the target database with all the tables. The “R3load” program uses the structure files (STR) and a template file (TPL) for this. The template file is RDBMS specific and created by “R3ldctrl” on the source system. During the last step, all table data is loaded into the target SAP system.

Both programs “R3load” and “R3ldctrl” are driven through a driver program, which is more user friendly. The driver program depends on the SAP release:


“R3INST” for all releases below 4.0A; “R3SETUP” for all SAP releases 4.0A up to 4.6C, and “SAPINST” for all SAP releases higher that 4.6C. It’s the same program that is used to install a “new” SAP system (which also uses R3load and dump files). It is, however, also possible to use SAPinst 6.40 or higher for OS/DB migration processes of an older SAP release.

INFO An “OS/DB migration” does not perform a SAP release upgrade. Both SAP source and target release are the same.

A reason for doing an OS/DB migration depends on various factors. Questions that might be asked are: is the platform that is used to run the SAP system still supported and what does the roadmap look like? Does an alternative platform have a better TCO (Total Cost of Ownership)?

7.7.2 OS/DB Upgrade

The release upgrade of the operating system and RDBMS software is not necessarily related to the upgrade of the SAP software. However, on many occasions there is a support dependency with the so-called “software stack.” The exact supported software stack is published by SAP as the “OS & DB Support matrix” and can be found on the SAP Service Marketplace.

As an example, an SAP BW 3.5 system running on AIX 5.2 and Oracle 9.2 can only be upgraded to SAP BI 7.0 if the operating system is first upgraded to AIX 5.3 and the database to Oracle 10.2

More complex is the situation in which the source release of SAP is not supported on, for example, Oracle 10.2 Assume we have an SAP R/3 4.0B system as a source release with Oracle 9.2 Now we would like to upgrade SAP to ECC 6.0. First we need to upgrade Oracle 9.2 to 10.2. SAP, however, does not support the combination SAP R/3 4.0B and Oracle 10.2 The solution for this is to ask SAP for a so-called “Bridge” support. This means that SAP will temporarily support the combination of SAP R/3 4.0B and Oracle 10.2

INFO For all supported combinations of SAP products and the RDBMS and OS they run on, please have a look at http://services.sap.com/pam

7.7.3 SAPGUI and ITS

SAP software is based on a client/server architecture, which means that the software is divided into different pieces. On the client side, the SAPGUI is deployed to act as an interface between the user and the application software. The SAPGUI release is closely bound to the release of the SAP kernel. Upgrading all PCs with a new release of SAPGUI can be quite an effort and therefore needs to be part of the project budget plan.

114 UPGRADING SAP

Figure 7.9: SAPGUI software logistics. ©Copyright SAP AG.

The Internet Transaction Server (ITS) software is also subject to releases upgrades. Like SAPGUI, the ITS software is also bound to the SAP kernel release. This means that ITS release 4.6C cannot be used with SAP R/3 Enterprise 4.7 and must be upgraded to ITS release 6.20.

Figure 7.10: Integrated ITS building blocks. ©Copyright SAP AG.


With NetWeaver AS 6.40, SAP has introduced the integrated SAP ITS, which means that SAP ITS no longer has its own separate (Microsoft Windows or Linux based) server to run. ITS is integrated into the ICM/ICF technology within the ABAP engine of release 6.40 and higher.

With the release of SAP NetWeaver 2004S (SAP AS 7.00), the external ITS 6.20 is no longer supported. This means that, by default, the embedded (or integrated) ITS instances need to be used.

Figure 7.11: Embedded ITS support timeline. ©Copyright SAP AG.

The embedded ITS is managed using transactions SICF and SITSPMON. Having all ITS workload on a “regular” SAP system has some advantages and disadvantages. The advantage is, of course, that we no longer need a separate server to host an ITS instance and the associate support costs. However, having this workload added to your SAP system requires more resources on the server. This is the main reason SAP recommends 64-bits hardware for these kind of installations.

7.7.4 Third-Party Products

Third-party products are also subject to the SAP release upgrade. This can vary from products that are written in ABAP and reside entirely in SAP, or products that reside at the operating system level. Examples are toolkits for archiving, auditing, security, forms printing, and monitoring. For each product, a release support certificate needs to be obtained from the vendor. If an upgrade of third-party product is required, it’s important to determine where during the upgrade process this software upgrade can take place.

116 UPGRADING SAP

Chapter 8UPGRADE TECHNOLOGY

The upgrade technology from SAP has significantly changed over time. The first upgrade technology of SAP was based on so-called “Delta” upgrades. This technology was changed as of R/3 release 3.0A with the so-called

“Repository Switch” technology. Later, SAP also introduced ICNV (Incremental Table Conversion) as an option to reduce downtime. Finally, the latest upgrade technology is called “System Switch.” All these innovations were introduced in order to improve the upgrade speed and to reduce the application downtime for the customer. All ABAP-based SAP applications make use of this new upgrade technology.

To get a good understanding of how an SAP upgrade works, we’ll first take a closer look at the techniques used by an upgrade. We will not discuss all individual phases of the upgrade—there are just too many of them.

8.1 TECHNICAL OBJECTIVE

The intention of a technical upgrade is to replace software components with newer versions. Two techniques can be distinguished: partial and complete replacement. During a partial replacement, only certain components are replaced with new executables and objects. In cases where Support Packages are applied to the SAP system using transaction SPAM or a new kernel patch is installed, we perform what we call a partial replacement. Only part of the repository is replaced and overwritten. This is not, however, the case when we perform a complete replacement. All objects and software components are replaced with newer ones.

117

118 UPGRADING SAP

From a technical perspective each upgrade consists of seven main phases. Certain phases can be executed during “productive” uptime or downtime depending on the chosen upgrade strategy. Certain phases can run during uptime or downtime.

Figure 8.1: Seven “Technical” upgrade phases. ©Copyright SAP AG.

During the “Preparation” phase, the upgrade will be prepared from a technical perspective, which means that certain checks are performed. Also, the PREPARE software is installed and loaded into the SAP system and the all parameters are entered. These parameters are later used by the upgrade.

The “Initialization” phase is used to start the upgrade itself. During the third phase, “Data Transfer,” new objects that belong to the new “target” release are loaded into the system. This is done by using a shadow repository. The fourth phase, “Basis Adjustment,” contains all activities and steps required to prepare and adjust the SAP Basis layer for the new “target” release. Steps that are performed during this block are the exchange of the repository, kernel, and table adjustments. What needs to be done to the Basis layer also applies to the application layer. This will be done during the fifth phase, “Application Adjustment,” which contains sub-phases for application table conversions and so-called XPRA or “Reports after put.” The “Completion” phase contains activities to clean up the system and run statistics. The “Post Processing” phase can be used to fix object conflicts and issues around changed functionality.

8.2 DELTA UPGRADE

Up until SAP R/3 release 3.0A, all upgrades were based on a so-called “Delta Upgrade.” During a Delta Upgrade, only those objects and software components that need to be renewed are replaced. However, due to certain interdependences between the various objects, they need to be installed in a certain order. This

UPGRADE TECHNOLOGY 119

was established by using patch bundles. These patch bundles were compiled in bundle sets. By applying a patch bundle set, a technology upgrade of SAP was performed.

Figure 8.2: SAP release “Delta Upgrade.”

Although this procedure works fine, there is one big disadvantage. It’s only possible to upgrade to the next sequential release. For example, it’s only possible to upgrade SAP R/3 release 2.2E to release 2.2F and not immediately to 2.2G. In case customers did want to upgrade from 2.2E to 2.2G, they first had to go to release 2.2F.

SAP has abandoned this technique with the release of SAP R/3 3.0A. All upgrades since then are based on what is known as “Repository Switch.” Nevertheless this technique is still the foundation of transaction SPAM (Support Package Manager).

8.3 PREPARE

Each technical SAP upgrade starts by running the PREPARE phase. During the PREPARE phase, several different things are done, such as checks at the operating system level, available filesystem free space, supported OS version, and environment settings; checks at the RDBMS level, such as available database free space, supported RDBMS release, and checks in the SAP system itself. Besides these checks, the SAP system itself is prepared for the upgrade. Additional objects, such as ABAP programs, are loaded into the system, which are used during the upgrade itself. Also, the upgrade tools are copied from CD-ROMs to the “/usr/sap/put” directory.

The PREPARE phase can be run during productive operation of the SAP system. It can also be stopped, resumed, repeated, and restarted when necessary. Therefore, the PREPARE phase can be executed way in advance before the real upgrade. However, it’s a prerequisite for the upgrade, so it needs to be performed.

120 UPGRADING SAP

TIP During the PREPARE phase, all SAP upgrade DVDs need to be supplied. Each DVD is located at a mount point. The result of the detection of all DVDs is listed in a file called “cdtrace.log” that is located in /usr/sap/put/log.

The different “modules” performed during the PREPARE phase are shown in Figure 8.3.

Figure 8.3: Upgrade PREPARE “modules.” ©Copyright SAP AG.

The PREPARE modules can have the following features: � They are mandatory or optional. � The predecessor modules that have dependencies need to run first. � There are modules that can run multiple times, but there are also modules

that can only run once. � PREPARE modules can run individually. As of target release R/3 4.7 Enterprise, SAP has changed a few items in the

PREPARE tool. The “Read-CD” phase has been split up in such a way that all kinds of extensions can be added to the upgrade. Furthermore, the “Installation” phase has been added, which is responsible for the creation of the “shadow” instance.

All results of the PREPARE modules are written to a file called CHECKS.LOG, which is located in “/usr/sap/put/log.” Besides this central log file, each module writes its own log file as well. The log file names comply with their respected module names.

Although the exact sequence of modules that are performed differs from upgrade to upgrade, it is mainly determined by the SAP target release. A short list of PREPARE phases:


� INITIALIZATION � IMPORT � READ_CD � CHECKS : GENERAL, ACTIVATION and CONVERSION � OPTIONAL

Figure 8.4: Upgrade PREPARE selection screen. ©Copyright SAP AG.

After all checks and phases have been processed and finished successfully, the PREPARE program is finished. The PREPARE phase thereby is officially done and the upgrade process using R3up can be started. If it is required, for whatever reason, it is always possible to repeat the PREPARE phase without any harm to the SAP system.

8.4 UPGRADE KEY

All installations and upgrades to SAP NetWeaver 7.0–based systems need a key during installation and upgrade. Such a key is created within the Solution Manager

122 UPGRADING SAP

and only needed once. Through this process, SAP would like to force customers to install and eventually use the Solution Manager. For SAP ERP 2004 (SAP ECC 5.0), you require SAP Solution Manager 3.1 with Support Package 20 or SAP Solution Manager 3.2 with Support Package 4. You can also use SAP Solution Manager 4.0, of course. For products like SAP Business Suite 2005 (including SAP NetWeaver 7.0) you require at least SAP Solution Manager 3.2 with Support Package 8.

The upgrade key is generated using the following sequence: Transaction SMSY → Landscape Components → Systems → Menu →

Main Instance → Other Objects.

Figure 8.5: Creation of Installation and Upgrade key. ©Copyright SAP AG.

INFO More information about creating keys can be found in SAP Note 811923 and 805390.

8.5 SAP UPGRADE ASSISTANT (CLASSIC)

The SAP Upgrade Assistant (or UA for short) is the tool used to perform the entire upgrade. The UA is a client/server application, which means that one part of the tool is running on the server where SAP is running, and one part is running on the PC the engineer is using.


Figure 8.6: SAP Upgrade Assistant and its components.

The UaServer is the server part of the SAP UpgradeAssistant. It is written in Java and therefore requires a JVM to be installed on the host. To start the UaServer on the SAP server just issue this command:

sapsid$ java –cp <upgrade-dir>/ua/ua.jar UaServer &

Under UNIX account <sid>adm the JVM (called java) is started and it will start JAVA routine UaServer, which is located in Java-Archive with the name ua.jar.

Once the server side of UA is started, the PC counterpart can be started as well. This is done using:

C:\> java –cp \…\uagui.jar UaGui

However, it is recommended to use a script for this:C:\UAGUI> startuagui.bat

The “startuagui.bat” might have the following contents:

@ECHO OFF

REM START UaGUI

C:\JAVA142\BIN\JAVA –CP C:\APPS\SAP\UAGUI\UAGUI.JAR UaGui

The UaGui does not have to run on a PC. It is possible to run the UaGUI on the same server the UaServer is running. This requires, however, the use of an X/Windows interface on any Unix/Linux server.

Besides the UaGui tool, it’s also possible to use Microsoft Internet Explorer to perform the upgrade. The UaServer communicates over TCP port 4239 by default, so the URL is http://<SAPserverToBeUpgraded>:/4239.

124 UPGRADING SAP

Figure 8.7: SAP Upgrade home page. ©Copyright SAP AG.

After selecting “Start Upgrade Assistant,” the UAGUI pops up.

Figure 8.8: SAP Upgrade Assistant ©Copyright SAP AG.


8.6 SAP UPGRADE ASSISTANT (NEW)

With the release of SAP NetWeaver 7.0, the SAP Upgrade Assistant has been renewed and is based on the SDT (Software Delivery Tools) GUI framework. This new SAP Upgrade Assistant offers more options to manage and control (remote) upgrade sessions from the PC. The entire PREPARE and upgrade process can be managed from various PCs. It is no longer needed to stay connected all the time. To control it from a remote host you must start the SDTGui in a Web browser, which requires Java Web Start technology. Starting the SDTGui in a Web browser:

1. Start a Web browser and enter http://<hostname>:6239 in the address field. 2. Choose Start J2EE Upgrade Frontend (SDTGui). Starting the SDTGui Locally: • Change to <upgrade directory>\exe. • Execute the command startgui.bat.

8.7 OTHER UPGRADE TOOLS

The SAP Upgrade Assistant is just a tool for the engineer to perform the upgrade. The upgrade itself is performed by several other programs, like R3up, R3trans, R3load, and tp. Most of the tools are also used by the regular SAP software logistics processes.

Figure 8.9: Overview of all upgrade executables.

R3up is the program that actually does the upgrade. However, to make the tool user friendly and offer the ability to work with several observers, SAP added the UaServer in front of it. Once the UaServer is started on the SAP server, and the engineer is connected by using the UaGui or a Web browser, the R3up process can be started. Therefore, you don’t have to start the R3up process yourself on the operating system level, UaServer does this for you.

126 UPGRADING SAP

TIP Access to UaServer is protected by a user id/password combination, which is set to “admin / admin” by default. It’s recommended to create your own user id/password combination for audit reasons and change the password for user id “admin.” If you accidentally loose this “admin” password, you can delete the file “UaState,” which is located in “/usr/sap/put/ua.” All additional users are removed and the “admin/admin” combination is activated again.

The essential difference between R3trans and R3load is the fact that R3trans uses logical objects that are listed in table TADIR, where R3load uses physical tables instead. R3load is much quicker in exporting and importing data. R3load uses TABART (table DDART and DD09L) information for data exchange between systems, where R3trans uses TADIR information. Both tools have a rich set of command line options; R3trans, for example, can be used to import transport requests into an SAP system:

root> su - sidadm ; cd /usr/sap/trans/bin ; R3trans –I /usr/sap/trans/data/R900002.D01

8.8 SAPUP AND SAPJUP

In case the SAP source system has both ABAP and Java installed, both need to be upgraded to the next release. Therefore, SAP has released a second tool besides SAPUp (the new name of R3Up). This new tool is called SAPJUp and is invoked by the Upgrade Assistant. It takes care of the phases required to upgrade the NetWeaver AS Java.

Figure 8.10: Architecture of the Upgrade tools with Dual Stack. ©Copyright SAP AG.


If you run an ABAP-based server and a Java-based server in the same system, you have to upgrade them in parallel. This is a so-called “Dual Stack Upgrade.” The two upgrade processes require a synchronization that affects the following areas: upgrade progress, user management, profile changes, start/stop of the SAP system, and reset of upgrades.

The upgrades of both parts, the ABAP-based server and the Java-based server, have to be synchronized. When you start SAPJup, it detects that there is an ABAP server installed in the same system. The upgrade program then prompts you to start the ABAP server upgrade as well. In the same way, the upgrade program for the ABAP server upgrade, SAPup, asks you to start SAPJup when it detects a Java server. Both SAPUp and SAPJup detects counterpart engines to be sure upgrades are done simultaneously.

The PREPARE tool is able to detect whether the SAP system consists of both ABAP and Java engines. Both will be upgraded at all times. It’s not possible to skip the upgrade of either of the engines. Both tools, SAPUp and SAPJup, work independently, however, they communicate through so-called “Sync points.” Upgrading ABAP and Java stack must be performed in parallel with the following sync points:

• Begin of downtime – GETSYNC_PREUPTIME_FINISHED

• Modification of profiles – GETSYNC_PROFILE_CHANGED

• End of downtime – GETSYNC_DOWNTIME_FINISHED

NOTE The only option not to upgrade AS Java is to de-install it. This has to be done before the PREPARE option at the Dialog REQ_J2EE.

Figure 8.11: Various synchronization points for Dual Stack upgrade.

©Copyright SAP AG.

During downtime in the ABAP upgrade the user management facility SU01 is not available. In case the User Management Engine (UME) uses this ABAP user

128 UPGRADING SAP

management, it cannot access any user data during this period. Therefore, the Java upgrade program switches the UME configuration to data source “local.” This is only a temporary configuration for the duration of the upgrade and is switched back after the upgrade.

The ABAP upgrade program changes the profile parameters for starting and stopping the SAP system so that the Java instance is not started automatically together with the ABAP engine. The Java upgrade program starts and stops the J2EE Engine with internal commands when needed.

Figure 8.12: Two upgrade tools working in parallel.

If one of the two upgrades fails, both upgrades need to be reset. You should not proceed with one of the upgrade processes, because this would lead to an inconsistent system state.

NOTE The upgrade requires at least Software Delivery Manager version 6.40 Support Package 13. If you have a lower SDM version, you need to update the SDM before you start PREPARE.

8.9 ADD-ONS AND INDUSTRY SOLUTIONS

The complexity of an upgrade is dependant on the use of additional components on top of R/3 or any other SAP applications, such as Industry Solutions and IS Components. Certain IS components, especially ones of the first generation, such as IS-Oil, are adjusting the Core of R/3 rather than added on top of R/3. That means that certain standard R/3 objects are replaced or modified by IS-Oil specific objects. The upgrade needs to take care of these modifications during the phase


EU_IMPORT and BIND_PATCH. In case an upgrade is performed to an SAP R/3 release older than 6.0, the IS Solutions need to be added in the upgrade. For upgrades to target release 6.0, all IS Solutions are already embedded.

For upgrades up to ECC 5.0, the new repository for the IS Solution Add-On is shipped on one or more CD-ROMs, which need to be specified (number and location) in the PREPARE phase called INITPUT_PRE. For ERP 6.0 all IS Solutions are shipped as part of the default export DVDs.

Figure 8.13: Separate upgrade CD-ROMs for add-ons.

Besides separate CD-ROMs for each IS Solution Add-On, you also have to take CRTs (Conflict Resolution Transports) that need to be added in the BIND_PATCH.

There is a phase called ADDON_CHK during the upgrade that checks what add-ons and Industry Solutions are installed in the source SAP system. This list is compared with a file called IS_RANGE.LST that is shipped with the upgrade kit. This file contains a description of all add-ons and IS Solutions included (supported) by the upgrade export CD-ROM. This IS_RANGE.LST ASCII text file looks like:

# Ranges of ADD-ONs that are included in the Export

#

# ADD-ON-ID RELMIN RELMAX

PI 2001_2_31I 2002_1_46C

BANKING 403A 461

If the add-on version in the source release is lower than the value specified with RELMIN, the customer needs to upgrade the add-on at least to version RELMIN before he can proceed with the PREPARE. If the add-on version in the source release is higher than the value specified by RELMAX, the customer needs to include an add-on upgrade version into the upgrade in, phase IS_SELECT. The output of this PREPARE phase is also written to file “/usr/sap/put/log/CHECKS.LOG.”

The IS_SELECT phase (IS_CHK in older SAP release upgrades) provides the ability to include all kinds of add-on packages and Industry Solutions in the

130 UPGRADING SAP

upgrade. The IS_SELECT phase is accompanied by a phase called EXECIS, which reads the AVERS (installed add-ons and populates the table NAVERS, add-ons delivered by the upgrade kit). The selection of this phase is stored in “/usr/sap/put/logs/EXECIS.LOG.”

The phase right before phase IS_SELECT in PREPARE, called UPLOAD_REQUEST, will ask for the location of all EPS files belonging to all add-ons and Industry Solutions that need to be installed during the upgrade. The question is:

START OF PHASE UPLOAD_REQUEST

If you intend to include ADD-ON Upgrades with SAINT Packages or to apply Support Packages into the upgrade, you can now make available the needed packages. All fitting packages will then be chosen as default selection in the phase IS_SELECT for the SAINT Packages and in the phase BIND_PATCH for the Support Packages. Do you want to search for new packages in directory “/usr/sap/trans/EPS/in”?

Figure 8.14: Phase IS_SELECT selection screen. ©Copyright SAP AG.

The IS_SELECT phase enforces a decision about all installed and delivered add-ons. The selection screen shows a list of installed add-ons in the system and all add-ons that are delivered in the SAP target release. You will find here items like the ST-PI plug-in and for SAP R/3 Enterprise 4.7 all the extension sets. The possible status of each add-on object can be:


UPG STDCD –- Upgrade to version on standard upgrade CD. This is applicable for add-ons, which are delivered on the standard upgrade export CD-ROM. If a more recent version is available from SAP, download this and include this higher release into the upgrade.

UPG CD – Upgrade with an add-on CD. There is an upgrade required for this add-on that is available on a separate upgrade export CD-ROM.

UPG SAINT – Upgrade with the SAINT package. The upgrade add-on is delivered in a SAINT package (AOU) that needs to be prepared as EPS package in “/usr/sap/trans/EPS/in.” This step will be handled by the Add-On Queue Calculator in phase ADDON_QCALC.

For add-ons that might conflict with a new release or add-ons that cannot be upgraded to a newer or higher release, the customer has to make certain decisions. The IS_SELECT phase provides the ability to make these decisions. The following choices are valid:

KEEP – Keep with Vendor key. This choice will transfer the add-on unchanged to the new target release. However, the vendor needs to provide a “vendor key” for this. This is to ensure that third-party software is certified by the vendor for usage in the new SAP release.

KEEP YOURS – Keep your version. It’s similar to the KEEP choice with the exception of not having to provide a vendor key.

DEL – Delete. It’s a passive deletion of the add-on and only possible for “unprotected” add-ons, which are listed in “/usr/sap/put/bin/IS_PROTECT.LST.”

DEL CD – Delete with CD-ROM programs. It’s similar to the DEL choice with the exception of a deletion process. The deletion process consists of a set of transports or a SAINT package, which will de-install the add-on. SAP delivers, for example, a deletion CD-ROM for the IS-Oil Downstream add-on. Customers using IS-Oil can consider de-installing this add-on if they’re only interested in the CA-JVA (Joint Venture Accounting) add-on.

UNDECIDED – No decision yet. Default choice for all add-on objects in the IS_SELECT selection screen. The customer needs to change this for all objects.

The move of add-ons is also prepared during the IS_SELECT phase. This move reflects the possibility to move add-ons from one SAP layer into another. For example, a certain plug-in, which is in the SAP source release part of the Functional layer, might be moved (“Retrofit”) to the Basis layer in the SAP target release. A file called “/usr/sap/put/log/IS_MOVES.LST,” which is delivered with the upgrade kit, heads this move operation. The actual move that will be done is listed in a log file called “/usr/sap/put/log/MOVEMENTS.LOG.” The IS_MOVES.LST has the following layout:

132 UPGRADING SAP

# Movement of Add-On Products

#

# These movements are performed imaginarily before

# the upgrade is really performed, please keep this in

# mind. The add-on supplement CD must support the state # which is the result of all movements defined here. # # --------------------------- # VERSION 1 # ---------------------------

(IS-R 1.2B) moves to (SAP_APPL,40A)

Additional information about the add-ons that are delivered with the upgrade kit can be obtained from file “/usr/sap/put/bin/RADDTAB.DMP.” This file contains, per supported add-on, an update type and status field, which is updated during the upgrade. The update field can have the following values:

“W” – Default value of all objects in this file before any choices have been made “E” – After decision UPG CD, means that add-on upgrade is part of an upgrade

CD “T” – After decision KEEP or KEEP YOURS the add-on will be transferred to

new release “U” – After decision UPG CD or UPG SAINT for add-ons that are being upgraded “L” – After decision DEL or DEL CD for all add-ons that will be deleted This status field can have the following values: “+” – The add-on is installed. “-“ – The add-on is de-installed. “M” – The add-on is merged to the TODIR table, which means it has a temporary

status during the upgrade.

INFO The inclusion of SPAM/SAINT updates in IS_SELECT is only supported in upgrades on SAP source releases 4.0B or higher. For SAP source releases below 4.0B, such as SAP R/3 3.1I, the phase IS_READ is used instead.

8.10 ADD-ONS AND INDUSTRY SOLUTIONS (AS OF ERP 6.0)

As of SAP ERP 6.0, all Industry Solutions are embedded in the SAP core delivery. This means that the target release repository will contain all available IS Solutions. The upgrade will automatically detect the installed IS Solutions and will activate the proper IS Solution within the new target release by using the Switch Framework.


NOTE There are still add-ons, extensions and IS Solutions that are not part of the standard delivery. If your system does have such a plug-in installed, beware of the fact that it’s not automatically being upgraded. The Upgrade will detect it, but a manual intervention is needed. You might also have to order a separate CD-ROM/DVD for this. Information about standard delivered functionality can be found in SAP Note 838003.

8.11 BIND_PATCH

SAP Support Packages, described in more detail in Section 4.7, can be applied in two ways: standalone by using the SAP Package Manager (also known as SPAM) or by adding them to an SAP release upgrade. It’s very important to understand the consequences of BIND_PATCH before you’re going to make use of it.

Let’s assume we have an SAP R/3 system on start release 4.5B with Support Package level 25. We would like to upgrade to SAP R/3 Enterprise 4.7 without any additional Support Packages. The consequences on this action might be that we downgrade certain functionality. To explain, a situation can go wrong if we just upgrade a system without applying Support Packages. Imagine an ABAP program RVABAP01 that is delivered with SAP R/3 4.5B. This ABAP program contains a serious bug due to the fact it’s trying to divide a number by zero. Support Package 1 (SP1) will correct this problem by adjusting the ABAP code. However, this bug was discovered after the release of the newer version 4.7. Therefore, just upgrading from 4.5B SP1 to 4.7 SP0 will introduce this bug again.

Figure 8.15: ABAP source code correction deleted during upgrade.

In order to correct this bug again, we need to apply Support Packages after the upgrade in order to restore the original bug fix.

Performing this operation after the upgrade is not an issue, however, if we’re trying to correct an error on a table structure, which contains data. It is not possible to do that after the upgrade.

134 UPGRADING SAP

To explain the situation for data in tables, imagine we have a table called TABX in our 4.5B system with a certain structure. Due to new functionality added to the Support Package, for example, to support new legal requirements, fields are changed or even added to the table. When this new functionality was released to the market after the release of SAP R/3 4.7, this structure change is unknown to the upgrade.

Figure 8.16: Data lost during upgrade.

In the worst situation, you might end up loosing data during the upgrade. This issue is known as “Equivalence Attributes” and can be solved in the upgrade during the BIND_PATCH phase.

To prevent this from happening, the upgrade allows you to include Support Packages in the upgrade. The BIND_PATCH phase in the PREPARE tool allows you to specify the Support Packages you want to add to the upgrade. However, since SAP Web AS 6.10, certain items in BIND_PATCH have been changed. We will take a look at both “old” solutions, based on R/3 target release 4.6C and lower and the “newer” solution, which is based on SAP R/3 target release 4.7 or higher. This means that there is a difference between SAP Basis 4.6 and lower and SAP Web AS 6.10 and higher.

During BIND_PATCH in PREPARE, you will be asked whether Support Packages need to be included. It is strongly recommended to include these. Depending on the release of PREPARE and R3up, certain things need to be done manually. For example, the newer R3up is able to pick EPS (Electronic Package Service) files up from “/usr/sap/trans/EPS/in” and UNCAR or UNSAR them. However, if you’re working with an older R3up due to the fact your target SAP release is older than R/3 Enterprise, you have to disassemble these EPS files yourself. Just download all necessary EPS files from the Web and place them in “/usr/sap/trans/EPS/in” and update your system with the latest SPAM update.


TIP During a SPAM update, several errors might occur, such as: LOAD_PROGRAM_LOST, SAPSQL_SELECT_WA_TOO_SMALL, or SAPSQL_WA_TOO_SMALL. These errors are caused due to a “bootstrap” problem. You’re updating the engine, which is doing the update for you. Just ignore the message by exiting transaction SPAM, reset all buffers in the SAP system with /$SYNC, and restart transaction SPAM.

You need a copy of the latest SPAM for using program RSSAPM13 or RSSPDASS, depending on your SAP source release, in order to create co- and datafiles from every EPS file. At a later stage, R3up will bind these files to the upgrade. In a few occasions it might also be possible that R3trans and tp need to be upgraded to a higher patch level. This is possible in case the co- and datafiles are created by SAP with a newer version of tp and R3trans compared to what is installed on your system. In older SAP releases, the ABAP programs that are used instead are RSEPSUPL (Upload Support Packages in SPAM) and RSEPSDOL (Create ATT files from EPS bundles).

TIP Please read carefully the SAP Upgrade Manual and all related SAP notes before you do any actions. ABAP names might change from time to time and certain steps are done by R3up/SAPup now.

During previous upgrades, the process of applying Support Packages during the upgrade was similar to a normal, regular, import of Support Packages using SPAM. The co- and datafiles that reside in the Support Packages are imported the same way during phases BIND_PATCH, PATCH_CMDIMP, and PATCH_MERGE as done by SPAM. Therefore, the same rules apply for this technique as for the normal SPAM situation.

Not all combinations of Support Package queues can be imported into the system. The consequence of this is that only one Support Package queue can be imported during the upgrade. As explained previously in Chapter 4, certain Support Packages have conflicts.

Having conflicts between Support Packages during BIND_PATCH can be problematic when you loose data during the upgrade. Assume you’re on SAP R/3 3.1I, with Support Package level 35, and you want to upgrade to SAP R/3 4.6C. Certain functionality is only shipped in Support Package 10 for release 4.6C and therefore you want to bind at least Support Package level 10 with your upgrade. However, there is a conflict between Support Package 8 and 9, therefore, you can only bind up to level 8 in your upgrade phase BIND_PATCH. The warning, which is shown during PREPARE phase PATCH_CHKN look like this (this example is taken from a BW upgrade to 3.0B) :

WARNING> *** Patch Level too high *** The latest “BW Support Package” confirmed in your system has patch level 17. But: the upgrade to be applied here is based on

136 UPGRADING SAP

the BW Support Package state with patch level 14. Any conflict with BW Support Package, patch level 15–17, can be resolved with the latest available release for the R/3 System or with the latest “BW Support Package” for Release 30B.

TIP If you seem to lose data due to this issue, the advice would be to address this yourself by correcting the tables yourself. However, do this only when you’re on target release 4.6C or below. Otherwise, contact SAP Global Active Support.

The BIND_PATCH phase is also supported by phase CONFLICT_CHECK, which performs a sanity check with respect to conflicts between the various patches. This phase uses ABAP function module SPDA_PREPARE_PATCH, which is part of the SPAM transaction. Therefore this function is only available for upgrade with a SAP source release higher than 4.0B. The log files produced by the phase are “/usr/sap/put/log/CONFLCHK.LOG” and “/usr/sap/put/log/SPDA_CONFLCHK.LOG”.

8.12 PLUG-IN ADDITIONS

Certain interfaces between Core SAP and extensions are implemented using Plug-Ins. Plug-ins have their own release cycles, which might differ from SAP core release. Although plug-ins will eventually move into the Web Application Server layer, to date their still installed and maintained separately.

The process of upgrading a plug-in can be quite complex. Therefore, SAP has a separate section in the Upgrade area on the SAP Service Marketplace that includes a wizard application that should help in the determination of the upgrade steps. On some occasions you have to perform interim upgrades on the source release before you can upgrade to the target.

INFO Additional information on SAP R/3 and Basis plug-ins can be found at the Marketplace location http://service.sap.com/r3-plug-in.

8.13 LANGUAGES

If, besides English and German, additional languages are installed on the target system or are required in the target system, you need to take special care of this. Additional languages are indeed additions to Core SAP. Languages and texts can be seen as part of the Repository of SAP, but are loaded and stored separately. This means that the customer can add texts to the SAP systems with a new unique language key. These customer additions are not treated as modifications, and are


not touched by the upgrade. However, SAP name range language additions (and modifications made by the customer) are affected by the upgrade. If, during the upgrade, these languages are not included into the upgrade, these languages are removed from the SAP system. This is a method of removing additional languages that are no longer required in the SAP system. You just have to upgrade to a higher SAP release without including those additional languages into the upgrade.

It is also possible to add the additional languages to the SAP system after the upgrade. This is the same operation as adding a new language to the SAP system using transaction SMLT. For SAP systems with Industry Solutions included, additional language sets are available. These sets contain additional texts for all extra, Industry Solution–specific objects that are unknown to Core R/3. If, for example, an R/3 system is loaded with IS Utilities and in addition to English and German, the language French is required; the French language set for IS Utilities is required. If this set is not loaded into the system, IS Utilities–specific screens are not available in French, and the default language, English, is shown instead.

There are several phases, during PREPARE and the upgrade itself, that are responsible for getting the languages upgraded. Phases like LANG_CHK that checks whether all installed languages are supported by the upgrade, LANG_SELECT that copies all required language import files to “/usr/sap/put” and RUN_RSUPGSLI that configures the selective-language options during PREPARE. The language load itself is performed during the load of the shadow tables in phase SHADOW_IMPORT_UPG1.

8.14 USER MODIFICATIONS

User- and customer-created modifications to standard SAP take the most time during the upgrade project. The upgrade process is intended to overwrite (or renew) all objects in the SAP system. This is not a problem for standard SAP objects because SAP will replace them with newer ones. However, this overwrite process will replace all SAP objects (programs, texts, screens, etc.) and therefore modifications to these objects will be overwritten, too. In order to preserve these modifications, extra steps are necessary.

8.14.1 Preserve Modifications

During the upgrade processes, several phases are assigned to the task of preserving the customer-created and generated objects. The following steps are performed in sequence:

(1) Lock development workbench – This step will lock the option for developers to create, adjust, and delete objects in the SAP system. The Repository Switch method requires a stable SAP system. That is, a SAP system that is not changed during the upgrade.

138 UPGRADING SAP

(2) Collect all modified DDIC objects in SAP name range – This list will later be used by the SPDD transaction.

(3) Collect all modified ABAP programs in SAP name range – This list will later be used by the SPAU transaction.

(4) Collect all generated objects – All objects that are generated by SAP, for example, FI verification or substitution rules, are collected and put into a single command file

(5) Collect all ABAP programs and DDIC objects in the customer name range – These objects are also put in a command file

(6) Object export – Export all these objects to a DATA (dump) file at the OS level and use the previously created command files for these. This step is performed by the standard SAP transport tools “R3trans” and “tp export <COMMANDFILE>.”

(7) Run transaction SPDD – This will offer the ability to clarify what table fields, field domains, and data elements should be kept or overwritten by the upgrade.

(8) Object import –- Import all previously exported objects back into new target release.

(9) Run transaction SPAU – This step can be performed after the upgrade is finished. It will allow you to make decisions on what ABAP program (version) should be kept.

During the PREPARE phase, the ADJUSTCHK will check whether there are adjustments made to the SAP system. The most important ABAP report that is used for this is RDDGETMO, which can also be used by the customer to list all modifications. The ADJUSTCHK phase writes all found modifications to the file named “/usr/sap/put/log/UMODPROT.<SAPSID>.”

TIP Modifications to objects that are part of the Basis layer are always returned to SAP standard. This is to increase upgrade performance. There is no option to save these modifications. If you would like to keep these modifications, you just have to reapply them after the upgrade is finished.

8.14.2 SPDD

The SPDD transaction needs to be performed by the customer in order to keep all modifications done to Data Dictionary objects after the SAP release upgrade. The SPDD transaction uses ABAP report RSUMOD02, which lists all modifications of tables, views, indexes, match-code objects, and structures.


Figure 8.17: Transaction SPDD. ©Copyright SAP AG.

After SPDD lists all DDIC modifications to the customer, the customer needs to decide what to do with these modifications. There are three options:

(1) Keep the modification, which means the field addition is kept as a table append.

(2) Return to SAP standard, which will lead to its original layout of the table. (3) Choose SAP recommendation. SAP will show a recommendation, which you

can follow. Decisions around domains and data elements are not always that clear. Therefore, check yourself whether the suggestion make sense.

When all decisions have been made, you can mark all entries as “being done” and you can add all modifications into a single transport request. This transport request should be created in the Development system (usually the first upgraded system) and released for further SAP systems in the landscape.

After the SPDD phase has been finished, the ACT (Activation) phase can be started. All Data Dictionary modifications will be activated, which means that the table structures will be used for the creation or adoption of “real” database objects.

TIP There are several tools in SPDD for helping you out with the decision-making process. The layout-delta screen shows you the difference between the “new” SAP delivered layout of the table and what’s currently the layout. You should definitely use this tool.

140 UPGRADING SAP

It’s important to understand the consequences of your choice during modification adjustments in SPDD. It’s very possible that the wrong decision leads to the loss of fields and therefore of data. This is applicable to tables, domains, and data elements. For other Data Dictionary objects, such as match code and lock objects, structures, and views.

8.14.3 SPAU

Transaction SPAU, which runs the ABAP report RSUMOD04, is similar to SPDD, except it’s applicable to ABAP Repository objects rather than the Data Dictionary. Transaction SPAU lists all modifications done to:

� Reports (includes module pools, ABAP reports, queries. and function modules)

� Messages and texts � Menus � Screens (Dynpros)

Figure 8.18: Transaction SPAU. ©Copyright SAP AG.


Like transaction SPDD, the SPAU transaction offers the ability to process modification adjustments to standard SAP repository objects. To collect all modifications made in the SAP system, report RSUMOD04 checks table TADIR for repair flags and tables E070 and E071 for all objects in transport requests. And Table TDEVC is checked to see whether objects belong to SAP or customer name range. Although this information is also available in table ADIRACCESS, which contains all object keys per modified object, the SAP upgrade tool does not take this table into account.

Figure 8.19: Latest warning from the system before change to SAP coding is made.

The list of modified objects is shown per transport request. It’s up to the customer to decide whether the modification should be kept or not. The option “Return to SAP Standard” means whether the modification made to the ABAP code will be overwritten by a new delivered object. If the source code modification is done on behalf of an SAP note, it’s relatively easy to make a decision. Usually the code fix is part of a Support Package or fixed in the upgrade, therefore, “Return to SAP standard” is the most common choice. If the modification should be kept it gets more complex. If the modification was made to implement additional functionality, this functionality needs to be integrated into the coding that is delivered with the upgrade. If the particular program is not changed between the source and target release, the modified code can be kept. However, if the programs do differ, a complete reimplementation of the modification is required.

The SPAU list is stored in table SMODILOG, which has the following layout (only the most important fields are shown here):


OBJ_TYPE CHAR (4) Object type (as in TADIR)

OBJ_NAME CHAR (40) Name of object

OPERATION CHAR (4) How to deal with modification

UPGRADE CHAR (1) Upgrade relavant

142 UPGRADING SAP

UPG_MODE CHAR (1) How to deal in case of upgrades

SPAU CHAR (1) Shown in SPAU

TRKORR CHAR (20) Transport request/task

SPAU_CODE CHAR (1) Current status in SPAU

The OPERATION field can have the following values:

OPERATION field status Description

PRE Exit at start of modularization unit

POST Exit at end of modularization unit

NEW New modularization unit

ALL Overlay unit

REPA Modification without support

TRSL Translation entry

IMP Business add-in implementation

MOD Modification to source code

If you look at the content of table SMODILOG during SPAU, you will see that most SPAU entries are of type OPERATION=”MOD.” You will also see that table SMODILOG is not normalized; the whole- and subobject relationship is stored in this single table.

Figure 8.20: Relationship between R3TR PROG and LIMU REPS in SMODILOG.

Where the SPDD list needs to be solved during the upgrade, the SPAU list can be processed after the upgrade is finished. Issues around SPAU can be solved up to several weeks after the upgrade. Because of the fact that all ABAP Repository changes are kept in the version management database, it’s relatively easy to reverse changes made to the system.


TIP If you want to know what changes are made to the system before the upgrade or PREPARE is started, refer to table ADIRACCESS to start with. Another good option is the ABAP report RDDGETMO, which is also used by R3up. This report shows all modifications made to the system per transport request.

During the upgrade, table UMODOBJ is refreshed regularly with information about modified objects and their adjustments. The UMODOBJ table (Upgrade Monitor Information of Objects) has the following layout:

Field Type (dimension) DescriptionSAPRL CHAR (4) SAP target releasePGMID CHAR (4) Object ID (see TADIR)OBJECT CHAR (4) Object type (see TADIR)OBJ_NAME CHAR (110) Name of objectUPGRMODE CHAR (1) Session of upgradeMODART CHAR (1) Modification typeSTATUS CHAR (1) Edit statusPATHTRID CHAR (20) Support Package nameSAPKORR CHAR (20) Transport request/task

This table is used to support phases BIND_PATCH, CONFLICT_CHK, SPDD, and SPAU in order to solve object modification conflicts. The field UPGRMODE contains information about the session of the upgrade and in what phase objects are identified and should be fixed. The MODART field contains information about the type of modification and the STATUS field contains information on the current status of the modification for the object performed in SPDD or SPAU. Possible values of this STATUS field are:

STATUS value DescriptionC Completed and closedP In processO Completed and OKN New or added to the listA Automatic adjustableH Semiautomatic adjustable

If objects reside in Support Packages or Transport requests, the appropriate information about this is stored in fields PATHTRID and SAPKORR.

8.14.4 Transporting Modification Adjustments

Decisions made about object modification adjustments in SPDD or SPAU can be put into a single transport request. This transport request, which is usually being

144 UPGRADING SAP

created during the first upgrade in your SAP landscape, can be used later on in other upgrades of SAP systems in that same landscape. Assume you’re first upgrading the DEV (development and test) system and, consequently, you will upgrade QAS (quality assurance or acceptance) and PRD (production or integration) systems; the collected decisions can be imported during the upgrade, so that manual SPDD and SPAU actions are no longer required.

To mark SPDD and SPAU decisions you just select the object and press “Select for Transport.” After the upgrade is finished you just release the transport with transaction SE01 or STMS. By adding the transport request number to the file named “/usr/sap/trans/umodauto.lst” on your next upgrade of, for example, QAS or PRD, the upgrade will automatically import these SPDD and SPAU decisions into the process.

Figure 8.21: Automatic transport of modification adjustment.

INFO The reason to store the umodauto.lst in “/usr/sap/trans” instead of “/usr/sap/put” is the fact that “/usr/sap/put” is not shared between the SAP systems.

8.14.5 Modification Assistant

Since R/3 release 4.5A, SAP supports object modification through a process called “The Modification Assistant.” This Assistant is a tool that resides in the ABAP development tool SE38. The objective of the Modification Assistant is to help the customer in managing their modifications more efficiently. The Modification Assistant appears as a couple of buttons in SE38, only when an ABAP program is changed.

Figure 8.22: Modification Assistant buttons in SE38.


The “Insert” button places a text frame at the cursor location so that any customer code can be placed in there. Later on, this text frame is used to identify customer modifications to standard SAP coding.

* { INSERT D01K900004 * * } INSERT

This text frame is handled as comment text in ABAP and therefore neither compiled nor executed. However, at the same time of the insertion of this text, an entry is added to table SMODILOG. This SMODILOG table contains all the information that is used by the “Modification Browser,” an essential part of the Modification Assistant. The Modification Browser, which can be accessed through transaction SE95, provides the ability to list all modifications made to the system, including those ones that were made without the Modification Assistant.

Figure 8.23: Expandable tree structure of modifications in SE95. ©Copyright SAP AG.

The Modification Browser contains both ABAP Repository and Data Dictionary modifications and lists them in an expandable tree structure.

146 UPGRADING SAP

8.15 UPGRADE DIRECTORY

The entire upgrade, including the new shadow instance, is located in the Upgrade Home Directory named DIR_PUT. The location of DIR_PUT can be adjusted to serve specific needs, however, it is recommended to follow the standard location, which is “/usr/sap/put” on UNIX-based operating systems and <DRIVE>:\USR\SAP\PUT on Microsoft Windows Server–based operating systems.

The DIR_PUT location should be large enough to contain the following files:

� Upgrade tools in “/usr/sap/put/bin”

� New kernel of target release in “/usr/sap/put/exe”

� New repository, add-ons, and languages in “/usr/sap/put/data”

� All log files produced during upgrade in “/usr/sap/put/log”

� Temporary files produced during phases in “/usr/sap/put/tmp”

� Java engine upgrade tool JPREPARE and SAPJup in “/usr/sap/put/Jupgrade”

� The shadow instance in “/usr/sap/put/<SID>”:

� “/../SYS/profile” start, instance, and default profile

� “/../DVEBMGS/work” all trace files

� “/../homeshd/<SID>” start and stop scripts

The following size is recommended by SAP in cases where the upgrade target release is ECC 6.0; 5000MB of freespace and 20% additional space if you have a significant number of custom developments. If additional languages, besides German and English, need to be loaded during the upgrade, add 300MB per language. The PREPARE phase FREECHK checks whether there is sufficient freespace available in DIR_PUT. The most important folders in the upgrade directory are:

<DIR_PUT>/bin • This directory contains configuration and script files. The files in this

directory are delivered by SAP and extracted from archives during PREPARE or generated during operation of SAPup. The executable SAPup also resides in this directory if the upgrade is performed on a UNIX machine.

<DIR_PUT>/exe • This directory contains the kernel of the destination release. The files in

this directory are delivered by SAP and extracted from archives during PREPARE.

• The executables in this directory are of destination release. If you need to exchange tools or the kernel in this directory, you need to get executables of the release you are upgrading to.


<DIR_PUT>/htdoc • This directory contains HTML files with information about the upgrade

directory structure, an Upgrade FAQ, and the HTML phase list. <DIR_PUT>/tools • This directory contains tools used by SAPup during the upgrade process.

The files in this directory are delivered by SAP and extracted from archives during PREPARE.

8.16 UPGRADE LOG FILES

A variety of log files are being produced during the upgrade. SAPup monitors all contents of these log files for you. So, if during one of the phases a severe error occurs, SAPup will show this at the end of the phase. Logs are located in <DIR_PUT>/log.

There are several types of log files produced during the upgrade: � R3up.log or SAPup.log: The overall log file of the R3up tool. � UpgDialog.log: The log file that collects all input performed by the upgrade

engineer � R3upchk.log: Log produced during the PREPARE phase � <phase-name>.ELG: ErrorLoG belonging to specific upgrade phase � <phase-name>.LOG: Log file produced by specific upgrade phase � <jobname>.<SID>: Log file produced by ABAP Job � <phase-name>.SAV: Copy of ELG or LOG file of previous run For example, the RDDIT006 phase, which saves the customer name range and

generated objects, produces the following log files: � DIFFCALC.LOG: Log file of RFC login step � CUSTEXP.<SID>: Log file of background job RDDIT006 � DIFFCALC.ELG: Condensed log file with all errors from CUSTEXP.<SID> � DIFFCALC.SAV:.LOG and .ELG log files from previous runs The phases executed by tp produce files, such as SLOG (Step LOG), which

contains an entry for each tp step: SLOG<REL>: START put D01 START tpsetstopm D01 STOP tpsetstopm D01 START tplock_eu D01 The ALOG file (Action LOG) and the ULOG file (Upgrade LOG) contain

entries for each tp call done by R3up.

148 UPGRADING SAP

During certain upgrade phases, all log files are written in “/usr/sap/put/tmp” and copied to “/usr/sap/put/log” after the phase is stopped or finished.

When a severe error occurs during one of the upgrade phases, SAPup reports this back, using .LOG and .ELG files, to the UaServer. The upgrade engineer will notice this through the UaGui or Web browser. After the problem is solved, it’s possible to repeat the phase. The current .ELG and .LOG files are copied to .SAV files.

After the upgrade is finished, all log files can be viewed from within the SAP system. In order to do this you need to use ABAP report RDDPROTO.

TIP Before starting the upgrade on an Oracle system, execute the following SQL statement on the database via SQL*Plus. SQL> select * from V$NLS_PARAMETERS where PARAMETER = ‘NLS_NCHAR_CHARACTERSET’. If the NLS_NCHAR_CHARACTERSET still returns the value US7ASCII, change this to UTF8. The procedure to perform this step is described in Note 669902. Starting the upgrade without performing this step will result in some of the upgrade phases failing/returning wrong results.

8.17 TOOLIMPORT

The various TOOLIMPORT phases are performed to import additional tools (ABAP programs and tables) that are specific for the upgrade. These objects are added to the SAP system and exclusively used during the upgrade. However, they will be deleted during the repository switch of the SAP system. With the test that takes place in PREPARE phase TOOLVERSION_INI, the system checks whether the system can carry these additional objects. The log information of this phase is written in the “/usr/sap/put/log/TOOVERS.LOG.” This phase will determine, according to the SAP source release, which TOOLIMPD phases have to be executed during the upgrade in order to import the additional objects into the system.

During the upgrade process itself, which is run by R3up/SAPup, a similar test is repeated by phase TOOLVERSION_UPG. SAPup will also check the available freespace in the database in phase SPACECHK_IMP. Although the TOOLIMPD phases do not contain that many objects, the upgrade process needs to be ensured about the sufficient freespace. The name of the phase that will import the “upgrade tools” into the SAP system is dependent on the SAP source release:

R3up phase name SAP source release (Basis layer)

TOOLIMPD1 R/3 3.0D–3.1I

TOOLIMPD2 R/3 4.0A–4.0B

TOOLIMPD3 R/3 4.5A–4.6D

TOOLIMPD4 SAP WAS 6.10–6.40

TOOLIMPD5 SAP AS 7.00–7.10


The log of this phase is written to “/usr/sap/put/log/TOOLIMPD.ELG.” Subsequently, phases are MVNTAB_TOOL, which activates the nametabs for the upgrade tools and phases TOOLIMPDI, TOOLIMPDM, and phase JOB_RDDGENRS. This imports additional SAP source release independent upgrade tools and generates all reports in the system. In addition to these phases, the customer can decide to import the latest available upgrade tools into the system. The name of the phase is dependent on the SAP source release:

PREPARE phase name SAP source release (Basis layer)

TOOLIMP4_FIX R/3 4.0A–4.6D

TOOLIMP6_FIX SAP WAS 6.10–7.10

The ABAP upgrade tools that are loaded into the source system can be upgraded during the PREPARE with renewed versions. See SAP note 522711. An example of this is FIX_R3E470SR1.SAR for SAP R/3 systems that are upgraded to R/3 Enterprise 4.7 SR1.

8.18 CLEANING THE SYSTEM

To make the upgrade of your SAP system a success, it’s important that the SAP system is clean before the actual upgrade takes place. But what is a clean SAP system? A clean SAP system means no open repairs in the system, no locks on tables or other objects, and other outstanding or queued operations.

During the SAP release upgrade, several checks are performed to see whether the SAP system is clean. Let’s take a closer look at the different checks during the upgrade:

(1) Object locks – This test checks whether objects are locked in transport requests. For this operation, table TLOCK is accessed. If locks are found in the SAP system, you can remove them by just releasing the transport request and the appropriate task.

(2) Open repairs – This test checks whether objects have been modified in a non-development system. For this operation, table TADIR is accessed. If direct modifications are found in your Production or Acceptance SAP system, you first need to find out why they were created in the first place. Modifications of objects should not be allowed in SAP systems other than the development system. The best way to deal with this is to remove the repair flag from the object using transaction SE03.

(3) Running import jobs – This test checks whether all transport request import jobs have been finished. For this operation, tables TRBAT and TRJOB are accessed. If unfinished import jobs are found by PREPARE or R3up, there are a couple of solutions for this problem: the best option is to use “tp getprots <SAPSID>” from directory “/usr/sap/trans/bin” as “sapsidadm” user. A

150 UPGRADING SAP

second option is to remove all entries from the tables using ABAP program RDDCLEAN.

(4) Outstanding updates – This test checks whether all asynchronous update requests are performed. For this operation, tables VBHDR and VBDATA are accessed. Outstanding or cancelled update requests need to be checked with the owner before processing can be continued or requests are deleted. There are two methods to remove issues around update requests: Run ABAP report RSM13001 and first use first the “REORG” option before the “DELALL” option. If this method fails, try to delete all entries from the tables VBHDR and VBDATA.

(5) Disable scheduled batch job – It’s important to deactivate all scheduled batch jobs during the upgrade. Use transaction SM36 to see what batch jobs have been scheduled.

(6) Process Direct Input Session – Depending on the source release, tables APQI and APQD (both used for Direct Input Sessions, see transaction SM35) might change their structure. Therefore, a table conversion is required during the upgrade. The consequence of this is that Input Sessions created before the upgrade cannot be processed after the upgrade. Use transaction SM35 or BMV0 for details.

(7) Archive unnecessary entries in ACCTIT, ACCTHD, and ACCTCR – The ACCTIT table set is used as an interface between the MM and FI module. However, it’s possible that this table contains a large portion of unused table rows and should be archived. See SAP note 83076 for more details.

(8) Delete obsolete spool files – Use transactions SPAD and SP12 to manage, reorganize, and delete all obsolete spool files (print and batch job requests).

(9) Reorganize performance statistics – Via transaction ST06 or ST06N, there is an option to reorganize and delete obsolete performance statistics.

(10) Confirmation of all Support Packages – Use transaction SPAM to confirm all applied Support Packages.

8.19 SHADOW TABLES

“Shadow tables” are tables that are created in the background during the upgrade next to the “normal” tables. Shadow tables are either “Exchange tables” or “New tables.”

The first group of shadow tables is called the “Exchange tables,” which are candidate tables for replacement by a new release. An example exchange table is “D010S,” which contains all ABAP sources. This table contains all ABAP sources of that particular release, lets say SAP R/3 source release 4.0B. During the upgrade, a new shadow table “D010S~” is created. This table will contain the entire ABAP source code of SAP R/3 target release. Due to a possible table name conflict, all


exchange tables are following a certain name convention. The following name convention is used for shadow tables:

Orginal Table Name Shadow Table Name SAP source release

TABLE TABLE___4G Below 4.0A

TABLE TABLE~ Above 4.0A

TABLE TABLE “new table”

The second group of shadow tables are “New tables” that are new to the SAP system. These tables do not have a table name conflict, and therefore will have the actual name. “New tables” are created in phase NEWTAB_CRE, which uses an ASCII text file called “/usr/sap/put/ntabsql/ntmast.tab.” This phase is performed by the tp tool. Shadow tables are vital for both the “Repository Switch” and the “System Switch” principles.

8.20 REPOSITORY SWITCH

The “Repository Switch” principle was introduced in upgrades to SAP R/3 target release 3.0A. This principle is based on the creation and import of “shadow tables.” These shadow tables are located next to the regular tables in the SAP system. The “Repository Switch” principle consists of six major steps. Figure 8.24 will shows the upgrade of SAP R/3 source release 4.6C to target release ECC 6.0.

Figure 8.24: First step in “Repository Switch.”

During the first step, the repository (ABAP programs, screens, transactions, menus, texts, and the entire SAP Dictionary) of the target release ECC 6.0 are loaded into the SAP database system. R3load uses three input files for this phase:

(1) DD<DB>.TPL – This file is an RDBMS-specific file shipped by SAP that contains a template for SQL statements. R3load uses these statements to create tables and indexes and import rows into the shadow tables. The

152 UPGRADING SAP

<DB> is replaced by ORA for Oracle, MSS for Microsoft SQLServer, and DB6 for IBM UDB. An example of such a file looks like:

prikey : BEFORE_LOAD ORDER_BY_PKEY

seckey : BEFORE_LOAD

cretab : CREATE TABLE &tab_name

(/{ &fld_name &fld_desc /-, /} )

IN &location

crepky : CREATE TYPE 2 UNIQUE INDEX &pri_key ON &tab_name

(/{ &key_fld /-, /} )

USING STOGROUP &location

PRIQTY &init

SECQTY &next

ERASE NO

PCTFREE &pctinc

CLUSTER

BUFFERPOOL &bufferpool

CLOSE YES

;

ALTER TABLE &tab_name

ADD PRIMARY KEY ( /{ &key_fld /-, /} )

creind : CREATE TYPE 2 &unique INDEX &ind_name ON &tab_name

(/{ &fld_name /-, /} )

USING STOGROUP &location

PRIQTY &init

SECQTY &next

ERASE NO

PCTFREE &pctinc

BUFFERPOOL &bufferpool

CLOSE YES

…………………

…………………

tab: D010S~ DDIC00.SDDIC00 BP2

ind: D010S_____0~ IDDIC00 BP3

…………………


This example file “DD<DB>.TPL” has, for all major R3load operations, a section, such as CRETAB for the creation of the table, CREPKY for the creation of the primary key, and CREIND for the creation of the index. The section PRIKEY and SECKEY are telling R3load whether the key constraints need to be created before all rows are inserted or afterward—this might differ between the RDBMSs. The prefixes TAB and IND are used to tell R3load in what tablespaces, stogroups, or devspaces the tables and indexes need to be created.

(2) EX0000nn.STR – This file contains the field structure for all tables. R3load uses this structure to assemble the “CREATE TABLE…” statement. The file has the following layout:

tab: D010S~ att: SSDEF 6 ?? R all D010S~1 fld: PROG CHAR 40 0 0 not_null 1 fld: R3STATE CHAR 1 0 0 not_null 2 …………………… …………………… fld: BLOCK LRAW 0 0 0 null 0 ……………………

Each row in this file starts with a prefix. Prefix TAB identifies the table name. The prefix ATT describes certain attributes of the table, such as its “Data Class” and one or more prefix FLD lines describes the field layouts of the table—one line per field.

(3) EX0000nn.001 – This file, which is platform, RDBMS and character set neutral, contains the data for all shadow tables. R3load reads all data from this file and constructs the “INSERT INTO…” statements from this information.

Figure 8.25: R3load constructs different SQL-statements.

The R3load import writes several log files from which the “*.TSK” and “*.DPR” contain the most valuable information. The TABART (Import Package) files have the following naming convention:

154 UPGRADING SAP

Import Package Structure Data Import log

Exchange Tables EX0000[1-20].STR EX0000[1-20].001 EX0000[1-20].DPR

Basis Tables EX000[21-23].STR EX000[21-23].001 EX000[21-23].DPR

In the next step, tp will create new tables in the SAP system. For upgrades up to SAP R/3 target release ECC 6.0, this is done in phase NEWTAB_CRE. The tp process uses a ASCII file called “/usr/sap/put/ntabsql/ntmast.tab,” which contains a list of all new tables.

Figure 8.26: tp creates new tables.

For an upgrade to SAP 4.6C or higher, SAP uses different phases. These phases are entirely executed in the “Shadow Instance.” However, the mechanism is the same as for the “Repository Switch” method.

In the next step, the “new” repository will become active and the “old” repository is dropped. This is achieved by a sequence of “drop table….” statements at the database level.

Figure 8.27: The old repository tables are dropped.

and eventually with the “alter table rename….” statement


Figure 8.28: New repository tables are renamed.

The “new” repository becomes the “active” repository. The final step is the “conversion” of application and basis tables.

Figure 8.29: PCON phase converts all tables.

8.21 TABLE CONVERSION

Table conversion takes place during the import of transport requests, the implementation of Support Packages, the installation of add-ons and Industry Solutions, and during SAP release upgrades. There are two types of conversions:

Structure Change Conversions (SSC) – Every time the layout or structure of a table with content is changed, SAP will convert this table.

Cluster- or Pool-to-Transparent Table Conversions (CPTC) – These conversions are ad-hoc performed during SAP release upgrades or on customer request.

During upgrades, there are two mechanisms for table conversions that are used with both SCC and CPTC conversions:

Internal Conversions – Performed through ABAP programs that are predefined, such as RDDGEN0L, or dynamically created. An “internal conversion”

156 UPGRADING SAP

can be monitored through transaction SE14, which uses a “restart-log” table TCNV. This table contains, for all outstanding internal table conversions, the status. Each status value represents a step during the conversion:

1. Initialize – During this step the new structure is checked against the existing table structure. This step will propose a conversion mechanism, such as T → T (Transparent to Transparent Table).

2. Drop indexes – drop all indexes on the “old” table. 3. Rename old table – during this step, the “old” table is renamed to its

QCM-counterpart.

Request: Convert Table ZMYTABLE01 (SNMSEE/15.07.03/13:06

Process: gousap01_1

Test activation of Table ZMYTABLE01 Successful

Field FIELD03 was deleted

ALER TABLE is not possible

Convert Table ZMYTABLE01 by unloading and reloading the data

Database object for table ZMYTABLE01 is checked

Database object for table ZMYTABLE01 is consistent

Type of conversion: T -> 1

Begin step ZMYTABLE01–TT_STEP1:

Step is empty

Step ZMYTABLE01-TT_STEP1 executed successfully

Begin step ZMYTABLE01–TT_STEP2

SQL :

DROP INDEX ”ZMYTABLE01~0’’

SQL :

RENAME ”ZMYTABLE01 TO ”QCMZMYTABLE01’’

Step ZMYTABVLE01–TT_STEP2 executed successfully

4. Create new table – This step will create a table with the “new” structure

Begin step ZMYTABLE01–TT_STEPS :

SQL :

CREATE TABLE ”ZMYTABLE01’’

(”MANDT’’ VARCHAR2 (000003)

DEFAULT `000’ NOT NULL,

”FIELD01’’ VARCUAR2 (000040)

DEFAULT ` ‘ NOT NULL)


”FIELD02’’ VARCHAR2 (000040) DEFAULT ` ‘ NOT NULL) PCTFREE 10 PCTUSED 40 TABLESPACE PSAPSTABD STORAGE (INITIAL 0000000016 K NEXT 0000000160 K MINEXTENTS 0001 MAXEXTENTS 0300 PCTINCREASE 0000 FREELISTS 001 FREELIST GROUPS 01)

5. Data conversion – Copy all relevant rows from the QCM table into the “new” table and align all fields where needed. During this step, certain conversion rules are followed, such as filling empty fields with “0” (zeroes) or spaces.

6. Drop QCM table - The “old” table is no longer needed and can therefore be deleted.

Conversion method : LOAD (RADCUSCH) Mapping Function : DEF_MAP (%_T00010)

Commit after at least every 16.777.216 bytes

SQL :

LOCK TABLE ”ZMYTABLE01’’ IN EXCLUSIVE MODE NOWAIT

Number of inserts ............................: 1

Number of inserted tuples ....................: 3

Internal size of a typel/byte ................: 83

Number of non-inserted duplicates ............: 0

Number of executed commits ...................: 1

Array size used ..............................: 395

Data loaded from QCMZMYTABLE01 to ZMYTABLE01

SQL:

DROP TABLE ”QCMZMYTABLE01’’

Step ZMYTABLE01–TT_STEPS executed successfully

7. Create indexes – Indexes can be re-created on the “new” table. CREATE UNIQUE INDEX ”ZMYTABLE01~0’’ ON ”ZMYTABLE01’’ (”MANDT’’,

”FIELD01’’)

158 UPGRADING SAP

PCTFREE 10

TABLESPACE PSAPSTABI

STORAGE (INITIAL 0000000016 K

NEXT 0000000080 K

MINEXTENTS 0001

MAXEXTENTS 0300

PCTINCREASE 0000

FREELISTS 001)

In transaction SE14 there are several options for table conversions available. Conversions can be done online in foreground processing, through scheduling a background batch job, or though a collective run (mass processing). Afterward you can check whether the conversion was successful or not. The input list for the conversions during upgrade is held in table TBATG (Batch Generator), which has the following layout:


OBJECT CHAR (4) Object type (see TADIR)

TABNAME CHAR (30) Name of table to convert

INDNAME CHAR (3) Unique index id of table

TGORDER NUMC (1) Sequence of process by batch generator

FCT CHAR (3) Function for table conversion program

EXECMODE CHAR (1) Entry for background process

SEVERITY CHAR (1) Status of mass processing

This TBATG table is used by the Mass Conversion tool that is implemented as Batch job generator.

During the upgrade, a file called “/usr/sap/put/bin/TABCONV.LST” is produced, which contains a list of all candidate tables for conversion. When a conversion is performed, all information about the status of each conversion is held in table TCNV. The TCNV table has the following layout:


TABNAME CHAR (30) Name of converted table

FUNC CHAR (3) Conversion function

SRCTAB CHAR (1) Source table type, e.g., transparent

DESTTAB CHAR (1) Target table type

TEMPNAME CHAR (30) Temporary table name

ACTMODE CHAR (3) Activation mode


STEP1 CHAR (1) Is step nr.1 executed?

………. …….. ……….

STEP6 CHAR (1) Is step nr.6 executed?

CUSER CHAR (12) Owner of table conversion

The FUNC field can contain different values from which CNV (activation, adjusting database, and converting data), ICN (incremental table conversion), and DEL (delete all data) are the most important ones. The fields SRCTAB and DESTTAB indicate the table types during the table conversion. In most cases both fields will contain the value “T,” which indicates “Transparent to Transparent table conversion.” The six STEP fields each represent one of the six conversion steps—only one field contains an “X” value.

External Conversions – are performed through the external tool R3trans. External conversions are required for certain tables that are used by the SAP Basis layer. Examples of such tables are Basis tables that are part of the Batch Engine in SAP. The “internal conversion” tools will make use of these tables. And therefore, to avoid a catch-22 situation, these Basis tables need to be converted externally.

The steps performed by the external conversion are:

1. initialize – This step will determine the conversion method.

2. unload data – During this step, all rows of the table are unloaded to a flat file at the operating system level, normally “/usr/sap/trans/data” or “/usr/sap/put/data.”

3. delete data – This step will drop the “old” table from the database.

4. activate – The new table is created according to the new structure.

5. record load – The data residing in the flat file is loaded into the new table.

6. create indexes – Additional indexes are created on top of the new table.

There are several phases during the SAP release upgrade that perform table conversions: PCON (conversion of application data for SAP upgrade to target release up to 4.6C), PARCON (same as PCON, but run in parallel and for upgrade to SAP target release 6.10 or higher), and XCNV (external conversion of Basis tables). The PCON conversions are run in SAP background work processes and therefore can be monitored using transaction SM50. another option for monitoring the progression is to look for NCONV….<SID> files, which are produced by each conversion job and located at “/usr/sap/put/tmp.”

TIP When errors occur during upgrade phases PCON or PARCONV, do not ignore these errors by entering a password. You might end up losing data when these kinds of errors are ignored. Do not delete entries from table TBATG (mass processing) and TATAF (distribution) yourself unless you’re absolutely sure what the consequences are.

160 UPGRADING SAP

8.22 ICNV

Incremental Table conversion is an attempt by SAP to reduce downtime during the upgrade. A significant portion of the downtime during the upgrade is caused by application table conversions. The incremental table conversion option, which resides under transaction ICNV, provides the ability to convert tables online before or after upgrade phase PCON.

ICNV was introduced by SAP in upgrades to target releases 4.0A and 4.0B as a post-upgrade step for the conversions of two tables: EDIDOC (IDOC messages) and CDCLS (Change Documents Cluster). This special type of ICNV, also known as “late conversion,” was able to convert these tables after the upgrade was finished during productive usage of the SAP application. In the upgrade to SAP R/3 release 4.6A, two restrictions were removed—ICNV can be performed before the upgrade (during the PREPARE) and other tables can be converted as well. PREPARE will determine the tables that will benefit from being converted incrementally.

TIP When ICNV is run before the PCON phase, it’s recommended to finish 95% of the conversion before you continue with the upgrade itself. SAPup will check whether sufficient rows are converted before you can continue with the upgrade.

The principle of ICNV (Incremental Table conversions) has been innovated over time. SAP puts a lot of effort into the development of ICNV to make the tool more robust, flexible, and more efficient. Started at release 4.0A, the tool was only able to convert to predefined tables. The next edition of ICNV was able to run in advance of the PCON phase, and the most current version of ICNV, which is shipped as part of the “System Switch” upgrade, is able to convert any candidate table in the system and is available for all database platforms.

Figure 8.30: Principle of Incremental Conversion (ICNV). ©Copyright SAP AG.


The technology behind ICNV is based on database triggers. ICNV will create an additional table that is based on the new table structure. The “old” table remains active in the database and is used as such. Each time a row is updated, deleted, or inserted in the active table, the database triggers an event to inform the ICNV engine. The ICNV engine will update the “new” table according to its structure.

The ICNVREQ phase running during PREPARE collects all candidate tables for incremental conversion, which are listed in the files called SORTTABS.LST and TABCONV.LST. The file SORTTABS.LST can be edited, so certain priority choices can be made. However, ICNVREQ will only add those tables to the list that have their final structure. This structure cannot be changed afterward. ICNVREQ also looks at the number of rows in the candidate tables. If this number is not significantly large, therefore, conversion of this table will not add to the downtime of the application. The table will not be added to SORTTABS.LST and TABCONV.LST.

The latest ICNV provides the ability to: � Convert any table in the system; tables that are modified due to � Table structure change due to customer modifications � Table structure change due to upgrade � Table structure change due to Support Packages � Table structure change due to Installation of add-ons

Figure 8.31: Old table T1, new table QCMT1, and the view T1.

162 UPGRADING SAP

� Display all candidate tables for incremental conversions � Decide which tables are converted through ICNV � Start the conversion process � Monitor the running conversion(s) � Estimate the runtime of the conversion(s) The following restrictions or rules are applicable for ICNV: � In the new “System Switch” upgrade method the ICNV can only be used

during the “Downtime Minimized” scenario. � ICNV makes certain modifications to tables by adding a new QCM table

and by adding triggers at the database level. These modifications cannot be reset or reverted during the upgrade while ICNV is running.

� You should not start a Data Archiving process (transaction SARA) for tables that are converted by ICNV.

� After ICNV starts converting a particular table this table becomes locked for all structure changes. Transaction SE11 cannot be used for this table.

� ICNV requires a certain number of BDG (Background) processes to run the conversion jobs.

When you access transaction ICNV, you will find an “Assistant” button on the right of the screen. This button starts the ICNV wizard, which contains four different buttons:

(1) First step: Initialization – Start the initialization of the conversion, which means that the QCM table is created with:

i. “RENAME TABX TO QCM1TABX” ii. “ALTER TABLE QCM1TABX ADD FIELD CNV_FLAG” iii. “CREATE VIEW QCM2TABX” iv. “CREATE UPDATE TRIGGER in database”:

CREATE TRIGGER TRIUTABX BEFORE UPDATE OF MANDT, FIELD01, …… ON QCM1TABX REFERENCING OLD AS OLD NEW AS NEW FOR EACH ROW WHEN (OLD.CNV_FLAG <> ‘ ‘) BEGIN IF (:OLD.CNV_FLAG = ‘C’) THEN :NEW.CNV_FLAG := ‘U’; END IF; …… …… END;


(2) Second step: Data transfer – The actual copy of data from the source to target table. ICNV has the ability to optimize this process through the setup of different background jobs on several application servers.

(3) Third step: Switch – Will switch the tables back to their original names. (4) Fourth step: Delete entry – Will remove a table from the ICNV worklist. The four functions can also be accessed through the menu. When issues arise

during the conversion you can use the Reset option, which can be accessed through the menu.

TIP The ICNV tool is not only intended for upgrades, but can also be used during regular usage of your SAP system. If you need to change the structure of a table for business reasons, and this table contains a large number of rows, you can perform the following steps. Change the structure of your table in SE11 and just check and save the adjusted table layout. Go to transaction ICNV and add the table to the worklist through “Edit → Add table.” Use the Assistant-button for all other steps.

Since SAP Web AS 6.10 and higher, ICNV also offers “Conversion Scenarios.” For manual conversion, just select scenario “PREUPGFREE.”

INFO For more information on ICNV, use the F1 Help button in transaction ICNV or see SAP Note 490788.

8.23 DDIC SUBSTITUTION

As of SAP R/3 release 4.0A, SAP supports table names longer than 10 characters. The consequence of this is the field length change of all Basis tables that contain information about tables. These Basis tables are Data Dictionary tables, such as DD01L (Domains), DD02L (Table header), DD03L (Table fields), DD04L (Data elements), and DD09L (Table settings); and the nametab (table runtime) tables, such as DDXTT (Table header), and DDXTF (table field); and, of course, the TADIR (Objects directory) table. All these tables need to be converted during an upgrade of source release 3.1I to 4.0A or higher. In order to prevent a bootstrap problem (these tables are required during table conversions), SAP decided to deliver a “new” DDIC substitute during the upgrade. In other words, all these tables are not converted, but replaced with new content.

Tables that are new, such as customer-created tables or tables that are part of add-ons or Industry Solutions, are exported from the old tables and imported in the newly created tables.

This principle is similar to the ABAP Repository switch. Therefore, the DDIC substitution became a part of the repository switch as of SAP R/3 4.0A upgrades.

164 UPGRADING SAP

8.24 ACT – ACTIVATION

The activation of new or revised table structures is the most critical phase of the upgrade. The activation process is described in detail in Chapter 4 “ SAP Software Logistics,” but we will take an upgrade-specific view to this phase. The overall ACT phase of SAP upgrades up to target release 4.6C (Repository Switch upgrade method), consists of the following subphases:

(1) RSUMOD30 – This subphase collects all candidate table and structure modification adjustment candidates.

(2) DDIC_<REL> – During this subphase, the prepared Modification Adjustment transport is imported into the SAP system. The transport is listed in “/usr/sap/trans/umodauto.lst.”

(3) RADDREXE – Renames SAP data elements that conflict with customer-created data elements.

(4) RSUMOD20 – This ABAP, which is run as job JOB_UMOD20_UPG, realigns all structure changes with the runtime and database objects.

(5) SPDD – During the upgrade, this subphase shows the upgrade engineer a dialog box, which provides the ability to enter transaction SPDD and perform all object modification adjustments.

(6) ACT_<REL> – The actual ACTIVATION phase during the upgrade. This subphase is performed by R3up using tp and R3trans.

(7) RDDINDCH – Creation of secondary indexes. The runtime of the ACT phase heavily depends on the number of modifications

made to table structures and the number of included Support Packages into the upgrade. The ACT phases are performed during application downtime. Therefore, SAP redesigned this process and as of SAP target release 6.10. The System Switch Upgrade method uses a slightly different ACT phase. The ACT_<REL> phase has been moved to the shadow instance and therefore can be run during productive use.

The most important thing to perform during the ACT phase is error checking. The activation of table, domain, data elements and structure changes is performed by tp using several different command files. Each failing tp session will produce its own dedicated error log file. SAPup will collect all errors produced during the ACT phase and show these messages at the end of the phase. Errors produced during the ACT phase should not be ignored, although it’s possible by entering a password that is provided by SAP.

The errors that can appear during the ACT phase are: Missing domain/data element – This is the most common error during the

ACT phase. A table is activated with listed data elements, which are not activated yet. This can be solved quite easily by repeating the phase—it’s a sequence issue.

Name conflict error – During the activation of a data element, the same name appears more than once. This error can easily be solved by choosing another (unique) name.


Duplicate name in table – This table contains two fields with the same name. These errors can easily be solved by choosing another (unique) name.

Database error – The table create statement fails due to an error at the database level. This can be caused by several factors: extend or space problems, database is not running or inaccessible.

The ELG error log can look like this:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ DDIC ACTIVATION ERRORS and RETURN CODE in SAPACCR46C.D01 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1EEDO519X”Datenelement” “PES_TIPLIQ” could not be activated

1EEDO519 “Tabelle” “PCER_ATTR” could not be activated

1EED0319 Return code..............: “8”

1 ETP111 exit code : “8”

The error numbers are produced by “tp,” therefore, they should be interpreted as follows:

“tp” error return code Description

4 Warning

8 Error at SAP Data Dictionary level

12 Error at RDBMS level

During PREPARE, a phase called ACTREF is performed, which should recognize name conflicts upfront. Although this tool is very powerful, due to mistakes and inconsistencies made during SPDD, errors can still appear. The ACTREF phase writes all its information to the file called “/usr/sap/put/log/RSTODIRX.LOG.”

8.25 KERNEL SWITCH

During the kernel switch phase, known as KX_SWITCH, the SAP executables at the operating system level are replaced by new ones. Assume an upgrade is performed from SAP R/3 4.6B to SAP R/3 Enterprise 4.7. Before the upgrade, the SAP R/3 system runs on top of the SAP kernel 4.6D patch level ABC. During the KX_SWITCH phase, this SAP Kernel is replaced by SAP WAS 6.20 Kernel patch level XYZ.

During the PREPARE phase, the new SAP kernel is located in “/usr/sap/put/exe” and copied from the SAP kernel CD-ROM, which is shipped as part of the upgrade kit. However, it’s recommended to ignore this kernel and overwrite it with a new SAP kernel, which can be obtained through the SAP Service Marketplace.

166 UPGRADING SAP

Always take care of a consistent set of executables. The versions of disp+work, R3trans, tp, and other programs always need to work with a DBSL driver, such as dbslora.dll (Windows), dbslora.o (UNIX) for Oracle, or dbslmss.dll for Microsoft SQLServer.

The KX_SWITCH phase copies the “prepared” kernel files from “/usr/sap/put/exe” into the area “/usr/sap/<SID>/exe,” which is the permanent location of the SAP kernel.

Figure 8.32: Process of SAP kernel exchange during upgrade.

The new kernel can only be activated by a stop and start of the system. Therefore, the KX_SWITCH phase is part of the “downtime” of the upgrade.

The new set of executables is an absolute requirement to handle all kinds of new repository objects and features of the new release. Therefore, the KX_SWITCH phase runs before the Repository Switch, object activation, and table conversion. The new kernel files are copied from the installed DVDs onto the server in the area where the entire upgrade resides. From this location the files are copied over to the area from where the shadow instances run. During the KX_SWITCH phase, the new kernel is copied over the old kernel.

The SAP kernel is a collection of various files. It’s important that the right collection is used. For example, a Unicode-specific kernel for a database that contains the Unicode character set. In some cases, tools like WebDispatcher, IGS, and SAP Cryptolibrary need to be added manually.

TIP In case you would like to use the latest kernel patch for your upgrade, please check SAP Notes 211077 and 690154.


8.26 UPGRADE DOWNTIME STRATEGY

SAP supports different types of upgrade strategies, which all apply to managing the downtime of your upgrade. For upgrades to SAP target release 4.6C and lower, three different options are available. All three of them are based on the “Repository Switch” method and influence the SAP application downtime. The “System Switch” method just supports two different techniques: downtime and resource minimized. Both techniques are based on the usage of a Shadow Instance, which implements the Repository Switch by using a separate SAP instance running at the SAP target release.

Upgrade Technology

Repository Switch System Switch

A_off Downtime Minimized

A_on Resource Minimized

A_switch

The choices you can make are determined by the downtime you can cope with during the upgrade and the available resources. Like mentioned before, the upgrade technology is dependent on the target release of your upgrade. The “Repository Switch” method supports three strategies where the “System Switch” method only supports two strategies.

Figure 8.33: Different strategies in Repository Upgrade. ©Copyright SAP AG.

During “A_on” the import of the new repository is performed when the database logging is switched off. This process is faster, but it is more difficult to

168 UPGRADING SAP

recover from an error or database corruption. In the “A_on” strategy the new repository is loaded into the database when logging is switched on. The “A_switch” strategy is based on “A_on” with the exception of the offline backup at the end of the upgrade.

As you can see, all strategies are related to the backup and recovery of the SAP database. The “System Switch” method, however, supports two different strategies: Downtime Minimized, which uses a separate second SAP instance next to the main instance, and the Resource Minimized strategy, which uses a separate SAP instance instead of the main instance.

Strategy Advantages Disadvantages

A_switch Short downtimeLess disk storage required to store database logging

Offline backup needed after upgrade is finishedMonitoring of free space of disks which contain database logging files

A_on Shortest downtimeNo offline backup needed after upgrade is finished

Most disk space needed to store all database logging filesMonitoring of free space of disks which contain database logging files

A_off No disk storage required to store database loggingNo monitoring of free space of disks which contain database logging files

Offline backup needed after upgrade is finishedLongest downtime

As of upgrades to and from SAP R/3 4.7 Enterprise, all upgrades are based upon the “System Switch” method. That means that you can only choose from using the Downtime or Resource minimized strategies. Both strategies are implemented within the Shadow Instance. Therefore, the three different strategies that are used by the Repository Switch method are no longer applicable, unless you upgrade to target release 4.6C or older.

These two strategies are focused on an additional instance. For the “System Switch” technique, the following matrix is valid:

Strategy Advantage Disadvantage

Downtime Minimized Less application downtime required

More additional hardware resources required

Resource Minimized More application downtime required

Less additional hardware resources required


The used upgrade strategy used during the upgrade is determined by several factors and therefore the decision needs to be agreed upon upfront. How much downtime is acceptable to the business versus the availability of additional server and storage hardware?

8.27 SYSTEM SWITCH UPGRADE

The “System Switch” upgrade method has been introduced to serve one goal at a time—it’s either to reduce the downtime of the SAP application during the upgrade, or it’s to reduce the computer resources during the upgrade. So the “System Switch” upgrade method comes in two flavors: “Downtime minimized” and “Resource minimized.”

The “System Switch” upgrade is implemented by using a so-called “Shadow Instance.” This is basically a separate SAP Web Application Server, running next to the existing instance. This second “Shadow” instance is a set of SAP Kernel executables (dispatcher, work processes and message server) of the target release and are stored in “/usr/sap/put/SID.” The “Normal” instance executables are located at “/usr/sap/SID.”

Figure 8.34: Different strategies in System Switch upgrade. ©Copyright SAP AG.

170 UPGRADING SAP

One of the major advantages of having a separate “shadow” instance during the upgrade is the ability to run this instance on another machine. In this case, you’re able to distribute “upgrade”-related workload of your productive environment to a dedicated machine. This may also be a different type of machine or platform.

The “Shadow” instance needs to have a unique instance ID, which should differ from the “Normal” instance ID. The SAPup tool selects N+1 by default, where N is the instance ID number of the “Normal” instance. So in our example of P01, which runs under ID “01,” the “shadow” instance will run under ID “02.”

The TCP port allocation will look like this: /etc/services # normal instance P01_01 sapdp01 3201/tcp sapgw01 3301/tcp sapmsP01 3601/tcp sapgw01s 4801/tcp # shadow instance P01_02 sapdp02 3202/tcp sapgw02 3302/tcp sapmsSHDP01 3202/tcp sapgw02s 4802/tcp

The SAPup takes complete care of this allocation unless one of these new required ports are already in use!

Figure 8.35: SAP Shadow Instance during “System Switch” upgrade.

Besides having a separate instance ID and related TCP ports, the “shadow” instance also uses a different set of instance profiles and startup scripts.


All required files are located in “/usr/sap/put/<SID>”: SYS/profile DEFAULT.PFL <SID>_DVEBMGS<nr>_host

START_DVEBMGS<nr>_host DVEBMGS<nr>/work dev_disp, dev_w*, etc… homeshd/<SID> startsap stopsap

The ownership of these files and processes in memory belong to <sid>adm—the same user id the “normal” instance is running with.

Each time SAP releases a new upgrade strategy they’ve improved the reduction of downtime during the upgrade. The “delta”-based upgrade resulted in the longest application downtime. This was significantly decreased by the introduction of the “Repository Switch”-based upgrade, where options like “A_off” and “A_switch” were introduced. With the introduction of ICNV or “Increment Table Conversion,” the application downtime, due to table conversions, was reduced even more. The “System Switch” upgrade method is the latest attempt of SAP to reduce even more application downtime.

The method is based on a shadow instance running next to the “productive” instance, which can be used to prepare, adjust, and convert existing tables and other data objects to the new layout without affecting the current tables. This is established through Exchange and New tables that reside in the system under a different name. After the creation, load, and conversion, the tables are renamed to their “new” and permanent name in the productive instance.

The following example will illustrate this mechanism: Assume we have a table called “SAPR3.EXCHANGE,” which is part of our

SAP source release, with the following layout: NAME CHAR(255) ADRESS CHAR(255) CITY CHAR(255) PHONR INT(8) In the SAP target release, the PHONR will be adjusted to INT(15) to support

all kinds of new international telephone numbers. Imagine that this table is very crucial for the operation of the SAP application, and therefore cannot be converted online. The upgrade will create a new table “SAPR3.EXCHANGE~” with the new layout:

NAME CHAR(255) ADRESS CHAR(255)

172 UPGRADING SAP

CITY CHAR(255) PHONR INT(15) An alternative schema or database user is created, which does serve the

shadow instance. This user will own all synonyms to the new or exchange tables. For example, for Oracle:

(1) SQL> connect sapr3/……….; (2) SQL> create table “exchange~” ………..; (3) SQL> connect sapr3shd/………; (4) SQL> create synonym “sapr3shd.exchange” for “sapr3.exchange~”; (5) SQL> connect sapr3/……….; (6) SQL> grant all on “sapr3.exchange~” to “sapr3shd.exchange”; (7) SQL> connect sapr3/……….; (8) SQL> create view “sapr3shd.v_exchange” as select * from “sapr3shd.

exchange”; In steps (1) and (2) the new “SAPR3.EXCHANGE~” is created with the new

layout, followed by steps (3) and (4) where a table synonym “EXCHANGE” is created under schema SAPR3SHD. In steps (5) and (6) the proper authorizations are set and in step (7) and (8) an additional view is created. This last step is optional and not applicable for all tables. The schema user example SAPR3SHD is based on the normal SAP schema in your RDBMS, however, since SAP Web Application Server 6.10, the SAP schema in your RDBMS might be SAP<SID> for new installs. SAP started this new naming convention to support MCOD (Multiple Components in One Database).

Figure 8.36: Relationship between tables and shadow tables.

Two system tables are maintained during the upgrade, which contains information about the shadow tables: PUTTB (for the productive instance) and PUTTB_SHD (for the shadow instance). The layout of these two tables is as follows:



TABNAME CHAR (40) Name of original table

WCONTENT CHAR (1) Table content

BUILDCONV CHAR (3) Name convention for conversion table

The field WCONTENT can have the following values: “D” = exchange table, “Q” = shadow table, and “P” = new table. The possible values for field BUILDCONV are:

“001” : ‘TABLE___4G’ (if SAP source release is below 4.0A) “002” : ‘TABLE~’ (if SAP source release is above 4.0A) (on AS/400 the name is “TABLE?”) “003” : ‘TABLE’ (if table is new in the system)

Action Original name Shadow name Value BUILDCONV

New table none TABLE 003

Table Exists (< 4.0A) TABLE TABLE___4G 001

Table Exists (> 4.0A) TABLE TABLE~ 002

Figure 8.37: Different phases for both “System Switch” scenarios.©Copyright SAP AG.

The sequence of phases that are run by SAPup depends on the selected downtime scenario. In case the downtime minimized scenario is selected, the activation of tables is done by the shadow instances. In Figure 8.37 we see on the left the normal SAP instance and at the left the shadow instance. The arrow indicates the move of the activation phase from the normal instance to the shadow instance, depending on the chosen strategy.

174 UPGRADING SAP

The upgrade phases, which make use of the “shadow” instance, are: � SHD_BUILD � SHD_ACT � SHD_CNV � SHD_IMP � Subfaces � INITSHD � SHDINST_CRE � SHDINST_DB_PREP (crshdusr.sql) � SHDINST_CPY � SHDINST_ADAPT � PARDIST_SHD � PARMVNT_SHD

Figure 8.38: Incremental table conversion ICNV with “System Switch” scenario. ©Copyright SAP AG.

The ICNV phase (Incremental Table Conversion) runs at different sequences in the “System Switch” scenario compared to the old “Repository Switch” scenario.

8.28 TABIM

During the TABIM (Table Import) phase, additional data is loaded in tables that belong to the SAP name range. All SAP table classes S, W, E, C, and G are affected by row insertions, modifications, and deletions—except for class A, which is protected against row modifications, where only insertions are allowed.


During EU_IMPORT, an entire new ABAP Repository and Data Dictionary are loaded into the SAP system. Data that is new to the target release, but needs to be loaded in existing application or control tables, is loaded during phase TABIM. You can use selection data for customizing fields or additional selection documents. The TABIM phase is run though tp and R3trans. Once all data has been loaded into the system, the phase EU_SWITCH will actually switch to the new repository of the target release.

8.29 XPRA—REPORT AFTER PUT

XPRA or “Report after Put” is an ABAP program or Function Module that is executed during a transport request import sequence, the import of Support Packages, and during upgrades. An average SAP R/3 system has more than 350 XPRA reports. You can see those XPRAs if you use the ABAP Report Information System, which can be accessed through key F4 in the ABAP display screen under transaction SE38.

The reports that are executed during XPRA are application-related conversions, adjustments, data mergers, or alignments for the conversion of release-specific SAP-shipped customizing that need to be adjusted during the upgrade. The runtime of the XPRA phase for the HR (Human Resource) module is notorious during upgrades. However, XPRAs are used by all SAP modules and applications, for example:

FICON46A FI Ledger 3.x → 4.x MLXPRA46A MM line items 3.x → 4.x RXWBODVC Adjust list of software components RXDCHKDB Cleanup of DD vs. DB inconsistencies XREPAPPL Conditional inserts of storage parameter entries The table OBJM contains the link between the SAP object (table, view, or index)

and its XPRA report. The table has the following layout:


OBJECTNAME CHAR (30) Name of SAP object (e.g., T777)

OBJECTTYPE CHAR (1) Object type (see table OBJH)

METHOD CHAR (1) XPRA execution method

METHODNAME CHAR (30) Name of ABAP or Function module

UPGRADE CHAR (1) Should be run during upgrade

MULTI_OBJ CHAR (1) More than one object involved

The METHOD field can contain the following two values: “AFTER_IMP,” which means the XPRA is run after the import into the system, or “BEFORE_EXP,”

176 UPGRADING SAP

which means the XPRA is run before the export of the object. When value “X” is stored in field UPGRADE, the ABAP program or function module is run for this object during the upgrade.

The XPRA phase reports are run as one of the last steps of the upgrade. However, due to the fact that table content is adjusted, the XPRA phase needs to be done at application downtime. XPRAs can also run as part of the activation of extension sets and IS add-ons.

8.30 PREPARATION STEPS

The two most important things to do before you start the upgrade are the execution of the PREPARE tool in advance, and obtaining all relevant SAP notes on upgrading to your target release. These SAP notes contain the latest information about issues and solutions that were discovered after the upgrade tools have been shipped to customers. Each upgrade kit is delivered with a primary SAP note, which can be found in the upgrade manual. This SAP note lists all the discovered issues and also contains the password you need to start the upgrade process.

8.30.1 Saving Wage Types

In case your SAP R/3 system is used for HR (Human Resource Management) purposes, and payroll processing in particular, you have to save the wage-types table T512W upfront. Entries in the customer name range in this table might be overwritten during upgrade phase XPRA. The T512W table is copied to table T599U and T512B using ABAP report RPU12W0S with action “Save.” This action needs to be performed before the upgrade. After the upgrade, ABAP report RPU12W0S with action “Restore” or ABAP report RPU12W0C can be used to copy all saved entries back to table T512W.

INFO More information about this subject and other HR-specific upgrade information can be found at http://service.sap.com/erp-hcm and for saving wage types please have a look at SAP Note 495789.

8.30.2 Extension of Database Size

Depending on your SAP target release, you have to create tablespaces, which will contain all-new target repository objects. Besides these new tablespaces, you also have to increase the size of existing tablespaces. The SAP target release system always requires more database space than the current release (for example, the SAP R/3 4.72 target release).


Oracle

PSAPBTABD 30MB PSAPBTABI 40MB

PSAPES620D 400MB PSAPES620I 200MB

PSAPPOOLD 50MB PSAPPOOLI 50MB

PSAPSTABD 80MB PSAPSTABI 100MB

PSAPEL620D 200MB PSAPEL620I 100MB

Informix

PSAPBTAB 70MB PSAPES620 800MB

PSAPPOOL 100MB PSAPSTAB 200MB

DB/2 UDB

PSAPBTABD 40MB PSAPBTABI 50MB

PSAPES620D 500MB PSAPES620I 400MB

PSAPPOOLD 60MB PSAPPOOLI 60MB

PSAPSTABD 90MB PSAPSTABI 130MB

For Non-tablespace-oriented RDBMS systems, the following values are applicable:

RDBMS Space added

Microsoft SQL Server 800MB

IBM DB/2 for iSeries 800MB

SAPDB (MaxDB) 160000 pages

New tablespaces for Oracle in case you upgrade from SAP R/3 4.6C to ECC 6.0:

Tablespace Create Size (MB)

PSAPES700D 6000

PSAPES700I 6000

PSAPEL700D 5000

PSAPEL700I 5000

Please check the appropriate SAP Notes that are mentioned in the Upgrade Guide for the exact sizes.

8.30.3 Reuse of Variants

Variants contain values and parameters, which are entered in the selection screen for certain ABAP programs and reports. Due to the fact that the layout of such reports might be different between the various SAP releases, it’s possible that

178 UPGRADING SAP

you have to re-create variants after the upgrade. However, it is still possible to reuse working variants created in the source release in the target release after the upgrade has finished. SAP delivers several ABAP reports, named RASUVAR1 and RASUVAR2, to save variants before the upgrade and restore them afterward. More information on this subject can be found in SAP Note 712297.

8.30.4 Upgrade Breakpoints

Sometimes you need to interrupt the upgrade process in order to execute a specific task, such as the import of an additional transport request. To interrupt the upgrade process, you can set “breakpoints” for SAPup. There are two ways for setting these breakpoints: (1) using the SAPup command-line option and (2) creation of a file called “R3UPPHAS.BRK.” The exact syntax for option (1) is: SAPup stop <phase>, where <phase> is the name of the phase where SAPup stops, for example, $ SAPup stop ACT_620. The second option uses the specification of the phase name in a file called “R3UPPHAS.BRK,” which should be located in “/usr/sap/put/bin.”

INFO More information on breakpoints in upgrades can be found in SAP Note 48184.

8.31 POST STEPS

After SAPup is finished, there are still tasks related to the upgrade to fulfill. These tasks are known as “Post Steps.”

8.31.1 Generate ABAP Load

An important poststep after the upgrade is the regeneration process for the new ABAP Repository. During this process, all ABAP programs and screens that were loaded into the system during the EU_IMPORT phase and switched on at the EU_SWITCH phase are being compiled from source code into executable byte code. The advantage of this post-upgrade process is performance enhancement after go-live. If this step is skipped, the ABAP programs will be compiled as soon as the first end user starts using these programs. This ABAP generation process is described in more detail in Chapter 4. During the generation of an ABAP program, certain tables (such as D010SINF) are exclusively locked, which has big consequences for the performance of the SAP system.

To ensure all ABAP programs are regenerated, SAP offers several tools. As of SAP R/3 release 3.0A an ABAP called RDDGENLD was introduced. This RDDGENLD uses the “GENERATE REPORT” statement to compile a list of programs. Since SAP R/3 release 4.6A, it has been integrated into transaction SGEN. The SGEN transaction offers several options to compile ABAP programs. A selection by R/3 module can be used or a list of ABAP programs can be provided to SGEN.


SAP keeps a list of recently used ABAP programs is an ASCII file called REPLIST on any application server. This file, residing in the SAP work directory, can be specified to SGEN. This will reduce the runtime of SGEN significantly.

SGEN uses table UPGLDGEN to keep track of all work. The number of entries in table UPGLDGEN is exactly the same as the number of entries in table TODIR (Delivery catalog), which contains information on all objects that can be compiled. The most important field in this table is STATUS, which contains the compilation status of each object. Possible values of this field are:

STATUS field value Description

‘ ‘ Not generated

‘X’ Generated

‘I’ Ignored

‘U’ Unknown compilation type

‘?’ Unknown object type

Table RSCMPTAB is used to control the behavior of report RSGENER8, which is used by SGEN.

For upgrades to target release 7.0, transaction SGEN is slightly modified. SGEN uses ABAP report RSPARAGENLOD to generate all reports in batch. Table GENSETC is just to keep track of all activities, and via the batch-job RSPARAGENER8, various smaller jobs with the name RSPARAGENJOB, are executed. The actual generation of all ABAP sources is done via the function module SUBST_GENER8_ABAP_LOADS, which subsequently, are called the ABAP statement “GENERATE REPORT”.

INFO More information on transaction SGEN and report RDDGENLD can be found in SAP Notes 379918, 312947, and 406974.

8.31.2 Generate ABAP Query Reports (R/3 4.0B)

When you upgrade an SAP R/3 from a source release below 4.0A you have to perform a ABAP Query Report conversion after the upgrade. As of release 4.0B, the namespace of ABAP Query Reports have changed. This conversion is not performed as a step during the XPRA phase and needs to be done manually. SAP ships two reports to support the conversion: RSAQSUMM and RSAQUM40. Additional documentation on this conversion can be found in SAP Note 92124. However, this action is only applicable for upgrades with source release 3.1I or below and target release 4.0B.

NOTE This section is only applicable for SAP upgrades to target release 4.0B.

180 UPGRADING SAP

8.31.3 Solve P Errors in LONGPOST.LOG

After the upgrade is finished, the SAP system can be made available for productive usage again. Before the technical upgrade is finished, the engineer should pay attention to the file LONGPOST.LOG, which is created in phase CHK_POST. This LONGPOST.LOG contains so-called P-Errors, which are not “show stoppers” to the upgrade and can therefore be solved after the upgrade. Errors that might end up in this file are XPRA errors for certain table entries or issues about conversions or compilations of less-important objects. If an XPRA fails to run it might stop with an “E” (severe) error or continues to run and log a “P” (less severe) error.

Although these errors are not seen as “show stoppers” for a productive usage of your SAP system after the upgrade, they still need to be solved after the upgrade. It is recommended to document the issues and their solutions in the upgrade runbook.

8.31.4 Adjust Authorizations

When SAP transactions are executed, certain Authorization Objects are checked for the proper authorization. In order for these checks to be executed successfully, the user must have the appropriate authorizations. This results in some users having more authorization than they really need. It also leads to an increased maintenance workload.

If the Profile Generator is being used, the amount of work to do the authorization checks (transaction SU24) is reduced significantly. The Profile Generator generates a profile with authorizations associated to an activity. The generated profiles are not always complete, especially in older releases of the Profile Generator. This means that individual authorizations that are not contained in the profiles need to be added manually. This is mainly the case with programs that call other programs, where the subprogram requires additional authorizations. To simplify such administrative tasks using the Profile Generator, the following steps need to be done:

1. Set the profile parameter auth/no_check_in_some_cases to the value Y. 2. Execute transaction SU25. The transaction “Profile Generator—Upgrade and First Installation” (SU25)

copies the proposals for check indicators and authorization field values delivered by SAP to the customer tables, which you can then change.

Now you can use the role maintenance functions and the Profile Generator to manage the authorization information for your users.

NOTE As of SAP NetWeaver 7.0 BI (BI 7.0) a new authorization concept was implemented. Therefore, the old BW 3.5 concept is no longer supported by SAP. This means a migration to the new concept is required. Such migration is done by activating the new concept in IMG and migrating objects using ABAP report RSEC_MIGRATION. Information can be found in SAP Notes 820183 and 923176.


8.31.5 Removal of “Obsolete” Tablespaces

The new target repository is loaded into tablespaces that are created just before the upgrade. After the repository switch has taken place, the old repository has become obsolete and therefore the tablespaces, which contain these obsolete repositories, can be deleted from the Sap database. The tablespaces you can delete do follow a name range, which contains the source release:

PSAPES31ID - Repository Source Code Data of SAP R/3 3.1I PSAPES31II - Repository Source Code Index of SAP R/3 3.1I PSAPEL31ID - Repository Object Code Data of SAP R/3 3.1I PSAPEL31II - Repository Object Code Index of SAP R/3 3.1I PSAPES40BD - Repository Source Code Data of SAP R/3 4.0B PSAPES40BI - Repository Source Code Index of SAP R/3 4.0B PSAPEL40BD - Repository Object Code Data of SAP R/3 4.0B PSAPEL40BI - Repository Object Code Index of SAP R/3 4.0B Although the deletion of tablespaces is relatively easy, it’s very important

to know which tablespaces need to be deleted from the database. If the wrong ones are removed, the missing data needs to be restored from a backup. There are two ways of performing the removal of tablespaces: using SAPDBA or through a command-line interface, such as SQLPLUS:

SQL> drop tablespace PSAPEL40BD; SQL> drop tablespace PSAPEL40BD including contents and datafiles; (as of Oracle 9i)

INFO On some operating systems, you need to remove the datafiles yourself using UNIX or Windows NT commands. The deletion of obsolete tablespaces is only applicable for SAP systems that make use of certain “tablespace”-oriented RDBMSs.

8.31.6 New General Ledger

Along with the introduction of SAP ERP 2005, a new ledger was introduced. The new general ledger (NewGL) encompasses some of the most important and exciting new functionality to become available in the SAP ERP Financials application in recent years. Where traditional general ledger solutions have required the reconciliation of multiple applications, SAP ERP Financials now provides a unified structure that includes individual ledgers, such as the cost of sales ledger, profit center accounting, and the consolidation staging ledger. As a result, it speeds reconciliation, ensures transparency and auditability, and enables customers to meet both internal and external reporting requirements, such as US-GAAP, IRFS, SoX, and Basell-II. The implementation of the new G/L is a project that should not be underestimated. Therefore, the technical migration of data from the classic general ledger to the new general ledger is a central part of such a project. Depending on each customer’s individual scenario, this migration could

182 UPGRADING SAP

mean a significant change to the live database, which must be safeguarded to ensure that historical data is kept intact. For this reason, SAP will help with your migration with a service to address the technical aspects of such a project and help guide you through the migration process.

INFO Additional information about the NewGL and the migration process and service can be found at http://service.sap.com/GL.

8.31.7 Install Optional SAP J2EE Engine

When you’re upgrading an SAP component to a release that uses the SAP Web Application Server as its base technology, you may have the option to install the “new” SAP J2EE engine. This SAP J2EE engine is, next to the ABAP engine, the second runtime engine in the SAP Web Application Server. However, it is only used by certain middleware and components. If your SAP application does not need such an SAP J2EE engine, there is no real need to install this product. The SAP J2EE engine, also known as Usage Type AS Java, can be installed using SAPinst. This Java add-in installation is done through the following SAPinst path: “Additional Lifecycle Tasks Java Add-In for ABAP Database Central System / Distributed System / High Availability System.

If you install a Java Add-In to an existing ABAP-only system, you can also install further Java usage types or Java software units, for example, EP, BI Java, MI, DI, or JCRM.

INFO More information about the optional installation of the SAP J2EE engine after an upgrade can be found in SAP Note 883948.

8.31.8 Reset the Upgrade

There are many reasons why a running upgrade needs to be stopped and reversed. One of the reasons might be an issue with the database or with the upgrade directory “/usr/sap/put.” The upgrade directory and the status of the database must match. This is a prerequisite for many upgrade phases that are dependent on successful completion of the previous phase. Therefore, certain phases can only be skipped after entering a key word. In cases of a restart of PREPARE from the beginning, it’s best to start with an empty upgrade directory.

INFO Additional information about the resetting of upgrades can be found in SAP Notes 417670, 158358, and 539903.


8.31.9 Maintain Shadow Instance

During the upgrade process it can happen that you get stuck with the Shadow Instance, which is used to implement the “System Switch” method. The following statement might be of help to control the Shadow Instance.

Start / Stop Shadow Instance

/usr/sap/put/bin/SAPup startshd

/usr/sap/put/bin/SAPup stopshd

Lock / Unlock Shadow Instance

/usr/sap/put/bin/SAPup lockshd

/usr/sap/put/bin/SAPup unlockshd

Influence DDIC password of Shadow Instance

/usr/sap/put/bin/SAPup set ddicpwd

/usr/sap/put/bin/SAPup set shdddicpwd

It’s possible to run the Shadow Instance on another server and on another platform. This means that if your SAP system runs on IBM pSeries machines with AIX as the operating system, you would be able to run a Shadow Instance on a Microsoft Windows server based on Intel Xeon processors. More information on how to implement such a hybrid scenario can be found in SAP Note 430992—Shadow Instance on another Windows host.

INFO Additional information on the SAP Upgrade Shadow Instance can be found in SAP Note 398100—Shadow Instance during upgrade.

8.31.10 Upgrade Elapse Time

There are two locations where you’ll find the elapse time of the upgrade process. Depending on the target release of the upgrade, it can be found at:

Upgrade Target Release Method of finding the information

Up to NetWeaver 2004 Run ABAP report RSUPGSUM

NetWeaver 2004S and higher Look at file upana.htm

The total elapse time is influenced by jobs and phases with long runtimes. The following phases are known to take a long time for completion. The exact runtime is dependant on many factors.

184 UPGRADING SAP

Phase Description

CNV_LIST This phase is used to calculate the estimated conversion time of candidate tables. Job name is RSUPGTAB with ABAP report RSUPGTAS and function module GET_TABLE_SIZE_<dbs>.

DYNSPCADD This phase checks whether there is enough space available in the database to hold all new tables, rows, and indexes. The file TRMAIMP.SPC contains all needed space.

RUN_RDDIT006_PRE This phase collects all the information on objects that have been changed in the SAP system.

DIFFEXPCUST This phase exports all customer objects to preserve it.

DIFFEXPDOCU This phase exports all customer documentation to preserve it.

ACT_<REL> This phase will activate all-new Data Dictionary objects (tables, indexes, data, elements etc.). During this phase the user will be prompted.

PARDIST_SHD This phase which runs in the Shadow Instance, takes care of the data conversion.

SHADOW_IMPORT_ALL This phase imports the new repository into the database using the Shadow Instance.

TABIM_UPG Additional table data is loaded into the system.

ADOIM_UPG Additional ADO objects are loaded into the system.

XPRAS_UPG This phase runs the XPRA reports.

8.32 CBU (CUSTOMER-BASED UPGRADE)

To reduce downtime on productive SAP systems, SAP offers the Customer-Based Upgrade. One of the main causes of downtime during an upgrade is “modification” to the SAP standard system and custom-developed objects. If the number of modification is large, you might consider making use of this service from SAP.

In practice, a copy of your productive SAP system is made up front and analyzed by the Upgrade Competency Center. As a result, a pre-packed, customer-specific, upgrade kit is created and will be used to apply the productive SAP instance.

The CBU process consists of the following steps (example upgrade R/3 4.0B → 4.7):


Figure 8.39: The “Customer-Based Upgrade” process. ©Copyright SAP AG.

(1) First a copy is taken from the productive SAP system. (2) This copy is used as the source system for the first upgrade to the target release,

using the ordinary SAP upgrade toolkit. (3) The new upgraded SAP system is used to create the “Customer-Based

Upgrade” toolkit. (4) Another copy of the productive SAP system is taken. (5) A second “dry-run” upgrade is performed to see whether the CBU toolkit

works. (6) Finally, the productive SAP system is upgraded to the target release using the

CBU toolkit.

INFO More information on CBU can be obtained through the SAP Service Marketplace at http://service.sap.com/upgrade.

186 UPGRADING SAP

Chapter 9UNICODE CONVERSION

Unicode is, like ASCII or EBCDIC, a character set that is used to represent numbers by characters. Everyone who works with computers probably knows that the character “A” is noted as the number 65 in the ASCII scheme.

This schema uses 127 bits to store the entire table. The IBM PC and compatible computers use an extended ASCII table that is based on 256 bits instead of the default 128 bits. However, even this is not enough to represent all characters used worldwide. The ASCII and extended ASCII schemas work only on computers with western languages. The Cyrillic, Japanese, Thai, Indian, and Chinese characters cannot be presented using the ASCII scheme. An SAP database on Oracle 9i uses the WE8DEC character set, which is based on ASCII. This character set, or encoding mechanism (also known as code page), provides the ability to store different types of characters in the database, such as Chinese, Japanese, and Thais. However, the application remains responsible for the encoding of the characters to numbers. This hampers the ability to exchange information between applications. It’s also more complex to run different nonwestern languages in one system. SAP has developed several mechanisms to solve this issue, such as MDMP (Multi Display Multi Processing) and Blended Code Pages; however, none of these techniques is really sustainable.

The solution for this issue in known as Unicode, which was developed by a few interest groups bundled as Unicode.org and without the help of the United Nations. Unicode is a character-encoding schema containing (almost) all characters used worldwide. An application that uses the Unicode character schema is able to

187

188 UPGRADING SAP

represent all languages and its characters. It’s for this reason SAP has decided to support Unicode as of SAP Web Application Server 6.10. For SAP R/3, the support of Unicode is as of Enterprise 4.7. An SAP R/3 system that has been upgraded to Enterprise 4.7 is only Unicode enabled, which means that the SAP system is based on the non-Unicode code page, but enabled to be migrated to Unicode. In order to make use of Unicode, the database needs to be converted to Unicode first.

9.1 CONVERSION PROCESS

Assume the following upgrade scenario: SAP R/3 4.6C on Oracle 9i with WE8DEC character set. After the upgrade it is running SAP R/3 4.7 Enterprise and Oracle 9i. The character set, however, is still based on WE8DEC. This because at the time of the installation and creation of the database, the create statement was as follows:

SQL> CREATE DATABASE “P01” ……………

………………………

………………………

CHARACTER SET WE8DEC;

Once the database is created with a certain character set, it cannot be reversed or changed. It’s for this reason we’re not able to convert the database into another character set, such as Unicode (Oracle UTF-8 or UTF-16) online. In order to get the database in Unicode format, the following steps need to be done:

(1) Run preprocessing steps: transaction SPUMG (2) Unload all data from database “P01” to flat files (3) Drop database “P01” (4) Create new database “P01” as:

SQL> CREATE DATABASE “P01” ………….. ……………………

……………………

CHARACTER SET UTF8;

(5) Import all data from flat files into new database “P01” (6) Install Unicode Support SAP Kernel executables (7) Run postprocessing steps

UNICODE CONVERSION 189

Figure 9.1: Basic steps for Unicode conversion.

9.2 UNICODE PREPARATION

The Unicode conversion is performed using various tools. The preprocessing is performed from within SAP using transaction SPUMG. This transaction contains several steps, such as “initializing the worklist,” “initializing the language set,” “consistency check,” and “inconsistency correction.” It also contains the preparation of pooled table conversions.

With the SPUMG tool, all texts are checked against Unicode requirements. This means that all text elements, regardless of the languages that are stored in the database, need to be as such that they can be converted to Unicode. The elapse time of this job is dependent on the amount of data to be checked and, of course, the number of installed languages. For an SAP system based on a single code page the preparation process is rather straightforward, but it becomes complex once it involves an MDMP system. MDMP-based SAP systems have a mix of nonwestern languages installed and this might lead to ambiguous characters in cases where text is stored without a language key. For example, the following hexa-decimal string 0xE2D5DAE1E2 might have different meaning in different languages. If the language key is not specified in the SAP text element, the Unicode conversion will fail.

The ambiguous character conflicts need to be sorted out before the database migration is started, by building and labeling a vocabulary.

190 UPGRADING SAP

Figure 9.2: MDMP installed languages. ©Copyright SAP AG.

The SPUMG tool creates a language list during the preparation, which is taken from the list of (active) installed languages. This list will be used to solve conflicts between the encoded value and the associated semantic.

From within the SPUMG tool, it is possible to create the vocabulary table, which can be used at a later stage in other systems as well (e.g., Sandbox Production). The vocabulary will contain a list of words that do not have language keys. However, before the Unicode migration can start, all these words need to be specified with a language key.

Figure 9.3: SPUMG steps during preparation phase.


The Conversion Control table is created during the step 1 of SPUMG and used as input for the System Vocabulary that is created in SPUMG steps 2, 3, and 4. In the case of failures, all four steps need to be repeated (reprocessed).

The status of the SPUMG preparation can be monitored using SPUMG → Extras → Monitor and provides the ability to follow each individual step. It also provides an overview of all sub-activities that are processed, such as the INDX tables. These INDX tables are used by, for example, the HR (Human Resource) module. These tables need special treatment during the scanning phase.

Once the SPUMG scanning is finished and the vocabulary is created, it’s time to go through the repair log. This repair log will contain all texts that do not have a language key. In a non-Unicode system it not required to have a language key specified for texts. However, it’s required for the Unicode system. Therefore, the conflicts listed in the repair log need to be fixed. The conflict resolution is just the process of going through each word or text and trying to recognize what the word means and what the language is. Once it’s recognized, the correct language key should be attached. This requires, of course, the proper knowledge of all installed languages. Having the right language interpreters in your project team is key.

Report UMG_VOCABULARY_STATISTIC lists tables and number of entries for all words without a specified language key. This might help to determine the elapse time of the conflict resolution process.

TIP Look at the contents of table TCPDB to see what code pages are in your SAP system. More information can be found in SAP Note 42305.

With hints, it’s possible to tell the SPUMG tool to search and replace all rows in a specific table with the right language key. For example, for all names Jörgen Schremp, label the text as being German. It’s possible to add such hints to all tables.

Figure 9.4: Structure of an INDX table. ©Copyright SAP AG.

192 UPGRADING SAP

INDX tables need special treatment because although they are transparent tables, they contain binary data that might consist of text. This binary data is loaded in and out of the INDX tables through the ABAP statement EXPORT TO DATABASE / IMPORT FROM DATABASE. Especially in MDMP systems, it might occur that the data in incorrectly coded and stored in the database.

An INDX table consists of two parts: a Transparent part, which can be viewed using a regular SQL select statement; and a Binary part, which contains data that cannot be viewed directly. The scanning process for ambiguous characters in INDX is similar to the other tables; however, it is a separate step in transaction SPUMG.

Once the SPUMG scanning process is finished, the final Unicode nametab can be created. This nametab is only consistent as long as no new DDIC objects are created or imported in the system. Therefore the creation of new DDIC objects should be avoided.

9.3 DATABASE CONVERSION

After the preprocessing steps, the entire database is downloaded to flat files using R3load. This process is executed using SAPinst and is similar to an OS/DB Migration, except neither the OS nor DB changes. This process is exactly the same as what has been described in section 7.7.1, an earlier chapter on OS/DB migration.

After the database is converted into the new Unicode format, it can happen that certain texts are not correct. This corruption might happen, especially on MDMP source systems. This problem is relatively easy to fix using transaction SUMG.

The elapse time of the database conversion is dependent of the size of the database and the hardware available to perform the conversion. In general, the R3load tool is able to process 100–200GB/h, although values of 300GB/h are measured. It’s possible to create parallel R3load sessions, where two R3load processes can be configured per available physical CPU in the system. The DISTMON (Distributed Monitor) can be used to decrease the downtime even more. This tool provides the ability to import the database at the same time it is exported. This requires, of course, two databases that are running simultaneously, one on each server. A second accelerator is the FastLoad option that is offered by the Oracle database. Information about this can be found in SAP Note 864861.

9.4 UNICODE SYSTEM REQUIREMENTS

The expected hardware requirements to run a Unicode SAP system are as follows: there will be an increase of CPU requirements for 30% of the system, which are


converted from an ISO-Latin character set to Unicode. For systems that run an MDMP Double Byte database, the increase is minor. Memory requirements are increased 15–25% due to “internal” UTF-16 usage of SAP application servers.

Encoding Vendors Add. Storage Req‘s

CESU-8UTF-8

Oracle, SAPDB (8.0)DB/2 for AIX and Win32

10–20%

UTF-16 SQLServer, SAPDB (7.0)DB/2 for AS/400

60-70%

Databases that use the UTF-16 encoding occupy significantly more storage than UTF-8-based databases. This is caused by the 8-bit versus 16-bit storage scheme. The 16-bit UTF-16 can be stored in memory and disks in two ways: Little- and Big-Endian. In UTF-16 each character is stored in 2-bit units by default, where in UTF-8 characters are stored by one or more 1-byte units. In case your SAP database consists primarily of western-language-oriented characters and is based on UTF-8 rather than UTF-16, it saves storage because the characters can be stored in 1-byte only.

After the import of the data into the “new” database, it’s far easier to load additional languages into the system, which are based on non-western characters.

9.5 UNICODE KERNEL

Once the database is reloaded with the new Unicode data, the SAP system can be started, but only after the SAP kernel has been replaced with the Unicode-specific version. As of the introduction of Unicode, SAP supports two different kernels. Although they look the same from the outside, they are different from the inside. Trying to use a non-Unicode kernel on a Unicode SAP database will lead to unexpected errors.

The kernel replacement is done as part of the Unicode conversion process handled by SAPinst. The SAPinst tool just needs to know the location of the new Unicode kernel.

9.6 COMBINED UPGRADE AND UNICODE CONVERSION

Upgrading SAP R/3 4.6C systems based on MDMP to SAP ERP 6.0 is an extra challenge, because MDMP is not supported on SAP ERP 6.0. This means that an upgrade and Unicode migration need to be combined into one project and one downtime window. This single (large) downtime window is called CU&UC or Combined Upgrade and Unicode Conversion.

194 UPGRADING SAP

Figure 9.5: CU&UC (Combined Upgrade and Unicode Conversion). ©Copyright SAP AG.

The CU&UC are two different processes that should be seen as separate things. The upgrade process is exactly the same as any other SAP release upgrade. The Unicode conversion is exactly the same as any other Unicode conversion. The only difference is the fact that it’s not supported (allowed) to go live with the SAP system at release ECC 6.0 with MDMP. So right after the upgrade is successfully finished, the Unicode conversion process has to start. After this has finished successfully, the CU&UC process is done.

There is one major difference between the normal and the UC&CU process: the SPUMG tool that is available in SAP R/3 4.6C to do the conflict scanning upfront. The SPUMG tool is only available in SAP R/3 Enterprise 4.7 or higher, which means it’s not available in 4.6C. Therefore, SAP has released a down-ported version of SPUMG for 4.6C, called SPUM4. The SPUM4 tool is loaded into the 4.6C system during the prepare phase of the upgrade process. Only once the PREPARE phase has started is the SPUM4 tool available for text conflict scanning.

The UC&CU process is designed to reduce the total downtime of the sum of both Upgrade and Unicode conversion. This is achieved by bringing the SPUM4 process in front of the upgrade. The UCCHECK process can only be done up front, however, this requires a standalone system on the correct release (SAP Web AS 6.20 or higher).

Figure 9.6 illustrates the sequence of events of the CU&UC process. At the left the CU part is shown, which consists of the prepare phase and the upgrade itself. During the prepare phase, the SPUM4 tool is imported and as of that moment SPUM4 activities can be executed to scan for text conflicts.

The UCCHECK tool helps to check whether ABAP programs are Unicode compliant, but it’s only available in SAP release 6.10 or higher. Therefore, the tool cannot be used in an SAP R/3 4.6C system, so any ABAP programs that need to be checked should be transported to a system that does have the UCCHECK tool


included. Once the programs are checked and fixed they can be imported back again as part of the upgrade. The transports cannot go back into the 4.6C system because 4.6C does not support all Unicode-specific ABAP statements.

Figure 9.6 Schematic overview of CU&UC process.

At the right of the figure the Unicode Conversion process is shown. After the conversion the entire sequence of events is finished by the SUMG activities.

TIP In case both SAP ERP and BI systems need to be migrated to Unicode, it is recommended to migrate the SAP BI first. The load of data from a non-Unicode SAP system into a Unicode SAP BI system is a supported solution.

NOTE For more information of the procedure, please check SAP Note 548016 and the “SAP Unicode Conversion Guide,” both of which can be found under http://service.sap.com/unicode.

196 UPGRADING SAP

Chapter 10UPGRADE PROJECT MANAGEMENT

The SAP system upgrade is a complex project and should be managed as such. Therefore, the project manager should be experienced in managing complex ICT or Business Affecting projects. The SAP upgrade requires a project team,

which includes staff with several skill sets and different backgrounds.

Figure 10.1: Different skills are required during an SAP Upgrade project.

To successfully complete an SAP upgrade, there are several methodologies available to the project team to achieve this goal. The two most common

197

198 UPGRADING SAP

methodologies are “ASAP for Upgrade,” which is developed by SAP, and “DSDM for SAP,” which is primarily designed for implementation projects, but also can be used for upgrade projects.

For the implementations of the SAP business processes and infrastructure, SAP has released their own adjusted copy of the TOGAF methodology from the OpenGroup. This methodology, known as the SAP Enterprise Architecture Framework (SAP EAF), is published to support companies building an Enterprise Architecture. A complete set of template documents has been released that can help in making choices about infrastructure, application selection, business processes, tools, and interfaces.

10.1 ASAP FOR UPGRADE

The “ASAP for Upgrade” is a special edition of SAP’s project management and implementation methodology “AcceleratedSAP” (“ASAP”).

Figure 10.2: Accelerated SAP phases. ©Copyright SAP AG.

It is shipped as part of the upgrade kit on a separate DVD. This DVD contains a large amount of HTML or CHM (Compressed HTML) files that are linked to each other through hyperlinks. The documentation on HTML is based on the same five phases as the regular ASAP model:

UPGRAGE PROJECT MANAGEMENT 199

ASAP for Upgrade ASAP for Implementation

(1) Project Preparation (1) Project Preparation

(2) Business Blueprint (2) Business Blueprint

(3) Realization of DEV and QAS (3) Realization

(4) Realization of Production (4) Final Preparation

(5) Go-Live and Support (5) Go-Live and Support

The five ASAP for Upgrade phases: (1) Project Preparation. This is the first phase of ASAP, which is used to

collect all resources required during the project: staff, equipment, budget, procedures, documentation, and overall project planning.

(2) Business Blueprint. This second phase is used to analyze the SAP system and prepare it for the upgrade. All business processes are analyzed is such a way that they can be prepared for the new functionality of the new SAP release. Therefore, both the new functionality of the SAP target release and current release are analyzed. This phase also includes the analysis of all customer-created modifications to the SAP system and the effects of the new release on the end user training materials.

(3) Realization of DEV and QAS. This phase is used to physically upgrade the entire SAP system landscape, except for the production system. It includes all technical work required to upgrade all software products, including SAPGUI on PCs. This phase is also used to create the upgrade runbook and scripts.

(4) Realization of Production. This phase is similar to phase 3, except for the fact that it is applicable to the productive SAP system. The runbook documentation that is used during this phase is written during phase 3.

(5) Go-Live and Support. This phase includes all steps that are involved to run and maintain the SAP system during productive use.

The ASAP toolkit is also available in the SAP Solution Manager. The toolkit is part of the “Implementation” module.

10.2 DSDM FOR SAP

Dynamic Systems Development Method, or DSDM for short, is a procedure model for software development. The model was developed in 1995 by the DSDM Consortium and is based on industry “best practices.” The core of the DSDM method is based on three principles: RAD (Rapid Application Development), Timeboxing, and Prototyping.

� RAD (Rapid Application Development) is a software development methodology that was introduced by James Martin in the early nineties as

200 UPGRADING SAP

a fast development method for software development projects. A lot of 4GL Case tools on the market are based on RAD.

� Time boxing is a project management technique where the project is divided by time frames rather than project milestones. A project is divided into, let’s say, four months, and each phase consists of all objectives of that particular month.

� Prototyping is a software development technique where software is created among prototypes. A program specification or definition is built around a prototype and the prototype is used as basis for the rest of the software development process.

In contrast to ASAP, which is “waterfall”-based, DSDM works in small development units that are added to the prototype. The development process itself is iterative, which means that the same development loop is repeated several times, each with a more precise result. The DSDM method consists of five “individual” phases:

� Phase A: “The feasibility study,” which is used to determine whether the DSDM method is the best method for this project.

� Phase B: “The business study,” which is to create a global business model or definition. This definition will be used as a blueprint for the SAP implementation.

� Phase C: “Function model iteration” is the first prototyping phase focused on determining the business and user requirements. This phase can be repeated several times and will result in two things: a functionality demonstrations and more detailed requirements.

Figure 10.3: DSDM method with five phases.


� Phase D: “System design and System build iteration” is the phase that will eventually deliver the system. This phase can be started parallel to phase C and can be repeated several times in order to get the best result.

� Phase E: The “Implementation” phase is used to give the system to the end user community. This phase will include training, further documentation, support and maintenance, and software life cycle management.

More information on DSDM and SAP R/3 can be found in the book Dynamic Implementation of SAP R/3 by Marcus Geiss and Roland Soltysiak (ISBN 0-201-67483-1).

10.3 PROJECT IMG FOR UPGRADE

The IMG (Implementation Management Guide) is a toolset that helps a project team with the implementation of an SAP system. For each business process, the IMG explains all required steps in the implementation process and tells the SAP standard setting for this process. It is set up around SAP modules and submodules and organized in a tree structure. Usually, the IMG is used during the implementation of SAP within a company. However, it can also be used as a tool for upgrade projects. The IMG, which is accessible through transaction SPRO, consists of a large “SAP Reference IMG” that covers all SAP modules. Normally, this list is reduced to the “Project IMG,” which only includes the modules that are part of the implementation project. The “Project IMG” is created through a “view.” This particular view only contains those modules, and thus buttons to the customizing settings for these modules, which are part of the project scope. The same list, however, can also be used during the upgrade project.

Figure 10.4: SAP Implementation Guide structure: three variants.

A “Project View IMG” provides the ability to create “Project Documentation” and provides access to the relevant customizing transactions. These customizing transactions are usually organized per SAP module, country, or any other project division method.

202 UPGRADING SAP

There are two customizing groups relevant to SAP release upgrades that can be used to organize the SAP release upgrade-specific IMG:

� Upgrade Customizing – which comprises the IMG activities and documentation that is necessary to allow functions to continue that were in use in the previous SAP release.

� Delta Customizing – is the SAP release-specific customizing that allows the enabling of new functionality.

TIP For each upgrade project in the SAP system, you can create an exclusive release-specific Implementation Guide, which will not be overwritten by the next release upgrade. For example, one for the upgrades from 4.0B to 4.6C and one for 4.6C to 4.72.

10.4 PROJECT ORGANIZATION AND ROLES

The success of the upgrade project depends heavily on the project people and the way the project is organized. Let’s have a closer look at how a project can be organized to facilitate the SAP upgrade process.

In most companies, projects are sponsored by a steering committee and lead by one or more project managers or leaders. The project itself might follow a matrix organization structure, where multiple smaller teams are working together.

Figure 10.5: Organization of Upgrade project team.

The project team is organized by smaller teams with experts. All technical work is done in the “Basis and Infrastructure” team. All ABAP programming


work, which includes all reporting, screens, and interfaces, is grouped in a separate dedicated team. All security and compliance-related work is also performed from within a single team. The reason for this is simple: accountability and ownership.

All functional work is grouped in several smaller teams. These teams might be organized by SAP module or business process. The reason for this is related to the size of modules—you need to have both business-specific and SAP module skills. All testing work is spread across the various groups, although you might consider moving it to a dedicated team as well.

The number of people in the project team depends on a number of factors: the usage of the SAP application in the company, the number of modules, the number of locations and countries involved, and, of course, the number of components. A project team might look like this:

Position Number of people

Project Management 1

Project Office 1

Basis and Infrastructure 2

ABAP and Interfaces5 3

Functional/Process Configuration 2 per module

Security 2

10.5 BUSINESS CASE

Trying to calculate financial benefits for an SAP release upgrade is not easy. The upgrade project costs should therefore be seen as “regular” maintenance costs or support costs. However, a correct and accurate budget and costs calculation is rather important. It basically prepares the organization for costs in order to keep the SAP system up and running over a longer period of time. Several metrics are out there to support a Business Case from a financial perspective. The most popular metrics are:

� NCF (Net Cash Flow) – The Net Cash Flow method collects all the expenditures and benefits of a project and orders them per year. When the total spent and income is positive over a certain period of time, the project has a positive return.

5 The activities are often grouped and called RICEF (Reports, Interfaces, Conversions, Enhancements, and Forms).

204 UPGRADING SAP

Figure 10.6: Example sheet with NCF.

� CCF (Cumulative Cash Flow) – This method is based on NCF, but cumulates all values over different years.

Figure 10.7: Example sheet of CCF.

� PBT (Payback Time) – The payback time uses the CFF method to collect all earnings and spend, but uses a separate column to calculate the payback time. This payback time (value) tells exactly what the investment costs and benefits are. It should only be used when you expect that the investment will pay for itself.

Figure 10.8: Example sheet with Payback Time.


� ROI (Return On Investment) – The ROI value is the ratio between the investment and the expected earnings from the project. However, the formula to calculate the ROI is much easier than a correct interpretation of the value.

ROI = Gains Costs

Costs−

� NPV (Net Present Value) – This method is used most often in Business Case analysis. It takes the current and future value of money into account. It answers the question of whether it is better to put the money in the bank rather than invest it in your project.

NPV = 1 22

FV FV+ + ...

1 + DR (1 + DR)

⎛ ⎞⎜ ⎟⎜ ⎟⎝ ⎠

– Investment

A complete function to calculate NPV is available in Microsoft Excel as NPV(DR,Benefit).

� IRR (Internal Rate of Return) – Similar to NPV, the IRR represents a metric to calculate the future value of money. The IRR metric uses a recursive calculation and it is also available as a function in Excel: IRR (v1, v1, guess).

Most of these financial metrics are based on inflows (revenue and income) and outflows (costs and investments). In our situation we have to deal with (expected) cost reduction, expected additional earnings, and investments. The expected future earnings and cost savings are very hard to predict, however, in a world where IT spending is coming under serious pressure, it is an absolute requirement to calculate this.

Figure 10.9: From business requirements to a project.

206 UPGRADING SAP

10.6 BUDGET PLANNING AND COST CALCULATION

Planning the project and its budget is an important job for the project manager. The project cost-calculation upfront can be done in two different ways:

� Through available resources � Required resources � Bottom-up approach � Top-down approach The first method just assumes that if there are 4 FTEs (Full-Time Equivalent)

available to the project and that they will be used and the cost calculation is based on that. The second method is based on resource requirement planning. This requires a more in-depth planning of activities during the project. Each project step should be translated in staff resource requirements multiplied by time multiplied by staff rating.

The calculation can be approached from two different angles: top-down or bottom-up. In the top-down approach you calculate the costs based on external benchmark figures and apply them to your own organization and project. The bottom-up approach really drills down to all elements and activities of the project and adds them up to an overall total number. Although this approach is more accurate, it does require a strict project plan and scenario upfront.

The following table contains all project costs estimated according to the bottom-up approach:

Area Subarea Units Price per unit Totals

SAP upgrade Pilot 25 days $150 $3,750

Development 15 days $150 $2,250

Production 36 days $150 $5,400

QAS Cloning 5 days $150 $750

Development Enhancements 60 days $200 $12,000

Modifications 75 days $200 $15,000

Customizing 40 days $150 $6,000

Interfaces 20 days $200 $4,000

Testing 100 days $60 $6,000

Training FI/CO 5 days $100 $500

MM/SD/PP 5 days $100 $500


Hardware Production 1 server $100,000 $100,000

Acceptance 1 server $50,000 $50,000

Development 1 server $50,000 $50,000

Pilot (rental) 1 server $10,000 $10,000

PC upgrades 150 PCs $250 $37,500

Network LAN 2 switches $1,000 $2,000

WAN 1 contract $15,000 $15,000

Software Licenses 3 contracts $50,000 $150,000

Overhead Project Management 100 days $150 $15,000

Total $485,650

This upgrade example includes the replacement of all hardware and certain elements of software and service contracts. This includes the network infrastructure and WAN contract as well. In most upgrade projects, the costs are in solving modifications and adjustments to the standard SAP coding.

In order to calculate the costs, an inventory needs to be made, such as this example:

Object Classification Modification Testing

Type Complex? # Objects Per object Total Per object Total

Transaction Low 8 2 hours 16 1 hour 50

High 3 6 hours 18 2 hours 6

ABAP Low 15 4 hours 60 1 hour 15


Interface Low 8 3 hours 24 1 hour 8


DDIC Low 2 2 hours 4 1 hour 2


Misc. Low 5 2 hours 10 1 hour 5


Sub Total 206 Sub Total 104

Total 310 hours

Although every matrix shown in this example may not be applicable to your company-specific situation, it is still very useful as a baseline or starting point.

208 UPGRADING SAP

10.7 PROJECT RUNBOOK

The “project runbook” is a document that is used during the SAP upgrade process. This document needs to be written by members of the project team and contains a chronological ordered set of steps needed to upgrade the SAP instance. The steps that need to be done can be obtained from the official SAP upgrade manual. So just take all steps from the upgrade manual and run them against the system. Write down all the decisions you make and skip all steps that are not applicable to the upgrade.

It’s recommended to create such a runbook, especially for the production instance. An option is to use the official SAP upgrade manual and mark all important and relevant sections in the guide.

Another good source of information to construct this runbook are the scripts that are delivered with the “ASAP for Upgrade” roadmap. This roadmap is available for download from the SAP Service Marketplace at http://service.sap.com/upgrade.

If a large number of SAP instances need to be upgraded, it is recommended to keep both the Upgrade Script and SAP Upgrade Manual. The major difference between the SAP Upgrade Manual and the Project Upgrade Script is the fact that the script contains information specific to your systems, such as:

� Hostnames are specified � SAPSIDs are specified � Userids and passwords, which are necessary during the upgrade (DDIC,

for example) � Exact file locations (Upgrade Export CD-ROMs) � Transports created in advance � SPDD and SPAU steps � Timings per phase � Backup interrupts and timings The Upgrade Script is created according to the findings that were observed

during earlier upgrades in the SAP landscape.

10.8 TESTING

Testing is a very important activity for any SAP project, whether is for an implementation or an upgrade project. However, testing covers more than just the hunt for software bugs:

� Business Process Testing � Component Testing


� Integration Testing � Stress and Performance Testing � Runbook and Script Testing

10.8.1 Business Process Testing

This type of test includes all tests with respect to business processes. The business-process-specific tasks are important in this test. It consists of performing day-to-day tasks by an end user, and simulates using the SAP system. For example, one critical business process is Order-to-Cash, which is applicable to most companies.

Figure 10.10: Business Process “Order-to-Cash.”

Such a business process affects many departments in an organization and consists of many steps and interfaces. This means that the test needs to be performed by end users from different departments and needs to be looked at from a helicopter view.

10.8.2 Component Testing

The “Component” test only includes a particular component from the SAP application. Such a test only makes sense for situations where just one single component is affected by the change.

Figure 10.11: Component “Warehouse Manager.”

210 UPGRADING SAP

Although component testing is seen as rather labor intensive, it makes sense to let it be performed by the user community. The advantage of this is that the software is well tested and the user community becomes (already) familiar with the (new) functionality.

10.8.3 Integration Testing

“Integration Testing” is meant to test both internal and external components. This may include several SAP systems and their interfaces.

Figure 10.12; Integration Testing (1).

Because such tests run over several different components and applications, it is rather complex to perform. However, it remains very important to guarantee the consistency of your IT landscape.

“Integration Testing” can also be performed within a single system, in case a new piece of functionality needs to be tested in an existing environment. For example, the integration of current implemented business processes with new processes.

Figure 10.13: Integration Testing (2).


10.8.4 Stress and Performance Testing

The purpose of stress, volume, and performance testing is to see whether the application infrastructure is capable of handling the expected workload during productive usage. During such tests, a large number of transactions are processed against the application in order to see what the result will be. In most cases, these type of tests are performed through dedicated tools—stress-test tools. A well-known player in the SAP market for such tools is “HP/Mercury LoadRunner.” Tools like these are able to simulate a large number of client systems. Each client sends a certain amount of workload to the application.

Figure 10.14: Stress and volume testing.

10.8.5 Runbook Testing

The “runbook” (also known as “script”) is a document on paper that contains all the steps that need to be done in order to upgrade the SAP “Production” instance from one release to another. Such a runbook is used during the “final” upgrade.

The runbook is created according to findings acquired during previous upgrades done on the same type of SAP database. The steps toward the creation of a runbook might look like Figure 10.15.

Figure 10.15: The opportunity to create an “upgrade” runbook.

212 UPGRADING SAP

After the runbook is written, it needs to be tested. The best way of doing this is by executing the runbook against an SAP test system that contains a copy of the production instance. Especially for cases where the SAP production instance is very critical to the business in terms of downtime, this content of the runbook must be very mature and well-tested. A description of the exact elapse of the upgrade is an essential element in a runbook.

Figure 10.16: “Upgrade” runbook life cycle.

10.8.6 Automatic Testing

Testing has become more important over time and therefore the effort and staff spent to do all the testing are increasing significantly. Now, as business processes are becoming more spread-out across various different components, and parts of the processes are outside the company, new tools have been developed to mitigate these issues. Therefore, SAP has invested extensively in CATT (Computer Aided Test Tool) and recently in eCATT (Extended Computer Aided Test Tool). CATT is SAP’s built-in test tool that offers the ability to run “test” scripts against SAP transactions, screens, and programs. However, the drawback of this tool is the fact that it can only handle solutions based on the ABAP personality. A second issue is the single instance test—the tool can only be used in a single SAP instance. Processes, which run over multiple SAP instances, for example, CRM, ATP, and R/3, cannot be tested from within CATT. The CATT is completely integrated in the ABAP personality of SAP and can be accessed through transaction SCAT.

The new tool, called eCATT, should deal with these shortcomings. eCATT is able to perform over several different systems and includes all kinds of applications developed in different languages: ABAP, Java, JSP, ASP, etc.


Figure 10.17: Using “eCATS” to test entire business process transactions.

An option to host the eCATT system is the SAP Solution Manager. The matrix below shows the trade-off between eCATTs and an external tool.

eCATT No additional license costs

No additional maintenance costs

SAP uses itself for testing their applications

Maintenance is part of standard SAP support contract

Can only used for functional testing

Supports both ABAP and non-ABAP personality

External tool Additional license costs

Additional maintenance costs

Support of new SAP features always lags behind

Can be used for stress testing

May include test-organizer tool

INFO For more information on the availability of eCATT, please have a look at http://service.sap.com/ecatt.

All systems based on NetWeaver 7.0 (e.g., SAP Solution Manager 4.0) are equipped with transaction ST30—Global Performance Analysis. This transaction provides you access to all kinds of tools that are related to performance analysis and improvement of the SAP systems in your landscape. It’s also possible to run test scenarios through the ST30 toolkit.

214 UPGRADING SAP

Figure 10.18: Global Performance Analysis—Transaction ST30. ©Copyright SAP AG.

The test scenarios are recorded and played by using the regular eCATT system. The out can be combined with other tools like the Code Inspector and SQLtrace. This mechanism creates a single cockpit for all performance- and testing-related problems.

A company called “HP/Mercury” ships one of the most common “external” test tools used. This vendor delivers a suite of tools that helps you with the automation of the process around testing as well as with the tests itself.


Figure 10.19: HP/Mercury Quality Center screen shot. ©Copyright Hewlett-Packard.

This tool is also shipped with the default NetWeaver installation kit from SAP. The software is available for 14 days. After these 14 days, the software stops working and can only be activated with the proper license key.

10.9 SAP LANDSCAPE MANAGEMENT

The SAP system landscape design alters during the period of the upgrade and therefore good landscape management is required. Landscape management consists of a clear plan that tells exactly in what order the systems are upgraded and what the status is of a certain system during the upgrade period.

10.9.1 System Landscape Scenarios

Most SAP landscapes consist of at least three systems: Development, Acceptance, and Production. However, a significant number of customers have decided to add additional SAP instances to the landscape in order to support prototyping, data loads, and integration testing. The SAP system landscape should be organized during the upgrade project in such a way that it could serve the following objectives:

216 UPGRADING SAP

� Supportability of the Production instance during the entire upgrade project. � Possibility of a rehearsal of the upgrade before the actual production instance

is upgraded. � Ability to test all implemented business processes and interfaces in the new

target release. � Ability to test and manage all customer modification adjustments. There are several insights to handling the SAP system landscape during the

upgrade, for example, the availability of additional hardware, complexity of the implementation, duration of the upgrade project, and upgrade runtime. The main purpose of an upgrade project is to upgrade the “production” instance. Therefore, it is recommended to perform an upgrade of a copy of the production instance first. To do this, we need a machine that is capable of hosting this copy of the production instance. This will eventually lead to follow-up upgrades for the other SAP instances. Such a scenario consists of the following phases:

Phase 1 – Duplicate Production P01 to U01 and upgrade U01 to the new SAP release.

Phase 2 – Test all required business processes in the new SAP release hosted on U01.

Phase 3 – Perform and test all Customer Modification Adjustments in U01, but do not insert them in a transport. The U01 will NOT become part of the SAP system landscape.

Phase 4 – Collect all documentation of actions performed in phases 1–3.

Figure 10.20: Phase 1 consists of duplication and upgrade.

Phase 5 – Duplicate Development D01 to M01 in order to support the source release for productive purposes. The M01 instance can be hosted on the same machine we’ve being using for the U01 instance. The M01 is used to support the production instance in cases where things are broken in the source release. Assume we’ve upgraded D01 to the new target release and at the same time a serious error is discovered in P01, which is still at the source release. We need to be able to fix


this error in an instance like M01 and transport it over from M01 into P01.

Figure 10.21: In phase 5, a copy is made of D01 to M01.

Phase 6 – The upgrade of instance D01 to new target release. Phase 7 – The upgrade of instance A01 to new target release. Phase 8 – The upgrade of the production instance P01 to the new target

release. Phase 9 – Restore the original CTS flow in the SAP system landscape.

Figure 10.22: Restoration of the original SAP system landscape.

An option might be to take a copy of P01 U01 and upgrade U01 to the new target release and keep this instance during the entire upgrade project. The D01 instance is upgraded after the production P01 instance has been upgraded. So this scenario consists of the following phases:

Phase 1 – Duplicate the P01 instance to U01 and upgrade U01 to the new target release.

Phase 2 – Test all required business processes in the new SAP release hosted on U01.

Phase 3 – Perform and test all Customer Modification Adjustments in U01. During the duration of the upgrade project, the U01 will be the source of all modifications.

218 UPGRADING SAP

Phase 4 – Collect all documentation of actions performed in phases 1–3. Phase 5 – Upgrade the A01 instance to new target release. Phase 6 – Upgrade the P01 instance to new target release. Phase 7 – Upgrade the D01 instance to new target release. In this scenario, the D01 instance remains the support instance for the P01

production instance on the source release. To reduce the number of upgrades, which takes a lot of time, it’s possible to skip the upgrade of the A01 instance and refresh it using a duplication of the P01 instance. It can also be considered for the D01 instance. However, it should not be considered for both D01 and A01. And bear in mind that a refresh of the D01 instance with P01 might have an effect on all non released development changes and storage consumption. The same process can be followed for D01. However, auditors do not like to see copies of production instances being used by developers.

TIP For duplication of SAP instances between machines, please have a look at the appropriate SAP documents called “SAP Homogeneous System Copy Guides,” which can be found at http://service.sap.com/systemcopy.

If an extra fourth machine is not available, a simpler scenario should be considered. Such a scenario would look like this:

Phase 1 – Promote QAS instance A01 to become Development Support for the production instance on source release.

Phase 2 – Upgrade development instance D01 to the new target release, with or without a database refresh of production on top of development.

Phase 3 – Upgrade production instance P01 to the new target release. Phase 4 – Upgrade QAS instance A01 to the new target release or take database

refresh from development instance D01 or production instance P01.

Figure 10.23: System landscape upgrade scenario for three systems.


In order to support the project with the decision-making process, advantages and disadvantages of all possible scenarios are listed here:

Scenario Advantage Disadvantage

Additional U01 instance and reuse the same machine as M01

-

-

-

Possibility to do an upgrade rehearsal on production dataProductive Support in same releaseCertain activities can be done in parallel

-

-

-

Additional database copy (duplication) activities requiredMore complex CTS administration requiredAdditional hardware (machine and storage) required

Additional U01 only -

-

Upgraded U01 can be used as reference system during entire upgrade projectLess upgrades to perform

- No Support system available for production system in source release

Additional M01 only - Support for production in source release available at all times

- Upgrade of D01 is the first rehearsal for production, but does not contain productive data

Both additional U01 and M01

-

-

-

-

Possibility to do an upgrade rehearsal on production dataProductive Support in same release

Certain activities can be done in parallelUpgraded U01 can be used as reference system during entire upgrade project

-

-

Complex CTS administration

Requires two additional SAP instances (machine and storage)

Although MCOD offers the option to create multiple SAP instances in one database, it will not help you here. Because most of our scenarios require copies to be taken from other instances, MCOD is not designed for this. Running multiple instances (Separate SAP instance and Database instance) on one machine might be a solution; however, this strongly depends on the available hardware resources, such as memory, storage, and CPU power. The usage of hardware that is can be

220 UPGRADING SAP

partitioned and makes use of virtualization is the most flexible option to get SAP instances hosted temporarily.

10.9.2 Cross-Release Transports

With a “cross-release transport,” objects and customizing are transported between SAP systems of different releases. In general, SAP does NOT support cross-release transports. However, in certain cases it is the only way to get things done properly, for example, when a serious ABAP program error needs to be fixed in the production instance P01, but the development instance D01 is already upgraded to a higher SAP release.

Whether objects or customizing can be transported depends on a few things:

Object Effect

SAP ABAP program Is object changed after upgrade?

Customer ABAP program Are interfaces (screen, table, or files) still compatible?

SAP table definition No problem if structure is the same

Customer table definition No problem

Customizing setting Only a problem when customizing table has new definition or values are interpreted differently

Issues may arise in cases where the target system supports the more strict Unicode check on programs.

After the objects and customizing have been transported, you should read and analyze the log files that are produced during the import. Also, check and compare all objects between the two SAP systems. If customizing settings and object changes cannot be exchanged between two releases using the transport method, they need to be applied manually.

Figure 10.24: Manual reentry of changes between SAP releases.


TIP Because the transport request is exchanged between two different releases, two different versions of tp and R3trans are involved. Although a few errors or warnings are displayed during the exchange, it’s highly recommended to use the latest available patch levels for all executables.

10.9.3 Show System Information

During the upgrade project, the status of SAP systems will change. Therefore, it’s important to inform users (end users and developers) about the status of the SAP system. There are four (easy) ways of doing this:

(1) Prelogon message change (method 1) – The prelogon screen is changed through screen 0020 in ABAP program SAPMSYST. This results in the modification of standard SAP code and therefore requires an object key.

(2) Prelogon message change (method 2) – Prelogon message change using transaction SE61. This method is supported as of SAP R/3 4.6A and does not require changes to standard SAP coding—see SAP Note 205487.

(3) System Message – Create System Message using transaction SM02. This message is only shown to the user after logon.

(4) Bitmap picture on desktop – A bitmap (picture) can be shown to every user. Although it’s normally used to show the company logo, this picture might also contain upgrade or access information. In order to see this picture, the user needs to be logged on to the system.

TIP The best option is only available as of SAP R/3 release 4.6. The prelogon message change method 2 offers the ability to add texts to the SAPGUI logon screen before the user is actually logged on. The combination of information shown in this screen and locking the accounts of the end users is the best combination to protect the system from being used during the upgrade and still provide adequate information to the end user community. See SAP Note 205487 for more details.

10.10 PROCESS OWNERS—SAP CCC

The upgrade of an SAP application has major impact on the business processes that have been implemented. Therefore, strong involvement of the business is required. Each business process that is implemented in SAP should have an owner. This owner is directly responsible for the way the business process has been implemented in SAP. If customizing and objects that represent business processes need to be changed and tested, it is the process owner who should initiate this.

222 UPGRADING SAP

Figure 10.25: Relationship between the “Business” and the Project Team. ©Copyright SAP AG.

In most companies, the “Business Process Owner” (or BPO for short) is in direct contact with members of the project team and the SAP CCC (Customer Competence Center) team or some kind of other CoE (Centre of Excellence). The BPO will ensure that business requirements are brought to the attention of the SAP CoE and are implemented in the system. Especially during upgrade projects, it is important that people of the project team are working closely with the BPOs. When the application is not well-tested it might jeopardize the continuity of operations of the SAP application and therefore have a negative impact on the business. It also might affect the acceptance of the new SAP release in the organization.

The BPO team can be organized based upon departments in the company. This is illustrated in Figure 10.25. Another option is to make a BPO responsible for an entire region within a company or enterprise. Or alternatively, the BPO is responsible for an entire business process chain, such as “Order-To-Cash.”

10.11 BC SETS

Customized settings can be collected into “Business Configuration Sets” (BC Sets). BC Sets make the process of customizing much easier by providing documentation and tools. BC Sets can also be used for complex SAP implementations in large enterprises, where, for example, Company Group customizing is distributed to the smaller subsidiaries using BC Sets. These sets contain group-specific customizing settings, which are only valid for the receiving systems. Although SAP has organized their BC Sets around business processes, modules, and industry solutions, customers can also create their own dedicated BC Sets as well.

There are two types of BC Sets: “Simple BC Sets” and “Hierarchical BC Sets.” BC Sets have the following attributes:


� BC Set Name � BC Set Type (“Simple” or “Hierarchical”) � BC Set Description (text field) � Supported SAP Release information � Person who made the last change � Date and Time of the last change BC Sets contain collected customizing settings that are implemented as

rows. Each customizing setting originates from a different table. BC Sets are also the building blocks for the Business Function Sets (BFS). This new BFS is the foundation of the Switch Framework that is available as of SAP NetWeaver 7.0 and used to activate the Industry Solutions in SAP ERP 6.0 by using transactions SFW3 (creation) and SFW5 (activation).

Figure 10.26: BC Sets contain various collected customizing settings.

The Hierarchical BC Sets contains other BC Sets. These other BC Sets contain collected customizing settings. The following activities can be performed using transaction SCPR3:

� Create, delete, and maintain BC Sets � Create Transport Request with BC Sets � Download BC Sets to .BCS file on SAPGUI workstation (PC desktop) � Upload BC Sets from .BCS file at SAPGUI workstation (PC desktop) � Compare different BC Sets � Compare content of BC Sets with active customizing settings � Activate BC Sets, which means all content will become active

customizing As you can see, there are two ways of transporting BC Sets: (1) through the

regular SAP transport mechanism and (2) through the so-called .BCS files at PC level.

224 UPGRADING SAP

TIP It is strongly recommended to start using BC Sets as soon they become available in your SAP system. BC Sets are available as of SAP R/3 4.6C and other SAP products with the appropriate Basis release.

10.12 BUSINESS ENGINEER

The SAP Business Engineer was an essential tool in the early days of R/3 that was used to represent Business “Reference” Models implemented in R/3. However, with the introduction of the ASAP toolkit and ValueSAP, the Business Engineer is no longer being used and supported. In SAP R/3, it can still be accessed through transaction SB09 and SB10—SAP Reference Model (EPC Event-driven Process Chains) and transaction SWO1 for the SAP Business Object Browser. However, newer versions of SAP no longer have this functionality available. Tools such as the IDS Scheer ARISTM or IntelliCorp LiveModellerTM can be used instead.

10.13 ABAP AND OTHER OBJECTS

A significant part of the upgrade resources is spent to solve customer modification-issues and adjustments to the standard SAP system. The impact of an upgrade on customer-developed objects can be distinguished as follows:

Customer object Impact during upgrade Effort

Customer ABAP reports Minimal Simple syntax check only and see whether all table fields are still valid (name and length).

Customer Transactions, Menus and Screens

Moderate More modifications, adjustments, and testing required. Often, customer transactions are used as front-end for BDC programs.

User exists Significant Can be significant due to complete integration test.

Interfaces Significant Depends on the complexity and used technique of the interface; ALE, SAP Automation, BDC, SAP Messaging, RFC. Requires ABAP programs or complete redesign.

SAPscript / SAPforms Minimal Just redefine new output forms and test.


Customer DDIC objects Moderate Should not be a big issue. However, if references are made to tables, domains, or data elements of standard SAP that are changed by the upgrade, effort can become bigger

Modifications to stand-ard SAP programs and screens

Significant Difficult to identify and. Therefore, labor intensive; however, should become less of an effort due to modification browser.

Modification to standard SAP DDIC objects

Minimal Only if modifications are done through table appends.

10.14 AUTHORIZATIONS

An upgrade might have an impact on the authorization concept of the SAP system. As of SAP R/3 release 4.0B, the authorization concept is organized around the “Profile Generator,” which is fully supported as of release 4.6B. The Profile Generator, which can be accessed through transaction PFCG, provides the ability to create Profiles, Activity Groups, and User Menus that are assigned to users.

In cases of an upgrade from SAP R/3 3.1I, 4.0B or 4.5B toward release 4.6C or higher, consider the following activities with respect to authorizations:

� Convert “Report Trees” to “Area menus” using transaction RTTREE_MIGRATION. That means the report tree transactions SART, SERP, and SARP no longer work, as you would have expected.

� Convert manually created profiles (with transaction SU02) to “Activity Groups” using the Profile Generator under transaction PFCG. SAP is moving away from transaction SU02.

� Determine the “new” transactions shipped with the new SAP release and add them to the existing authorization concept.

� Modify all technical settings using transaction SU24. � Investigate whether the user-specific menus should be used instead of the

SAP standard menu. � Consider the use of CUA (Central User Administration). However you

need to understand the consequences and procedures of the tool before it can be used.

TIP Have a look at SAP Notes 33341 and 159885 on CUA before implementing this new SAP tool.

226 UPGRADING SAP

Besides this small action list, SAP has added a few new items to the EnjoySAP (release 4.6B and higher) concept:

� Separate authorization objects (S_RFC class) for RFC and BAPI calls. In order to implement this, you have to activate the instance profile parameter “auth/rfc_authority_check.”

� There are separate authorization groups for customer tables and views that can be created through transaction SE34 or SUCU. This will eventually lead to entries in the customizing table TDDAT.

The Profile Generator consists of a set of menus and wizards that help you to create a more effective authorization concept that is easy to maintain. This concept is based on activity groups and menu paths that are automatically converted into profiles, which can be assigned to individual users or entire user groups.

Figure 10.27: Overview of Transaction PFCG (Profile Generator).

Both custom-defined objects and table-row-level access still require alternative maintenance. Differences between the ways “authorization objects” works in the different SAP releases is shown in the following matrix:

3.1 4.0 4.5/4.6B 4.6C/4.7

Activity Group (Master) Activity Group

(Master) Role

- Responsibility Derived Activity Group

Derived Role

- Composite Role

Profile

Composite Profile


The following subjects need to be checked after the release upgrade: � New transactions and their related new authorization objects � Removed or withdrawn obsolete transactions from profiles � Changed authorization objects in existing transactions The magnitude of work that needs to be done to the SAP authorization objects

is related to the number of transactions and ABAP programs. It is also bound to the SAP target release.

SAP Release 3.1I 4.0B 4.5B 4.6C 4.7 6.0

Transactions 12,500 16,000 20,000 51,500 71,500 74,600

Authorization Objects

520 715 825 980 1,340 1,766

One of main reasons behind the significant growth of the number of transactions codes in SAP R/3 4.6C, 4.7, and ECC 6.0, is the fact that a lot of reports from the report tree have been moved to dedicated transactions. It was a resource-intensive activity to manage the authorization of such a report tree. In most cases, users had unrestricted access to the report tree or no access at all. It was not possible in older releases of SAP R/3 to control access on a report-by-report basis.

The authorization concept of this large number of transactions and authorization objects can only be managed by using the “Profile Generator,” which can be accessed using transaction PFGC. Manual effort is still required in certain situations, such as Company Code level protection.

The technical steps for authorizations after an upgrade are: (1) Technical upgrade of the SAP system (2) Execute transaction SU25 (a) Maintain tables USOBT/USOBX ; step 1, 2A and 2B (b) Control activity groups ; step 2C (c) Add new transactions ; step 2D (d) Create transport of all changes (3) Add new transactions and report tree actions

TIP In SAP Note 156196, you will find information on ABAP report “ZREP_COPY_T_RY_ARGS,” which lists all conversion candidates for standard profile names.

If certain authorizations are missing from the system, SAP offers the option to add the SAP_NEW authorization profile to a user. This composite profile contains all required authorizations that were added to the SAP system since SAP R/3 release 2.2. This will solve any issue you will have with accessing new transactions and objects. However, it is also a security breach because a lot of objects have changed since SAP R/3 release 2.2

228 UPGRADING SAP

TIP On a few occasions, certain transactions have been changed between the different SAP R/3 releases. The SAP R/3 target release system will contain a table with the name “PRGN_CORR2,” which contains a mapping between the old and the new transaction codes.

As of SAP R/3 4.6C, the address information of users is no longer stored in table USR03, but in various different ADDR* tables.

10.15 ISSUES DURING UPGRADE

Several different issues can happen during an upgrade, such as, hardware or machine failures or issues with the database. After such an event, in most cases the upgraded can be continued without any additional actions. However, in some cases it is better to restart the upgrade.

When an error occurs during the PREPARE phase, the best thing to do is just start PREPARE all over again. When the substitution repository (phase EU_IMPORT) is already loaded or new tables (NEWTAB_CRE) are created in the system, you need to follow the directions in SAP Note 417670. The steps described in this note are:

� Stop the PREPARE process or stop SAPup. � Run ABAP report RSUPGRES; this report determines and removes all new

tables belonging to the target release. � Delete all content of /usr/sap/put. � Install Upgrade toolkit from CD-ROM. � Restart SAPup.

TIP You can use transaction DB02 with option “Checks: Database ↔ ABAP Dictionary” to see what tables are added to the database during the NEWTAB_CRE phase. Under UNIX and Linux, you can use AWK to create a file named “ntdrop.sql,” which should look like this (Oracle only):

$ cd /usr/sap/put/ntabsql $ awk ‘{ printf “DROP TABLE SAPR3.%s ;\n”, $2 }’ ntmastr.tab > ntdrop.sql $ sqlplus ‘/ as sysdba’ SQL> @ntdrop.sql

This statement creates a file “ntdrop.sql,” which can be executed from within SQLPLUS and contains a DROP TABLE statement for each table that is listed in “ntmastr.tab.”

If the upgrade phase is already running and it has not passed phase MODPROF_TRANS, you can follow the same steps as described here, however,


you have to perform additional actions. Besides deleting newly created tables, you also have to remove the newly created tablespaces and run ABAP function module SUBST_EXCHANGE_NAMETABS using transaction SE37. Before you decide to do this, first read SAP Note 158358 and contact SAP Global Active Support.

The most common issue related to the database is the so-called “Archive Stuck.” In this situation, the filesystem that is used by the RDBMS to write log files to is full. As a protection mechanism, the RDBMS just stops working and waits until it is fixed.

A more serious event is database corruption. In case of just such a situation, the only option is to restore or recover the database. It is strongly recommend to use SAPDBA for these kinds of actions.

It is also possible that the “/usr/sap/put” directory becomes corrupt or is deleted. This directory is very critical to the upgrade, and if any content is lost you basically loose the upgrade. Therefore, you should make several backups of “/usr/sap/put” during the entire upgrade process.

If you run into a particular issue during the upgrade of a production system, for example, a severe error you cannot ignore, you should open a message with SAP Global Active Support (AGS). This SAP AGS support desk is able to sort out most of the issues that may arise during an upgrade.

In order to solve certain issues during the upgrade in the SAP system, you must unlock the system. During critical phases in the upgrade, SAPup locks the SAP system against access to the applications. In the event of an error during such a phase, you need to unlock the SAP system before you can enter it. This can be done by using the “tp” program, which resides in “/usr/sap/put/bin.”

root$ su – sidadm ; cd /usr/sap/put/bin

sidadm$ tp unlock_sys SAPSID

or: root$ su – sidadm ; cd /usr/sap/put/bin

sidadm$ to unlock_eu SAPSID

TIP In case urgent repairs need to be performed in a production system, which is usually set to “nonmodifiable,” you can set the system option back to “modifiable” by using the following SQL statement (Oracle example):

SQL> update sapr3.tadir set edtflag = ‘R’ where pgmid = ‘HEAD’;

SQL> commit;

10.16 ACTIONS TO DO BEFORE UPGRADE

Before the SAPup upgrade process can be started, certain things need to be sorted out first. The pre-steps that are related to the preparation of the system are

230 UPGRADING SAP

designed in such a way that you don’t have to do them during the upgrade. This list is a summary of a couple of these steps that are (sometimes) required to be done during the upgrade. However, they can be done upfront. It is recommended to add these steps to the runbook.

• Lock the users with ABAP report EWULKUSR or using transaction SU10. • Be sure you have the password available of user DDIC in client 000. • Be sure you have all transports released through transaction STMS. • Be sure you have sufficient disk space available for all log files that are

produced during the upgrade (“/usr/sap/trans” and “/usr/sap/put”) and for all new tablespaces.

• Download all relevant Support Packages and store them in “/usr/sap/trans/EPS/in.”

• Download the latest relevant SAP Kernel patch set. • And last but not least, read all relevant SAP notes. Start with the Composite

note.

Chapter 11THIRD-PARTY TOOLS

Each SAP system is part of a much larger IT landscape. Such IT landscapes might include all kinds of different software packages, such as office desktop software, email infrastructure, interfaces, and Web applications. The SAP

system landscape itself may also be extended with additional software.

11.1 MONITORING TOOLS

A number of tools are available for system and application monitoring. Most of these tools are capable of monitoring SAP-specific components or have adapters to integrate the monitoring tool with the SAP engine. SAP delivers a system and application monitor called CCMS (Computer Center Management System) by default with every SAP component that is based on the ABAP personality. The main screen of CCMS can be accessed through transaction RZ20, which will show you an expandable tree with all kinds of monitoring items (known as MTE). Each item represents a certain monitor that takes care of a particular object in the SAP system.

Besides the SAP system itself, CCMS also takes care of the RDBMS system and parts of the operating system. It also provides the option to support the monitoring of other non-SAP programs and processes using the CCMS Agent. With this feature, the entire IT landscape can be monitored by CCMS, which hooks up in the System Management Cockpit® of the SAP Solution Manager.

231

232 UPGRADING SAP

Besides SAP Solution Manager and CCMS, a wide range of monitor software packages are available on the market. Suppliers, such as IBM (with Tivoli and Insight), BMC (with Patrol), HP (with OpenView), and Computer Associates (with UniCenter and Wily Introscope) deliver special add-ons for SAP monitoring that need to be installed in your SAP system as a bundle of transports. The main advantage of these tools is the ability to monitor all kinds of infrastructure. Most of the tools are part of a larger monitoring infrastructure or framework. A popular monitor and management framework is Microsoft Operations Manager (MOM), which is based on Management Packs. Microsoft products, such as SQLServer, Exchange, and SharePoint are all shipped with a Management Pack. Such a Management Pack consists of a set of rules and best practices and therefore makes it relatively easy to add such infrastructure to an existing IT landscape. For connectivity between SAP Solution Manager/CCMS and MOM, you need to have a Management Pack for SAP. Such tools are delivered by Tidalsoft and go under the name of Horizon for SAPTM.

Figure 11.1: Monitor solution architecture of an SAP system.

The majority of monitoring tools are based on an agent architecture, where each individual agent takes care of a specific element of the SAP software stack. An agent connects itself to the element and checks the health of this element according to configuration parameters and thresholds. A central collector is responsible for the collection of the output of all the agents. This output, which consists of events, is sent to a “monitor console” for further processing.

Besides commercial products like Tivoli, BMC Patrol, and CA-UniCenter there are also non-commercial tools available for system monitoring. The most common open-source monitor tool is “Big Brother.” There is even an SAP and Oracle add-on available for this product. The most common commercial monitoring infrastructure product is BMC Patrol. BMC Software delivers a broad set of SAP-specific software products, for monitoring, RDBMS management, interfaces, performance analysis, and optimization. The BMC Patrol products suite is used for SAP system and application monitoring, and consists of several products.

THIRD-PARTY TOOLS 233

The BMC monitor products use a so-called KM (Knowledge Modules) to monitor specific components of the SAP system. The SAP KM, which is implemented under the product name BMC Trak (this products was acquired from an Israeli company) is meant to monitor the SAP component itself, is entirely written in ABAP, and uses a dedicated name space to protect its objects. The Windows, UNIX, SQLServer, DB/2, and Oracle KM are all meant to monitor their respective components. BMC uses a console to display all monitoring message, however, it requires separate software for automated ticketing or alerting. Tools like BMC PEM (Patrol Event Manager) and Proxima Centauri helps with this process.

Key to the success of such tools is the implementation of the right IT support processes, such as ITIL, and the implementation of a CMDB (Configuration Management Database) with all IT assets that host all used IT configuration items like software and hardware.

Figure 11.2: BMC Patrol Monitor tools for your entire enterprise.

11.2 TRANSPORT TOOLS

These tools help manage transport requests in large and complex SAP system landscapes. Companies that implement SAP in a global organization with several regions and multiphased projects definitely need such a tool. The regular TMS, which is shipped with SAP by default, is absolutely insufficient to support such complex projects. There are a few known tools on the market for this purpose: RevTrac, Object Manager, and Transport Express.

234 UPGRADING SAP

These tools add functionality to the standard CTS/TMS facility that is built in to SAP by default. Tools like these offers the option to run reports against transport requests, a workflow mechanism for change and approval management, and the ability to synchronize complex SAP landscapes. SAP itself offers the ChaRM (Change and Request Management) tool, which expands the TMS kit with request, permission, and approval functionality. This ChaRM tool resides in the SAP Solution Manager 4.0 .

11.3 INTERFACE TOOLS

Another group of tools that are used by companies are interface tools. These tools focus on the exchange of data or information between applications. The purpose of these interface tools is to manage data and information exchange between applications of various vendors. The exchange of information between SAP applications can be implemented via RFC, ALE, IDOCs and BAPIs. When data needs to be exchanged with non-SAP applications, XML format or ordinary flat files are often used. The most commonly used tools are IBM WebSphere MQ (formerly known as MQSeries), IBM CrossWorld (member of WebSphere MQ family of products), TibCo, SonicMQ, and SeeBeyond.

A lot of customers are making use of the SAP Business Connector. This OEM version of the WebMethods B2B Integration Server is only supported if SAP falls under the license agreement. Currently, there is no definitive date when SAP BC will be out of maintenance. As soon as an end-of-maintenance date is defined this SAP note would be updated accordingly. Technically, the SAP Business Connector 4.7 runs with the newer versions of SAP ERP. However, SAP strongly recommends implementing the interfaces using the SAP Process Integration (PI).

11.4 TAX CALCULATION TOOLS

Another family of important interface tools is tax calculation tools, which are very popular in the United States. Various vendors are active on the market to provide tools for calculating tax for SAP systems. The most commonly used tools in this area are: Sabrix, TaxWare, Vertex, and TaxFactory.

For all these products it is important to know whether an upgrade to the SAP system requires an upgrade of the tax software as well.

11.5 OTHER TOOLS

Besides monitoring, transport management, and interface tools, an SAP system can also work with other tools, such as Batch-Scheduling tools (e.g., BMC Control-M),

THIRD-PARTY TOOLS 235

Data Extraction tools (e.g., Informatica), and Data Copy tools (e.g., InfoShuttle). For all these tools it is required to check what the supported version combinations are. This should be checked with the appropriate vendor of the product.

SAP no longer delivers the solutions themselves. Certain suppliers are promoted to preferred suppliers for certain solutions. So, Redwood software is the preferred supplier for batch scheduling software and is the “Cronical” product shipped as part of the SAP NetWeaver 7.0 installation kit under the name “Central Job Scheduling for SAP.”

236 UPGRADING SAP

Chapter 12SAP NEW DIMENSIONS PRODUCTS

This chapter describes the upgrade steps that are specific to certain SAP applications. The upgrad e process of all SAP software applications that are based on the ABAP personality follow the same upgrade process. Products

such as R/3 (ERP), BW/BI, CRM, and APO/SCM are all using SAPup for the upgrades. The SAPup tool uses exactly the same steps, procedures, and phases for all the products.

However, there are different application-specific differences between the various components. These differences are described here per SAP application component. The SAP ERP (R/3) is taken as the comparison basis.

12.1 BUSINESS INFORMATION WAREHOUSE

Upgrading an SAP Business Information Warehouse application is exactly the same as upgrading SAP R/3. Depending on source and target release, two upgrade technologies are available: “Repository Switch” and “System Switch”:

Upgrade Path (source → target release) Upgrade Technology

SAP BW 2.0B → SAP BW 2.1C Repository Switch

SAP BW 2.0B → SAP BW 3.0B System Switch

SAP BW 2.0B → SAP BW 3.1C System Switch

SAP BW 2.1C → SAP BW 3.0B System Switch

237

238 UPGRADING SAP

SAP BW 2.1C → SAP BW 3.1C System Switch

SAP BW 3.0B → SAP BW 3.1C System Switch

SAP BW 3.0B → SAP BW 3.5 System Switch

SAP BW 3.1C → SAP BW 3.5 System Switch

SAP BW 3.1C → SAP BI 7.0 System Switch

SAP BW 3.5 → SAP BI 7.0 System Switch

SAP Business Information Warehouse, BW for short, is based on ABAP and uses the ABAP Personality in the Web Application Server. BW uses a so-called OLAP engine, which is fully implemented in ABAP code. The data-warehouse data is stored in an “extended” star scheme that is implemented in transparent tables. All the ABAP programs, screens, and tables can be accessed through regular transactions, such as SE11, SE16, SE38, and SE80. An upgrade of an SAP BW system does not differ from an upgrade of SAP R/3. The only two differences are: Alpha conversion and a new concept around BW Content. As of SAP NetWeaver 2004S BI (also known as BI 7.0), an extension was introduced that is based on Web Dynpro for Java. Therefore, the AS Java and BI Java usage type need to be installed after the upgrade.

12.1.1 BW Alpha Conversion

Most BW systems that are already productive contain inconsistent values in tables with ALPHA (Alphanumeric), NUMCV (Numeric), and GJAHR (Fiscal Year) fields. The upgrade might fail when tables with these inconsistent values are wrongly converted. In the worst case, the customer is not even notified about these wrong conversions, however, the end user reports will show the wrong results.

In order to prevent this from happening, SAP has a tool that needs to be run before an upgrade takes place to SAP BW 3.0B or higher. This tool is implemented in transaction RSMDCNVEXIT and is part of a Support Package.

SAP BW source release SAP BW Support Package

2.0B 22

2.1C 14

3.0A 03

There is no issue when the appropriate Support Packages are not imported into your BW system—the tool is also delivered as part of the TOOLIMPORT phase.

The transaction RSMDCNVEXIT is run as part of the PREPARE phase and can be used to run both the consistency checks as well as correcting such inconsistencies. However, the check can take a significant amount of time, especially on large databases, and therefore it is recommended to apply the appropriate Support Packages on time and perform the exercise upfront. When

SAP NEW DIMENSIONS PRODUCTS 239

you call the transaction, you have to decide for each inconsistent characteristic whether to convert the data, or whether to remove the conversion routine. However, it is important to understand that “system administrators” cannot make such decisions by themselves. SAP strongly recommends that the upgrade project team ask the BW end users, so that you can decide on one of the alternatives. A wrong decision could cause multiple characteristic values to be grouped together, although they describe different objects. This could have serious impact on the productive operation of your SAP BW system.

INFO For more information on the transaction RSMDCNVEXIT, please take a look at SAP Note 447341 or press on the “Information” button on the screen of this transaction.

12.1.2 BW Business Content

As of SAP BW release 3.1C, SAP started to introduce “BW Business Content.” This Business Content, or BW_CONT6 for short, is just the split of BW into two major parts: BW Technology and BW Business Content. The BW Technology contains the SAP Basis Layer (or SAP Web Application Server) parts and the BW-specific OLAP engine and BW-specific transactions. The BW Business Content contains all of the SAP standard delivered InfoCubes, InfoObjects, Queries, and Reports.

Figure 12.1: SAP BW division into Technology and Business Content.

In SAP BW releases lower than 3.1C, new Business Content was delivered as part of Support Packages. As of SAP BW release 3.1C, this Business Content is delivered through BW Content add-ons. These add-ons are installed using transaction SAINT and will bring your BW system to a higher release without having to perform an entire BW instance upgrade. This has major consequences for the BW release numbering.

6 Also known as BI_CONT (Business Intelligence).

240 UPGRADING SAP

Figure 12.2: SAP BW 3.1 Content upgrade path.

The BW instance needs to be brought to release 3.1C (SAP_BW 310) through a regular upgrade with PREPARE and R3up. This system will have both components SAP_BW_310 and BW_CONT_310. The BW_CONT_310 can be upgraded to a higher release SAP BW 3.2 by implementing BW_CONT_320 through transaction SAINT. After SAP BW release 3.2, the next release will be 3.3 and 3.4, which requires a consecutive implementation of BWCONT_330 and BW_CONT_340. The BW_CONT packages should be implemented incrementally, which means BW_CONT_320 before you can go to BW_CONT_330.

An upgrade to SAP BW release 3.5 requires a full upgrade of both BW Technology and BW Content using PREPARE and R3up.

Figure 12.3: SAP BW upgrade of release 3.3 to 3.5 and to 7.0.

In order to support this model, SAP has implemented the following Support Package components in SAP BW:

SAP BW Support Package Component Description

SAP_BASIS SAP Basis Layer

SAP_ABA SAP ABAP Environment

SAP_AP SAP Application Platform

SAP_BW SAP BW/BI Technology

PI_BASIS SAP Basis Plug-In

BI_CONT BW Business Content


12.1.3 BW-Specific Upgrade

There are a few things that are different for an SAP BW upgrade compared to an SAP R/3 upgrade, especially if the target release is BI 7.0

The handling of Dialog and Batch processes has been changed. This can be identified upfront be running ABAP Report RSBATCH in the system. The new DTP process affects certain DataSources and PSA tables. Therefore, a check needs to be run in the system using ABAP reports RSSM_HASH_ENTRIES_CREATE, RSSTATMAN_CHECK_ CONVERT_ DTA, and RSSTATMAN_CHECK_CONVERT_PSA. The BW performance statistics cube need to be reconstructed by looking at the steps described in SAP Notes 934848 and 964418.

The AS Java usage type is required in cases where the following IT Scenarios are going to be used: Integrated Planning, xApps Analytics, EP for BI-Java, Visual Composer, and any other Web Dynpro for Java-based application. This also requires the use of the SAP System Landscape Directory (SLD).

Other checks that need to be done up front are: • Job RSCPINST, to check the Code Page–specific settings of the SAP

database. • Run RUTMSJOB to ensure the consistency of the SAP Dictionary. • A repair of InfoCubes can be performed by using SAP Notes 996602 and

458363. • Master Data (MD) can be checked using report RSDMD_CHECKPRG_

ALL. • Check invalid temporary tables using SE11 → DB requests → Mass

Processing → Invalid temporary table. • Check for deletion of jobs using report RSBTCDEL2. SAP Note 784969 will

be helpful with this. • The R/3-specific plug-ins for BW, known as ST-PI and ST-A/PI, need to be

upgraded to the right level as well. SAP Notes 539777, 557584, and 69455 will be helpful with this.

• Queries need to be checked before editing, see SAP Note 337950.

NOTE SAP BW systems containing SEM functionality should be upgraded after activities for SAP Note 632429 have been applied.

Activities that may need to be performed afterward are: • Setting up the correct BW Start Menu using Transaction SSM2: RS00 for BW/BI UG00 for SEM • Activation of the new authorization concept of BI 7.0. The SAP Note 820183

contains more in-depth knowledge about this.

242 UPGRADING SAP

• The BI 7.0 add-on package needs to be downloaded from the SAP Marketplace software repository and applied on top of the SAPGUI for Windows.

TIP Using the “Downtime Minimized” scenario with an SAP BW upgrade will only allow you to use the Query engine. Extractions and load activity should still be avoided. Therefore, it probably makes sense to consider the “Resource Minimized” scenario instead. It will be faster in the end.

12.1.4 SAP BI Lock Server

There are three different ways for SAP NetWeaver 2004S BI (BI 7.0) to store persistent table locks. The BI 7.0 lock server is used in BI Integrated Planning and in BW Business Planning and Simulation (BW BPS).

• SAP Lock Server (known as a standalone Enqueue Replicator) • Shared objects memory of an application server • SAP LiveCache instance In the first two cases, the lock tables have a fixed maximum size. When you

set the size, you must ensure that it will not be exceeded during system operation. Otherwise, program terminations may occur because these exceptions cannot be caught in ABAP programs. The location of the BI lock server is set through transaction RSPLSE.

12.1.5 BI Accelerator

The BI Accelerator is a query offload engine that is attached to an SAP BI system. It consists of a farm of Intel Xeon CPU–based blade servers with a lot of memory. This memory will hold indexes to data kept in the SAP BI cubes. The query performance gain is achieved by using column-based storage rather than tuple-based storage.

Figure 12.4: Redirect of query request into the BI-A system. ©Copyright SAP AG.


In Figure 12.4, a query is run against an InfoCube residing in the SAP BI system. If the InfoCube has been configured for BI-Accelerator, the query will be redirected to the BI-Accelator.

The BI-Accelerator is based on Intel Xeon CPU–based blade servers running Suse/Novell Linux 64 bits and SAP TREX 7.0. It is, however, not the intent to use this TREX instance for other search requirements. The BI-Accelerator is shipped as an appliance with its own dedicated storage subsystem that is connected through Fiber Channel to each blade and through NFS (HP uses OCF2; IBM uses GPFS) to each Linux operating system image. The maintenance is primarly done through SAP BW management transactions, such as RSDDV and RSDDBIAMON, which are delivered by SAP BI 7.0 and an X/Windows-based Python program “TREXadmin.”

The main advantage of the BI-Accelerator is query performance without having to spend a lot of time tuning the InfoCubes with Aggregates. For BI systems that do have query performance problems, a business case for BI-Accelerator is quite simple.

SAP deploys this same infrastructure for the so-called Netweaver Enterprise Search Appliance, which is positioned as an enterprise-wide tool to search through documents located in various SAP and non-SAP backend systems. It shipped with a customized version of Trex and uses similar index techniques as BI-A. From a hosting and management perspective, this Search appliance is exactly the same as the BI-A appliance.

12.2 SRM (SUPPLIER RELATIONSHIP MANAGEMENT)

SAP SRM (Supplier Relationship Management) application was initially released under the name Business-to-Business Procurement (BBP) and later renamed to Enterprise Buyer Professional (EBPro). The main function of the application is to support (large) enterprises and companies in the procurement of goods and services.

Figure 12.5: SAP SRM/CRM release 4.0 and 5.0 and SRM 6.0 “Component stack.”

SAP SRM and CRM reside in the same database, which means that the export DVD you receive in the installation kit contains both SRM and CRM. After the

244 UPGRADING SAP

installation of this export load, both applications are available. Through one of the available customizing settings, you can choose SRM, CRM, or both applications. The combined application is called SAP_BBPCRM.

It is possible to run both applications, SRM and CRM, in one SAP instance, preferably in different clients. Such a setup is also used by SAP for the “All-in-One-Server” solution.

SAP Web AS SAP CRM SAP EBP / SRM SAP BBP

4.6C 2.0B 1.0 2.0B

4.6D 2.0C 2.0 --

6.10 3.0 3.0 --

6.20 3.1 3.5 --

6.20 4.0 4.0 --

6.40 -- 5.0 --

7.00 5.0 6.0 --

All SRM application-specific upgrade items are related to the non-ABAP products, such as the SAP Business Connector and the Requisite Catalogue database. SAP has announced to withdraw support of the SAP Business Connector (an OEM version of WebMethods B2B Integration Server) in the near future. Customers are supposed to migrate their XML interfaces to SAP XI (eXchange Infrastructure). SAP XI is based on both the ABAP and Java personality. The only ABAP-related actions for the upgrade are relevant for OS/390 customers and specified in SAP Notes 184399 and 407663, which include an ABAP source code correction required by certain SAP SRM/CRM source releases.

TIP In order to see what components are supported with what middleware products, please refer to the “EBP/SRM MasterGuide.” And you should, of course, view the SRM/CRM upgrade–specific SAP Note 596514.

One of the extra steps during the upgrade is the correct handling of “Product Master Data” in the Catalog database. You have to log on to the SRM application and select option “Importing Catalogs” under “Content Management” as option of the menu “Master Data.” Another additional check is the “User Attributes,” which can be checked up front with the ABAP report BBP_ATTR_XPRA350. These User Attributes are replaced by InfoTypes during the upgrade.

A separate action during the upgrade project is the upgrade of the Catalog database application. Most SRM customers make use of the Requisite BugsEye Catalog database, which runs on a variety of Java application servers, such as IBM Websphere, Tomcat, and Jrun. SAP recommends replacing these non-SAP Java engines with the SAP-specific J2EE engine. A separate migration procedure is by published by SAP and can be found at http://service.sap.com/instguides.


Figure 12.6: SAP SRM 6.0 software components in a complex environment.

©Copyright SAP AG.

As of SRM 5.0, SAP released its own solution for product catalog management called CCM. The CCM add-on is integrated into the ABAP stack and can be installed in the SRM instance using transaction SAINT. For upload of unstructured data into CCM, SAP XI/PI is used. An MCOS installation based on SRM, CCM, and XI/PI is therefore supported and should be considered.

12.3 CRM (CUSTOMER RELATIONSHIP MANAGEMENT)

The SAP CRM application is implemented in the same export DVD as SRM. Therefore, most of the described exceptions to the standard upgrade also apply to CRM. An average SAP CRM implementation contains far more middleware components than any other SAP application. SAP CRM Solution Suite contains the following components:

� SAP CRM Server (based on ABAP personality on SAP Web AS) � SAP Business Connector with CRM RNET (RosettaNet package) � SAP IPC (Internet and Pricing Configurator) � SAP Mobile Engine Server (integrated in SAP Web AS of CRM Server) � SAP Mobile Engine Client (Web server, SOAP Proxy, and mVB)

246 UPGRADING SAP

Figure 12.7: Average SAP CRM application infrastructure. ©Copyright SAP AG.

And optional components: � SAP SCM (used for ATP checks) � SAP BI (for reporting over CRM activities) � SAP EP – Enterprise Portal � SAP KM – Knowledge Management � SAP IPC – Internet Pricing Configurator (embedded VM Container ABAP

7.00) More information about each of these components can be found in the “SAP

CRM Master Guide,” which can be downloaded from http://service.sap.com/crm-inst.

An important new feature of SAP CRM 4.0 is the “Customizing Scout.” This tool, which requires an SAP Solution Manager release 3.1 or higher, is able to discover customizing settings from an SAP R/3 system and transfer them to SAP CRM in order to use them. This process can save the project team a significant amount of staff time.

Figure 12.8: Synchronizing customizing settings through “Customizing Scout.”


All these middleware components are part of the SAP CRM solution suite and therefore should be part of the upgrade project. The first step is to see whether an individual component upgrade is required and, if so, the correct software needs to be obtained. A so-called software or middleware component support matrix should be created. Such matrices provide an answer to which SAP CRM runs with what middleware release. The next step is to upgrade each of the middleware components. For tools, which run on the SAP J2EE engine, this requires a new JAR package. These JAR packages are usually upgraded through a J2EE Deploy tool or through SAPinst.

A typical SAP CRM–specific step during the upgrade is the de-registration of inbound queues with transaction SMQR. In this transaction, you have to select all CRM_SITE* specific entries.

TIP Run the “DDIC vs. DB Consistency Check” in transaction DB02 before the upgrade. This will reduce activation issues for table M_MCHA. If an inconsistency is discovered, you just can delete the table from the database.

12.4 SCM (SUPPLY CHAIN MANAGEMENT)

SAP SCM (Supply Chain Management) is an application that covers the area of production planning, demand planning and forecasting. SAP SCM uses a set of Linear Programming algorithms for this on top of data that resides in InfoCubes. Especially Demand Planning (DP) uses InfoCubes. The InfoCubes are accessed through the OLAP engine and therefore SAP SCM uses the same technology layer as SAP BW.

Figure 12.9: Technical layers and functional modules of SCM.

12.4.1 SCM Middleware

To support SAP SCM in planning and forecasting activities, two additional applications are available: SAP LiveCache and SAP Optimizers. The LiveCache

248 UPGRADING SAP

application is an add-on, which preferably should be installed on separate hardware and uses an in-memory database system to do its work. The SAP LiveCache application use an FPT (Fast-Path-Tree) algorithm in combination with an object-oriented RDBMS (OMS—Object Management System) to achieve the best possible performance. To improve the planning performance even better, you can install additional “Optimizer” application servers.

Figure 12.10: SAP APO building blocks.

These additional application components, such as SAP LiveCache, follow their own release schedule, however, only certain combinations are supported with SAP SCM (APO—Advanced Planning and Optimizer).

SAP APO Release SAP Basis Layer SAP LiveCache

APO 2.0A 4.6A 7.2.0

APO 3.0A 4.6C 7.2.0

APO 3.1 4.6D 7.4.0

APO 4.0 / SCM 4.0 6.20 7.4.3

SCM 4.1 6.40 7.4.3

SCM 5.0 7.00 7.5.0

SCM 6.0 (SCM 2007) 7.00 7.6.0

Information about the various components used by SAP SCM and the associated IT Scenarios are described in more detail at http://service.sap.com/scm.


Figure 12.11: SAP SCM 5.0 landscape building blocks. ©Copyright SAP AG.

12.4.2 SCM Upgrade

Most of the SCM-specific upgrade differences are related to the middleware. Two additional steps are added to the SCM upgrade procedure: REQ_APOUPG1 and REQ_LCUPG. The REQ_APOUPG1 phase is used to provide a time frame to the upgrade engineer for saving the SAP LiveCache transaction data into the SCM database. This step must be done before the actual upgrade of the SAP LiveCache software. You can use ABAP report /SAPAPO/OM_LC_UPGRADE_3X_40, if the SAP SCM target release is 4.0, to save this transaction data.

The second SCM-specific phase, REQ_LCUPG, is used to provide a time frame in the upgrade to perform the SAP LiveCache and Optimizer software upgrades. The SAP SCM upgrade manual contains a separate section on how to perform these upgrades.

Before the SAP LiveCache software is upgraded, the LiveCache Persistency Database, which was implemented in SAPDB version 7, needs to be backed up. This should be done before the EU_IMPORT0 phase.

The last additional step that needs to be done is to block the R/3 CIF interfaces, using ABAP reports /SAPAPO/CIFSTOPQUEUES for outbound and RSTRFCI1 for inbound traffic. See SAP Notes 487261 and 528913 for more information.

INFO Additional information on upgrading SAP LiveCache and SAP SCM Optimizers can be found in SAP Notes 436949, 573512, 599468, and 490325.

250 UPGRADING SAP

12.5 PROCESS INTEGRATION

SAP released a significant number of new application components under the family brand “NetWeaver” solution, such as BI (Business Intelligence), XI/PI (Process Integration), NWDI (NetWeaver Development Infrastructure), and EP/NWP (Enterprise and NetWeaver Portals). In most cases, these components are referred to as usage types of the SAP NetWeaver framework and Application Server (AS). The installation and upgrade process of these components are all done using SAPinst. In this respect, it is important to understand that NetWeaver is based on both ABAP and Java, and that certain components use either of the two, or just one engine.

The SAP XI/PI application consists of several components that are implemented in both ABAP and Java. Therefore, the SAP XI/PI application requires both engines to be installed.

Figure 12.12: SAP NetWeaver Process Integration—Building Blocks.

This means that an upgrade of SAP XI/PI involves the upgrade of both the ABAP component and the Java component. Such an upgrade is performed through a mixed upgrade technology with both SAPup and SAPJup. In case of an installation, the entire process is taken care of by SAPinst.

The SAP XI (Exchange Infrastructure Application) release 3.0 is implemented as a SAINT add-on on top of SAP Web Application Server 6.40. Table CVERS has the following entries:

SAP Component Release Description

SAP_BASIS 640 SAP Basis Component

SAP_ABA 640 Cross-Application Component

APPINT 300_640 SAP Exchange Infrastructure 3.0


A few SAP applications are implemented as add-ons on top of existing components and use existing components as the foundation layer. To install one of these products, the foundation layer software needs to be installed first. The SAP application itself is installed on top of this foundation layer using transaction SAINT. On a few occasions, an upgrade of such an SAP application consists of installing new Business Content with transaction SAINT—the foundation layer is not changed during the upgrade. SAP applications that have this upgrade behavior are:

SAP Application Add-on on top of…

SAP SEM SAP BW

SAP EH and S SAP R/3

SAP eRecruiting SAP Web AS or ECC 6.0

SAP Solution Manager SAP CRM

Figure 12.13: SAP Application upgrade using transaction SAINT.

Although both CRM 3.1 and CRM 4.0 are based on SAP Web AS version 6.20, the upgrade is still performed through R3up. There are only a few “smaller” SAP applications that use SAINT as an upgrade tool, for example, eRecruiting or upgrading SAP Solution Manager from version 3.1 to version 3.2.

252 UPGRADING SAP

Chapter 13SAP NETWEAVER JAVA AS

The SAP NetWeaver Application Server (NWAS) consists of two personalities or so-called engines. The two personalities are ABAP AS and JAVA AS, where AS means Application Server. In addition to this, SAP released

various standalone engines, such as LiveCache and TREX, whereas others have been integrated in AS, such as IGS, ITS, and IPC.

The ABAP personality has been available for many years. The Java personality is quite new to most of us. The NetWeaver Java AS is a follow-up development of the In-Q-My Java application server that was introduced by SAP in version 6.20. As of SAP NetWeaver 2004 (Basis release 6.40), it is fully integrated into the ABAP support tools, which means it:

• Integrated in the start and stop of the ABAP AS • Resides in the same filesystem structure as the ABAP AS • Shares the same database as the ABAP AS • Same database tools (like BRTOOLS) can be used for maintenance • Integrated in the CCMS monitoring solution The SAP NetWeaver Java AS can be deployed in different ways. One option

is to install it at the same sequence as the ABAP AS. This process is done by using SAPinst and selecting both AS stacks for installation. The second option is based on a so-called Java add-In installation, which is performed at a later stage than ABAP AS. This option is used in case an existing ABAP-based application is upgraded to ECC 6.0, or in case an additional component is needed based on Java. For example, the Java AS is required when Adobe Interactive Forms (AIF) are used. The Adobe

253

254 UPGRADING SAP

Document Service (ADS), which is the foundation of AIF, is deployed on the Java AS.

Figure 13.1: SAP Java Application Server. ©Copyright SAP AG.

13.1 DEPLOY OPTIONS

There are various options for how the Java AS can be deployed on servers. It can be deployed standalone, in a cluster, as an add-in on a single ABAP AS, or distributed across many servers—with or without ABAP AS. The SAP Java Application Server is based on a single Java Dispatcher per instance and one or more Java Server processes. Each server process is able to process requests and has a dedicated link into the database to store data. The SAP Central Services (SCS) consists of the SAP Message Server and a standalone enqueue server. These two services deal with all the synchronization activities between various nodes in the cluster and take care of locks in the database.

Figure 13.2 illustrates a scale-out deploy option with both ABAP and Java AS. In order to dispatch the user requests to both systems, an additional piece of software is needed that is shipped by SAP free of charge and is called “SAP Web Dispatcher.” This software component should be installed (in a cluster setup preferably) on a server and all HTTP(s)-based requests dispatched further down to the various SAP instances. The advantage of such a deployment scenario is the fact that all servers look the same. However, the disadvantage is the control and flexibility with computer resources. The Internet Communication Manager

SAP NETWEAVER JAVA AS 255

(ICM) is embedded in the SAP ABAP kernel and used to control all HTTP(s)-based sessions. Regular (classic) SAPGUI sessions are still handled by the SAP ABAP dispatcher and message server.

Figure 13.2: Option 1—server scale-out deploy scenario for both ABAP and Java AS.

Another option is to install both ABAP and Java AS on the Central Instance/Database server and scale out per personality.

Figure 13.3: Option 2—shared first instance, segregated scale out on application servers.

In this case, a server is fully dedicated to run either ABAP or Java workload. This option has the advantage of being able to tune the memory parameters for the different personalities.

In the third option, both ABAP and Java are being segregated to their own servers. The only exception is the database, which is still shared between ABAP and Java.

256 UPGRADING SAP

Figure 13.4: Option 3—all personalities are segregated, except for the database.

An advantage of this setup is that both personalities are storing their data in a single database, which makes it easy for maintenance.

Figure 13.5: Option 4—Two different SAP clusters: ABAP AS and Java AS.

The last deployment option is a total segregation of both personalities. In this scenario, nothing is shared between ABAP and Java. This option is often used in large organizations where an SAP Portal is implemented with a large number of users. The SAP Portal infrastructure is implemented and deployed completely separate from the SAP backend systems, such as ERP, BI, and CRM.


Figure 13.6 End user access to SAP backend system using SAP Portals.

13.2 JAVA STARTUP AND CONTROL FRAMEWORK

The Java startup and control framework is used to start, stop, and monitor an SAP Java Instance and is available as of NetWeaver 2004 (SAP AS 6.40). The Java startup and control framework are comprised of the programs JControl and JLaunch. JLaunch is started by JControl and then it starts the bootstrap Java program or an element of the Java cluster (dispatcher or server process). The framework consists of the following components:

• JControl starts, stops, and monitors the processes of a Java instance (usually a dispatcher and several server processes). The program implements the SAP signal handling to stop the instance. JControl starts the JLaunch processes.

• JLaunch starts a Java program. It loads the JVM into its own address space and then represents the required cluster element. The program can receive notification from the JControl process via named pipes to stop the cluster element and terminates in cases where the JControl stops running (fork emulation under Windows).

• The Bootstrap JAVA program synchronizes the binary data from the Java database with the local filesystem and creates a property file, which describes the processes of the Java instance.

258 UPGRADING SAP

Figure 13.7: SAP Java instance startup framework. ©Copyright SAP AG.

In a combined (dual-stack) installation, the ABAP dispatcher starts up the Java AS instance by invoking the JControl program. This JControl invokes another program, the so-called Bootstrap Java program that connects to the database and reads all Java VM properties and writes them to files at the operating system level (bootstrap.properties). After this has been done, the Bootstrap Java program terminates itself and returns the control back to JControl. The JControl program now starts up a small SAP Java instance, consisting of two JLaunch processes, one acting as a Server node and one as a dispatcher. These two processes are reading the Java VM properties files and synchronising all Java deployments between the database and the operating system files. This process may take a while, especially after applying Support Packages, component deployment, or upgrades.

After this has finished, the JLaunch processes are terminated and control is given back to the JControl process. At last, the final SAP Java instance is started with two or more JLaunch processes. The first one is always the Java dispatcher and the others are either one or more Java Server node processes or an optional SDM process.

The JControl process remains in charge of all other child processes. In cases where the SAP Java instance is not started by the ABAP dispatcher, a so-called standalone installation or single stack, the JControl process is launched by the regular “startsap” script. During the Java instance startup, additional processes are launched.


� SAPOSCol - collector for performance analysis at the operating system level

� Message server - part of SCS subsystem, similar to ABAP stack message server

� Enqueue server - part of SCS subsystem, takes care of LUW lock requests

� IGS - Internet Graphics Server, used to render graphics � WebDispatcher - optional; process to dispatch HTTP requests between

instances � CCMS Agent - optional; CCMS Agent for availability monitoring

13.3 JAVA TRACE AND LOG FILES

The SAP Java instance stores all kinds of information in different log and trace files. This list is a small overview of the most important files that need to be inspected in case of a problem with the startup of the Java instance:

� dev_jcontrol - trace file of JControl � dev_bootstrap - trace file of the initial bootstrap process � dev_bootstrap_ID.... - trace file of the node bootstrap process � dev_dispatcher - trace file of the J2EE dispatcher node � dev_server<x> - trace files of the J2EE server nodes � dev_sdm - trace file of the SDM process

Each SAP Java instance runs under a unique 8-digit ID that is dynamically created during startup time and will change every time you restart the instance.

Other important log f iles can be found in /usr/sap/SID/j2ee/work or /usr/sap/SID/DVEBMSGnn/work:

� jvm_bootstrap.out - JVM process console output of first bootstrap � jvm_bootstrap_ID.out - JVM process console output of second bootstrap � jvm_server0.out - JVM process console output of server node 0 � jvm_dispatcher.out - JVM process console output of dispatcher � std_bootstrap.out - OS standard output log file � std_server0.out - OS standard output log file � std_dispatcher.out - OS standard output log file Both JControl and JLaunch executables have a Java Virtual Machine embedded,

which is implemented using a dynamic link library (.dll on Microsoft Windows and .so on Unix and Linux). So, we do not see any JAVA process running at the operating system level, although they are there. Each of these embedded JVM

260 UPGRADING SAP

processes (they might appear as threads on the operating system level) have their own logging mechanism, which is also known as JVM Console logging.

13.4 JAVA CONTROL

The SAP Java startup and control framework also take care of the availability of the various Java and related processes.

Figure 13.8: SAP Java JControl availability management. ©Copyright SAP AG.

This is implemented through the main control process JControl. In case the JControl gets killed, it will be automatically started by the ABAP dispatcher in case Java is part of a dual-stack installation. The Message Server also does some pooling into the JControl process but is unable to do any reactive action. The “JCMon” tool is a command line utility to get a view of the availability of the Java instance. This utility can be compared to the ABAP stack utility “dpmon”.

13.5 AUTOMATIC STARTUP OF JAVA INSTANCE

As mentioned before, the SAP Java AS instance can be started as an integrated part of the ABAP engine startup. In order to establish this, certain instance profile


parameters need to be set. On the server where the Java instance is added, the following parameters need to be added to the SAP ABAP AS instance-specific profile:

• rdisp/j2ee_start = 1; for automatic startup of the Java engine. • rdisp/j2ee_start_lazy = 1; if this parameter is set to 1, the Java engine will

not be started before the ABAP engine is fully up and running (including initialization).

• rdisp/j2ee_error = <value>; if this parameter is set, a <value> number of attempts will be done before the startup will be stopped in case the engine does not start up.

• rdisp/j2ee_timeout = <seconds>; this parameter will control the time the Java engine gets to register itself to the ABAP dispatcher as fully started.

• icm/HTTP/j2ee_<xx>; TCP port that is allocated for all traffic between the Java engine and the ICM.

The Java engine can also be started, stopped, and restarted using Transaction SMICM → Administration → J2EE Server → Send Soft Shutdown → With Restart.

INFO It’s supported by SAP to run a JAVA AS 6.40 add-in installation in combination with an ABAP 6.20 system. This means the combination SAP R/3 4.72 Enterprise, based on ABAP 6.20, with Java instance 6.40 is supported. More information can be found in SAP Note 914486.

13.6 JAVA MANAGERS AND SERVICES

The SAP Java engine is based upon the standard implementation of the Sun J2EE (Java 2 Enterprise Edition) Application Server specifications 1.4.2 and will soon become available under JEE 5 specifications. In rough terms, this means that the Java application server is an implementation of a Web server (container) attached to a servlet engine and the support of EJB (Enterprise Java Beans). All building blocks support the J2EE 1.4.2 API, such as JMX, JDBC, JNDI, etc.

The Java 2 Enterprise Edition is an expansion on the standard J2SDK (Java 2 System Development Kit), which makes it easier to build and distribute applications in Java. The following features are part of the J2EE Application Server specifications:

• Support for the infrastructure of a distributed, concise application • Built-in support for authentication • Built-in support for simultaneous use with several users • Automated data raise • Built-in methods for guaranteed data integrity

262 UPGRADING SAP

• Built-in support for Enterprise Application Integration • Built-in support for naming services The architectural basis of J2EE has been pulled up around the idea of a three-tier

application: a front-end system that the interface for the user regulates, a back-end system that is used to store data (such as a database) and a middleware (or middle tier) where the actual work of the application is done (the so-called business logic). This follows the principle of the Model-View-Controller architecture and the entire J2EE concept has been based on the scalability of this architecture. On the basis of this architecture, J2EE supports the development of two classes of applications: light applications, or Web applications, and the very heavy, concise applications.

Figure 13.9: Java Application common building blocks.

Most common Java application servers are based upon this architecture: SAP J2EE Server, Oracle OC4J Server, BEA Weblogic, IBM WebSphere, Tomcat JBoss, and WebMethods.

Figure 13.10: SAP Java Application server managers.


These common Java building blocks have been expanded by SAP with Managers and Services. The SAP Java application server consists of at least the following Managers:

• Locking Manager – Takes care of all the lock requests within the cluster. • Cluster Manager – Takes care of all the event synchronization within the

cluster. • Configuration Manager – Takes care of the distribution of the configuration

information between the cluster nodes and the database. • Log Manager – This manager configures the logging routines for the kernel.

It provides properties for storing system-critical logs in the database. • Application Thread Manager – This manager supplies the threads in which

client applications’ source code is executed. It provides a set of properties for starting and managing client threads in the Java Virtual Machine.

• Class Loader Manager – This manager takes care of the loading of Java classes (compiled Java programs) into various Java Virtual Machines (JVM).

• Ports Manager – This manager provides a set of properties for the reconfiguration of the accepted client sockets. The options provided are used by the platform’s networking code as a hint for the size to set the underlying network I/O buffers

• Thread Manager – This manager supplies the threads in which SAP J2EE engine system operations are executed. It provides a set of properties for starting and managing system threads.

• Service Manager – This manager acts as a container, in which all services in the cluster are working. It provides a set of properties for management of services and the relations between them.

There are a few more managers in the system; however, they are not described here.

Some Managers run on just the Dispatcher process, some on the Server Node processes, and some on both. The list of Services running on the SAP Java engine is much bigger. To list a few of these services:

• Deploy Service • Log Viewer Service • Monitoring Service • JDBC Connector Service • SLD Data Supplier Service • Web Container Service These services can be started and stopped on the fly and configured through

the Visual Administration tool.

264 UPGRADING SAP

13.7 JAVA CONFIGURATION MANAGEMENT

The SAP Java Engine comes with three tools to manage application deployment and configuration:

• Visual Administrator The Visual Administrator is the main tool to manage all configuration items

and parameters of the SAP J2EE engine. The tool is based upon Java, and it uses the graphics capabilities of Java, namely Swing/AWT; it requires Microsoft Windows or X/Windows on UNIX and Linux. The tool connects to the SAP J2EE engine using the proprietary protocol called P4 and requires authenticated access. Once connected to the engine, it provides the option to configure all kinds of parameters that are stored in both the database and XML parameter files at the operating system level. The Visual Administration tool requires an up and running SAP Java instance.

The Visual Administrator runs on a PC or can be installed on a server and run through either RDP, PCAnywhere, or X/Windows emulation. This tool will soon be replaced by the NWA (NetWeaver Administrator), which is entirely based on browser technology.

Startup: (Windows) …\sap\admin\go.bat (Unix/Linux) /…./java/bin/java

–jar go.jar

• ConfigTool The SAP ConfigTool is used for configuration items that are related to the

startup and memory resources that are required by the SAP Java instance. This tool does not connect to any other running process. It just makes changes to XML and other properties files. The ConfigTool is, for example, used to add Server node processes to a Java instance.

Startup: (Windows)...\j2ee\configtool\ConfigTool.bat (Unix/Linux)../

j2ee/configtool/ConfigTool

• DeployTool This component is a graphical user interface that allows you to: - Generate J2EE archive components from existing class fields and

deployment descriptors - Assemble these components in an application EAR - Edit the deployment properties of an EAR or an archive component - Deploy an EAR or an archive component on the specified J2EE engine

cluster elements Startup: (Windows)...\j2ee\deploying\DeployTool.bat (Unix/Linux)../

j2ee/deploying/DeployTool


13.8 JAVA-SPECIFIC FILESYSTEMS

The physical location of the SAP J2EE engine files depends on the type of installation. If the SAP Java instance is deployed using the add-in installation method, the following filesystem structure is created:

/usr/sap/SID/DVEBMGSnn/ ← ABAP home /j2ee ← Add-In installation /admin ← Visual Administrator /cluster ← Deployed Applications /configtool ← ConfigTool /deploying ← DeployTool /log

/SDM ← SDM Software Deployment Mgr /work ← location of all log files /SCSmm ← Java Central Services /SYS ← ABAP kernel executables /profile ← ABAP + Java profiles If the SAP Java instance is installed as a standalone system, the following

locations are used to store all files: /usr/sap/SID/JCnn Java Central Instance (CI) /SCSmm ← Java Central Services (SCS) /usr/sap/SID/Jnn ← Java Dialog Instance (DI)

13.9 JAVA DATABASE ACCESS

The NetWeaver AS Java instance (aka SAP J2EE engine) is shipped with its own Database Access subsystem, which relies on various standards and protocols. The best known protocols are JDBC, SQLJ, and JDO, which is used by most other vendors as well. The JDBC protocol is the most commonly used version, but there is an intent to move to the more advanced SQLJ. The SQLJ protocol was developed by “The SQLJ Group,” a consortium comprised of database vendors and Sun Microsystems and is now the most used protocol by SAP applications hosted on the Java engine.

Any of the deployed Java applications can access data in the database using various ways—either through SQLJ (SAP Best Practice solution), JDBC (the more classic method), or through EJB, CMP, or JDO. Each of these protocol drivers are redirected through the Connection Pool subsystem that communicates to the OpenSQL for Java subsystem. This subsystem is more or less similar to the

266 UPGRADING SAP

OpenSQL engine of the ABAP engine. It consists of four major building blocks: Java Dictionary, which holds the information about all tables and fields and their definitions; Table Buffer (similar to what has been used by ABAP); SQL/JDBC Checker, which helps you in improvement of SQL statements (proactive); and the SQL Trace tool (reactive).

Figure 13.11: Building blocks of the SAP NetWeaver AS Java Database Access.

The Java database is stored as a dedicated database schema, which may or may not be combined with the ABAP database schema in a single physical database. The schema name is normally SAP<SID>DB for the primary part and an additional SAP<SID>MM for the SAP Enterprise Portals part.

13.10 JAVA PATCH MANAGEMENT

In order to apply patches to the SAP NetWeaver AS Java, a special tool is shipped, known as JSPM or Java Support Package Manager. This Java/Swing-based tool is located at /usr/sap/<SID>/<instance>/j2ee/jspm.

Startup: (Windows)...\j2ee\jspm\go.bat (Unix/Linux)../j2ee/jspm/go

It reads the files from the /usr/sap/trans/eps/in directory which are put over there by the customer. Patches are downloaded using the SAP Download Manager, either through the SDWC Web site or through the SAP Solution Manager Maintenance Optimizer.


Figure 13.12: SAP Java Support Package Manager. ©Copyright SAP AG.

As of NetWeaver 7.0 SP12, it is possible to deploy new usage types on an existing Java stack using JSPM. The packages that need to be installed should be located in EPS/in.

NOTE Additional information about the usage and prerequisites of SAP Java Support Package Manager can be found at http://service.sap.com/jspm.

13.11 SAP NWDI—JAVA CHANGE MANAGEMENT

Development with SAP NetWeaver Java Development Infrastructure is based on team-oriented and component-based development. With this infrastructure, developers work in a team and share their source code in the Design Time Repository

268 UPGRADING SAP

(DTR). The software is organized in components. Development configurations are used to define the developer’s view of the development infrastructure.

In contrast to the team-oriented and component-based development, the central component build is no longer based on command line tools and individually made scripts; instead it utilizes the Component Build Service (CBS) that is part of SAP NetWeaver Java Development Infrastructure. The CBS builds components and their dependents on demand and provides ready-to-use libraries and deployable files for developers and runtime systems. Furthermore, the software change management process now is automated. The Change Management Service (CMS) is used to transport software, including source code and libraries, through the landscape. Finally, CMS supports automated deployment of executables on central test servers and in production systems.

Figure 13.13: SAP NWDI building blocks. ©Copyright SAP AG.

The NWDI (formerly known as JDI—Java Development Infrastructure) is deployed on top of SAP NetWeaver AS Java and consists of DTR, CBS, and CMS. It is the recommendation of SAP to deploy it on its own dedicated infrastructure. The main reason for this is the workload requirements for the CBS application. The NWDI is the central tool where all Java developers connect via their NWDS (NetWeaver Development Studio), SAP’s own implementation of Eclipse Java IDE (Integrated Development Environment).

The NWDS can be deployed in two ways: completely local or partially local. If the NWDS is installed completely local, both NWDS as well as an entire copy of an SAP NetWeaver AS Java is installed on a PC. The database is hosted on MaxDB. This lets the developer build a Java application offline. The partially local installation only contains a copy of the NWDS toolkit.


Each developer should register all its development objects (programs, screen, and table definitions) in the DTR, which is nothing more than a multi-user version management tool. Once the Java development is finished, it needs to be packaged by using the CBS application. This process might take a lot of CPU power. The last process is the promotion of the package through the SAP system landscape by using the CMS. By using the CMS tool, a Java Package is promoted from “Design Time” into “Run Time.” However this CMS tool will be replaced by CTS+ once it is available.

13.12 SAP VISUAL COMPOSER

The SAP Visual Composer (formerly known as GUI Machine) is a Screen Painter tool to develop SAP Portal applications. It is positioned as a tool for power and advanced users and provides the ability to create serious end user applications without the need to program in any language.

Figure 13.14: Position of the SAP Visual Composer in the toolset. ©Copyright SAP AG.

The basic Portal content is developed using the Portal Content Studio, which is accessed through the Web browser. Complete Web Dynpro applications are created by using the NWDS and NWDI infrastructure. Although the NWDS contains a lot of code templates and generators, it still requires a lot of programming effort. The SAP Visual Composer is positioned right in the middle of these two other tools.

The SAP Visual Composer (VC) is accessed through a Web browser that supports Adobe Flash and Microsoft XML. From the VC screen painter it is possible to access all backend applications, such as ERP, BI, SCM, SRM, and CRM that are registered in the SLD connected to the Portal. The VC design-time system creates iView pages when finished that are hosted on the SAP Portals.

The SAP Visual Composer is shipped as part of the SAP Enterprise Portal. For EP 6.0 based on SAP Basis 6.40, it needs to be installed separately or is shipped with

270 UPGRADING SAP

a Support Package. Visual Composer is shipped by default with SAP NetWeaver Portals 7.0 and therefore does not have to be installed separately.

Both Design Time (the part that is used to build the application) and Run Time are embedded in the SAP Enterprise Portal. However, for the Design Time part, additional software is required for the desktop, which is Adobe SVG and Microsoft XML. With the release of NWCE 7.1, two Visual Composers are available: One that is shipped with NetWeaver Portals 7.0, and one that is shipped with NWCE 7.1. The Visual Composer that is shipped with NWCE is named Visual Composer 7.1 and resides as a plug-in in NetWeaver Development Studio 7.1 (based on Eclipse version 3.3). However SAP continues to support and develop Visual Composer 7.0

Figure 13.15: Screen shot of SAP Visual Composer. ©Copyright SAP AG.


13.13 SAP NETWEAVER COMPOSITION ENVIRONMENT

SAP positions itself as a platform solution vendor instead of ERP vendor. The NetWeaver platform is more than just a collection of components, such as Portals, BI, and PI. It’s a development and orchestration platform. Composite applications and Web services are critical in this architecture. The NetWeaver Composition Environment 7.1 (NWCE) is a product to develop and compose these types of applications.

The NWCE is shipped in two flavors: desktop and server edition. Both are based on the SAP AS Java 7.1 release, which is shipped with the new SAP JVM. The desktop version is supported on Windows XP (Vista will follow later) in combination with either Microsoft SQLServer 2005 or MaxDB 7.6. The server edition is Windows 2003 64 bits only. The purpose of NWCE is to extend the capabilities of the NWDS and incorporate the Visual Composer 7.1 into a single tool. The NWCE development platform is formed by SAP Netweaver Development Studio (NWDS), which is based on Eclipse 3.3 with extra plug-ins.

The NWCE acts as the main Design-and Run Time platform within the eSOA NetWeaver eco-system. Development objects can be promoted into the runtime landscape by using NWDI and Solution Manager with ChaRM and CTS+.

13.14 ADOBE DOCUMENT SYSTEM

Most users have a love-and-hate relationship with SAP software. Due to the size of the functionality of SAP, the interface can become very complex. Certain users that hardly access the system, for example, users that register their leave requests and expence claims in SAP, are not very familiar with the interface. A solution to this problem is Adobe Interactive Forms (AIF). AIF consists of input and output forms that are shown in a Web browser at the end user’s PC and are based on Adobe FlashTM technology, which is embedded in Adobe AcrobatTM. The PDF forms are actually stored in the SAP application and presented on demand on any end user screen.

The Adobe Document System (ADS) is the foundation of AIF and consists of a Design Time and Run Time component. There are actually two Design Time components: the Adobe LiveCycle DesignerTM which runs on a PC and the Form Builder in ABAP Workbench transaction SE80. Once the AIF forms have been created and tested, they are deployed on the ADS that runs on the NetWeaver Java AS.

End users should have two components installed on their PC: Adobe Acrobat PDF viewer and Adobe Active Components Framework (ACF). This ACF framework is based on Microsoft OCX (ActiveX) technology and needs to be installed, enabled, and allowed to run on the PC.

272 UPGRADING SAP

Figure 13.16: SAP Adobe Documents Services building blocks.

NOTE There are companies that have strict policies about running ActiveX components on desktop PCs. In case this is applicable, it needs to be sorted out first before deployment can be done.

The Adobe Interactive Forms are mainly used for applications where users need to fill-in data to a form. An example of this might be all kinds of self-service applications. The forms may be based on templates that are supplied by external vendors and institutions. A good example of this is the American Tax Authority IRS, which supplies all kinds of PDF forms that can be imported into the Adobe LiveCycle Designer and are ready to be used in any SAP application.

The ADS will, in most cases, be the reason to deploy the NetWeaver Java AS system next to the SAP ERP 6.0 system. The ESS/MSS (Employee Self-Service/Manager Self-Service, part of HCM—Human Capital Management) will use Adobe Interactive Forms in various scenarios.

TIP Additional information on ADS can be found at http://service.sap.com/adobe.

13.15 CTS+

The success of an SAP project is mainly driven by the Change Management process done during the implementation. The core toolset for SAP Change Management is TMS (Transport Management System). However, the TMS toolset


has one big drawback, which is that it only supports ABAP. As of the release of SAP NetWeaver, a significant portion of the SAP solution is delivered through the Java code and therefore can only by managed through a proper Java-supported change management toolkit. CTS+ is positioned as such a toolkit. It is an extension of the existing CTS functionality that resides in TMS. The CTS+ toolset runs on any NetWeaver 7.0 SP12 and higher system and runs on ABAP and Java. The part that runs on Java contains the Web server and Web services. The Web server is used for portal content developers and NWDS users to create transport requests. The web interface will also offer the option to upload portal EPA and PAR files. These EAR files originate at NWDS and the TPZ files at XI, and are loaded into TMS. This makes it possible to create and manage transport request that contain both ABAP and non-ABAP objects. Once the transport requests are released, it will just create a co- and datafile with the EPA, PAR, EAR, and TPZ files embedded.

Figure 13.17: Transport with both ABAP and non-ABAP objects embedded. ©Copyright SAP AG.

The promotion of these transport requests, with both ABAP and non-ABAP objects, is done exactly the same way as with the normal TMS functionality. It is possible to use the ChaRM (Change Request Management) functionality on top of CTS+, which makes it possible to synchronize ABAP and non-ABAP objects between different components in the landscape. Both CTS+ (Domain Controller and Web server) and ChaRM can run in the SAP Solution Manager 4.0 dual-stack installation.

NOTE CTS+ is also known as OTO (One Transport Order), which refers to the ability to be sure that all objects, ABAP and non-ABAP, are promoted in the same order.

274 UPGRADING SAP

Chapter 14SUPPORT TOOLS

SAP has released many tools over time, which might help you during your upgrade project. Most of these tools are free of license fees. Some of these tools are part of your SAP application; some need to be installed into your

SAP system in order to use them.

14.1 ASU (APPLICATION SPECIFIC UPGRADE)

Although most application-related data conversions are handled by the XPRA phase, a couple of steps still need to be done manually by the functional support staff. An example of such a conversion is the report variant, which requires some special attention after the upgrade. To help automating this task, SAP has developed the “ASU Toolbox,” which consists of a set ABAP reports and programs to run such conversions.

The ASU Toolbox consists of a main screen with all the required and optional steps. Each step consists of an ABAP program that performs a certain postupgrade step, which normally needs to be done manually. The ASU Toolbox is not part of standard “SAP R/3” and therefore needs to be imported just before you start upgrading the system. The source release of your upgrade determines the exact version of the ASU Toolbox you have to import into your system. Once the ASU Toolbox has been imported into your system using CTS or “tp import,” it can be accessed through transaction code SE38, by running report “RASUTGA1.”

275

276 UPGRADING SAP

Figure 14.1: Main screen of ASU Toolbox. ©Copyright SAP AG.

INFO Information about the ASU Toolbox and the transports and software can be found in SAP Note 623723. This note also includes various PDF documents as attachment.

14.2 SAP SOLUTION MANAGER

The SAP Solution Manager (SSM) becomes more and more important to all companies who make use of SAP software. It is positioned as a full “Life Cycle” support tool for any SAP implementation and any SAP system. It consist of tools that help the implementation of an SAP application, and to support (Run and Maintain) a running SAP application. The official SAP statement on this is “The SAP Solution Manager is a platform that provides the integrated content, tools, and methodologies that you need to implement, support, operate, and monitor your enterprise’s solutions from SAP.”

The SAP Solution Manager’s current release is 4.0 and is positioned as the target release for the next few years. The Solution Manager can be used as a central configuration repository for various different SAP applications, such as SAP

SUPPORT TOOLS 277

ERP, BI, and SRM. The configuration effort is done in the Solution Manager and propagated to the various SAP components. The SSM 4.0 can also be expanded with new functionality that is shipped with either Support Packages or Enhancement Packages. For example, the new CTS+ and DBACockpit are shipped in Support Package 12, where TDMS is shipped with Support Enablement Package 1.0.

Figure 14.2: Business Process Monitor in SAP Solution Manager. ©Copyright SAP AG.

Another function of the Solution Manager is known as the Support Desk functionality, which uses the standard functionality of SAP CRM. The “SAP Competency Center” of any organization can use this functionality to process all requests coming from the business and forward them to SAP Global Active Support.

A third function of the SAP Solution Manager is to monitor infrastructure and applications. SAP Solution Manager uses the SAP CCMS engine, which is part of the SAP Basis layer, as infrastructure for Business Process Monitoring (BPM) and Business Activity Monitoring (BAM). The CCMS engine is used to collect all events,

278 UPGRADING SAP

logs, and issues from the various components and send through the RFC protocol to the Solution Manager. The Solution Manager is able to react to these kinds of events and is capable of sending alerts to support staff. Solution Manager is also able to collect data about performance, batch jobs, and perform trend analysis.

Besides infrastructure monitoring, the Solution Manager also provides the option to monitor business processes. This monitor is based on action and document flow of certain business processes. When a document gets stuck in one of the components (due to logical or infrastructure issues), Solution Manager is able to alert on this.

Figure 14.3: Overview of “Solution Monitor” in SAP Solution Manager. ©Copyright SAP AG.

Another nice feature of SAP Solution Manager is the ability to create Service Level Reports (SLR). Such reports are generated on a PC using SAPGUI, Microsoft Word, and Excel. The CCMS data that is used in the SLR report is obtained using the SDCC engine, the same engine that is used for the EarlyWatch reports. The SLR does have exactly the same layout and text as an EarlyWatch report. The only difference between the SLR and an EarlyWatch report is the lack of SAP recommendations in the SLR.

As mentioned in earlier chapters, the SAP Solution Manager is used to create installation and upgrade keys and is the only way to download Support Packages. The SAP Solution Manager Maintenance Optimizer (SSM MOP) is used to prepare

SUPPORT TOOLS 279

the download basket. Once prepared, this download basket is accessed using the SAP Download Manager and used to download all packages to the PC.

INFO Information about ordering, installing, managing, and using SAP Solution Manager can be found at http://service.sap.com/solutionmanager.

14.3 SEP (SUPPORT ENABLEMENT PACKAGE)

The Support Enablement Package is delivered as an Enhancement Package for the SAP Solution Manager and contains the following modules:

• SAP Test Data Migration Server (TDMS) • SAP Custom Development Optimization Package (CDOP) • SAP Reverse Business Engineer (RBE) • BMC Appsight for Windows/.Net • CA Wily Introscope • SAP Best Practices for Operations It expands the SAP Solution Manager with tools that allow for a better

understanding of the usage of the system from a functional and business perspective.

Figure 14.4: Position of SEP in upgrade roadmap. ©Copyright SAP AG.

Three beneficial tools are SAP TDMS, SAP CDOP, and SAP RBE. Each tool has its own footprint and purpose. However, bear in mind that the SEP suite is a licensed product. Information on SAP SEP can be found at http://service.sap.com/ssep.

280 UPGRADING SAP

14.3.1 RBE (Reverse Business Engineer)

Reverse Business Engineer 2.0 is a tool that was available free of charge in the past and helped to discover the usage of the SAP system. It ran on PCs and used MSDE (Microsoft SQL Server Desktop Engine) as a database. The tool acquired all kinds of usage data for the SAP system. This information was extracted from various tables and included data about configuration settings, used business processes, ABAP reports, and programs. The output of the tool could be used to determine what modules and business processes were really used in the system. The RBE 1.0 tool is no longer available and has been superseded by SAP RBE 3.0, which resides in the SEP Enhancement Package for SAP Solution Manager. The SAP RBE 3.0 tool itself consists of two parts: the extract reports, which should be installed on the SAP R/3 system, and the front-end tool that runs on a PC. The SAP RBE 3.0 kit has exactly the same architecture as RBE 2.0. The only exceptions are the integration with SAP Solution Manager and the support for both SQLServer and MaxDB.

The extractor runs an ABAP report ZRBE_GENERATE_EXTRACT in the SAP R/3 system, which needs to be of an SAP release of 4.6C or higher, and creates various files (types TXT and XML) that can go up to 2GB in size. These files are loaded into the SAP RBE 3.0 front-end tool that uses a database (either SQLServer or MaxDB) to store results and filtered sections. The database can be installed locally or remotely.

Figure 14.5: SAP RBE 3.0 front-end tool. ©Copyright SAP AG.

SUPPORT TOOLS 281

The SAP RBE 3.0 front end is based on Microsoft .NET 2.0, which means this is a prerequisite for the installation.

The result and analysis provides the ability to see what functionality is configured and used in the SAP R/3 system. This information might help in the assessment of the upgrade and associated elapse time of the project.

NOTE The SAP RBE 3.0 tool is only able to work with SAP R/3. None of the other SAP applications are supported.

14.3.2 SAP CDOP

The SAP Customer Development Optimization Package provides a comprehensive set of functions to optimize tasks in the area of customer-specific developments. This is very convenient during upgrade projects. The SAP CDOP tool consist of three parts—two standard parts and one optional part:

• Clearing Analysis • Upgrade/Change Impact Analysis • Add-on Assembly Kit (optional) The Clearing Analysis tool is used to identify and analyze obsolete repository

objects. The results of a Clearing Analysis are an ideal starting point for the clearing process for custom development. The Upgrade/Change Impact Analysis tool helps with the assessment of the technical impact of an SAP Upgrade or Support Package with respect to custom developments. It will estimate the amount of work required for adapting them.

Finally, the Add-on Assembly Kit is a toolkit for assembling and delivering custom developments as SAP-like add-ons. It can serve as the basis for group rollout and for consistent and standardized change and release management.

All three parts make use of the same characteristics collector, which collects information about the relations and usage of the following objects:

• Domains • Data elements • Tables • Transactions • Table types • Views • Classes • Function groups • Programs • Type pools • Enqueue objects

282 UPGRADING SAP

• Cluster/pool structures • Matchcode objects All these objects are registered in the customer name range or name space. The resulting report is shown on screen by using traffic lights. Severe problems

are indicated in red and warnings in yellow. The report ends with the summation of all objects.

14.3.3 SAP TDMS (Test Data Migration System)

Issues about the size, and therefore the associated costs, of having a test server with a copy of “real” production data are known to most of us. There are third-party tools available to create a test database, which is a subset of the production database. However, SAP has decided to develop such tools of their own and one is called the TDMS (Test Data Migration Server). The TDMS is a tool, which is based on ABAP, that takes care of managing one or more databases that are created as clones of SAP production databases.

In today’s world, most administrators create a test database by the restoration of a backup of the production database on a different server. This process has a few drawbacks: extra server hardware is needed, extra disk storage is needed, restoration of settings is required, creation of users, and adjustment of authorizations to be done. Most of these activities are manual and may result in errors. It also comes with an audit issue, because the SAP test instance contains sensitive production data.

Figure 14.6 SAP TDMS engine building blocks. ©Copyright SAP AG.

The TDMS runs as part of the SAP Solution Manager and takes care of the following things:

• Information on structural relationships

SUPPORT TOOLS 283

• Production and non-production systems • Definition and storage of business rules (controlling of objects to be

migrated) • Consistency relations • Controlling/monitoring during migration • Protocol functionality for the migration process The TDMS engine is basically an advance client-copy tool. All data is copied

from one client to another (remote) using RFC with the use of special filters. It acts as a mediator between the production instance and the test data instance

and thus is logically placed in between. The TDMS uses three different reduction scenarios in order to achieve this goal:

• TDSHL – (System Shell) Contains cross-client data and user-master data, but not the client-dependent data. This is the minimum required data to run an SAP client.

• TDMDC – (Master Data and Customizing) - This leads to a minimal system for demo, testing, and training. Only user-master and customizing data are included. Stock-taking data can be added optionally.

• TDTIM – (Time Based) - All client data is copied, including transaction data. However, the transaction data can be limited by using the FROM DATE clause.

14.4 LAW (LICENSE AUDIT WORKBENCH)

The SAP License Audit Workbench (LAW) is an add-on that is available by default in SAP Web Application Server 6.10 and higher, and can be installed in older SAP systems through a single transport. The LAW helps to collect all user information with respect to license-fee obligations. All collected information can be sent to SAP A.G. for further processing. This tool is pretty helpful for complex landscapes with various components for customers with a Component-Based License agreement, rather than a mySAP.com license agreement.

INFO Information about SAP License Audit Workbench (LAW) can be obtain though the following link: http://service.sap.com/licenseauditing.

14.5 UPGRADE ROADMAP

Positioned as a central guide for the entire project team, the SAP Upgrade Road Map provides SAP’s latest upgrade methodologies to plan and execute an SAP upgrade project. It is a collection of SAP’s latest knowledge and best practices on

284 UPGRADING SAP

project management. It also contains functional and technical aspects of upgrading an entire SAP system landscape, regardless of the selected components.

The SAP Upgrade Road Map is structured along the following five phases: 1. Project Preparation 2. Upgrade Blueprint 3. Upgrade Realization 4. Final Preparation for Cutover 5. Production Cut-over and Support The upgrade roadmap basically follows the same sequence as the SAP ASAP

methodology, which is used for SAP implementations. The first phase is used to prepare the project that includes the upgrade business case, project scope, team setup, supplier- selection and user community engagement. The second phase is used to perform a gap analysis between the current and target SAP release. Through this mechanism, new functionality will be brought into the system and will be configured appropriately. During the third phase, a couple of test upgrades are performed and all additional configurations for the new release are done. The fourth phase is used to prepare and create the runbook for the final cut-over of production from source to target release. The fifth phase includes the actual cut-over of the productive environment to the target release.

The latest version of the SAP Upgrade Road Map 3.1 includes the latest updates on upgrade content for application-specific and technology aspects of SAP Business Suite 2005 (SAP ERP 6.0), major enhancements for project management, and content that is based on PMI standards as well as a new topic section called “Global Delivery Consideration.” See http://service.sap.com/upgrade for more details.

14.6 ARIS FOR NETWEAVER AND RBEPLUS

The RBEplusTM (RBE means Reverse Blueprint Evaluation) is used to extract information from the productive SAP system and feed it into the ARIS® Modeling tool. This eliminates the manual rework of mapping business processes in ARIS and subsequently the SAP Solution Manager. The RBEplus tool uses information from the ST03 database (e.g., table MONI) to obtain information about the used modules and transactions in the system. This information is combined with the customizing settings in SPRO to form an overall business view. The combination ARIS for NetWeaverTM (ARIS is an add-in installation on top of the SAP NetWeaver AS) and RBEplus make sense for customers who wants to re-implement SAP, either through a fresh install or upgrade, based upon an existing installation. The collected information is sent from RBEplus into the ARIS toolkit. This graphical CASE (Computer Aided Software Engineering) tool is later being used for Business Processes Modeling.

SUPPORT TOOLS 285

INFO More information on the ARIS for NetWeaver suite and the IBIS tool RBEplus can be found at http://www.ids-scheer.com.

14.7 ASSESSMENT WITH INTELLICORP

The last support product suite described in this chapter is from IntelliCorp®. This vendor delivers a complete suite of tools under the name of LiveCompareTM that help in creating assessments for SAP Upgrades and for an implementation of Support Packages. The tool is able to create a gap analysis between the current SAP system and the SAP target release. Either by using an existing target SAP system or through object lists. IntelliCorp also delivers the LiveModellerTM suite which offers similar functionality as ARIS for NetWeaver product.

INFO More information on the suite of products from IntelliCorp can be found at their Web site http://www.intelliCorp.com.

14.8 ADDITIONAL INFORMATION RESOURCES

The SAP Service Marketplace contains additional information related to SAP Component upgrades. Information can be found about the target release of your SAP upgrade. In cases where the upgrade is from SAP R/3 4.6B to R/3 Enterprise 4.72, it will show all differences between the two releases. The information can be found at http://service.sap.com/upgrade → “Development News Browser.”

Figure 14.7: Selection screen of Development News Browser. ©Copyright SAP AG.

286 UPGRADING SAP

To obtain more information about the (new) functionality of the SAP Component target release, you will find under http://service.sap.com/upgrade → “Upgrade Content” → “Business Maps.” The information is listed per business and industry sector.

14.9 UPGRADE COACHING

Besides upgrade tools that help finish the upgrade project successfully, it is also possible to obtain services from SAP A.G. These services range from the performance of a complete upgrade to hiring consultancy hours. The last option is quiet popular and very beneficial. This service is known as the “Upgrade Coach” and is based on buying consultancy time from SAP itself. Such a consultancy is assigned to the project and helps the project with the up-front assessment, planning, sizing, selection of functionality, gap analysis, and the actual upgrade of the landscape itself.

INFO All information on SAP services from upgrades can be found at its own section at http://service.sap.com/upgradeservices.

Chapter 15THE DIRECTION OF SAP

This chapter takes a closer look at what the future might look like with respect to SAP applications, and what infrastructures will be at our disposal. It will emphasize the future trends in general and SAP in specific, for both business

and technology. Everybody wants to know what the future might bring, especially what the stock market is going to do. Unfortunately, that is not possible; however, what is possible to predict are certain trends in the IT industry and how they can be leveraged in business processes. Such trends should be incorporated into the SAP upgrade plans and roadmaps.

15.1 ROADMAPS

It is common practice for companies to have certain roadmaps in place—Business Roadmaps for functionality and Technology Roadmaps as enablers. What technology will be implemented in the (near) future in order to host this functionality and how it is segregated.

The Business Roadmap includes a time line and release overview per SAP application and component. It also might include what type of business is implemented and whether things are shared or business-sector specific. Such a roadmap is, of course, dependent on the size of the company and the way the business processes are implemented. However, it is recommended to see whether things that are not business-sector specific can be shared between various sectors or hosted in their own SAP system. Processes such as procurement, Human Resources

287

288 UPGRADING SAP

(payroll, employee self-service, travel expenses, and personal administration and development), finance, and real estate are good candidates for such central services. Also, the management of company master data is a candidate for this.

The technical roadmap will contain decisions on what technical platform the (future) SAP system will be on. A rough forecast on capacity is included as well as when release upgrades are planned. This roadmap will also include decisions around message handling (A2A Process Integration), Central Master Data Management, User Interfaces, Identity Management, System Monitoring, Event Handling, Disaster Recovery, and High Availability. It should also include decisions on platforms, storage technology, network technology, technical security options, and virtualization methods.

15.2 SAP xAPPS

SAP xApps or “Cross-Applications” are applications that are written by SAP or partners of SAP that fulfill so-called “Next Practice” business requirements. “Next Practice” business requirements are certain industry-specific or company-specific business requirements that are not “Best Practice.” SAP xApps can be written in either Java or ABAP and follow certain rules to communicate with their environment. Various xApps applications have been released, either developed by SAP or partners. Examples of such xApps are: xPD (Product Definition), xRPM (Resource and Program Management), and xIEP (Integrated Exploration and Production). The main goal of xApps (next practice) is to provide integrated business applications to companies above “best practice” applications. So business processes like “Procure-To-Pay” and “Hire-To-Retire” are common in any company, and therefore such processes should be implemented as Best Practices and reside in the SAP Business Suite. On the other hand, business processes that are unique to a certain industry or company should be implemented as Next Practices.

Figure 15.1: Position of SAP xApps in the software stack. ©Copyright SAP AG.

THE DIRECTION OF SAP 289

An xApps application is like glue between various other applications. One important element of an xApps is the Composite Application Framework (CAF). This framework’s intent is to standardize and harmonize the way software and Web services are working together. The idea behind CAF is not new; the famous API (Application Programming Interface) that is offered by software vendors, such as Microsoft, Oracle, BMC, IBM, Borland, etc., already fulfill this role. However, in general, APIs are bound to programming languages, hardware platforms, middleware, and database subsystems. CAF is not bound to any architecture, it is language neutral, and is self-describing. The current development tool for CAF and xApps is either ABAP Workbench or NWDS, but will be expanded with NWCE (Composition Environment) as of NetWeaver 7.1.

INFO Additional information on xApps can be obtained via http://service.sap.com/xapps.

15.3 eSOA

Within a few years time, the IT world will move from business-centric client/server architecture to an inter-business (collaboration) centric Web services architecture. A Web service is an automated (through IT) business task that can be accessed using an open standard interface, called SOAP (Simple Object Access Protocol, www.w3.org/TR/soap/) and described by another open standard called WSDL (Web Service Definition Language, www.w3.org/TR/wsdl). Each business process will be divided into smaller atomic units, called tasks. Each task will be run by a Web service–oriented application, which is hosted within (in source) or outside (outsource) the company. The most often used example to explain Web services is about the “Travel Agency.” Assume you want to book a trip to the Caribbean. Through a Web site, from a single transaction, you are able to book the To and Return flight, the rental car, and the hotel. Each step within the transaction is implemented as separate Web service, which resides with another company. So the “Travel Agency” application calls the car-rental Web service to book the car, flight Web services for the flight reservations, and a hotel Web service for the Hotel reservations.

Various protocols are used for Web services: XML, SOAP, Internet, WSDL, UDDI, and WS*. All these protocols ensure that applications (businesses) are able to collaborate (work together) with each other and that information is (secure) shared and not get lost.

290 UPGRADING SAP

Figure 15.2: Protocol stack used by Web services.

Web services are platform and language independent. Most development tools are able to generate “Web service” proxies for any piece of program code. This provides the option to reuse existing code and make it accessible as a Web service. In the forthcoming years, SAP will do the same with all their applications. Most of BAPI’s will be accessible using Web services.

To be able to find such Web services on the Internet, a UDDI (Universal Description Discovery and Integration (www.uddi.org), standard has been developed to create directories to keep the definition and location of Web services. There are public UDDI services, but it is recommended to deploy an “Enterprise”-specific UDDI service within the company.

Figure 15.3: Enterprise SOA landscape with ESR. ©Copyright SAP AG.

eSOA (enterprise Services Oriented Architecture) is SAPs offering to create inter-enterprise-wide Web services. By using these Web services, companies are able to automate business process exceeding company boundaries. When several


different Web services are bundled and published as a single solution, it is called an “Enterprise Webservice.” The first (partial) implementation of SAP eSOA architecture is SAP NetWeaver 7.0, but becomes fully available through release 7.1, which contains the full functional Enterprise Services Repository (ESR). The world of Web services (preferably implemented with SAP tools) should result in an eco-system that is driven by a community of members with both commercial and noncommercial interest and therefore similar to the Open Source community. Time will tell whether this is going to work or not.

Two major scenarios are supported by the ESR: Composition and Integration. The Composition scenario is meant to create business applications that are composed of various Web services using CAF and NWCE. The Integration scenario is based on the more classic EAI (Enterprise Application Integration) method of coupling applications. In both cases the ESR will contain references to Web services used within the enterprise. The tool provides the option to store and manage all external and internal Web services via a browser-based interface. The ESR itself is shipped through SAP NetWeaver Process Integration (PI) 7.1 or SAP NetWeaver Composition Environment (CE) 7.1.

15.4 BPP (BUSINESS PROCESS PLATFORM)

The first steps taken by SAP in the eSOA world were done through the release of NetWeaver PI 7.0, which serves as an A2A (Application-to-Application) interface tool between SAP and other software. With the release of NetWeaver 7.1 (also known as NetWeaver 2007 Code name “New York”), SAP has gone a step further. It will contain a UDDI 3.0-compatible Enterprise Services Repository, some kind of Yellow Pages, which stores descriptions of Web services, interfaces, and global data models. This will enable all customers to fully leverage the potential of building, using, and managing Web services across the enterprise and beyond.

The Business Process Platform (BPP) is a design and runtime platform to run enterprise business processes that are based on open standards and are vendor agnostic. The core of BPP is SAP NetWeaver PI for Process Integration, a UI layer to access the business applications, and Web services to run business logic. These Web services are basically implemented in the SAP backend systems, either through traditional components, such as SAP ERP, CRM, SRM, and SCM, or through composite applications (xApps). In order to secure investments of the past, most SAP ERP, CRM, SRM, and SCM components are either entirely rewritten or wrapped into a Web service. It is breaking up the software into smaller chunks that customers can snap together and break apart—like Lego building blocks. They are tied together with other open Web services. The advantage: customers can pick and choose the features they need, and even add up building blocks provided by companies other than SAP. This will let them create and modify applications faster and more cheaply than they can today. It is the intent of SAP to promote SAP

292 UPGRADING SAP

PI into a Business Process Platform (BPP). In other words, the BPP system becomes the central repository and controller for all Web services.

Where SAP R/3 was based on modules and transactions, the BPP will be based on Business Processes, such as Procure-to-Pay, Make-to-Order, and Hire-to-Retire. Processes like these are already available in SAP R/3 and are also available through Portal Business Packages, but BPP will bring it to a higher level. That means the processes are more flexible, adjustable, and easier to implement by non-IT-educated staff. In order to create a better understanding of what processes are bounded to corresponding Web services, SAP has organized all of their Web services in so-called ES Bundles. An ES Bundle is a collection of enterprise Web services around a certain common business process. Examples of such ES Bundles and business processes are Procure to Pay (P2P), Order to Cash (O2C) and Hire to Retire (H2R).

15.5 BPEL (BUSINESS PROCESS EXECUTION LANGUAGE)

The next step is to enable all SAP backend software components, such as SAP ERP, SRM, CRM, and SCM into Web services, so they can be easily used as such. Building such applications and using Web services that reside on various backend systems is known as Orchestration. It is done by translating business processes, described using workflow schemas, into Composite Applications. A commonly used language for this is known as Business Process Execution Language (BPEL) which is based on XML.

The actual business processes will be orchestrated using the NetWeaver Composition Environment, via the Process Modelling plug-in (code-named Galaxy) of NetWeaver Development Studio. This tool provides the ability to model business processes in a format known as BPMN (Business Process Modelling Notation). Once a model is created and converted into the BPEL format, it will be executed on the Business Process Platform runtime environment. SAP has plans to release its own BPEL applications via a mechanism known as Process Extensions.

One important requirement for B2B (Business to Business) processes is a standard for data exchange. The problem is not so much the exchange protocol, but rather the format of the data objects. In order to exchange such data objects between B2B collaboration partners (via the execution of Web services), a standard has been developed. This standard includes all known data types that can be used within companies and between companies. The development of this standard took place with support of the United Nations (UN/CEFACT CCTS) and ISO 15000-5, and is known as Global Data Types (GDT). The GDT standard defines to the lowest level the exact layout of a certain data object. For instance, what fields and with what length a company’s price tag is built upon.


15.6 NEW ROLES AND RESPONSIBILITIES

The required IT skills to leverage the potential of the SAP eSOA ecosystem is different from the skills available today. A couple of new roles have been introduced to build and maintain IT systems effectively, based on eSOA.

• Information Architect – is basically responsible for the translation of information that is needed across the enterprise and beyond. Centralized data management (Master Data Management) is part of such a role.

• Solution Architect – (formerly known as the SAP Functional Consultant) is responsible to identify business needs and translate them into solutions. Business Processes are the basic building blocks for such solutions. The Solution Architect should be familiar with at least three SAP ERP modules and various components. Knowledge of programming, data modeling, and User Interfaces are also required.

• Infrastructure Architect – (formerly known as the SAP Basis Consultant) is responsible for the design, implementation, and maintenance of all technical infrastructure needed to run all SAP components. Main areas of knowledge are databases, operating systems, networks, desktops, and servers.

• Enterprise Architect – this role becomes more and more important because enterprises are growing beyond their own boundaries. The Enterprise Architect’s main responsibility is to keep business and IT aligned. An Enterprise Architect strives for a maximum ROI on IT investments and helps with the prioritizing of business opportunities and translates them into IT plans and roadmaps.

15.7 USER INTERFACES

In the past, SAP software could only be accessed through the SAPGUI. With the introduction of ITS and Portals, SAP components can now also be accessed using a Web browser, such as Microsoft Internet Explorer, FireFox, and Mozilla. A new generation of UI platforms has been added to the portfolio. These new UI platforms are PDA (Personal Digital Assistants), SmartPhones, and the DUET solution. The DUET solution is the result of a partnership between SAP and Microsoft. DUET enables users to access SAP solutions via Microsoft Office components, such as Outlook. A typical DUET scenario would be time-writing in the Outlook Calendar. This information can be used for billing purposes in SAP ERP.

INFO Additional information on DuetTM can be found at www.duet.com.

Another initiative that will be released soon is the Muse client. The Muse client is a so-called thin client, running on a PC. The client has a smaller footprint than

294 UPGRADING SAP

SAPGUI, but is as big as a Web browser. The Muse client fills the gap between both UI platforms. Although the future is with Web browser–based applications, for some power users the Web browser interface is too cumbersome to work with. The Muse client runs as a small footprint on a PC and uses a combination of Web protocols (HTTP, SSL) and SAPGUI (DIAG, RFC) protocols.

15.8 ON-DEMAND COMPUTING

Another trend that needs to be on the radar screen of any IT manager is On-Demand Computing. Two major flavors of On-Demand Computing can be identified: Hosting, and Software as a Service (SaaS). SaaS used to be known as Application Service Provision/Provider (ASP). With Hosting, only the infrastructure is externally managed, but all other IT responsibilities are still within the enterprise. With SaaS, the entire IT infrastructure, plus all software, resides outside the enterprise and is accessed using Web technology. In most cases, SaaS software is generic and therefore not adjustable. The expectation as of this writing is that SaaS will only be adopted by small companies and SMBs (Small and Medium Businesses).

15.9 SAP ADAPTIVE COMPUTING INFRASTRUCTURE

With an increasing number of different applications and higher availability requirements, the hosting of application infrastructure becomes more complex. Therefore, the industry has kicked-off several initiatives.

SAP Adaptive Computing Infrastructure (ACI) is a solution and initiative from SAP to address the issue of increasing requirements for flexibility and on-demand business. The solution is based on the idea of the decoupling of infrastructure consumers and resources. All computer resources are virtualized, which means that all software components (the so-called infrastructure consumers) can run on any piece of hardware, regardless of the operating system and hardware platform, or vendor.

Import initiatives are virtualization using logical partitions or guests. In this hosting model, the SAP system no longer runs on dedicated hardware, but in a logical system. Various solutions are already available. Such solutions are based on VMWare ESX running on either Linux or Microsoft Windows. Also, high-end solutions, such as IBM pSeries and iSeries virtualization, using micro-partitions, can be deployed as can similar solutions from Hewlett Packard Virtual Server Environment (VSE) and Sun Microsystems N1 technology.


Figure 15.4: IT Provisioning logical view.

The implementation of Adaptive Computing is done in two steps. During the first step, all applications are migrated to “virtualized” hardware. This step is also known as hardware or server consolidation. The second step is the implementation of the “provisioning” layer. This layer consists of various software applications that measure the workload of the applications, and adjust hardware usage parameters. The SAP ACC intends to act as a hardware-vendor-neutral IT Provisioning layer.

Most SAP-certified hardware vendors started with the delivery of solutions on top of SAP ACC, such as Hewlett Packard with Adaptive Enterprise for mySAP (AE), IBM with Dynamic Infrastructure for mySAP (IDI), Fujitsu-Siemens with their FlexFrame for SAP, and Dell with their Adaptive Computing (AC) initiative.

The SAP ACC controller consists of a dedicated SAP system, running both SAP ACC (based on WebAS 6.40 Java), an SLD, and a Solution Manager. The ACC Controller is able to kick-off scripts on the various SAP application servers. These are start, stop, migrate, clone, and backup scripts that are provided by the various vendors.

Figure 15.5: Position of ACI in SAP business solution. ©Copyright SAP AG.

The SAP ACI initiative attempts to bring the hosting of application infrastructure to the next level. With an increasing demand for availability (global businesses),

296 UPGRADING SAP

flexibility (mergers and acquisitions) and lower costs, classical infrastructure hosting becomes a problem. With classical hosting, we mean the architecture that is based on coupling between applications and physical hardware.

Figure 15.6: Technical building blocks of SAP ACI. ©Copyright SAP AG.

The SAP ACI is based on the following building blocks: � SAP ACC (Adaptive Computer Controller). This is a dedicated SAP

NetWeaver AS Java system, which can be accessed using a Web browser. It shows the panel (SAP ACI Console) that contains all hosted applications and servers. Through this panel, the system administrator is able to configure (deploy, remove, migrate, and clone) applications on top of physical servers or logical partitions.

� SAP SLD (System Landscape Directory). This function is embedded in the SAP J2EE engine and acts as a central repository of all assets in the IT landscape, such as applications, middleware components, and infrastructure devices.

� SAP Solution Manager. This system is used to collect all CCMS information regarding server utilization. These numbers are shown in the ACI console.


This system does not have to be a dedicated system, but can be shared with other SAP Solution Manager functions.

� SAP Standalone Gateway. Use to route RFC traffic. Only required when SAP ACC and Solution Manager are running on different servers.

� SAP applications. Basically every SAP component can be controlled from within the SAP ACI framework.

� SAP ACC can be integrated in the NWA (NetWeaver Administrator) tool.

INFO More information on SAP ACI can be found at http://service.sap.com/adaptive.

15.10 E2E MANAGEMENT

As a result of many customer surveys, SAP has decided to move into the space of the end-to-end (aka E2E) solution management. This includes a broad range of tools that are embedded in either the SAP Solution Manager and any of the other tools, such as DBACockpit, which resides in any NetWeaver 7.0 system under transaction code DBACOCKPIT or E2E RAC (Root Cause Analysis), which is embedded in the new Work Centers and shipped with SAP Solution Manager support packages. Some of these new tools are also shipped via Enhancement Packages for SAP Solution Manager. An important new toolset is Extended Traceability (ET for short) that helps in the compliancy space, but does not focus on user provisioning. Where SAP GRC focuses on user provisioning and segregation of duties, Extended Traceability will support the object change management in the solution landscape. The solution is based around Change- and Test Management, and document processes and procedures.

The new transaction DBACOCKPIT is a further development of what was started as transaction DB50 and DB06, which were specially written for certain RDBMSs like MaxDB and DB/2. This new DBACockpit offers the ability to centrally manage and monitor different databases from different vendors. A central cockpit is used to access various systems connected via RFC.

The new SAP Solution Manager “Work Centers” will act as single points of access for administrators. Such a Work Center is just a screen with various tabs that hold certain activities. Therefore the logic behind the Work Centers is similar to that of roles in a Portal.

The SAP NetWeaver 7.1 Application Server deploys what is commonly known as the Central License Server. This license-server registers and manages all SAP licenses for all the SAP instances in the landscape. Normally during the startup phase of the SAP instance, the message-server reads the information either from the database (SAP releases 6.40 and below) or from the kernel (SAP releases 7.0 and above). Every time an end-user logs on to the SAP system, the message-server is check for a valid SAP license. With this new Central license-server, the end-user

298 UPGRADING SAP

no longer is checked against the local message-server, but rather against this new central server. With this tool, all SAP licenses are centrally managed and stored using transaction SLICENSE.

Another central tool is the Printing Assistant for Landscapes (PAL) which is accessed using transaction PAL. The PAL tool centrally registers all printers in the enterprise that are used for SAP. Once centrally registered at the server, the printer definitions are distributed to all other SAP systems in the landscape. This significantly saves on effort and costs to manage printer definitions in case a printer is added or removed from the landscape. The PAL tool is shipped via a Support Package for NetWeaver 7.0 or 7.1 and support SAP backend systems as of 6.20 and higher.

With an increasing number of IT systems in the landscape, provisioning users are becoming more complex than ever. More users need to be created, managed, and removed from more IT systems. A first attempt towards a solution was set by the release of CUA (Central User Administration). This tool is basically an extension of transaction SU01, and uses ALE to distribute the User Master Record between SAP systems. However, it only supports SAP systems, and cannot act as a data source for non-SAP systems. In order to fulfill this gap, SAP has acquired a company called MaxWare and has renamed their solution suite to SAP NetWeaver Identity Management. The tool is based on two building blocks: IC (Identity Center), which is the central database that keeps all User Master records and VDS (Virtual Directory Server) which is actually an adapter to connect Identity Center to partner systems and databases. The SAP NetWeaver Identity Management tool will act as the central tool to provision all userid within the company, and subsequently, distribute them to the relevant SAP and non-SAP backend systems.

15.11 DOWNTIME PREVENTION

One of the major hurdles during maintenance and upgrades of SAP systems is dealing with downtime. SAP and other software suppliers are working on this problem. Certain software and firmware can be upgraded concurrently. For example, as of the release of Oracle 10g, it is possible to make consistent backups without having to suffer from performance problems. Another practical feature is the “flashback database” option, which makes it possible to put the database back in time, by undoing all changes made to the database. Effectively, this means we have the option to revert all applied patches (support packages are upgrades to your SAP system), in case things went wrong. This option prevents the situation where the entire database has to be restored to the point just before the upgrade started. This is a significant reduction of downtime to the application in case the SAP system needs to be restored to the point before the upgrade.


15.12 FUTURE TRENDS

So what will an average SAP IT landscape look like in five years? SAP moves toward a Web service (eSOA)–enabled application platform that is able to host various business applications (BPP). Traditional monolithic applications, such as ERP, CRM, BI, SCM, and SRM will be split up into smaller parts. Web services are assembled together in larger Enterprise Services. Such services are not necessarily hosted from within the company. External services can be embedded as well. The SAP IT landscape moves toward a collection of “physically” decoupled services and specific and general business building blocks. These blocks can be implemented in various development languages and frameworks, but are all connected using open standards, such as SOAP, WDSL, UDDI, and WS*.

The remaining question is what the migration roadmap will look like. The SAP ERP systems will be upgraded to the latest releases SAP ERP 6.0 and be enhanced using Enhancement Packages up to the next major SAP release, which is planned for 2012. Each new Enhancement Package will offer better support for eSOA with new Web services.

Next to such component trends, we will see new technologies appear that will focus on both hosting and infrastructure support known as Provisioning. As discussed before, the IT infrastructure will be virtualized and therefore decoupled from the application components. The virtualization layer will take care of running the various components, regardless of the runtime platform. Provisioning will provide more flexibility, less infrastructure costs, and less of a vendor lock-in. Also, options like Grid-Computing are on the horizon.

Other things that will influence the provisioning of servers are developments around Green Data Centers and Appliances. A data center becomes green after the power consumption has been reduced by 30% or more. Most hardware vendors are looking into alternative cooling and less heat dispersion. Although the hardware and storage requirements increase, it is no longer allowed to consume more energy to host these requirements. Therefore, all kinds of remedies are put in place to reduce power consumption, such as decreasing the clock speed of a server CPU in case it is not needed, and more effort is done in virtualizing physical servers into logical servers.

Appliances are devices that only serve one specific purpose and consist of both hardware and software. More vendors will deliver products out-of-the-box as appliances in order to reduce TCO. Known examples of such appliances are the SAP BI-Accelerator, Firewalls, Intrusion Detection Systems (IDS), NAS, Netezza BI Database Machine, and backup devices such as Virtual Tape Libraries (VTL). An advantage of such an appliance is the reduced deployment time and lower administration.

Another emerging technology trend is the “Enterprise Wide Open Network,” which means that the company-specific network is no longer behind bars, but directly attached to the open Internet. The advantage of such a solution is

300 UPGRADING SAP

the flexibility of connecting applications from various enterprises to form a collaborative network. An advantageous item would be the price per unit of such a network. Fully Internet-based networks are much less expensive when compared to dedicated networks. Of course, it needs to be assessed on a case-by-case basis, whether it is desirable to run your enterprise across open networks. Security and availability are the two major risks of such open networks.

A bit farther into the future will appear the full adoption of virtual worlds by companies as a new channel to their customers and other partners. Virtual worlds are communities where, through advanced Web access technology, a higher user experience can be achieved. After Web 1.0 and 2.0, the virtual worlds will be marked as Web 3.0. Web 3.0 enterprises are better at providing some extra experience with products they sell over the Internet.

APPENDIX A

LIST OF SAP R/3 “OBJECT IDENTIFIERS”

PGMID R3TR

APPL- Application class CDAT- View cluster maintenance: Data CLAS- Class (ABAP objects) CNTX- Context DEVC- Development class DIAL- Dialog module DOCT- General text DOCV- Independent documentation objects DOMA- Domain (ABAP Dictionary) DSEL- Selection view DSYS- Chapters in a book structure DTEL- Data element (ABAP Dictionary) ENQU- Lock object (ABAP Dictionary) FORM- SAPscript form

301

302 UPGRADING SAP

FUGR- Function group FUGS- Function group w/ customer include (SAP part) FUGX- Function group w/ customer include (customer part) INTF- Interface (ABAP objects) LDBA- Logical database MCID- Matchcode ID (ABAP Dictionary) MCOB- Matchcode object (ABAP Dictionary) MSAG- Message application area PARA- SET/GET parameters PROG- ABAP program SHLP- Search help (ABAP Dictionary) SQLT- SQL table STYL- SAPscript style SYAG- System log messages SYND- Syntax documentation TABL- Table (ABAP Dictionary) TABU- Table content TDAT- Customizing: table contents TEXT- SAPscript text TOBJ- Definition of a maintenance and transport object TRAN- Transaction TROB- Specification of a transport object (old) TTYP- Table type (ABAP Dictionary) TYPE- Type group VDAT- View maintenance: data VERS- Version number VIEW- View (ABAP Dictionary) XPRA- Program executed after transport

PGMID R3OB (APPLICATION OBJECTS)

CHDO- Change document definition DSYO- Hypertext structure NROB- Number range definition REWR- Report writer SETS- GL set

APPENDIX A 303

PGMID LIMU HEADER

ADIR- Object directory entry CINC- Class include (ABAP objects) R3TR CLAS CLSD- Class definition (ABAP objects) R3TR CLAS COMM- Object list from request or object list CPRI- Private header (ABAP objects) R3TR CLAS CPRO- Protected header (ABAP objects) R3TR CLAS CPUB- Public header (ABAP objects) R3TR CLAS CUAD- GUI definition R3TR PROG

DOCU- DOCUMENTATION (CLASS-SPECIFIC)

CF GUI (functions) R3TR PROG DE Data element R3TR DTEL DI Dialog module R3TR DIAL DI Dialog module parameter R3TR DIAL DO Domain R3TR DOMA DZ Data element supplement R3TR DTEL FU Function module R3TR FUGR FX Function module exceptions R3TR FUGR HY Hypertext R3TR DSYS IN Info text R3TR DOKV NA Message R3TR MSAG RE Report R3TR PROG SD Syntax ABAP R3TR SYND CONT R3TR SYND DDIC R3TR SYND DYNP R3TR SYND RSYN R3TR SYND SL System log R3TR SYAG TB Table R3TR TABL TS Pool/Cluster R3TR SQLT TV View R3TR VIEW

304 UPGRADING SAP

TX General text R3TR DOCT KO Documentation for command files LIMU COMM VA Domain values R3TR DOMA DOMD- Domain definition (ABAP Dictionary) R3TR DOMA DTED- Data element def. (ABAP Dictionary) R3TR DTEL DYNP- Screen R3TR PROG ENQD- Lock object definition R3TR ENQU FSEL- Field selection R3TR PROG FUGT- Function group texts R3TR FUGR FUNC- Function module R3TR FUGR INDX- Table index R3TR TABL MAPP- Mapping information (ABAP objects) R3TR CLAS MCID- Matchcode ID R3TR MCOB MCOD- Matchcode obj. def. (ABAP Dictionary) R3TR MCOB MESS- Single message R3TR MSAG METH- Method (ABAP objects) R3TR CLAS MSAD- Message application area definition R3TR MSAG REPO- Report source and texts R3TR PROG REPS- Report source R3TR PROG REPT- Report texts R3TR PROG SHLD- Search help def. (ABAP Dictionary) R3TR SHLP SHLX- Search help text part (ABAP Dictionary) R3TR SHLP SQLD- Pool/Cluster definition R3TR SQLT SQTT- Technical attributes pool/cluster R3TR SQLT TABD- Table definition (ABAP Dictionary) R3TR TABL TABT- Technical attributes of a table R3TR TABL TTYD- Table type definition (ABAP Dictionary) R3TR TTYP TTYX- Table type definition text part R3TR TTYP TYPD- Type group source R3TR TYPE VARI- Report system variants R3TR PROG VARX- Report application variants R3TR PROG VIED- View definition (ABAP Dictionary) R3TR VIEW VIET- Technical attributes of a view R3TR VIEW

APPENDIX B

ASAP OF UPGRADE ROADMAP

1 Upgrade Project Preparation

1.1 Initial Upgrade Project Planning 1.1.1 Determine Upgrade Project Organization 1.1.1.1 Define Upgrade Organization and Roles 1.1.1.2 Assign People to Roles 1.1.1.3 Plan and Set Up Communication Environment 1.1.2 Prepare Upgrade Project Plans 1.1.2.1 Create Upgrade Project Work Plan 1.1.2.2 Create Upgrade Project Budget Plan 1.1.2.3 Create Upgrade Project Resource Plan 1.2 Upgrade Project Procedures 1.2.1 Define Project Management Standards and Procedures 1.2.1.1 Define Project Documentation 1.2.1.2 Create Issue Management Plan 1.2.1.3 Define Project Planning and Monitoring Standards 1.2.1.4 Define Release Management Strategy

305

306 UPGRADING SAP

1.3 Technical Requirements Planning 1.3.1 Perform Technical Requirements Planning 1.3.1.1 Going Live Functional Upgrade Check 1.3.1.2 Determine Software and Hardware Requirements 1.3.1.3 Create Rough Plan for Upgrade Schedule 1.4 Training Upgrade Project Preparation 1.4.1 Align End User Training and Documentation Upgrade Strategy 1.4.1.1 Review Implementation Project Strategy 1.4.1.2 Draft End User Training and Documentation Needs

Assessment 1.4.1.3 Draft End User Training and Documentation Project Plan 1.4.1.4 Develop End User Training and Documentation

Recommendations 1.5 Upgrade Preparation 1.5.1 General Upgrade Preparation 1.5.1.1 Check Notes 1.5.1.2 Prepare Test Cases 1.5.1.3 Create Test Plan 1.5.2 Technical Upgrade Preparation 1.5.2.1 Prepare for Minimal Downtime 1.5.2.2 Plan Modification Adjustment 1.5.2.3 Refine Schedule for Upgrade of All R/3 Systems 1.5.2.4 Plan Upgrade of Operating System 1.5.2.5 Plan Upgrade of Database Software 1.5.2.6 Plan Upgrade of Frontend Software 1.5.2.7 Plan Upgrade of Non-R/3 Software 1.5.2.8 Install Additional Hardware 1.5.2.9 Ensure Change Request Consistency in All R/3 Systems 1.5.2.10 Ensure Customizing Consistency in All R/3 Systems 1.5.2.11 Refine and Approve Schedule for Upgrade of All R/3 Systems

2 Business Blueprint

2.1 Analysis of the Productive R/3 Systems 2.1.1 Create Overall View of the Productive R/3 Systems 2.1.1.1 Analysis of the Productive R/3 Systems 2.2 Gather Info about the Functionality of the New R/3 Release

APPENDIX B 307

2.2.1 Familiarize Yourself with the New R/3 Release 2.2.1.1 Check Release Notes and Use Delta Trainings 2.3 Analyze and Classify the Use of New Standard Functionality 2.3.1 Assign New and Changed Standard Function to the Business

Processes 2.3.1.1 Assign New and Changed Functionality to Business Processes 2.3.2 Replace Own Enhancements and Modifications with New standard.

Function 2.3.2.1 Analyze Enhancements and Modifications 2.3.3 Change Management, Business Impact Map 2.3.3.1 Create a Business Impact Map 2.3.4 Refine Business Process descriptions 2.3.4.1 Review Changes and Refine Documentation 2.4 Define Aims of the Upgrade project 2.4.1 Refine the Aim of the R/3 Upgrade and Define New Projects 2.4.1.1 Refine Planning of the New R/3 Release 2.5 Training Upgrade Business Blueprint 2.5.1 Finalize End User Training and Documentation Upgrade Strategy 2.5.1.1 Update End User Training and Documentation Needs

Assessment 2.5.1.2 Define End User Training and Documentation Requirements 2.5.1.3 Draft Training Curriculum and Documentation Topics 2.5.1.4 Define SAP Training Environment Requirements 2.5.1.5 Finalize End User Training and Documentation Plan

3 Realization of DEV and QAS

3.1 Upgrade and Test Development System (DEV) 3.1.1 Perform DEV System Upgrade 3.1.1.1 Perform Upgrade of Frontend Software across all R/3 Systems 3.1.1.2 Freeze Existing R/3-Projects 3.1.1.3 Perform Installation of Prerequisite Upgrade Software 3.1.1.4 Perform PREPARE in DEV 3.1.1.5 Pre-Upgrade DEV System Backup 3.1.1.6 Perform Non-R/3 Software Upgrade for DEV 3.1.1.7 Perform R/3 Upgrade of DEV 3.1.1.8 Perform ABAP Adjustment

308 UPGRADING SAP

3.1.1.9 Perform Post-Upgrade Maintenance in DEV 3.1.1.10 Post-Upgrade DEV System Backup 3.1.1.11 Unfreeze DEV system for New Settings and Adjustments 3.1.2 Upgrade all Activity Groups and Authorization Profiles 3.1.2.1 Upgrade Authorization Profiles Manually Created Prior to

4.6x 3.1.2.2 Upgrade Activity Groups from Release 3.0F to 4.6x 3.1.2.3 Upgrade Activity Groups from Releases 3.1x,4.0x or 4.5x to 4.6 3.1.3 Define Upgrade IMG 3.1.3.1 Create Upgrade IMG 3.1.3.2 Check Configuration Release Notes 3.1.4 Maintain DEV System 3.1.4.1 Perform Upgrade Configuration 3.1.4.2 Check and Adapt Customer Development 3.1.4.3 Check and Adapt Interfaces 3.1.4.4 Perform Unit Testing in DEV 3.1.4.5 Export New Change Requests from DEV System 3.2 Upgrade and Test Quality Assurance System (QAS) 3.2.1 Perform QAS Upgrade 3.2.1.1 Perform Installation of Prerequisite Upgrade Software 3.2.1.2 Perform PREPARE in QAS 3.2.1.3 Pre-Upgrade QAS Backup 3.2.1.4 Perform Non-R/3 Software Upgrade for QAS 3.2.1.5 Perform R/3 Upgrade of QAS 3.2.1.6 Perform Post-Upgrade Maintenance in QAS 3.2.1.7 Import New Change Requests from DEV to QAS 3.2.1.8 Post-Upgrade QAS System Backup 3.2.2 Upgrade all Activity Groups and Authorization Profiles 3.2.2.1 Upgrade Authorization Profiles Manually Created Prior to

4.6x 3.2.2.2 Upgrade Activity Groups from Release 3.0F to 4.6x 3.2.2.3 Upgrade Activity Groups from Releases 3.1x,4.0x or 4.5x to 4.6 3.2.3 Test QAS 3.2.3.1 Conduct Functional Upgrade Test 3.2.3.2 Perform Technical Upgrade Tests 3.2.3.3 Review and Approve Upgrade Test

APPENDIX B 309

3.3 Training Upgrade Realization 3.3.1 Define and Develop End User Training and Documentation... 3.3.1.1 Develop Course Outlines 3.3.1.2 Develop/Revise End User Documentation 3.3.1.3 Develop/Revise End User Training Content 3.3.1.4 Populate SAP Training Environment 3.3.1.5 Develop Training Logistics Plan 3.3.1.6 Conduct Training System Test 3.3.1.7 Finalize and Produce Content

4 Realization of Production

4.1 Training Upgrade Final Preparation 4.1.1 Conduct End User Upgrade Training 4.1.1.1 Implement Training Logistics Plan 4.1.1.2 Conduct End User Training 4.1.1.3 Evaluate Training Effectiveness and Implement Improvements 4.2 Upgrade Production System (PRD) 4.2.1 Perform PRD System Upgrade 4.2.1.1 Perform Installation of Prerequisite Upgrade Software 4.2.1.2 Perform PREPARE in PRD 4.2.1.3 Pre-Upgrade PRD System Backup 4.2.1.4 Perform Non-R/3 Software Upgrade for PRD 4.2.1.5 Perform R/3 Upgrade of PRD 4.2.1.6 Perform Post-Upgrade Maintenance in PRD 4.2.1.7 Import New Change Requests from DEV to PRD 4.2.1.8 Post-Upgrade PRD System Backup 4.2.1.9 Adaptation of R/3 Profile Parameters for Optimal; performance 4.2.1.10 Perform Monitoring During Turnover in PRD 4.2.1.11 Unfreeze Existing R/3 Projects 4.2.2 Upgrade all Activity Groups and Authorization Profiles 4.2.2.1 Upgrade Authorization Profiles Manually Created Prior to 4.6 4.2.2.2 Upgrade Activity Groups from Release 3.0F to 4.6x 4.2.2.3 Upgrade Activity Groups from Releases 3.1x, 4.0x or 4.5x to 4.6

310 UPGRADING SAP

5 Go Live and Support

5.1 Production Support 5.1.1 Provide Production Support 5.1.1.1 Direct Problem and Issues 5.1.1.2 Manage and Resolve Problems 5.1.1.3 Confirm Live Environment 5.1.1.4 Going Live Functional Upgrade Check

APPENDIX C

ADDITIONAL WEB RESOURCES

www.sap.com www.sdn.sap.com www.service.sap.com www.sapfans.com www.asug.com www.sapgenie.com www.solutionbrowser.erp.sap.fmpmedia.com www.sap-press.com www.microsoft-sap.com www.duet.com www.oracle.com/sap

311

312 UPGRADING SAP

APPENDIX D

ABOUT THE CD-ROM

� Included on the CD-ROM are templates, Microsoft Power Point slides, and sample sheets related to upgrading and implementation of SAP:

Upgrading BW 3.5 Dual stack system to BI 7 Dual Stack system with EP7 SAP R/3 Upgrade (A) – Technical Part SAP R/3 Upgrade (B) – Technical Part 4.0B to 4.6C Oracle Upgrade Runbook 9.2 to 10.2 BW upgrade from 3.0B to 3.5 Using JAVA Technology (presentation) SAP R/3 Memory Management Upgrade checklist.xls- contains a technical upgrade checklist for Basis teams Upgrade costs.xls- contains a sheet with an adjustable cost model to calculate

SAP Upgrade project costs Upgrade plan.xls - an extra upgrade plan in Excel format Upgrade timings.xls - contains a template to measure the SAP upgrade elapse

time � All of the figures from the book including those originally produced in 4

color

313

314 UPGRADING SAP

A

A2A, 291ABAP, 5, 13, 16-19, 36, 39, 126, 250, 255, 273,

288ABAP and other objects, 224-225ABAP AS, 17, 104, 253, 261ABAP dispatcher, 13, 258-260ABAP engine, 40ABAP kernel, 255ABAP objects, 18, 79ABAP “personality,” 38, 238, 253ABAP program, 8, 22, 24, 27-30, 41, 46, 135,

220ABAP programming, 202-203ABAP report, 148, 176, 280ABAP repository, 145, 178ABAP stack utility, 260ABAP stack, 13ABAP team, 94ABAP virtual machine (AVM), 18ABAP workbench, 17, 39AC, 295ACC, 295

AcceleratedSAP, 198ACF, 271ACI, 293-297ACT – activation, 139, 164-165Actions to do before upgrade, 229-230Activation and distribution, 50-52Activation, 19, 46Adabas/D, 15ADAP AS, 254Adaptive computing, 295Add-ons and industry solutions, 128-133ADIRACCESS, 21, 24-25Adjust authorizations, 180-181ADO import, 47Adobe document service (ADS), 254, 271-272Adobe document system, 271-272Adobe interactive forms (AIF), 253-254, 271Advanced planning and optimization

(APO), 4-5, 17, 29, 55, 87AE, 295ALE, 234Alpha, 18Alter table, 52American SAP user group (ASUG), 89

INDEX

315

316 UPGRADING SAP

APO/SCM, 237Application availability, 109-110Application Life Cycle Management Suite,

108Application thread manager, 263Archiving, 150ARIS, 284AS, 253AS Java, 238, 268AS stacks, 253ASAP for upgrade, 198-199ASCII, 187ASP, 18, 293ASP market, 59Assembler/370, 17ASU (application specific upgrade), 275-276ASU toolbox, 275ATAB, 27Authorizations, 225-228Automatic startup of Java instance, 260-261Automatic testing, 212-215

B

B2B, 292

Backup domain controller, 41

BAM (business activity monitoring), 277

BAPI, 226, 234

Base11-II, 181

Basis kernel, 17

Batch generator, 158

BC component, 7

BC sets, 222-224

Berkeley LPD, 8

BFS (business function set), 78

BI, 4, 7, 250, 268, 271, 277, 299BI accelerator, 242-243BI Java, 238BI-A, 243Big Brother, 232Big-Endian format, 18BIND_PATCH, 133-136Blended code pages, 187BMC software, 232, 279BMC Trak, 233Boostrap Java program, 257Borland, 289BPEL (business process execution language),

292BPP (business process platform), 291-292BR3up, 240BRTOOLS, 31, 253BSEG, 28BSP (business server page), 10, 18, 38-39Budget planning and cost calculation, 206-207BugsEye, 244Business blueprint, 199Business case, 203-205Business connector, 234, 244Business continuity plan (BCP), 110Business engineer, 224Business information warehouse, 237-243 BI accelerator, 242-243 BW alpha conversion, 238-239 BW business content, 239-240 BW-specific upgrade, 241-242 SAP BI lock server, 242Business packages, 5Business process owner (BPO), 222Business process support team, 94-95Business process testing, 209

INDEX 317

Business scenarios, 5Business warehouse (BW), 4-5, 29, 55, 73, 87,

100BusinessOne Engine, 7Business-to-business procurement (BBP),

243BW alpha conversion, 238-239BW business content, 239-240BW business planning and simulation (BW

BPS), 242BW content, 238BW technology, 239BW/BI, 100, 237BW-specific upgrade, 241-242

C

CA Wily introscope, 277CAF, 289, 291Capability maturity model, 96CASE (computer aided software enginee-

ring), 284CATS (time writing), 109CATT (computer aided test tool), 212CA-Unicenter, 232CBS (component build service), 268-269CBU (customer-based upgrade), 184-185CCC (customer competency center), 94, 96-

98, 222CCF (cumulative cash flow), 204CCMS (computer center management

system), 60, 231, 253, 277, 282CCMS, 60, 231, 253, 277, 282CCUEVAL, 106CDOP, 279Central instance/database server, 255

Central job scheduling, 235Central user administration, 225ChaRM (change and request management),

198, 234, 271, 273CISC, 18Class load manager, 263Cleaning the system, 149-150Client copies, 53-59 Multiclient manager, 59 Remote client copies, 57-58Client copy FAQs, 57Cluster manager, 263Cluster- or pool-to-transparent table

conversions (CPTC), 155Cluster Server (MSCS), 110Clustered tables, 28-29CMDB, 233CMM (capability maturity model), 96CMP, 265CMS, 268-269CoE, 222Combined upgrade and Unicode conver-

sion, 193-195Command file import, 46Component testing, 209-210Composite application framework, 289Computer aided test tool, 212ConfigTool, 264Configuration manager, 263Conflict resolution transports (CRT), 60-62,

66, 72Consolidation system, 42Conversion control table, 191Correction and transport system (CTS),

40-53 Activation and distribution, 50-52 DDIC import, 48-49

318 UPGRADING SAP

Running the XPRA job, 52-53 Transport activities, 41 Transport management system, 41-42 Transport requests, 43-45 Transport steps, 46-48 Transport tools, 45-46Create table, 52CRM (customer relationship management),

4-5, 7, 9-10, 17, 20, 29, 87, 100, 237, 245-247, 251, 268, 277, 291-292, 299

CRM master guide, 246Cross-release transports, 220-221CTO (change and transport organizer), 40CTS, 15, 40-53, 273CTS toolkit, 40-41CTS/TMS facility, 234CTS+, 271-273CUA, 225, 298Customer competency center (CCC), 94,

96-98Customer-based upgrade, 184-185Customizing objects, 34-35Customizing scout, 246-247

D

Data copy tools, 235Data dictionary, 33, 48, 111, 139, 145, 151Data dictionary objects, 53Data extraction tools, 235Data model, 36Data tables, 25-34 DBDIFF, 33-34 Indexes, 31-32 Table data classes, 30-31 Table logging, 32-33

Table technical settings, 32 Table types, 26-30Database conversion, 192Database error, 165Database growth pattern, 109DB/2, 233DBACockpit, 277, 297DBDIFF, 33-34DBIF database, 14DBSL (database software layer), 14, 27-28DDIC, 48DDIC import, 46, 48-49DDIC substitution, 163DDSYN, 27Delivery type attribute, 30Delta customizing, 202Delta upgrade, 118-119Demand planning (DP), 247Deploy options, 254-257DEV, 199DEVACCESS, 21, 25Developer key, 21, 24-25Development classes, 20-21Development locks, 23-24Development objects, 16-17Development package, 20-21Development workbench, 20DIAG, 294Dictionary objects, 79Disable scheduled batch job, 150DISTMON, 192Distributed monitor, 192DLLs, 81Domain controller, 41Drop table, 52DSAG, 89

INDEX 319

DSDM for SAP, 199-201DSDM method, 200DTR, 268Dual stack upgrade, 127Duet, 293DYNA, 14Dynpro processors, 14

E

E2E RAC, 297EAR, 273EarlyWatch reports, 54EBPro (enterprise buyer professional), 4-5,

87, 243ECC, 104, 129, 106, 151, 194, 227, 253Eclipse, 271EH&S, 73EJB (enterprise Java beans), 10, 265Employee self-service, 109Enhancement framework, 76-77Enhancement packs, 81-82Enterprise services oriented architecture,

290-291EP, 104EP/NWP, 250EPA, 273EPC (Event-driven process), 224EPS, 61-62ERP, 100, 268, 271, 277, 291-292, 299ES bundle, 292eSOA (enterprise services oriented architec-

ture), 289-291, 293, 299ESR, 291ESX, 293ET, 297

Event-driven process, 224Exchange tables, 150Execute report after put, 52Extended computer aided test tool (eCatt), 212Extension of database size, 176-177External conversions, 159EXTERNIND, 23

F

Fast-path-tree, 248FI-CO (finance and controlling), 5FireFox, 293FS-CD, 73FTEs, 206FTP, 9Function module, 37

G

GAM (global account manager), 98GDT, 292Generate ABAP load, 178-179Generate ABAP query reports, 179Generation, 19Global active support, 229Global performance analysis, 213Global service manager (GSM), 98GoLive, 54, 199Green data centers, 299

H

HACMP, 110HCM (human capital management), 272

320 UPGRADING SAP

Heterogeneous system copy, 111Horizon for SAP, 232Hot packages (HP), 60HP MC/ServiceGuard, 110HP, 60, 232HP/Mercury LoadRunner, 211HR (human resources), 5HTML, 198HTTP, 8-9, 254-255, 294

I

IAORA, 31IBM, 289, 295IBM CPI-C, 8IBM CrossWorld, 234IBM DB2, 15IC, 298ICM (internet connection manager), 10, 13,

254ICMan (internet connection manager), 38-39ICNV, 117, 160-163, 171, 174ICT, 197IDI, 295IDOCs, 234IDS, 299IDS Scheer ARIS, 224IGS, 253Implementation and support, 93-98 Business process support team, 94-95 Remaining tasks, 95 Required number of staff, 96 SAP ABAP support team, 95 SAP Basis support team, 95 SAP Basis/technology support team,

95

SAP customer competency center, 96-98 SAP functional support team, 95Implementation management guide (IMG),

23, 201Increased complexity of system landscapes,

100-101Indexes, 31-32Industry solutions and add-ons, 72-75 Installation using R3up, 73-75 Installation using SAINT, 75INDX tables, 26Infocubes, 12, 55, 239, 243, 248Infomix, 15InfoObjects, 239InfoShuttle, 235Infotypes, 244In-Q-My Java application server, 253In-Q-My technologies, 9-10Install optional SAP J2EE engine, 182Installable software units, 12-14 Java connector (JCo), 13 Usage types, 12-13Installation using R3up, 73-75Installation using SAINT, 75Integration system, 41Integration testing, 210Intel, 18Interface tools, 234Internal conversions, 155Internet connection manager, 38-39Internet explorer, 293Internet transaction server, 114IPC (inter-process communication), 8, 253 DIAG (dynamic information and

access gateway), 8

INDEX 321

RFC (remote function call), 8 SAPGUI, 8iPlanet, 10IRFS, 181IRR (internal rate of return), 205IS components, 128IS solutions, 128IS-Health, 60IS-Hospital, 60IS-Media, 78IS-Oil, 60, 72-73, 78, 128IS-Solutions, 72-73, 78Issues during upgrade, 228-229IS-Utilities, 72IT, 233, 293ITIL, 233ITS, 114, 253, 293

J

J2EE, 9-10, 13-14, 244, 247, 261-262, 264J2EE engine, 182J2SDK, 261J2SE, 69Java AS system, 104, 253, 255, 260-261Java configuration management, 264Java connector (JCo), 13Java control, 260Java database access, 265-266Java dispatcher, 254Java engine, 264Java managers and services, 261-263Java patch management, 266-267Java stack, 13Java startup and control framework, 257-259

Java trace and log files, 259-260Java, 13, 123, 126-127, 250, 255, 273, 288, 295JavaServlet, 10Java-specific filesystems, 265JBoss, 10, 262JCmon tool, 260JCo engine, 10JControl, 13, 257-260JDBC, 265JDO, 265JLaunch, 257-260JRun, 10, 244JSP (Java server page), 10, 18JSPM, 266JVM, 13-14, 18, 123, 258-259

K

Kernel switch, 165-166Key performance indicators, 107-108KM, 232Knowledge modules, 233

L

Languages, 82-85, 136-137LAW (license audit workbench), 283Legal change packages (LPC), 60Life cycle, 276LIMU REPS, 17LIMU REPT, 17LIMU VARI, 17 Linear programming, 247Linux, 228, 243, 259, 264Little-Endian format, 18

322 UPGRADING SAP

LiveCache, 247-249, 253LiveCache instance, 242LiveCycle Designer, 272LiveModeller, 224Location of users, 110Lock development workbench, 137Locking manager, 263Logical databases, 5LogManager, 263

M

Main import, 46Maintain shadow instance, 183Maintenance optimizer, 71Maintenance strategy, 90-91Master data, 244Match code activation, 46MatchCode object, 35-36 MaxDB, 268, 280MaxWare, 298MCOD, 102-104, 219MCOS (multiple components on one

system), 13, 67, 104-105MDMP, 187, 189MEC audit trail, 91MEC questionnaire, 91Messages, 37-38 Abort, 38 Error, 38 Information, 38 Warning, 38Message classes, 37Message server, 260Microsoft, 14-15, 289

Microsoft operations manager, 232MM (materials and management), 5Modification assistant, 144-145Modification browser, 145MOM, 232Monitoring tools, 231-233Move nametab, 52Mozilla, 293MPC environment, 59MSDE, 280Multiclient manager, 59MVC paradigm, 39mySAP Business Suite, 4-5, 70, 122, 284, 288mySAP ERP, 4-5, 13

N

Name-ranges, 21-22Namespaces, 22Nametab object, 50NCF (net cash flow), 203Netezza BI database machine, 299Netweaver application server (NW AS), 8,

253NetWeaver composition environment, 271Netweaver development studio, 270New functionality, 91-92New general ledger, 181-182NewGL, 181NFS, 41NoteAssistant, 79-80NPV (net present value), 205NRIV, 23Number range objects, 23Number ranges, 23

INDEX 323

NWCE, 271, 289, 291NWDI, 250, 268NWDS, 268, 271

O

O2C, 292Objects, 43Object classification, 16Object directory, 16Object key, 21, 24Object locks, 149Object type, 16Object-indentifier, 16-17OCI, 14OCS (online correction support), 59, 69-70OCX, 271ODBC, 14, 27OLAP (online analytical processing), 10-12,

103OLAP engine, 238-239, 247OLTP (online transaction processing), 10-12,

103OLTP versus OLAP, 10-12OMS, 248On-demand computing, 294Open repairs, 149OpenSQL, 33, 265-266Oracle, 8, 14-15, 113, 187, 233, 262, 289, 298OS/DB migration, 31, 111-113OS/DB upgrade, 113OSS notes, 29, 59, 69OSS SAP system, 69Outlook, 293Outstanding updates, 150

P

P2P, 292PAI (process after input), 36PAL, 298PAR, 273PBT (payback time), 204PDA, 293PGMID, 16-17PI, 4Plug-in additions, 136PM (plant maintenance), 5Pooled tables, 26-27Portals, 4Ports manager, 263Post steps, 178-184 Adjust authorizations, 180-181 Generate ABAP load, 178-179 Generate ABAP query reports, 179 Install optional SAP J2EE engine, 182 Maintain shadow instance, 183 New general ledger, 181-182 Reset the upgrade, 182 Solve P errors in LONGPOST.LOG, 180 Upgrade elapse time, 183-184PP (production planning), 5PRD, 144PREPARE, 119-121, 176, 228, 240Preparations on hardware and software,

110-115 OS/DB migration, 111-112 OS/DB upgrade, 113 SAPGUI and ITS, 113-115 Third-party products, 115Preparation steps, 176-178

324 UPGRADING SAP

Extension of database size, 176-177 Reuse of variants, 177-178 Saving wage types, 176 Upgrade breakpoints, 178Preserve modifications, 137-138Process direct input session, 150Process integration, 250-251Process owners—SAP CCC, 221-22Production preparation client, 53Profile generator, 225-226Project IMG for upgrade, 201-202Project organization and roles, 202-203Project preparation, 199Project runbook, 208Project view IMG, 201Prototyping, 200PS (project system), 5

Q

QAS, 144, 199QM (quality management), 5Queries, 239

R

R/2, 3-5R/3, 87R3load tool, 31, 83-84, 111-112, 126, 151-153,

192R3TR PROG, 16R3trans, 45-46, 58, 83-84, 126, 135R3up, 135, 250RAD (rapid application development),

199-200

RAFC, 226RBE (reverse business engineer), 279-281RBEplus, 284RDBMS, 9, 15, 27-29, 45, 99, 111, 229, 232,

248RDDIMPDP, 46Real tables, 29Redwood software, 234Release upgrades, 80Remote client copies, 57-58Repair flag, 24REPOLOAD, 18-19Reports, 239Repository switch, 18, 151-155, 163REPOSRC, 16, 18-19Requisite catalogue database, 244Reset the upgrade, 182Reuse of variants, 177-178RFBLG, 28RFC, 234, 294, 297RFC communication, 81RFC mechanism, 52RISC, 18RK (controlling), 5RM (materials management), 5Roadmaps, 287-288ROI (return on investment), 205, 293RSCLICOP, 55RSEPSDOL, 135RSEPSUPL, 135RSPFPAR, 17Runbook testing, 211Running import jobs, 149Running the XPRA job, 52-53Runtime object, 50RV (sales), 5

INDEX 325

S

Saas (software as a service), 7, 59, 293Sabrix, 234SAINT, 239, 250-251SAP ABAP engine, 10SAP ABAP support team, 95SAP ACC, 295-296SAP adaptive computing infrastructure

(ACI), 294-295SAP AG, 17SAP all-in-one, 4SAP application server, 67SAP AS ABAP, 14SAP basis, 19SAP basis consultant, 293SAP basis layer, 7, 239, 277SAP basis/technology support team, 95SAP BI cubes, 242SAP BI lock server, 242SAP BRE, 277SAP business by design, 7Sap BusinessOne, 4SAP BW, 239-240SAP CDOP, 281-282SAP client server architecture, 7-10 Netweaver application server (NW

AS), 8 SAP kernel, 8 Oracle, 8 SAP instance, 8 SAP dispatcher, 8 TP-monitor (transaction processing),

8 RDBMS, 9 SAPGUI, 9

ICM (internet connection manager), 10

SAP web AS 6.10, 9 IPC (inter-process communication),

8-9 DIAG (dynamic information and

access gateway), 8-9 SAPGUI, 8-9 RFC (remote function call), 8-9SAP central services (SCS), 254SAP development studio, 39SAP dispatcher, 8SAP EAF, 198SAP ECC, 67SAP enterprise architecture framework

(SAP EAF), 198SAP EP, 7, 73, 132, 122, 181, 234, 237, 246,

266, 269, 272, 299SAP functional support team, 95SAP global support organization, 54SAP instance, 8SAP IPC (internet pricing configurator), 14,

246SAP Java instance, 258SAP kernel, 8, 18SAP kernel patches, 80-81SAP KM, 233, 246SAP landscape management, 215-221 Cross-release transports, 220-221 Show system information, 221 System landscape scenarios, 215-220SAP lock server, 242SAP maintenance optimizer (SMO), 70-72SAP message server, 254SAP NetWeaver composition environment,

271SAP notes, 79-80, 249

326 UPGRADING SAP

SAP NW AS, 9-10SAP NWDI—Java change management,

267-269SAP optimizers, 247-248SAP package manager, 133SAP patch manager, 68SAP quicksizer, 109SAP release strategy guide, 90SAP screen painter, 36, 269SAP service marketplace, 67, 70, 79, 98, 99,

136, 242SAP SLD, 296SAP SLM, 68SAP solution manager (SSM), 122, 213, 232,

246, 251, 271, 273, 276-279, 280, 284, 295-296

SAP TDMS (test data migration system), 282-283

SAP upgrade assistant (new), 125SAP upgrade assistant (UA), 122-125SAP visual composer, 269-270SAP web application kernel, 17SAP web application server, 7, 20, 38, 59,

188, 238-239, 250SAP web AS, 9, 134, 251SAP web dispatcher, 254SAP xAPPS, 288-289SAP XI, 244, 250SAP_ABAP, 61SAP_APPL, 60SAP_BASIS, 60SAP_HRP, 61SAPDB/MaxDB, 15SAPDBA, 31SAPGUI, 9, 114, 242, 255, 293-294SAPGUI and ITS, 113-115SAPGUI screen, 37

SAPinst, 248, 250, 253SAPJup, 127, 250SAPUP and SAPJUP, 126-128SAPup, 127, 170, 173, 178, 229, 250Saving wage types, 176SCM (supply chain management), 4, 247-

249, 268, 291-292, 299 SCM middleware, 247-248 SCM upgrade, 249SCM middleware, 247-248SCM server, 7SCM upgrade, 249Screen, 36-37SCS, 254SD (sales and distribution), 5SDT, 125SDTGui, 125SE38 ABAP editor, 59, 79Search helps and matchcode object, 35-36SeeBeyond, 234SEM, 55SEP (support enablement package), 279-283Server and database consolidation, 101-102Service manager, 263Shadow instance, 168Shadow tables, 150-151SharePoint, 232Show system information, 221SICF, 38-39Sizing for the new release, 105-110 Application availability, 109-110 Database growth pattern, 109 Key performance indicators, 107-108 Location of users, 110 Number of concurrent users, 108-109 Used software components, 108

INDEX 327

SLD, 269, 295-296SMB business solutions, 7, 294SMTP, 9SNOTE, 79SNOTE-note assistant, 59SNRO, 23SOAP, 289, 299Software as service, 59Software logistics, 15-16Solaris, 99Solution manager maintenance optimizer,

266Solve P errors in LONGPOST.LOG, 180SonicMQ, 234Source code corrections, 59SoX, 181SPAM, 61, 68, 75, 117, 133, 135, 140-143SPAM queue, 61, 65SPAM queue calculator, 65SPAU, 79SPDD, 79, 138-140SPRO, 23, 284SPUMG scanning, 191SPUMG tool, 189-191, 194-195SQL*Net, 8SQL/JDBC checker, 266SQLJ, 265SQLPLUS, 27-28, 181SQLServer, 15, 81, 152, 232-233, 271, 280SQLtrace, 214, 266SRM (supplier relationship management),

4, 17, 29, 100, 243-246, 268, 277, 291-292, 299

SRM/CRM, 244ST03 database, 284ST30 toolkit, 213

Stress and performance testing, 211Structure change conversions (SCC), 155Structure files, 112Structures, 29-30Subject matter experts, 94Support enablement Package (SEP), 108,

279-283 RBE (reverse business engineer),

280-281 SAP CDOP, 281-282 SAP TDMS (test data migration

system), 282-283Support package shadow import, 65Support packages, 53-54, 59-70 Conflict resolution transports, 61-62 SAP download manager, 69-70 SAP patch manager, 61 SPAM queue conflicts, 68-70 Support package import phases, 62-64 Support package stacks, 66 Support package types, 60-61 Support packages as of NetWeaver

7.0, 67-68 Support packages in R/3 Enterprise,

64-66 Tables used with SPAM, 68Support package types, 60-61 Conflict resolution transports, 61-62 SAP download manager, 69-70 SAP patch manager, 61 SPAM queue conflicts, 68-70 Support package import phases, 62-64 Support package stacks, 66 Support packages as of NetWeaver

7.0, 67-68 Support packages in R/3 Enterprise,

64-66 Tables used with SPAM, 68

328 UPGRADING SAP

Supported hardware platforms, 99-100Switch framework, 77-79Sync points, 127System landscape optimization (SLO), 108System landscape scenarios, 215-220System management cockpit, 231System switch, 117, 168, 183System switch upgrade, 169-174

T

TABART attribute, 30-31TABIM, 174-175Tables ADIRACCESS, 141 CCCFLOW, 56 CDCLS, 57, 160 CDHDR, 57 CDPOS, 57 CVERS, 250 D010L, 18, 33 D010Q, 33 D010S, 33, 150 DBDDIFF, 34 DBDIFF, 33 DBTABLOG, 33 DBTABPRT, 33 DD01L, 49 DD02L, 48, 84, 163 DD03L, 49 DD04L, 49, 163 DD09L, 32, 49, 126, 163 DDART, 126 DDXTF, 50, 163 DDXTT, 50, 163

DIFFKIND, 33 E070, 141 E070L, 43 E071, 44 EDIDOC, 160 GENSETC, 179 INDX, 192 MLICHECK, 33 MSSQL_LOGIN_INFO, 33 OBJH, 34 OBJM, 34 OBJT, 34 PLAN_TABLE, 34 PUTT_SHD, 172 PUTTB, 172 RADBDIF, 33 RSVTPROT, 33 SCU3, 33 SE11, 31, 35 SE80, 35 SM, 30 SMODILOG, 141-142 SOBJ, 34 SPRO, 35 T001, 34 T002, 83 T512W, 176 T599U, 176 TAB01, 50-51 TABX, 69 TADIR, 17, 24-25, 126, 141, 163 TAORA, 31 TATAF, 51 TBATG, 51, 158 TCNV, 158 TDDAT, 226

INDEX 329

TDEVC, 20, 141 TKA00, 35 TKA01, 35 TKA02, 35 TKVS, 35 TKVST, 35 TRBAT, 47 TRJOB, 47 TVKO, 84 TVKOT, 84 UMODOBJ, 143 UPGLDGEN, 179Table buffer, 266Table cluster, 28Table conversion, 155-159Table data classes, 30-31Table delivery types, 30Table logging, 32-33Table technical settings, 32Table types, 26-30TABNAME, 27Tasks, 43Tax calculation tools, 234TaxFactory, 234TaxWare, 234TCO (total cost of ownership), 70-71, 113,

299Technical objective, 117-118Technical upgrade only, 98Template files, 112Test data migration system, 282-283Testing, 208-215 Automatic testing, 212-215 Business process testing, 209 Component testing, 209-210 Integration testing, 210

Runbook testing, 211 Stress and performance testing, 211Text element, 37Thread manager, 263TibCo, 234Time boxing, 200Tivoli, 232TLOCK, 24TMS, 15, 40-43, 272TOGAF, 198TomCat, 10, 244, 262TOOLIMPORT, 148-149TopManage, 7TopTier, 7Tp showbuffer, 47Tp tool, 47TP-monitor (transaction processing), 8TPZ, 273Transaction codes DB06, 297 DB50, 297 DBACOCKPIT, 297 MCLIMAN, 59 PFCG, 225 RSDDBIAMON, 243 RSDDV, 243 SAINT, 73, 75 SARP, 225 SART, 225 SB09, 224 SB10, 224 SCC3, 56 SCPR3, 223 SD11, 36 SE01, 40, 44, 144 SE03, 40, 44

330 UPGRADING SAP

SE06, 40 SE09, 40 SE10, 40 SE11, 31, 36, 238 SE14, 156 SE16, 238 SE32, 37 SE34, 226 SE37, 37 SE38, 144, 238, 275 SE41, 37 SE51, 36 SE63, 37 SE80, 35, 39, 77, 238 SE91, 37 SE95, 145 SERP, 225 SFW3, 78, 223 SFW5, 78, 223 SICF, 38 SM, 30 SMLT, 83, 137 SMODILOG, 145 SOBJ, 34 SPAU, 138 SPAU_ENH, 77 SPDD, 138 SPRO, 35 SPUMG, 189 ST30, 213 STMS, 40, 42, 144 SU01, 298 SU02, 225 SU24, 225 SUCU, 226 SUMG, 192 SW01, 224

Transparent table, 26, 50Transport activities, 41Transport directory, 41Transport domain controller, 41Transport files, 83Transport group, 41Transport management system, 41-42Transport requests, 24, 43-45Transport routes, 41Transport steps, 46-48Transport tools, 45-46, 233-234Transporting modification adjustments,

143-144Trex, 243, 253TRNSPACE, 22

U

UA, 122UaGui, 123, 148UaServer, 123, 148UC&CU process, 194-195UCCHECK, 194-195UDDI, 289-290, 299Unicenter, 232Unicode, 81Unicode conversion process, 187-189Unicode kernel, 193Unicode preparation, 189-192Unicode system requirements, 192-193UNIX, 18, 41, 81, 99, 123, 146, 228, 233, 259,

264Upgrade breakpoints, 178Upgrade coaching, 286Upgrade competency center, 184-185Upgrade customizing, 202

INDEX 331

Upgrade directory, 146-147Upgrade downtime strategy, 167-169Upgrade elapse time, 183-184Upgrade key, 121-122Upgrade log files, 147-148User interfaces, 293-294User management, 60User management engine (UME), 127-128User modifications, 137-145 Modification assistant, 144-145 Preserve modifications, 137-138 SPAU, 140-143 SPDD, 138-140 Transporting modification adjust-

ments, 143-144US-GAAP, 181

V

VARDATA, 27VC, 104, 269-270VCM (virtual machine container), 13VDS, 298Version management, 47Vertex, 234Views, 29Virtual tables, 29Virtual tape libraries, 299VMC, 14VMWare ESX, 294VNSG, 89VSE, 293-294

W

Warehouse manager, 209WDSL, 299WE8DEC, 187-188Web Dynpro, 39, 105, 238, 241Weblogic, 10, 262WebMethods B2B Integration Server, 234,

244, 262WebSphere, 10, 244, 262WebSphere MQ, 234Windows, 233, 264, 271Withdrawn from maintenance, 88-90WS, 299WSDL, 289

X

xApps, 288-289Xeon, 242-243XI/PI, 250xIEP, 288XML 234, 269, 289xPD, 288XPRA, 47, 52, 56XPRA (report after put), 175-176XPRA programsxRPM, 288

Z

ZTEST, 24

332 UPGRADING SAP