SAP EssentialGuideToSapUpgrades

The Essential Guide to
SAP R/3 Upgrades
P.O. Box 90608 Washington DC 20077-7637

Phone: 301-287-2678 Fax: 301-816-0037 Email: customer@SAPpro.com Web: www.SAPpro.com
The Essential Guide to SAP R/3 Upgrades
Table of Contents
Upgrading to R/3 Release 4.5 and Beyond:

An ABAP Developers Guide 3
Steven Shi, Senior Software Engineer, Storability, Inc.
Jun Qian, Senior Consultant, Cap Gemini Ernst & Young
A Release 4.5 or 4.6 upgrade is a major undertaking in which ABAP
developers play a critical role. This article shares lessons learned from
the authors experiences that will help ABAP developers and project managers avoid potential pitfalls
and make their upgrade experience faster, easier, and less error-prone. It discusses the developers
responsibilities throughout the upgrade, new and/or improved development tools, tips for analyzing
requirements, resolving upgrade conflicts, avoiding modifications, and making the best use of the
SPDD and SPAU upgrade utilities.
Selecting the Optimal System Landscape

for Your SAP R/3 Upgrade Project 27
Arthur Miller, Manager, Upgrade Competence Center, SAP America
An R/3 upgrade requires that changes be made to the new system, and it requires support for
ongoing changes to the production system as well, so the underlying system landscape must
make it easy to manage change. Most upgrade projects use a variation on one of two
landscape strategies: rehearsal of the upgrade process on a separate, standalone R/3 sandbox system, with
the intent of rolling out the upgrade to the production landscape at a later time, or upgrade of the production
landscapes development system right away, followed after a time by the upgrade of the QAS system, with
the maintenance of additional, temporary development and QAS systems to support the production system at
the old release. Understanding the principles, benefits, and limitations of each of these strategies will help
you decide which approach best suits your upgrade project.
Readying to Resize Your R/3 Platform

Kurt Bishop, Remote Consulting Team, SAP America 43
Whether youre sizing a brand-new system or resizing an existing system, there is only
one governing principle sizing requirements are defined by the extent of the SAP
functionality to be implemented. Upgraded functionality, for example, may consume
resources, whether you use it or not. When resizing an existing R/3 system, you must account
for all upgraded and additional new functions and applications. You must also make sure your existing
system is properly tuned, so you dont needlessly buy additional hardware. How do you analyze your system
to determine whether or not it is properly tuned? And how do you account for the workloads presented by
current and future requirements from conventional R/3 as well as new Web-based functionality such
as mySAP.com,Workplace, and B2B? These are some of the questions this article will address.
Subscription Information
Past Articles Index and Subscription Order Form 59
1
PUBLISHER
SAP Professional Journal
P.O. Box 90608
Washington, DC 20077-7637, USA
(877) 947-3012 toll-free
(301) 287-2678 phone
(301) 816-0037 fax
customer@SAPpro.com
www.SAPpro.com
EDITOR-IN-CHIEF
Bonnie Penzias
Bonnie.Penzias@SAPpublications.com
MANAGING EDITOR
Heather Black
Heather.Black@SAPpublications.com
EDITORS
Kristine Erickson, Celeste Frey, Susan Rona
TECHNICAL EDITOR
Thomas G. Schuessler, ARAsoft
tgs@arasoft.de or thomas.schuessler@sap.com
CREATIVE DIRECTOR
Bob Oakley
DESIGNER
Mary Rezetka
PRODUCTION MANAGER
Farrah Behbahani
MARKETING MANAGER
Jonathan Kent
JKent@SAPpublications.com
EDITORIAL BOARD OF DIRECTORS
Keith Elliott, Diane L. Gottheiner, Karl Kessler, Heinz-Ulrich Roggenkemper
SUBSCRIPTIONS
SAP Professional Journal (ISSN 1524-7767) is published bimonthly. An individual subscription
(six issues) is $495. Volume subscriptions available.
DISCLAIMER
Although we use reasonable care to produce SAP Professional Journal, we cannot assume any
liability for its contents. In no event will SAP Professional Journal be liable for costs or damages,
direct or indirect, including special, remote or consequential damages, even if SAP Professional
Journal has been advised of the possibility of such damages, from any cause, whether in contract,
tort or strict liability, in excess of the subscription fee paid by the subscriber.
CHANGE OF ADDRESS
If you plan to relocate, please give us 4 - 6 weeks notice to ensure that you do not miss any
issues. Postmaster: Send address changes to SAP Professional Journal, P.O. Box 90608,
Washington, DC 20077-7637, USA.
TRADEMARKS
SAP is a registered trademark of SAP AG. All other registered trademarks are the property of
their respective holders.
2
Upgrading to R/3 Release 4.5 and Beyond: An ABAP Developers Guide
Upgrading to R/3
Release 4.5 and Beyond:
An ABAP Developers Guide
Steven Shi and Jun Qian
The verdict is in! You have just learned that your company has decided
to upgrade your SAP R/3 system to the latest release (either Release 4.5
or 4.6).
Thats great news for users, who stand to benefit from a host of
new and enriched functionality, including integration of Internet tech-
nology, Euro functionality, a more intuitive graphical user interface, and
many new features in every functional area. Its also great news for
development teams, who stand to benefit from a wide range of new
ABAP development tools and functions.
Steven Shi is a senior software
engineer with Storability, Inc., which
specializes in high-end enterprise Of course, once that initial wave of euphoria wears off, you realize
storage area networks. He has that in the high-tech world where we all live, nearly all good things
extensive experience in SAP logistics come with a price tag. An R/3 upgrade is no exception. Upgrading to
and ABAP development.
Release 4.5 or 4.6 will introduce lots of wonderful new features and
enhancements to your R/3 environment, but dont underestimate the
amount of effort required for this major undertaking.
ABAP developers play a critical role in this process. You need to

be prepared. You need to understand the big picture before things get
started i.e., what happens during an upgrade and what new features
will become available to you once the new release is in place. Only
then can you create a clear roadmap to steer you through this undertak-
ing and ensure that you will not get bogged down by what might seem
Jun Qian is a senior consultant with to be an overwhelming number of tasks.
Cap Gemini Ernst & Young, where
he has extensive functional and
technical experience in SAP logistics, In this article, we share lessons learned from our experience in
data warehouse, and technical areas.
(complete bios appear on page 26)
No portion of this publication may be reproduced without written consent. 3

upgrading to R/3 Release 4.5. We provide an over-

view of the R/3 upgrade process from the ABAP An upgrade and an implementation can
developers perspective, including new and/or be comparable in scope. Where they
improved development tools that will make differ is that an upgrade project, unlike
your job easier.1 a shiny, new implementation, must
accommodate the existing R/3 system
Along the way, we offer tips on analyzing and all its custom development
requirements, resolving upgrade conflicts, activities. The focal point of the four
and avoiding modifications. We also discuss phases of an upgrade project is, in
the upgrade utilities (SPDD and SPAU), fact, maintaining the integrity of existing
which have undergone significant changes in custom development objects and
Release 4.5. modifications that you want to retain
in the post-upgrade environment.
We hope that our experience can help you avoid
potential pitfalls and make your upgrade experience
faster, easier, and less error-prone.
The four phases are:
! Preparation: Here you create your upgrade plan.

The most important activity during this phase is
preparing an inventory of custom development
Anatomy of an R/3 Upgrade objects.
An upgrade and an implementation can be compa- ! Upgrading your development (DEV) system:
rable in scope. Both types of projects require a When you upgrade your system, you overwrite its
good deal of planning, are major capital invest- existing R/3 Repository (the entire ABAP Work-
ments, and are often driven by high-level business bench library of ABAP programs, screen and
requirements, such as e-commerce initiatives menu layouts, the Data Dictionary, etc.) and give
or Euro conversion mandates. Where they differ it a new one. A standard R/3 Repository is
is that an upgrade project, unlike a shiny, new imported into your system, which means its up to
implementation, must accommodate the existing you to identify custom development objects and
R/3 system and all its custom development modifications you want to retain and to perform
activities. the steps necessary to make that happen.
There are four phases in an upgrade project, and ! Upgrading your quality assurance (QAS)
the focal point of each phase is, in fact, maintaining system: During this step, you will be able to
the integrity of existing custom development objects exercise (for a second time) the process to
and modifications that you want to retain in the post- upgrade your system. You will then import the
upgrade environment. changes you made to your DEV system. And
finally, you will perform the necessary testing in
a controlled environment to verify the modifica-
1
This article focuses on upgrade topics related to ABAP development
tions you made.
objects, which will be of interest to both ABAP developers and
technical project leads. It does not address upgrade issues related to ! Upgrading your production (PRD) system:
R/3 Basis or Configuration.
Go live and transition to support. You will
4 www.SAPpro.com 2001 SAP Professional Journal. All rights reserved.

ABAP Enhancements
Before you upgrade to the new release, its Modification Assistant and Modification
a good idea to familiarize yourself with the Browser4: This new tool, integrated into the
following ABAP enhancements, even if you do ABAP Workbench Editor, works behind the
not plan to deploy these new features during scenes to register all the modifications you
the initial upgrade: make to objects in the standard system in a
separate layer in the ABAP Workbench. It
can help you simplify future upgrade efforts,
Business Add-Ins 2: These pre-planned SAP
as well as organize existing modification
program exit points are similar to CMOD/SMOD
projects. By using the Modification Assistant,
enhancements in Release 3.0. However,
SAP will automatically log changes for you;
Business Add-Ins differ from CMOD/SMOD in
during future upgrades, SAP will be able to
that they employ stronger object-oriented (OO)
use this information to determine whether
programming techniques, allow for multiple
some of these changes can be adapted
levels of software development, and can be
automatically. Using this tool will save you
defined according to filter values so that you
significant time and effort in subsequent
can control Add-In implementation based on
upgrades. A standalone transaction
specified criteria, such as a particular country
(transaction SE95) lets you easily view
value.
modifications in the current system. Choose
to see any or all modifications, whether or
SAP Forms3: Before you start modifying not you made them via the Modification
SAPscripts, be sure to check out the new and Assistant. Previously, there was no
improved SAP Form functionality. The new systematic way to review all the modifications
graphical editing tool (PC Editor), syntax in your system. The only way to obtain this
checking tool (Text Check), and the external information was to gather information
PERFORM statements, which allow you to from myriad sources, including user
call your own code programs right in documentation and jogging ones memory,
SAPscript, make writing forms faster and and performing many painstaking
easier. analyses.
import all the changes you consolidated in the holistic view of your current SAP installation. It is
DEV system to the PRD system, and monitor an excellent opportunity to remove obsolete objects;
some critical processes in the system that relate improve, organize, and document existing ones; and
to your development objects. get rid of unnecessary modifications.
The good news is that an upgrade affords you a Given this list of opportunities, performing an
R/3 upgrade is clearly not a one-person effort. You
need to assemble a cross-functional team to meet
2
For more information on Business Add-Ins, refer to Karl Kesslers these challenges, just as you would for an initial
article, Extending and Modifying the SAP Standard with Business implementation.
Add-Ins and the New Modification Assistant, in the Premiere Issue
of the SAP Professional Journal.
4
3
For more information on SAP Smart Forms, refer to Christoph For more information on the Modification Assistant, refer to Karl
Wachters article, From New Graphical Tools to SAP Smart Forms Kesslers article, Extending and Modifying the SAP Standard with
The Next Generation of SAPscript, in the November/December Business Add-Ins and the New Modification Assistant, in the
1999 issue of the SAP Professional Journal. Premiere Issue of the SAP Professional Journal.

Figure 1 A Typical Upgrade Team

Role/Title Tasks
ABAP Developers Analyze custom programs and modifications

Perform modifications to programs
Perform necessary unit testing
Technical Project Lead Coordinate development tasks

Provide technical guidance to ABAP developers
Basis Administrators Set up upgrade system landscape

Perform tasks of database upgrades
Customizers/Configurators Configure system

Lead business users in integration testing
Project Manager Manage the overall project scope

Track progress
Make fiscal decisions
Functional Team Lead Coordinate configuration tasks

Lead integration test in a business area
A typical upgrade team includes the participants Preparing an Inventory of

listed in Figure 1. Custom Development Objects
To determine the scope and impact of your upgrade,
Now lets discuss what happens during each of
you need to assess which development objects will be
the four phases.
affected and to what extent. As an ABAP developer,
you have the most expertise in this area and this task
is clearly your responsibility. Start by generating a
list of all custom development objects. This inven-
Phase 1: tory, which can be quite time-consuming to compile,
is the most important document for planning an
Preparing for Your Upgrade SAP release upgrade. It provides the basis for
As with any software upgrade, your teams first step resource estimates, project plans, and project
is to create an upgrade plan. The project manager is progress validation.
typically responsible for leading this effort. How-
ever, as an ABAP developer and/or technical project A typical inventory includes the following infor-
lead, you are responsible for delivering several mation for each custom development object in your
components that are critical to a comprehensive and R/3 system:
accurate plan. Object name
Object description
A typical R/3 upgrade plan includes resource,
budget, project, and test plans, all of which stem from Object type, such as transaction program and
an inventory of custom development objects. screen, user exit, interface (ALE, EDI, BDC,

etc.), form, report, Data Dictionary objects, ZZCUSOBJ (yes, yet another Z program!).
modifications, etc. The source code is available for free at
the SAP Professional Journal Web site at
Transaction code associated with the object
www.SAPpro.com. Follow these instructions to
Function module associated with the object install and run the program 5:
Direction (for interfaces): Inbound or outbound, 1. Create a program ZZCUSOBJ (the program type
with inbound generally taking priority over should be 1 for online program), and assign it
outbound the status of test program. Then save this pro-
Frequency: Upgrade frequently used objects first gram as a local object onto your system.
(for example, wait until the end to upgrade a
report that only runs once a year) 2. Next, upload the source code you downloaded
from the Web site into the program. Save the
Business criticality program.
Business process owner
Technical tester 3. To run this program, you can use transaction
code SE38, then type in the program name
Functional tester ZZCUSOBJ. Click on the Execute button.
Technical test result: Does the object pass syntax
check? For programs, do they pass program 4. On the programs selection screen, enter the
generation? For reports, can you run them and customer naming range and/or development
get results back? class.6 You also need to supply a PC file name
Functional test result: Does the object perform for the results to be downloaded.
correctly in the business process?
Other notes Once the program is executed, it will display a
log of the programs that have just been downloaded
to your PC in a tab-delimited text file. For ease of
! Tip analysis, you may want to open this file in a desktop
Based on our experience, we also suggest database software program, such as Microsoft Access.
that you define contingency plans for key The file includes the attributes contained in SAP table
business-critical objects in case of upgrade TRDIR (i.e., program type, application area, author,
failure. Spending this time now will save you etc.), plus the associated development class, descrip-
countless hours of costly production and/or tion, and any transaction. When you enter the cus-
business downtime later. For example, if tomer naming range, note that the range encompasses
your production bar code interface fails after more than simple Z programs. For example, the
the upgrade, do you have an alternative customer naming range for module pools is SAPMZ*
manual process in place to continue and for customer function groups is SAPLZ*. You
production until the interface is fixed? will find a complete list of SAP naming conventions
posted on www.SAPpro.com.
A Helpful ABAP Utility 5

To install this program, you need to be familiar with ABAP/4
for Inventory Preparation Workbench tools.
Gathering information on custom repository objects 6

In previous 3.x SAP releases, SAP delivers some objects that fall
is a critical, yet cumbersome task. To make it easier, within the customer naming range. Be sure to exclude these
we developed an ABAP utility program named objects, which are listed in the TDKZ table, from your analysis.

Classifying Development Objects Now comes the fun part. You must now decide
and Modifications what efforts, on average, are needed to convert each
object type. Obviously, there is no standard guideline
Next, you need to classify each custom development on how to come up with this number, since everyone
object in your inventory according to its type. works at a different pace. You need to rely on
Why is this classification necessary? Well, in your experience and expertise, and dont forget to
this early planning stage of your upgrade project, bounce any assumptions off each other in the project
you need to come up with a reasonable estimate team. For your reference, weve included a sample
of the efforts required to complete the development estimate spreadsheet in Figure 3. Remember, this is
tasks. To do this, you need to know exactly how not meant to be a guideline on how much effort is
many custom programs would need modification needed in your particular project!
in an upgraded environment. This is where the
classifying of objects by type comes in. Figure 2 Now that youve gone to the trouble of amassing
contains a list of common object types, along and classifying this info, you need to translate it into a
with guidelines for assessing the associated budget plan, which is the estimate on the dollar
conversion effort. amount needed, as well as a resource plan, which is
Figure 2 Upgrade Impact on Common Object Types

Object Type Impact of Upgrade Conversion Effort
Custom Reports Minimal Typically simple syntax errors only.

Custom Transactions Moderate More effort than reports. As many custom transactions are
and Screens written as a frontend for BDC programs, you may want to treat
them more like BDC programs.
BDC Programs Moderate Many will no longer work due to changes in screen flow
logic, as well as changes in transaction codes and
movement types (a complete list of these changes is
available at www.SAPpro.com).
Enhancements and Significant Varies greatly, often requiring extensive integration
User Exits testing.
Inbound and Outbound Significant Depends on interface complexity. ALE, EDI, SAP messaging,
Interfaces and workflow interfaces typically require more configuration
changes. Batch file transfers typically require more ABAP
programming.
SAPscripts Moderate If you have combined standard print programs with custom
SAPscripts, you may need to adjust your forms to work with
the new print program.
Custom Data Dictionary Moderate Usually not labor-intensive to convert. Includes tables, data
Objects elements, domains, database indexes, and matchcode views.
Look for opportunities to eliminate some of them based on
business requirement changes.
(continued on next page)

Figure 2 (continued)
Object Type Impact of Upgrade Conversion Effort
Miscellaneous Objects Moderate Typically small ABAP programs. Includes pricing formulas
and requirements routings for pricing, copy control, output
control, account determination, material determination,
listing/exclusion, LIS, etc. Can create nasty surprises in
production if not properly tested and converted.
Modifications to Standard Significant Most labor-intensive objects to convert. Often difficult to
SAP Repository Objects identify, especially if entrenched with many OSS notes.
Look for opportunities to re-evaluate and potentially eliminate
some of these modifications. Must have thorough unit
and integration test scenarios.
Modification to SAP Moderate For example, changing the data element texts so they have
Standard Data Dictionary custom field descriptions in material master or customer
Objects master, etc. Look for opportunities to eliminate these
modifications, as SAP has a standard way to accomplish
the same task (such as text enhancement, which is discussed
later in this article).
Figure 3 Example of Man-Hour Analysis for Custom Development Objects

Custom Object Types Number of Objects Estimating Factor Estimate
(Average Number (Days)
of Days/Object)
Reports 250 0.5 125

Batch input programs 100 1 100
Standalone transactions 25 1.5 37.5
(excluding those created for reports)
Inbound Interface 11 1 11
Outbound Interface 3 3 9
SAPscripts 25 1 25
Data Dictionary objects 150 0.2 30
Enhancement and user exits 20 2 40
Miscellaneous objects 25 0.1 2.5
Modifications 2 5 10
Subtotal 390
Overhead allocation for project management 20% of subtotal 78
Total man days for development objects 468

Figure 4 Example of a Budget Plan for Upgrading

Area Sub-Category Units Unit Price Price
System Preparation Development 468 $800 $374,400

Configuration 600 $800 $480,000
Basis 250 $800 $200,000
Training Production 25 $500 $12,500
Sales 25 $500 $12,500
Distribution 25 $500 $12,500
Finance 25 $500 $12,500
Project Management 200 $1,200 $240,000
Hardware Database server 3 $70,000 $210,000
PC upgrade 100 $2,000 $200,000
Network Upgrade etc., etc. 200 $800 $160,000
Total $1,914,400
Figure 5 Example of a Resource Plan for Upgrading
25
20 Number of
consultants
Number of
15 business users
10
0
January February March April May June July
the plan to hire some external consultants and enlist your reference, Figure 4 shows a sample budget plan
internal resources. Typically the project manager will and Figure 5 shows a sample resource plan. Again,
take the initial estimate and complete the remaining please note that these are not actual figures for your
task, and we wont go into greater detail on this. For project.

Enhancement and User Exit Issues ABAP developer needs to provide. Start by estimat-
ing the amount of upgrade effort required from the
SAP distinguishes between the terms enhancements development team. Multiply each custom develop-
and user exits. The enhancement concept, which ment object by the assigned estimating factor (which,
was introduced in Release 3.0, refers to custom devel- as you remember, was assigned based on object type)
opment projects achieved via CMOD/SMOD. You to come up with a total man-hour analysis. Then
always implement enhancements in the custom nam- assign additional development team resources (such
ing range. User exits, on the other hand, are carried as project management, training, documentation, and
over from a much earlier release. User exits are SAP communications) to determine your total estimate.
pre-planned subroutines within standard programs.
You always implement user exits in the SAP naming
ranges. You can find an example of a user exit in the !"Tip
subroutine USEREXIT_CHECK_VBAK within the
How to Get a List of Custom Routings
program SAPMV45A, which is used for sales order
and Modifications
processing.
SAP reserves the number range 600-699 for
Both enhancements and user exits are protected custom routings. For example, if you create a
from SAP upgrades. However, user exits typically pricing requirement 622, the corresponding object
require more effort to convert, because they operate name in the system would be RV61A622. If you
within SAP programs and share global variables with follow the SAP naming convention during
the main program. As you upgrade the main pro- development, you can easily obtain a list of your
grams, remember that you may also have to rewrite custom routings. Since Release 3.0, you need an
user exits. OSS authorization key to make any SAP object
modification and create a routing. These keys are
Remember that SAP keeps user exits in include stored in the transparent table ADIRACCESS,
programs with names like MVxxxFZx. To obtain a which you can view through transaction SE16. On
list of these includes (and thus the active user exits), the selection screen, enter program ID R3TR,
you can use our program ZZCUSOBJ and enter selec- object type PROG, and object name *6++
tion criteria for the program name MV+++FZ+. to get a list of repository objects that end with a
The downloaded PC file will show you who last number between 600 and 699. To review custom
changed each program, which in turn enables you to routings, use the configuration transaction
focus on those that you have changed. VOFM: Maintain Requirements and Formulas.
Develop Your Resource, Budget, From our experience, here are some additional
and Project Plans tips for creating a good resource plan:
Once you have finished analyzing the upgrade scope Be sure to assign adequate resources to finish the
and impact, your team is ready to develop a resource upgrade project in a reasonable amount of time.
and budget plan. The project manager is typically Do not allow the upgrade to drag on. The longer
responsible for leading this effort, which consists of the upgrade, the harder it will be for you to keep
defining the necessary budget and resources that are the production system and the upgrade develop-
required to complete the upgrade. A complete project ment system in synch.
plan for an SAP upgrade includes milestones and
resource requirements from all members of the cross- As the upgrade proceeds, chart your estimates
functional team. However, for the purposes of this against time and headcount variables (such as
article, well stay focused on the components that an staff availability, skills, and other competing

projects). Understand and communicate to Create Test Plans

project management the elasticity of your esti-
mate against these critical factors. For example, The last step in preparing for your upgrade is, in our
your cost estimate could change significantly if opinion, the most critical. You need to develop a
you cannot obtain enough internal resources detailed test plan to ensure that all critical business
during a critical phase of the project and need to requirements are tested and work as expected.
hire consultants to fill the gap. Typically, you will need to work with the functional
configurators to come up with this plan. As part of
this effort, you need to sequence the test cases and
plan for resources. When developing your test plan,
Prepare Your System Landscape make sure that you have covered the following areas:
In addition to developing a budget and resource plan, Business process validation (consider using
preparing your system landscape is an important part your Y2K test scenario as a template!)
of getting ready for your upgrade. Managing an
upgrade is a significant effort. From our experience, Reporting testing
minimizing the amount of work and managing it Interface tests
carefully are key success factors. As an ABAP devel-
oper or technical project lead, you play a significant Printing and forms testing
role in this effort in the following areas: Performance testing
Before beginning the upgrade, clean up your
Integration tests
development environment as much as possible.
You may also consider freezing some develop- Modifications
ment projects for the duration of the upgrade.
Procedure (i.e., workarounds)
Set up development and document standards, and
progress-tracking tools. Its highly likely that
you already have these tools in place to support
your SAP production system. Consider simply Phase 2: Upgrading Your
adapting them to support the upgrade project.
Development (DEV) System
Decide on a communication plan and a develop-
ment methodology. SAP publishes a free meth- You know what to expect during the upgrade, you
odology called ASAP, which includes an upgrade have an upgrade plan, and youre as prepared as
methodology. possible. At last, youre ready to actually begin
upgrading your development system! The primary
You also need to decide on a strategy to keep goals of the DEV upgrade are exercising the process
your production and upgrade environments in synch of an SAP system upgrade, making necessary adjust-
during the upgrade. Our experience has shown that ments to the upgrade environment through configura-
the most effective strategy is to minimize develop- tion and custom development, performing unit test-
ment in the old release unless it is critical to produc- ing, and releasing the changes for transport to subse-
tion. Making too many changes to the production quent systems.
system via the old development system defeats the
purpose of upgrade testing. For more information As an ABAP developer, the following tasks are
regarding effective strategies for keeping these your key responsibilities during this phase:
systems in synch, refer to the article Selecting
Resolve SPDD and SPAU modification issues
the Optimal System Landscape for Your SAP R/3
Upgrade Project on page 27 of this publication. Upgrade custom development objects

An Upgrade Transaction Primer SPDD and SPAU

By now, you should have a good understanding of allowing you to adjust them prior to the database
what activities occur during an SAP R/3 upgrade, conversion. Thus, it must be executed during the
how to plan for an upgrade, and how to prepare software installation, before the database conversion.
the development components of the project plan. During the upgrade, SAP identifies all at-risk modified
Its important for us to pause here to review what Data Dictionary objects and presents them for
actually happens to development modifications adjustment. At-risk means objects that could
when the upgrade occurs and what you as an potentially cause data loss in the new system if not
ABAP developer need to do at that time. Note that adjusted properly, including domains, data elements,
when the new release is installed, you will lose any tables, structures, table indexes, etc.
modifications to SAP Data Dictionary and reposi-
tory objects. However, SAP provides two transac- The person who performs the software upgrade
tions that allow you to view and adjust objects that (typically someone on the R/3 Basis team) must
you have modified: choose between retaining and canceling modification
for each object presented for adjustment. You dont
SPDD You use SPDD for adjusting most of have to make a final decision on every modified Data
the Data Dictionary objects during the upgrade. Dictionary object at this time. Instead, identify those
Since the R/3 Basis team typically installs objects that could inadvertently cause data loss during
the new software, they are also typically an upgrade in other words, modified Dictionary
responsible for carrying out the SPDD objects that affect transparent tables and cluster
transaction task. tables. For example, if you have mistakenly added a
SPAU You use SPAU for adjusting custom field to an SAP table without using the Append
repository objects, as well as a few Data structure, you need to convert this table using
Dictionary objects, after the upgrade. appropriate techniques before the upgrade. Otherwise,
Developers are typically responsible for you will lose all the information in this table field.
carrying out the SPAU transaction task.
The last step in the SPDD process consists of grouping
As these two transactions are related, its important all SPDD adjustments performed during this stage
for you as an ABAP developer to understand the under one change request. This request is then
overall process. The R/3 Basis team normally marked as Select for Transport for SPDD, which is
conducts several test runs on a sandbox system to used to upgrade subsequent systems (QAS and PRD).
gain experience with the SPDD process before We discuss select for transport when we discuss the
upgrading the DEV system. This experience, SPAU transaction.
combined with your analysis of modifications
to Data Dictionary objects, should allow you to After the system is upgraded to the new version, the
establish a strategy for the SPDD process. SPDD transaction also allows you to review decisions
A typical approach consists of analyzing made during the SPDD process. The system lists the
modifications in the current system, identifying adjusted Data Dictionary objects for you. You can also
items with risk of data loss, and reaching decisions select Tools ABAP Workbench Utilities
on these at-risk items prior to executing the Maintenance Upgrade utilities Dictionary
SPDD process. Remember, however, that you compare from the menu to view the list.
will need to coordinate closely with the R/3 Basis
team before, during, and after the software Undoing the SPDD process
installation to ensure the success of both the
The SPDD process is always completed during the
SPDD and SPAU processes.
upgrade software installation and cant be undone.
However, Data Dictionary object adjustments are not all
What Is the SPDD Transaction? final. If you do not want to keep the changes made via
The SPDD transaction is an integral part of the SPDD, you have two options to change them so that the
software upgrade process. It prevents data loss subsequent system upgrades (i.e., Quality Assurance -
due to changes in Data Dictionary objects by QAS and Production - PRD) will reflect your corrections.
(continued on next page)

(continued from previous page) These tasks can span weeks or months, depending
on the complexity of your system e.g., size of the
The first option is to overlay your change after the database, number of foreign languages supported, etc.
upgrade process. Treat the change to a Dictionary For reasons that will become clear in just a moment,
object as a regular upgrade task by creating a
change request and importing it after the upgrade.
when we review each activity in detail, this is usually
This is the most common way to make adjustments the most time-consuming phase of the project for
after the SPDD process. Obviously, in order to use developers.
this option, the change should have no data-related
impact. For example, you might use this approach
to restore a data element description back to SAP
standard, which poses no risk to stored data.
Resolve SPDD Modification Issues
The second option is more complex and involves

The task of resolving SPDD modification conflicts
interrupting the SPDD process during subsequent starts with reviewing the list of at-risk ABAP Data
upgrades. You should only use this option if you Dictionary objects to be addressed. To see this list,
foresee a risk of data loss. For example, you might you type in transaction code SPDD. If, like most of
use this approach to adjust a table field that was us, youre upgrading from a release earlier than
modified to have a wider field length than the SAP
standard. During the test phase of the subsequent
Release 4.5, all your Data Dictionary modifications
system upgrade, the R/3 upgrade control program will appear under Adjustable manually on the
will look for the special change request marked SPDD list, as shown in Figure 6. You can view the
select for transport for SPDD adjustment. Once it list sorted by CTS transport number or by application
finds this request, SAP offers to import the transport area. To toggle the view settings, select View
automatically. You can then choose to stop SPDD
to verify the changes in your SPDD change request
Settings Change view from the menu. For analy-
before they are activated. If you must re-adjust a sis purposes, we prefer to view the list by application
Dictionary object, you can do so at this time. Again, area because we like to coordinate and divide up our
this approach is reserved for objects that cannot be development efforts by their respective functional
adjusted via the first option. If you choose this areas.
approach, be sure to coordinate closely with your
R/3 Basis team to avoid incorrect or unexpected
results. To understand the conflict for a given object,
follow these steps to use the Version Management
What Is the SPAU Transaction? utility:
After the upgrade, all modified objects are overwritten
1. Move the cursor to a Data Dictionary object.
by standard SAP codes. The SPAU transaction
allows you to adjust programs (including module 2. Select Utilities Version management from
pools, ABAP reports, function modules), menus,
screens, interfaces, documentation, and text
the menu.
elements after an upgrade. In addition, SPAU covers 3. You will see a list of all versions for the object,
adjusting Data Dictionary objects for which there is
no risk of data loss (and therefore which are not including those in the previous release.
covered by the SPDD process), such as matchcode
4. Select both the current and modified versions.
views and lock objects.
5. Select Versions Compare (function key F5)
Since SPAU is done after the upgrade (again,
referring to the process of installing the upgrade
to view the difference between them, as shown in
software), developers are typically responsible for Figure 7.
carrying out this task. Compared to SPDD, the
process used to handle SPAU adjustments is much If you agree with the SPDD adjustments, you
simpler. We will discuss it in more detail in the dont need to do anything further. Otherwise, you
context of upgrading your development (DEV)
system.
must make the adjustments using the appropriate
ABAP Workbench tools, such as transaction SE11,

Figure 6 Viewing the SPDD Modification Issues List
Figure 7 Comparing Object Version Differences

Figure 8 Changing Keyword Descriptions via CMOD
Object Browser, outside of the SPDD list. Remem- Changing data element for keyword labels.
ber that the SPDD process is already complete This, too, is ill advised. Its best to use the SAP
at this time, you are simply reviewing the decisions. standard text enhancement tools to accomplish
The Adjust modification button that you see on this task.
the SPDD screen only applies to objects modified
Modifying domain to add a conversion routine.
with the Modification Assistant. Therefore, it will
This is another practice we do not recommend. A
not work if you are upgrading from a release earlier
far better approach is to use the field exit in SAP
than Release 4.5.
without modifying the standard system.
Avoiding Modifications You can easily avoid modifications by changing

the keyword description of any data element through
We often see customers make the following types of standard SAP tools in CMOD. For example, suppose
unnecessary modifications when examining the you want to change the description for the data element
SPDD list: MATNR from Material to Product. You would
follow these steps:
Adding table index or appending structure
1. Use the SAP transaction CMOD.
in change mode. Dont do this. Always use
display mode when you need to add an append 2. Select Goto Text enhancements
structure or table index. Keywords Change from the menu.

Figure 9 Viewing the SPAU Modification Issues List
3. Type the data element name and language, as Resolving SPAU Modification Issues
shown in Figure 8.
As for SPDD modifications, the task of resolving
4. Press ENTER. SPAU modification issues starts with reviewing the
list of items to be addressed. Follow these steps to
5. Add your own custom keywords for the data view the SPAU worklist:
element.
1. Type in transaction SPAU, or select Tools
You can also toggle between the customer
ABAP Workbench Utilities Maintenance
and SAP data element descriptions. To activate
Upgrade utilities Program compare from
the customer description, select Goto
the menu.
Text enhancements Keywords Restore
cust. version from the CMOD menu. To restore
the SAP description, select Goto Text 2. Choose one of the four sort options (by objects,
enhancements Keywords Restore by last changed, by transport requests, and by
SAP version from the menu. Refer to the SAP development classes).
documentation on enhancements for more details.
Executing the program with the default settings
6. Save the change to trigger the CTS request displays a list similar to the one shown in
screen. Figure 9.

Like most of us who are upgrading from a

! Tip
release earlier than Release 4.5, you will see all
Before you decide to re-apply a modification,
of your modifications listed under Without
make sure you have evaluated enhancements and
Modification Assistant. Follow these steps if
Business Add-Ins in the new system (for example,
you want to download the list in order to analyze
Release 4.6B comes with many more enhancement
it on a PC:
objects than Release 3.0D). Additionally, be
1. Put the cursor on the top level to expand all sure to consider whether any new functionality
sub-nodes. might work equally well.
2. Select Edit Expand subtrees from the !"Tip

menu. If you must make changes to the SAP standard,
use the Modification Assistant. This method will
3. To save the list, select System List Save
make future upgrades smoother and easier.
Local file from the menu.
After Release 4.5, modifications made with
the Modification Assistant can either be
!"Tip automatically adopted at upgrade time or
If your SPAU issue list is extensive, the down- adjusted semi-automatically later.
loaded list is not necessarily the easiest to
format and analyze. You may want to consider Restore the object to SAP original version
writing a temporary report in ABAP (referencing Alternatively, you can restore the object to the
the SAP program RSUMOD04) to get the data SAP original version. For example, you might
in a flat file. By the way, the SAP program for choose this option if your previous modification
displaying the SPDD list is RSUMOD02. was to apply an OSS note, but now the new
release incorporates that change. To choose this
option, select Modifications Reset to original
To analyze objects, use the Version Management from the menu. Note that SAP will restore the
utility (for details, refer to the previous section, object to its current version (not the version
Resolving SPDD Modification Issues). For each before the upgrade) because the object had been
modified object in the SPAU list, you need to choose modified before the Modification Assistant
between reapplying the modification or restoring it to became available. You will still be prompted to
the original SAP version: enter or create a transport request as if you were
making a change. Again, we recommend that
Reapply the modification you group all the SPAU changes into one trans-
One option is to change the new release of SAP port request. You may wonder why you need to
source code again. For example, you might carry out the action reset to original if you
choose this option if you determine that the modi- choose to leave object version as is. The rea-
fication is still necessary in the new release. Put son will become evident in the next step.
the cursor on the object. Then choose the Change
icon to branch into the appropriate ABAP editing After completing all modification adjustments,
tools, with the Modification Assistant mode use the select for transport function in SPAU to
turned on as the default. You can now use the automatically transfer them to a subsequent system
buttons to add, change, or delete codes from the (i.e., QAS or PRD). Similar to what the R/3 Basis
original. When you save your change, you will team did for the SPDD process, you select one special
be prompted to enter a transport request. You transport that is used for notifying subsequent
should group all SPAU adjustments under one systems of your SPAU adjustments. The transport
transport request. request that you select here is special, because during

an upgrade to a subsequent system, that system will Upgrade Development Objects

check to see if there is a change request marked for
SPAU adjustments. Once that change request is During the DEV upgrade, the second major task
found, the system will offer to import all the changes for ABAP developers is to convert all the custom
in the request. Once the import process is complete, objects. We recommend that you consider the
the system will regard all the objects contained in the following guidelines:
change request as properly adjusted and removes
them from the modified objects list. Therefore, in ! Prioritize upgrading objects based on their
future upgrades, these objects will not show up as business priority.
modified. This is why it is so important that you ! Consider the change frequency of an object.
perform the adjustments it minimizes the work Convert objects that require little configuration
involved in future upgrades! support first. Upgrade objects that are constantly
being modified in the production environment
To transport your SPAU adjustments, first release
last.
all tasks under the change request. Next, if you have
more than one change request, you first have to group ! Start major tasks early, especially if your
all entries in a single request. Figure 10 describes approach requires major integration testing (such
how to do this. You can select only one change as developing a new user exit to replace an old
request to be marked for transfer as a SPAU request. modification).
Then use the Select for transport button or select
Utilities Select for transport from the menu. By ! Involve business users before you start working
now you can see the significance of carrying out the on a given object. You may be pleasantly
reset to original action. Failure to do so means that surprised to find that some programs are no
these objects will not be included in the special SPAU longer needed!
transport and therefore will not be excluded from the
SPAU list during future upgrades. Before you begin, verify that objects are consis-
tent across the landscape! Due to unavoidable
Figure 10 Grouping Change Requests changes in the production environment to support
into a Single Request ongoing business needs, an object in the production
environment may not be the same as the version that
1. Go to request overview of the Workbench you are working on in the development environment.
Organizer (transaction SE09): Tools ABAP
Be sure to add a step in your development documen-
Workbench Overview Workbench
tation to record the object versions that are currently
Organizer Display.
in PRD and DEV.
2. Position the cursor on the request number of the
intended request for SPAU.
3. Choose Request/task Object list
Resolving ABAP Conflicts
Include objects.
4. Select the option Object list from request, enter In general, ABAP syntax checking in Release 4.5 and
the number of another request used during beyond is more restrictive than in previous releases.
adjustment in the field provided, and include For example, SAP flagged the following syntax errors
its object list. in Release 4.5B, but not in Release 3.0F:
5. Repeat Steps 3 and 4 until all requests used
during the adjustment have been included in the In the WHERE clause of a SELECT statement, a
request. date field was declared as type C and length 10.
6. Mark the master request as Select for This is not accepted in Release 4.5B; the date
transport for SPAU. field needs to be declared as a date type field.

We have often seen incorrect SELECT state- have the system automatically provide you with a
ments, such as: template for a BDC program. Follow these steps:
SELECT SINGLE FROM PLPO WHERE 1. Select the SHDB transaction code, or select
PLPO-PLNNR = '12345' AND System Services Batch input Edit from
PLPO-STEUS = 'PP08'. the menu.
In the WHERE clause, the developer had speci- 2. Click on the Record button.
fied the structure name, as well as the field name. 3. Compare the recorded steps with the old BDC
(Dont ask us why he wrote it like this!) This program.
code will compile in Release 3.0, but not in
Release 4.5 or Release 4.6. To fix it, you would 4. Modify the program accordingly.
change it to the following statement:
SELECT SINGLE FROM PLPO WHERE Tips for Adjusting SAPscripts

PLNNR = '12345' AND
STEUS = 'PP08'. ! Before trying to fix a failed form, try to
understand the business requirement and test the
In Release 4.5B, you cannot convert type F value standard SAP Form delivered by the new release.
to type N value. Instead, convert type F value to You may be able to eliminate a custom object.
type P value.
!"""Alternatively, if the standard SAP Form does
not meet your need, dont try to fix your old forms.
Converting BDC Programs and Interfaces Instead, copy the new standard SAP Form and
then overlay your changes.
A Batch Data Conversion (BDC) program or an
interface is much more likely to fail than a regular !"""Use the new Text Check feature to check
report. Depending on the number of BDC programs consistency between a form and its print program.
that need to be converted, this activity can form a This tool is useful for discovering hidden errors
major part of your upgrade effort. Often, the transac- that you might not easily find in testing.
tion screen field (new field or new required field),
screen sequence, or even the transaction code itself
is changed. For example, the material master basic Export Change Requests from DEV System
data view screen number has changed. In 3.0D, the
field for base unit of measure resides in program The last step in this phase is to organize your change
SAPLMGMM and screen 3004. In 4.6B, the screen requests. To ensure that change requests are exported
number is now 3005. This invalidates many material in the correct order, keep good documentation on the
master BDC programs. Visit www.SAPpro.com for a change requests you created. Oftentimes, you will
complete list of changed transaction codes. have change requests that must go into a subsequent
system in a particular order. To avoid confusion, you
Before you invest a lot of effort in fixing BDC should log in the change requests as they are released.
programs, first evaluate if new tools can fulfill the On some of our projects, we maintained a separate
business requirement. For example, you may find Access database so that everyone on the team could
that the standard ALE functions can replace an exist- log the requests in a centralized place. The tool also
ing data load program. However, if you do decide to tracked when a change request was logged, informa-
fix a BDC program, you may not know that starting tion that comes in handy when you later submit
with Release 3.1, you can record a transaction and change requests to the Basic team for transport.

Phase 3: Upgrading Your Quality from a development server because certain objects,
like queries, may only reside in PRD. You must
Assurance (QAS) System execute these tasks directly in the target system.
You have now successfully upgraded your develop-
ment system and are ready to move on to upgrading If you are upgrading from a release earlier than
your quality assurance system. The primary goals of Release 4.0, you need to convert any ABAP queries
the QAS upgrade are executing the SAP upgrade after the upgrade. For technical reasons, SAP does
process on the QAS server (which is usually a larger not carry out this conversion automatically during
database than the DEV server), testing the SPDD and the upgrade.
SPAU automatic import process, importing the con-
figuration and development changes you made in the SAP provides two reports to assist you in this
DEV system, and performing integration tests in a task. RSAQSUMM provides an overview of query
controlled environment. However, as an ABAP objects. RSAQUM40 allows you to convert and
developer, the following are your most important activate ABAP queries in your new system. If you
tasks in this phase: have never worked with SAP queries in a Release 4.x
environment, be sure to review the following change
Import transport requests from the development highlights before you begin the conversion effort:
system
Convert ABAP queries on the upgraded system The most notable change is that SAP now divides
ABAP queries into a standard area and a global
Activate custom enhancements on the upgraded area.
system
All queries that you created in a Release 3.x
Conduct performance and integration testing environment belong to the standard query area,
which is primarily designed for ad-hoc queries.
Standard area queries are client-specific. They
Import Transport Requests from the are not connected to the Workbench Organizer.
Development System
Importing transport requests from the development Since Release 4.0A, SAP has created a global
system is critical. This task allows you to test that query area. Global queries are client-indepen-
your transports are well organized and that your dent and used throughout the system, just like a
special transports for SPDD and SPAU work as regular ABAP report. These queries are con-
planned. Typically, your Basis team member will nected to the Workbench Organizer and therefore
perform this task, so be sure to coordinate with him can be transported to other systems.
or her. If your upgrade plans include stopping the
SPDD process to apply additional manual adjust- Starting with Release 4.0 and beyond, all query
ments, this is your last opportunity to test the objects delivered by SAP are located in the
approach before the final production upgrade. global area and have a /SAPQUERY/ prefix.
For example, the SAP global user group
/PQUERY/AM is assigned to global functional
area SAPQUERY/AM01. Query 01 within this
Convert ABAP Queries function area inherits the prefix.
You cant transport certain development tasks, like When working with standard area and global area
converting ABAP queries or activating customer queries, you cannot mingle the two groups. Standard
enhancements (which well cover in the next section) area user groups, function areas, and queries are

Figure 11 Obtaining a List of Query Objects via RSAQSUMM
always separated from global user groups, function 1. Run the report RSAQSUMM as shown in
areas, and queries. In any given SAP session, you Figure 11 to get an inventory of all query objects
can only view and work within one query area. The in the system. If this is the first time you are
query area in which you are allowed to work for a converting queries, you should not see any entries
given SAP session is set in your user profile. under the New standard area and New
transport datasets.
To start working with global area queries for the
first time, you must set a PID called AQW in your 2. Run the report RSAQUM40 as shown in
user profile. Set the value for global area to G (its Figure 12 to convert query objects. If you select
case-sensitive). Without this PID value, you will not the Convert all radio button, all query objects,
be able to view any of the global area queries deliv- including queries, user groups, function groups,
ered by SAP. (Consult OSS note 132813 for further and transports, will be converted into the new
information.) standard area and new transport datasets.
Follow these steps to convert ABAP queries: 3. Run the report RSAQUM40 again. This time,

Figure 12 Converting Query Objects via RSAQUM40
select the radio button Set release flag. This You may activate these components manually,
activates the query area and allows users to start or use the SAP program RSMODRES. If you select
using the query objects. (For more information, with generation on the selection screen of the report
consult the release notes in Release 4.0A and OSS RSMODRES, the associated programs and interfaces
note 92124.) are regenerated.
Activate Customer Enhancements Another post-upgrade task you will

need to perform is the activation of
Another post-upgrade task you will need to perform is enhancements. If you have created
the activation of enhancements. If you have created enhancement projects in your system
enhancement projects in your system through CMOD, through CMOD, you should know that
you should know that any GUI components i.e., any GUI components i.e., menu exits,
menu exits, screen exits, and their associated function screen exits, and their associated
exits are not activated automatically after an function exits are not activated
upgrade. automatically after an upgrade.

Conduct Performance and Integration Testing Be sure to review and approve all test
results, then deliver final documentation on any
Both performance and integration testing are key changed development objects to users for
components of the ABAP developers role during an training.
upgrade project, regardless of whether it is a technical
lead or a functional lead overseeing this task. The The test plan you developed in the previous phase
following types of performance testing are important will become a roadmap for this task. In the plan, you
because of database growth due to the upgrade and should take advantage of the tight integration features
change in database indices and structures: within your SAP system, and mix up your develop-
Test business-critical, performance-intensive ment objects within each string of the test. A string
programs (e.g., backorder rescheduling program, is a sequence of events in the test scenario for
MRP/MPS, etc.) in the QAS server with a example, a sales-to-cash test string may look like the
sizeable database. following:
Use runtime analysis and SQL trace for trouble- 1. Create a sales order for a foreign customer
shooting selected reports in either DEV or QAS. that is on initial credit hold. (Verify that
the user exit for credit hold works as
Integration testing is one of the most critical tasks intended.)
in the entire upgrade process. You need to devise a
good integration test plan that covers business critical 2. Verify that the order printed correctly.
transactions and adequately addresses the known (Verify your print program and your
modifications and enhancements in the system. Vali- SAPscript.)
date your test plan against the following checklist:
3. Release foreign trade block. (Verify your
! Full scenarios report on foreign trade.)
4. Release credit block. (Verify that the order

! Business processes was faxed properly to the customer.)
! Reports 5. Generate daily sales report through an
interface to your data warehouse.
! Electronic output (Verify your interface.)
! Interfaces 6. And so on.
! Enhancements
! Batch processing Phase 4: Upgrading Your
Production (PRD) System
! Printer, fax
By the end of Phase 3, you should feel quite confident
! Procedure that your upgrade project is on its way to its success-
ful completion. You have resolved the conflicts,
! Modifications converted your custom objects, conducted thorough
(if you are unlucky enough to have them) testing, and experienced several software installation
processes.

Before you proceed with the final step of !"""Decide on your project methodology early.
upgrading your production system, take the time to An upgrade project can be a complex project. A good
check once again that your environments are still project methodology is critical to its success. SAP
in synch. All differences between development delivers an excellent project tool, AcceleratedSAP
objects in the production and development environ- (ASAP), which is free and includes a dedicated meth-
ments must be reconciled. This is of paramount odology specific to an SAP upgrade. So even if you
importance! The last thing you want during decide not to use ASAP, be sure to ask for the free
the production upgrade is a surprise for example, CD from your SAP support person, and review the
discovering a table field has been changed directly methodology.
in production without your knowing about it.
Although you may have already conducted this !"""Constantly refer to the project plan. Dont just
analysis in the previous steps, it does not hurt to be lock up the project plan and only refer to it at the end
extra careful and run the analysis one more time of each phase. Make sure each member of the team
before you go live. has access to the updated project plan, knows exactly
where the team stands on the project roadmap, and
If you properly marked all SPDD and SPAU what is expected in the time ahead.
change requests in your development environment,
the R/3 upgrade control program will find them dur- !"""Dont forget about post-live training and
ing the test phase of the production system upgrade. support. The project does not end when you go
If this is the case, R/3 offers to import the transport live. Be sure to budget for extra resources, both
automatically, instead of having you execute the internal and external, during the initial stage after
SPDD/SPAU transactions again. By using this proce- going live.
dure, you still have the option of stopping SPDD/
SPAU to check the changes accepted automatically
before they are activated. Again, depending on your
situation, you may need to make a special adjustment
manually for SPDD.
Are You Ready to Upgrade?
Finally, as you did when you upgraded the quality
assurance system, perform the remaining tasks (con- Congratulations you now have all the information
verting ABAP queries and activating certain user you need to begin preparing for your own SAP R/3
enhancements) that can only be done in the target upgrade! The upgrade is sure to provide ABAP
system. developers with numerous benefits and exciting new
features.
But dont fall prey to upgrade pitfalls. Enter the

upgrade process with knowledge of what needs to be
Helpful Hints done and how you will do it. Hopefully, this article
will help you achieve this imperative.
!"""Dont underestimate the efforts required
on documentation. Documentation should be an The exercise of upgrading an SAP system encour-
integral part of each team members task, not an ages all of us to become more adept at dealing with
afterthought. Clear and timely documentation system enhancements and writing more rigid code.
provides great value for this project as well as for More important, the upgrade experience can help you
projects in the future, so dont cut corners on gain a more comprehensive understanding of the SAP
documentation. system. Using this knowledge, we can craft better

development strategies in the future and contribute to

building a more robust, efficient, and powerful SAP Steven Shi is a Senior Software Engineer for
system for your organization. Storability in Southborough, Massachusetts, the
market leader in building and managing high-end
enterprise storage area networks (SANs). Steve is
Jun Qian is a senior consultant with Cap Gemini tasked with building a first-of-its-kind application
Ernst & Young. He recently completed an SAP to enable real-time management of distributed
4.5B upgrade project where he was responsible networks and storage devices. In exchange for
for upgrading technical objects and the Quality doing real work, he gets to socialize with the
Management module. worlds best engineers in the fields of optical
networking, enterprise storage, and object-
oriented programming.
Jun has extensive functional and technical
experience in SAP logistics, data warehouse, and Steve has extensive experience in designing and
technical areas, including Materials Management, implementing modern n-tiered information
Quality Management, Business Information systems. His background ranges from mainframe
Warehouse (BW), and ABAP/4 development. computing to client/server technology, and from
Jun also has a background in SAPs B2B and SAP systems to Internet applications. Before
Aribas e-procurement applications, and he is joining Storability, Steve was a Lead Engineer
involved in CGEYs e-procurement initiative. for EC Cubed, an Internet application provider,
Prior to joining CGEY, Jun was a consultant with and led a team of software engineers building
Andersen Consulting. an e-commerce application on the Java platform.
Prior to EC Cubed, Steve was a functional and
Jun has an M.S. in Electrical Engineering technical consultant for SAP America and
from Gonzaga University in Washington, Andersen Consulting. He consulted his clients in
and a dual B.S. in Electronics Engineering the areas of SAP Materials Management, Sales
and Industrial Foreign Trade from Shanghai and Distribution, Quality Management, and of
Jiao Tong University in China. Jun can be course, ABAP development. Steve can be reached
reached at Jun.Qian@us.cgeyc.com. at steve_shi@mail.com.

Selecting the Optimal System Landscape for Your SAP R/3 Upgrade Project
Selecting the Optimal System

Landscape for Your SAP
R/3 Upgrade Project
Arthur Miller
As with any major packaged software installation, managing the periodic

R/3 release upgrade is a necessary part of life. Upgrading ensures that
you have access to the latest core functionality of the R/3 product, that
you can support the full mySAP.com product suite as well as the latest
third-party tools and packages, and that you will receive current support
from SAP in the form of Support Packages, HR legal updates, and bug
fixes published in SAPNet. SAPs goal is to make the release upgrade
process manageable meaning the upgrade can be completed in a
timely manner, at reasonable expense, and with minimal impact.1
Anyone who has participated in a previous R/3 release upgrade

knows that its not exactly a trivial exercise. Ideally, each and every
Arthur Miller has been business process used in your R/3 system must be re-tested for its
employed at SAP America functionality at the new release. Additionally, your authorizations
for over six years. He is scheme and custom Workbench developments (e.g., reports and
the manager of the Upgrade interfaces) must also be tested to ensure they continue to function as
expected. If youre not exactly sure how to evaluate these areas,
Competence Center, an
then an upgrade project requires that you first get your house in order
internal SAP support team in these areas.
that has the mission of
supporting SAP consultants In an ideal world, the process of upgrading your production
and customers through all landscape2 would be relatively simple: you would upgrade your
phases of the release
1
upgrade process. While this article focuses on SAP R/3 system upgrades, many concepts apply to other
mySAP.com application components, such as SAP Business Information Warehouse
(SAP BW), SAP Advanced Planner and Optimizer (SAP APO), and SAP Business-to-Business
Procurement (SAP BBP). Since these products are based on a similar technical architecture to
R/3, upgrades may be managed similarly. For more specific information, contact the respective
competency centers for these products.
2
A landscape, as used here, refers to the R/3 systems in use by an enterprise, the clients in
those systems, and the policies governing the management of changes to those systems.
(complete bio appears on page 42)

development system, move on to your quality assur- parallel with the upgrade project varies widely among
ance system, and finish with your production system implementations. At one end of the spectrum, some
one-two-three, and youre all done! implementations are able to all but eliminate produc-
tion changes for the duration of the upgrade project,
Reality, of course, presents an entirely different allowing only qualified emergencies. At the other
picture. The impact of the new release is simply too end, some upgrade projects are forced to conduct
great in a complex, integrated system like R/3 that their evaluation work alongside a significant degree
has been configured to a customers exact specifica- of change in the existing production system. This
tions. You generally need to make changes to the change could be the result of ongoing rollouts of new
new system that you will be rolling out, as well as users or functionality, or simply due to a relatively
support ongoing changes3 to the production system unstable environment that is still working out the
for the duration of the upgrade project. Because kinks.
change management is so critical to the upgrade
process, you want to make sure that you employ a There are probably an infinite number of different
system landscape that makes it easy to manage: upgrade landscape strategies that have been proposed
Changes that support the future rollout of the

upgrade: Modification adjustments, changes to The Repository Switch Upgrade
Customizing settings to either preserve existing In an upgrade, a new release of software is
functionality or make use of new functionality, applied to the R/3 Repository, which includes
and new ABAP Workbench development activity the entire ABAP Workbench library of ABAP
could all be part of the changes made to the new programs, screen and menu layouts, and the
release before it is ready for production activity.4 ABAP Dictionary and its assorted components.
Regardless of the net change between a source
Changes that support the existing production release of a system and the release it is being
system: Since an upgrade project may take upgraded to, a complete copy of the repository
months, it is not realistic to think that no changes is delivered with each upgrade. We refer to this
will be allowed in the production system prior to as the repository switch upgrade. 5 Since the
the upgrade of that system. Instead, such changes complete, standard repository of a given R/3
must be made in isolated environments, tested release is imported into the system (regardless
of what release was present prior to the
properly, and introduced into the production
upgrade), a series of adjustments are
system in accordance with the quality control performed to retain customer modifications and
procedures already in place. Since these changes new objects. Elements of the old repository that
also need to be present after the upgrade, they were created or modified by the customer and
must be included in the activities being performed are needed after the new repository is delivered
as part of your upgrade project. are copied into the new repository. Finally,
a switch is effected, and the old repository is
The degree of change that must be managed in deleted from the system.
3 5
The term change in this context refers to changes in functionality As of R/3 Release 3.0, SAP introduced the repository switch
effected through updates to Customizing settings or to the ABAP upgrade as the means of delivering a new release of R/3 to an
Workbench. Changes to master and transaction data are obviously part existing system. In the old days, before Release 3.0, only the
of normal production activity and are not considered changes in this changed repository objects were delivered with an upgrade; this
sense. method was called a delta upgrade. For example, the upgrade
4
The latter two types of changes changes to Customizing settings process between Releases 2.1D and 2.2C delivered a different set
and new ABAP Workbench development activity will be imported of objects than an upgrade from 2.2B to 2.2C. This strategy, while
into the newly upgraded system after the upgrade. Modification efficient from a data volume standpoint, led to many inconsisten-
adjustments are imported or manually performed at their respective cies and was difficult in general for SAP to support with a high
points during the upgrade itself. level of quality.

Figure 1 The System Identifies the Necessary SPDD Adjustments
from time to time, but for the most part, and depend- upgrade projects. As such, the goal of this article is
ing where they fall on the aforementioned spectrum, to present the two basic approaches, Method A and
all upgrade projects use a variation on one of the Method B, and allow you to decide which elements of
following two landscape strategies: each to incorporate in your own plan.
Method A: Rehearsal of the upgrade process on a
separate, standalone R/3 sandbox system, with the
intent of rolling out the upgrade to the production Method A: Rehearsal of the
landscape at a later point in time. Upgrade Process on a Separate
Method B: Upgrade of the production land- Sandbox System
scapes development system right away, followed
after a period of time by the upgrade of the QAS When upgrading a system landscape to a new release,
system, with the maintenance of additional, you must perform the following general steps for
temporary development and QAS systems to each system in the landscape:
support the production system at the old release.
1. Apply the upgrade to the system and make any
Understanding the principles, benefits, and limita- necessary SPDD adjustments during the process.
tions of each of these two landscape strategies 6 will This process includes the entire technical upgrade
help you decide which approach best suits your (see sidebar entitled The Repository Switch
upgrade project. No single strategy could apply to all Upgrade). The system will identify for you
which objects, if any, must be addressed in the
6
For the sake of simplicity, a basic three-system landscape will be used SPDD adjustment, as shown in Figure 1. See
in the examples. Extending the concepts to larger landscapes should
be relatively simple once the basic principles of each strategy are sidebar for more information on SPDD
understood. adjustments.

Figure 2 The System Identifies the Necessary SPAU Adjustments
2. At the very end of the upgrade, make the neces-

Why Are Modification Adjustments sary SPAU adjustments (see sidebar on modifica-
Necessary During an Upgrade? tion adjustments). Again, the system will have
Adjustments of ABAP Workbench objects are necessary
determined which objects require attention in this
in one specific case: when both SAP and the customer capacity, as shown in Figure 2.
have made changes to the object since the prior
release. (If SAP has made a change to a given object 3. Apply any new change requests to the system.
but the customer has not, then there is no conflict; These changes will represent the customer-
conversely, if SAP has not updated the object, then
a customer modification can be retained after the
specific adjustments to the new release to preserve
upgrade without question.) existing functionality and/or incorporate new
functionality, and should be considered as one of
This adjustment cannot be performed automatically by the primary deliverables of the upgrade project.
the system. Someone must examine both versions and
determine what the final result should look like. Since
SAPs changes are desirable in almost all situations,
4. Perform a final set of acceptance tests to validate
adjustment usually involves modifying the SAP code yet the system. These tests, which may be executed
again to include the customers new functionality. manually or via automated testing tools, should
put your business processes through their paces
SPDD is used to identify the ABAP Dictionary objects and allow you to see whether or not the upgraded
that affect data storage. This step is done during the
upgrade, prior to activation of the new ABAP Dictionary
system is performing as expected. The rigor and
to avoid potential loss of data in the underlying data- thoroughness to which you conduct these tests is
base tables. All other ABAP Workbench object conflicts up to you; I have found that upgrade projects vary
are identified in SPAU at the very end of the upgrade. greatly in this respect.

It is important to understand that it will take Figure 3 The Method A Architecture:

some time and a series of iterations before the One Upgrade Test System
exact tasks involved in these general steps can be
refined and proven.
The basic principle of Method A is to rehearse DEV QAS PRD

and refine these tasks on a separate upgrade testing 3.1H 3.1H 3.1H
system this separate system is identified as
UPG in Figure 3. You create UPG as a database-
level complete copy of any of the existing systems
Production
in the landscape. (In this figure, the standalone Periodic Landscape
refreshes
system is a replica of the development system.
The question about which system in your three-
system landscape should be copied onto the Standalone
UPG Sandbox
sandbox system the development, QAS, or 4.6B System
production system will be answered in just a
moment.) The four steps listed above are then 1. Upgrade applied
executed (obviously, the first time such a system
2. Adjustments performed
is created, there would be no customer-specific
adjustments in step 3). 3. Customer-specific adjustments added
4. Validation tests conducted

Figure 3 illustrates this approach for an upgrade
from Release 3.1H to 4.6B.
As the process is repeated, the UPG system changes made in the UPG system through each of
is necessarily destroyed and re-created as another these refreshes. During the first refresh or two, your
complete database-level copy of one of the existing project team will most likely be in a discover-and-
systems. The trick to this approach is retaining the learn mode. Thus, retaining changes may not be
You can give this system any name (e.g., DMY in the
TMS Configuration for diagram). In addition, you must also define a customer-
Landscape Method A object transport route (shown as ZUPG) between
UPG and your virtual system. Without this route,
If you are using Method A (using a separate system for change requests created in UPG are not transportable
upgrade testing), you do not need to modify the existing and cannot therefore be exported from the system.
TMS configuration to support changes within the pro- If your policy is to allow modifications of SAP objects
duction landscape. You do, however, need to provide during the upgrade process, then you also need to
for the export of changes from the upgrade sandbox establish the SAP transport route between these
UPG. You can accomplish this by defining a virtual two systems.
system as a consolidation system for UPG, as shown
below. The DMY transport buffer contains a sequential
list of the changes exported from UPG. If you need to
TMS Configuration for Landscape Method A import these changes into another system or back into
UPG after a refresh, you can copy the transport buffer
SAP at the operating system level and use it to perform the
UPG DMY import. You can rename this transport buffer to the
4.6B ZUPG
proper SID and use it to execute a tp import all
command, or simply use it as a reference.

Figure 4 Considerations When Choosing a Source System for the Upgrade Sandbox
Source System Characteristics Suitability for Upgrade Testing
Development Source of all configuration and Probably suitable for functionality testing,
development activities. Probably depending on how congruent the configuration and
many in-process or miscellaneous repository are with the QAS and production systems.
changes that have never been
transported elsewhere.
Quality Assurance Same functionality as production, Suitable for functionality testing, depending
but may not have much, if any, on the requirement for real application data.
real production master/
transaction data.
Production Valid configuration with real Ideal if technically feasible, due to the presence of
master/transaction data. real application data. May not be feasible depending
on size of the database.
necessary, and you can treat the system as a sand- Figure 4 compares the merits of using
box to help you evaluate the new release. Eventu- each system.
ally, however, you will need to preserve these
changes by releasing the change requests prior to the The most often-used system is the production
refresh and rebuild of the UPG system. You can then system, because it contains real-world application
import the same change requests back into the UPG data. A key consideration in choosing to use the
system as part of step 3 of the next refresh. (See the production system as the source for your upgrade
sidebar on the previous page for more suggestions as sandbox is obviously going to be the volume of
to how the Transport Management System, or TMS, production application data in that system. If your
configuration of such a landscape should be configured.) database is particularly large, the costs involved with
duplicating it could be prohibitive e.g., the size
may exceed your available disk storage space, in
Which System Should Be Used As a Source for
which case you would need to purchase additional
Your Sandbox System?
space.
Before you create the UPG system, you have to
decide which of the existing R/3 systems should be If your production system is, in fact, prohibitively
used as the source for creating the upgrade sandbox. large, the QAS system is a good second choice.
In a standard three-system landscape, the develop- Here, the benefits of proper change management
ment system, quality assurance system, and produc- processes become evident. If managed correctly, the
tion system each has characteristics that make it more QAS and production systems should be functionally
or less ideal than the others for this purpose. identical, in the sense that they contain near-identical
repository and configuration settings in the primary
! Tip QAS client. They differ only in the volume of appli-
As you decide whether or not it is feasible to use cation data present in the system. In such a setup,
the production system as the source system for the QAS would be a perfect choice as an upgrade sand-
upgrade sandbox, remember that there are box, since it will allow for valid functional tests
currently no tools or methods for extracting a without requiring duplication of enormous amounts
logically consistent subset of master or transaction of application data.
data. Thus, you must copy the entire production
system if real production master/transaction data A development system would be useful for some
is needed for testing. early versions of the upgrade sandbox, but is probably

not suitable for more detailed upgrade testing. (See the sidebar on page 34 for a discussion of
A development system is probably more out of cross-release transports.)
synch with production than any other system,
and is also unlikely to contain master/transaction Introduce changes into UPG at the next
data that even remotely resembles production refresh of that system, instead of bringing
system data. production support changes directly into UPG.
You can rely upon the testing process in step 4 to
identify any new problems that arise as a result of
changes to the base configuration.
Managing Changes to the Production Landscape
When considering how to manage the production Your choice of policy will depend on many
landscape changes during an upgrade project, you criteria. Primarily, you need to estimate and
have three options: consider the volume of production changes that
need to be supported. A high volume of production
Manually re-enter all DEV changes in UPG at changes will mean propagating those changes
an appropriate time (e.g., once the change has more frequently to the upgrade testing system.
passed QAS testing and is approved for import The frequency of UPG system rebuilds is also
into PRD). These changes are included in the a key factor.
upgrade impact analysis, but excluded from the
adjustments made in step 3 since they would If your plans call for rebuilding UPG only three
already be part of the base configuration. times during an eight-month project, you will have
relatively few chances to understand the impact of
those new production changes at the new release.
Effectively maintaining and enforcing this policy
Refreshing more frequently diminishes the impact
might be problematic for example, a Custom-
of manual re-entry, since the changes will appear in
izing transaction may change entirely between
the UPG system in a relatively short amount of time.
two releases, obscuring the re-entry process.
Since the upgrade team will rely heavily on
In general, I tend to recommend a more frequent
proper replication of changes, you need to insert
refresh of an upgrade sandbox system, with no real
some sort of QAS into the transport process to
attempt to continually update those systems with
ensure that the changes made within the produc-
changes in the production landscape. The actual
tion landscape are indeed replicated properly into
tolerable refresh frequency will depend on the volume
the upgrade testing system.
of transports going through your production land-
scape, but one refresh per month should be sufficient
Import all DEV changes into UPG via for a majority of upgrade projects.
change requests at an appropriate time. This
method may be faster than manual re-entry.
However, there is a risk that the import will
overwrite changes made as part of the upgrade ! Tip
project, due to the way changes are transported Managing an upgrade project alongside
(e.g., the entire Workbench object or Customizing significant change to the production landscape
table entry is included at one time). More signifi- (e.g., new rollouts of users or functionality) will
cant is the fact that this option involves transports certainly increase the length of time and total
between differing releases of the R/3 system, cost of your upgrade project.
which makes it inadvisable in most cases.

Cross-Release Transports
Generally, SAP neither recommends nor supports cross-release transports. However, since there are cases
where it may save time and manual effort, lets examine whether you should even consider these types of
transports. Primarily, the contents of a change request determine whether a cross-release transport is
technically feasible, as summarized below.
Feasibility of Cross-Release Transports

Type of Object in Cross-Release Explanation
Change Request Transports Allowed?
SAP-owned ABAP Definitely not Since SAP may have changed the object, transporting
Workbench objects from a different release could introduce changes that
are incompatible with other objects in the repository.
Customer-owned Yes, in most cases Unless the object has also been changed by someone
ABAP Workbench at the new release, a cross-transport object usually
objects poses no problems. Whether the program functions
as before depends on separate factors that must be
evaluated as part of the upgrade impact analysis.
Customizing table/ Possible If the underlying ABAP Dictionary structures have
view data not changed significantly, transports usually can be
imported without a problem. Dictionary inconsisten-
cies are usually identified as warnings or errors in
the import logs. It is always prudent to examine
the relevant transactions in the IMG to review the
results of the import.
Transport-defined Probably not These objects represent special transport rules
objects other than embedded in the source code of the OS-level utilities
above e.g., R3TR that perform the export/import. Since a cross-release
AM17, R3TR COC1, transport usually also involves different versions of
R3TR SRTR the utilities (tp and R3trans), problems may result.
Potential problems in this case may not be identified
in the import logs, so you should only attempt such
transports with caution.
Note: This information is not an endorsement of cross-release transports and is provided for informational
purposes only.
Variation: Using Two Separate Rehearsal in the diagram). Using a second system allows you to
Systems release and transport changes to a separate environ-
ment. Since testing the transport itself is part of the
Alternatively, you could implement a variation of the change management process in general, using a sec-
Method A strategy that incorporates two upgrade test ond system should result in higher-quality transport
systems at the new release. Figure 5 shows the archi- requests for step 3 although at the expense of
tecture for this Method A variation with two separate maintaining an additional system. Finally, applying
systems for testing the upgrade (called UPG and UP2 the upgrade process to more systems gives you more

Figure 5 Method A Architecture Figure 6 Method B Architecture

Two Upgrade Test Systems Two Production Support Systems
DEV QAS PRD DEV QAS PRD

3.1H 3.1H 3.1H 4.6B 4.6B 3.1H
Production Production
Manual re-entry of Landscape Landscape
changes or system DB copies
refreshes
UPG UP2 DV2 QA2

4.6B 4.6B 3.1H 3.1H
practice (a key element of upgrade success), perhaps Method B: Maintenance of

reducing the frequency of refreshing UPG and UP2.
Temporary DEV and QAS
When executing the actual upgrade of the produc- Systems to Support the PRD
tion landscape, you perform steps 1 through 4 for System at the Old Release
each of the systems in the production landscape:
DEV, QAS, and finally PRD. You can then discard The second upgrade strategy, Method B, consists of
the UPG and UP2 systems, since they are no longer directly upgrading the existing development system,
needed. without prior testing on a separate upgrade system.
After a period of time, the QAS system is upgraded,
Clearly, the phased-rollout approaches for both followed by the upgrade of the production system.
initial implementation and upgrades of R/3 are highly During this time, you implement secondary develop-
similar, in the sense that you must manage changes ment and QAS systems to support the production
for both the new and existing landscapes at the same system that is still at the old release.
time. Thus, the architecture shown in Figure 5 could
also be part of an overall strategy to support an entire The advantage of this method is that it reduces
implementation life cycle. In this manner, you could the overall time to upgrade by minimizing the actual
rebuild the UPG and UP2 systems to support the next number of upgrades necessary to move the entire
phase in the rollout plan. landscape to the new release. The reason for this is
that only three upgrades are ultimately required to
On the surface, this alternative Method A archi- get the entire landscape to the new release. Also,
tecture looks similar to Method B (the second depending on the volume of changes within the pro-
upgrade landscape method). But looks can be deceiv- duction environment during the upgrade project, it
ing. As we delve beneath the surface, you will see may not be necessary to maintain a secondary devel-
that Method B supports a very different approach to opment system (this is discussed later in the article).
a release upgrade. Figure 6 shows the Method B architecture with two

TMS Configuration for Create a virtual system (shown as DMY) to

use as a delivery system from the 4.5 QAS
Landscape Method B system. The transport buffer for this non-
existent system represents the transport
If you are using Method B (upgrading your
requests that should be applied to the produc-
production landscape and using secondary
tion system after the upgrade, in their proper
development and QAS systems for production
import sequence. Keep in mind that these
support), you will need to modify the existing
changes should include all the changes made
TMS configuration. Since you no longer want
to support the production environment made
automatic transports from DEV or QAS to
in DV2/QA2, since those changes should
PRD, you need to delete the delivery route
have been manually entered in DEV and
between these two systems. As shown below,
transported to QAS along with upgrade-
set up a standard TMS configuration between
related changes. With proper testing
DV2, QA2, and PRD that is basically identical
and quality control, applying these
to the one that previously existed for DEV
changes after PRD has been upgraded
QAS PRD.
should not be harmful.
Again, you need to decide whether modifica-

TMS Configuration for Landscape Method B tions to SAP objects are allowed in DEV, DV2,
or both, and add the SAP transport routes to
the configuration accordingly. In addition, you
SAP need to determine whether to permit changes
DEV QAS DMY
4.6B 4.6B to customer-owned objects in DV2. These
ZDEV objects would be treated as repairs in DV2,
since they would still reflect that the originat-
SAP ing system was DEV. If your policy is to allow
DV2 QA2 PRD these changes to be made and transported
3.1H ZDV2
3.1H 3.1H to QA2, set up the ZDV2 transport route
accordingly.
temporary systems for supporting production Based on this method, you can upgrade an entire
(called DV2 and QA2). landscape by following these steps:
1. Make complete database-level copies of your

Method B consists of directly upgrading
DEV and QAS systems. Give the copies unique
the existing development system,
names, such as DV2 and QA2, as shown in
without prior testing on a separate
Figure 6. Continue running the old release on
upgrade system. After a period of time,
these systems for the purpose of providing
the QAS system is upgraded, followed
production support.7
by the upgrade of the production
system. During this time, you implement
secondary development and QAS 7
For more information on the specific tasks involved in performing
systems to support the production a database-level copy of an R/3 system, refer to the document R/3
system that is still at the old release. Homogeneous System Copy, which is available as part of the R/3
system installation kits.

2. Apply the upgrade, including modification Figure 7 Method B Architecture One

adjustments, to the DEV system. Secondary Production Support System
3. Perform a series of impact analysis activities

on the DEV system, capturing any necessary DEV QAS PRD
changes in change requests. These activities 4.6B 4.6B 3.1H
will involve research and education on the new
release, as well as changes necessary to preserve DB copy
existing business functionality.
Manual
re-entry of
4. Apply the upgrade, including modification changes QA2
adjustments, to the QAS system. 3.1H
5. Maintain DEV and QAS at the new release,

applying transports as necessary from DEV to
QAS. Meanwhile, enter any production-support
scope and complexity. (See the sidebar on page 36
changes in the DV2 system, then transport them
for suggestions on the TMS configuration for this
through QA2 and finally to PRD.
landscape.)
6. Upgrade the PRD system, make any modification
adjustments, and import any change requests
generated on the DEV/QAS systems. Variation: Using a Single System
7. Discard the DV2 and QA2 systems, as they are
If the volume of production support changes is very
no longer needed.
low, you probably do not need to maintain both DEV
and QAS systems at the old release. Figure 7 shows
the architecture for this Method B variation with a
The advantage of Method B is that it
single system for supporting production (called
reduces the overall time to upgrade
QA2 in the diagram). Since changes would be rare
by minimizing the actual number of
and made only in an emergency, you would make
upgrades necessary to move the
them directly in the QA2 system and then transport
entire landscape to the new release.
them to the PRD system. Obviously, this approach
The reason for this is that only three
is not ideal if the volume of changes is high (e.g.,
upgrades are ultimately required to
numerous changes introduced to PRD every week).
get the entire landscape to the new
release.
Choosing Between Method A

Incorporating production support changes and Method B
remains an issue with this method. However,
the upgraded systems will never be rebuilt or Obviously, every project is different. No single
refreshed. Therefore, you must re-enter all produc- upgrade strategy works with every project for every
tion support changes in DEV, either manually or via customer. In one sense, the difference between the
change requests. In general, this method is suitable two methods is primarily philosophical. Should you
for more stable production systems (e.g., those with develop, test, and retest the upgrade process in an
relatively few changes being introduced) or those isolated environment? Or, should you start by
upgrade projects that are relatively simple in their directly upgrading the landscape, taking care to

Figure 8 Selecting the Right Upgrade Strategy

Decision Factor Method A Method B
Number of additional R/3 One system (potentially two, Two systems (potentially one,
systems required? based on your requirements). based on requirements).
Experience obtained with Many practice upgrades Practice is limited to the DEV
the upgrade process? are executed. and QAS systems.
Best strategy given a Yes, because production No, because all production
high volume of changes support changes may not need changes must be entered
within the production to be entered manually in manually.
environment? upgrade system.
Best strategy for a shorter, Maybe not, because the value added Perhaps, because the time involved
less complex upgrade project? by the extra systems decreases. is greatly minimized.
provide for changes within the production environ- scape to the high-level phases of the upgrade project
ment as needed? SAPs recent extension of support plan, and define the landscape separately for each
for Release 3.1I and 4.0B make this decision poten- unique situation. Figure 9 shows an example.
tially more important. For example, an upgrade from
3.1H to 3.1I is going to be quite low in its complexity During the Evaluation phase, no changes in UPG
due to the small functional and technological deltas are retained. UPG is rebuilt at the end of Evaluation,
between the two releases, while an upgrade from 3.0F and all changes will be preserved from then on. Two
to 4.6C is going to be at the other end of the spectrum more refreshes of UPG will again occur during
entirely. Buiness Blueprint, although these dont really change
the landscape per se. Once the Realization phase
Figure 8 contrasts key characteristics of the two begins, and the production landscape is upgraded, the
methods. landscape will change with each step of the way to
reflect new procedures and potentially the loss or
addition of systems in the landscape.
Further Considerations Then, with each step in the evolution of the

upgrade project, a more detailed landscape strategy
The following sections include some important can be documented. The landscape itself, change
considerations to keep in mind when undertaking a management policies and procedures, and other
system landscape upgrade i.e., documenting the key assumptions should be documented clearly
landscape plan, factors that will affect your invest- for each step.
ment in the upgrade, and managing downtime when
executing the upgrade. A landscape strategy is not static; it
changes and evolves along with the
project. Thus, it is usually helpful to
Documenting the Landscape Plan correlate the changes in the landscape
A landscape strategy is not static; it changes and to the high-level phases of the upgrade
evolves along with the project as a whole. Thus, it is project plan, and define the landscape
usually helpful to correlate the changes in the land- separately for each unique situation.

Figure 9 Upgrade Project Timeline
1st UPG 2nd UPG 3rd UPG 4th UPG DEV QAS PRD
build build build build upgrade upgrade upgrade
Evaluation Business Blueprint Realization
Points during the project in which the system landscape will change
Contributing Factors Based on your decision with regard to your up-

grade landscape strategy, how many extra R/3
Regardless of the method you choose to use, certain systems will you need? Do sufficient hardware
factors may well influence the investment of time and resources exist to support the extra system(s)?
money required to upgrade your R/3 systems to a new
release. If you are just starting to consider whether to If you decide to use an upgrade test system,
upgrade, or if you are still assessing the potential which production landscape system will you use
costs of upgrading, answering these questions may for creating it? Are there any issues with data-
help you identify potential areas of concern: base size or application data consistency across
the various systems?
How well are your system modifications docu-
mented? Do you know which modifications you
will still need at the new release? Keep in mind Managing Production Downtime When
that the upgrade considers manually applied OSS Executing the Production Upgrade
notes to be modifications, so having a list of
such notes will be very helpful in resolving With any production upgrade, minimizing productive
SPAU conflicts. downtime while the system is being upgraded is a
primary concern. To understand the concept of
How easily can you test the necessary business downtime as it relates to upgrade runtime, consider
processes on the system? Does the project team the high-level phases of an upgrade as shown in
have a good understanding of exactly what must Figure 10. Based on your database log archiving
be tested? While ideally every implementation strategy which controls how and when the data-
has a defined testing process that is used to test base redo logs are activated, and affects overall
all changes (for example, the production-support runtime as well as whether a full offline backup is
changes that often occur regularly), the upgrade required post-upgrade you may be able increase
project often reveals that no documented, defined productive uptime by running parts of the upgrade in
testing practice is in place already. The release parallel to productive activities. While there will
upgrade thus forces the issue, requiring the likely be some impact on system performance, at least
project team to address this deficiency as part of you can keep the production system available for as
the upgrade. long as possible.

Figure 10 Phases of an Upgrade and Their Effect on Productive Operations

Upgrade Phase Key Activities Status of Productive
Operations
Initialization Version and environment checks, upgrade Uptime

tools imported, and upgrade processing
parameters are entered.
Data Transfer New Repository is imported into the database; Optional

analysis is performed on customer
modifications.
Pool Transfer Some pool tables are converted into Downtime

transparent tables.
Basis Adjustment Old release is shut down; repository of Downtime

new release begins activation.
Application Adjustment Adjust modifications (SPDD early, SPAU Downtime

late), convert application pool tables, and
perform all other adjustments to the new
release.
You need to evaluate several factors when esti- up large databases (e.g., perform reorganizations)
mating the upgrade runtime. Carefully consider, and, before the upgrade to minimize this factor.
if necessary, address each of these factors before
beginning a production upgrade, especially if Database Size
minimizing downtime is a major priority: Although generally not the major factor in
upgrade runtime, database size can be critical
depending on the specific tables undergoing
Database Server Hardware
conversion and how big those tables happen to be
Note that the upgrade process does not use
in a given system. You can determine whether
application servers in a system. Generally, these
database size presents a consideration for
servers are shut down at the beginning of down-
you once the initial upgrades have occurred.
time and are not started again for the duration of
Also, additional clients tend to slow the
the upgrade. Therefore, the speed and processing
upgrade; delete any unnecessary clients before
power of the central database server is a primary
upgrading.
factor in determining upgrade runtime. In addi-
tion, investing in intelligent disk subsystems
Unexpected Problems
can pay significant dividends during upgrades,
Remember that encountering a problem that you
as they increase the overall I/O throughput of
have not seen on previous upgrades can result in
the system.
unexpected delays while you try to resolve the
problem. A single never-before-encountered
General Database Performance error that arises during a production upgrade
If a database is heavily fragmented, performance could prevent completion of the upgrade, if you
degradation may cause the upgrade to run longer cannot summon the necessary support resources
than is necessary. In general, consider cleaning in a timely manner. For this reason, I strongly

recommend that you make every attempt to Conclusion

practice the upgrade multiple times and fully
document each and every error or warning In my six years with SAP, I have been directly
message that occurs as well as its eventual involved with 15 different customer upgrade projects.
resolution. I have found the following practices to be generally
accepted throughout the extended SAP community
One common R/3 upgrade challenge is not as conducive to successful upgrade projects:
having any available servers that are the size and
class of the production database server. This scenario
makes it impossible to conclusively determine how ! Practice, Practice, Practice
fast the upgrade might run on that server. By Without doubt, having significant experience with the
running the upgrade on smaller servers, you can at upgrade process (the technical upgrade, modification
least determine an upper limit on upgrade runtime adjustment, customer-specific adjustments to the new
and use it to establish your schedule. Obviously, if release, and testing/validation procedures) is key to
the test server is considerably smaller than the the success of the overall upgrade effort.
production server, your estimates will be extremely
conservative. ! Control the Scope
To minimize project complexity and reduce the over-
As a protective measure, standard upgrade all duration of the project, consider restricting the
procedures call for a drop-dead time. At this implementation of new functionality during the
prespecified time, if the upgrade has either not fin- upgrade process. Focus first on preserving existing
ished or not passed the testing/validation process, you business processes at the new release, then take
abort the upgrade and restore the system to a point advantage of new capabilities after the upgrade.
prior to the upgrade. You can enlarge this time win-
dow by implementing a standby database. Some data
storage technologies, such as those offered by EMC ! Utilize Scripting/Testing Tools
Corp., allow for breaking the disk mirrors at a spe- Since the testing and validation procedure should be
cific point in time; in case of emergency, the restore performed many times, investing in supporting tools
can be performed from that mirror. Investigate your can pay significant dividends. For example, R/3
options, given the technology in place at your comes with the Computer-Aided Testing Tool
implementation. (CATT), and Mercury Interactive offers the
WinRunner product. As with any tools, they will
require an investment of time to learn properly. In
With any production upgrade, minimizing addition, the process of developing test scripts will
productive downtime while the system is help clarify the business processes in use and the data
being upgraded is a primary concern. necessary to validate them, and this will pay divi-
Based on your database log archiving dends long after the upgrade project has concluded.
strategy which controls how and
when the database redo logs are ! Track Modifications
activated and affects overall runtime, Avoid wasting time during the upgrade to investigate
as well as whether a full offline backup modifications that occurred years ago and for which
is required post-upgrade you may you have no documentation whatsoever. Instead, set
be able increase productive uptime by up a process now to track all modifications to the R/3
running parts of the upgrade in parallel system, and establish policies regarding long-term
to productive activities. ownership of those modifications. With no one avail-
able to vouch for or otherwise defend the presence

of a modification, you face the risk of not properly

Arthur Miller has been employed at SAP America
including it in the new release.
for over six years. He is the manager of the
Upgrade Competence Center, an internal SAP
! Clean House support team that has the mission of supporting
A release upgrade can be a clarifying endeavor. SAP consultants and customers by providing
Some projects accumulate a formidable number of direct support and information about available
extraneous clients throughout the landscape, many services, tools, and accelerators through all
with poorly defined roles. The upgrade project is a phases of the release upgrade process.
great time to re-evaluate the presence of these clients, Formerly, he was a technical consultant and
delete the unnecessary ones, and simplify the land- member of SAPs Platinum Consulting
scape and transport process in general. As mentioned Organization specializing in R/3 release upgrades,
before, database size can have a direct effect on the Transport Management System, and system
upgrade runtime, so consider the use of SAPs landscape management in general. Prior to
Archiving functionality to remove unnecessary joining SAP, he was a consultant with Andersen
master and transaction data from the production Consulting in Chicago, Illinois.
database prior to the release upgrade.
Mr. Miller, his wife, and two daughters live in
suburban Chicago. He has a Bachelors degree
in computer science from Northwestern
University. He can be reached at
arthur.miller@sap.com.

Readying to Resize
Your R/3 Platform
Kurt Bishop
Change is part of life for an SAP system. Functions change and expand
in scope. New applications are deployed. More users begin to log on.
Software gets upgraded. And more and more R/3 systems are feeling
the impact of Internet-enabled applications.
Will change degrade R/3s performance? Absolutely. If your

system has been around for a while, you may be painfully familiar with
common resizing symptoms such as consistently high OS-level paging,
low CPU idle times, slow disk response times, or a variety of memory
management problems. Add a few users, or new functionality, and your
challenge increases significantly. Should you extend your current
hardware or replace it? Either way, the same questions demand
Kurt Bishop is a member of answers:
SAP Americas Remote
Consulting Team. This How many servers do I need?
team, whose members are
How powerful does each server need to be?
trained in both application
and technical support of the This is your classic capacity planning challenge, the same one you
R/3 system, provides a conquered when you originally purchased your system, but with an
variety of consulting and interesting twist. Before you start a resizing exercise, you have to make
support functions for sure your existing system is properly tuned. Well, you dont have to,
customers and colleagues. but if you are experiencing any of the symptoms above, you ought to
ensure you dont buy more equipment when all you really need is to
Kurt focuses on capacity
properly tune what you have. Besides, during the tuning exercise, you
planning services, working have the advantage of being able to draw upon reams of CCMS
to standardize and improve (Computing Center Management System) statistics to form a solid
the process for both foundation for estimating user-based and/or transaction-based workload
customers and vendors. demands that will help you decide what new equipment to purchase.
(complete bio appears on page 58)

Whether youre sizing a brand-new system or Suppose you upgrade the entire suite of R/3
resizing an existing system, there is only one govern- modules, but dont plan to use any of the new func-
ing principle sizing requirements are defined tionality. Shouldnt the same old hardware work
by the extent of the SAP functionality to be fine? Probably not. Much of the new functionality,
implemented: whether you use it or not, is taking up space in
memory (the most common functions are stored there
Customers running Financials (FI), Asset to increase performance and keep database retrievals
Accounting (FI-AA), and Controlling (CO), who to a minimum).
are only upgrading their R/3 system to ensure
their system operates at the current release levels, How do you analyze your system to determine
will generally not take a big hit in performance. whether or not it is properly tuned? Then, once its
Realistically, the baseline functions for general tuned and its clear the system needs to be resized,
ledger, accounts receivable, accounts payable, how do you account for the workloads presented by
etc. havent changed in years. While there may current and future requirements from conventional
be a variety of new reports, screens, and GUIs, R/3, as well as new Web-based functionality such as
the purpose of these modules is still to gather mySAP.com, Workplace, and B2B? These are some
and report accounting statistics whose rules are of the questions I will address in this article.
defined by some of the most conservative groups
and rulesets in the world. Therefore, most new
releases of R/3s financial software will not have Make Sure Your Current
functionality that requires a massive addition of R/3 System Is Properly Tuned
memory or processing power.
Sizing based on workload or performance statistics
If your R/3 upgrade involves human resources, from an improperly tuned system will be inaccurate.
such as Personnel Accounting (PA) and Personnel Consider the following for confirmation.
Development (PA-PD); logistics, such as Sales
and Distribution (SD), Materials Management Every user or program in R/3 must have access to
(MM), Production Planning (PP), and Plant a variety of buffers and memory to store and process
Maintenance (PM); or any of the industry- information, perform calculations, and generate
specific modules like Retail (IS-R); and you are screens or reports. Before a user can access any R/3
upgrading to take advantage of new functionality, memory, you must properly implement 20-30 profile
workloads will probably increase significantly. parameters pertaining strictly to memory and buffer
allocations (e.g., abap/heap_area_total,
Similarly, if you add new modules or customize em/initial_size_MB, rdisp/ROLL_MAXFS)
existing ones e.g., custom ABAP (Advanced for each of your servers. The memory R/3 has avail-
Business Application Programming) programs or able to satisfy all of these requests is constrained by
new BAPI (Business Application Programming the operating system and how much of its memory is
Interface)-enabled applications you clearly are allocated exclusively to SAP. The operating system
changing the workloads, and subsequent demands memory is ultimately constrained by the physical
for memory, CPU, disk, etc. memory installed in your hardware.
And who isnt considering B2B (Business-to- When your system is first installed oftentimes
Business), Workplace, and other Web-based by someone you may never see again the system
frontends? These products change workload automatically generates memory parameters for the
demands and shuffle hardware requirements operating system and R/3. These default parameters
in a variety of ways. are based on estimates of typical users and

workloads, and a series of questions that are keeping ! The base configuration
the installer from catching an early flight home. ! The hardware and operating system statistics
! R/3 workload statistics
Lets assume your database server is delivered
with 2 gigabytes of physical memory, and the ! R/3 buffer and memory performance`
installation/setup program determines that SAP and
the database management system should each get half.
Analyzing the Base Configuration:
The R/3 installation program will define your startup
Servers, Work Processes, and Load Balancing
profile using a variety of assumptions to divide R/3s
1 gigabyte of memory among the multitude of buffers The Process Overview (SM50, SM51, and SM66) is
and memory pools available for the end users. So the most effective way to gain a high-level view of
what do we do when performance begins to decline? your R/3 systems current activity. These transac-
tions allow you to watch programs execute in real
With most of todays hardware, you could easily time as they record cumulative execution times for
assume memory to be a cheap fix for poor perfor- work processes. All three provide the same basic
mance and drop in an additional 2 gigabytes of physi- information, so try them all and settle on the ones you
cal memory. However, unless you update your R/3 prefer. Transactions SM50 and SM66 provide high-
startup profiles, the new memory will never be used level views of system components and ultimately
because SAP will only allocate the 1 gigabyte defined transport you to SM51 for details on each instance of
during your initial system installation. And guess R/3. For real-time analysis of specific memory and
who looks bad for spending money on memory buffer activity, explore transaction RZ03.
when performance shows no improvement at all?
(Its not the installer who took that early flight home.) If you observe uneven workloads where entire
servers appear much busier than others, review your
So, you should always tune your system before logon load balancing schemes before tuning indi-
conducting studies to determine the current systems vidual work processes.1 Statistics from SM51 on
ability to support future workloads. Similarly, work process activity will provide information about
suppose you have installed and properly allocated the types of jobs being processed and on the servers
4 gigabytes of memory on your server. Then you are handling the heaviest loads. This will help you iden-
told there will be another 25 users added to the sys- tify servers with too few or too many work processes.
tem next month. You log on to CCMS and check For example, if your system has a total of 40 update
memory allocations and find a shortage. You know work processes and 10 show no activity after several
how to allocate memory, so why not just call the days of normal business, you can save memory by
vendor and drop in another 2 gigabytes of memory? eliminating the unused work processes. If your dia-
log work processes are experiencing high wait times,
Well, if you logged on when a resource-intensive, you can simply convert the unused updates to dialogs.
end-of-quarter job was running, during the busiest If your workloads vary drastically but the activity can
part of the day, you might not realize that 96 percent be tied to specific time periods, explore the use of
of the time your system only uses 2 of the 4 gigabytes Operation Modes.
of memory. So will more memory improve overall
performance? When you see work processes in PRIV mode,
you need to analyze your memory management
You will need to study the system under a variety
of conditions to determine what the most appropriate 1
For more information on logon load balancing, refer to Janet
decision might be. I recommend you start with an Hutchisons article, Lessons in Logon Load Balancing, in the
analysis of: January/February 2000 issue of the SAP Professional Journal.

strategies and server profile parameters. Private mode Consistently low values for free swap space
is usually an indicator of complex problems that need generally mean you need more virtual memory
to be analyzed in agonizing detail. Although eliminat- or tuning of processes that are consuming large
ing private mode, or any memory problem, may amounts of memory
appear simple, verifying the underlying problem(s)
and implementing the appropriate solution is often
quite difficult. Simple solutions range from running
jobs in off-peak hours to allocating more extended ! Tip
memory. When those fail, you may find yourself Always interview the end users and determine
examining the entire environment and reconfiguring what specific functions they were trying to
dozens of profile parameters for each and every server. accomplish during the evaluated time
periods. This will often explain unusually
heavy workloads or values that just dont
Analyzing Hardware and make sense. If you arent careful, you may
Operating System Statistics spend a considerable amount of time and
Dont forget, R/3 is just another application running money trying to tune a one-time event.
under the control of the operating system and hard-
ware. In an ideal world, nothing other than R/3
would be running on the server. In the real world,
system monitors, sniffers, and other applications vie
for OS-level memory and processing power. This Analyzing R/3 Workload
can have a significant effect on the R/3 system, Statistics
because SAP memory management is completely Workload Analysis (transaction ST03) statistics
dependent on the resources allocated by the base produce some of the most intriguing indicators of R/3
operating system. performance. While Process Overview transactions
show real-time activity of individual servers and work
The following are some estimates and statistics processes, Workload Analysis collects, consolidates,
from R/3 transaction OS06 (Operating System Moni- and displays historical response times for the entire
tor) that would cause me to suspect problems with the environment and each individual R/3 process. You
hardware and operating system: can review statistics for specific transactions, function
CPU idle time for a server that consistently falls modules, and programs within any given time period.
below 30 percent Because R/3 will often divide user programs into
multiple components that may run in a variety of
Pages out/second that exceeds 10,000 per hour
work processes, we need some way to consolidate the
over a 24-hour period
activity and show results in a format that more closely
Load average over the last 15 minutes that resembles the business process. Workload Analysis
exceeds 3.00 does this and much more.
Low values for physical memory available
(this varies from system to system; however, Keep in mind, most statistics are averages for
newer releases of SAP and related database specific time periods, and therefore may be mislead-
systems need more memory) ing. For example, if transaction VA01 (Sales Order
Processing) shows an average response time of
High values for physical memory free 10 seconds, you may think you have a performance
indicate you are not using the memory you have problem. However, if the transaction executed nine
purchased, or are allocating it to something times with a response time of 2 seconds and one time
besides R/3 with a response of 82 seconds, the average response

Figure 1 Dialog Work Process Statistics

Description Maximum Values
Average response time 1000 ms
Average CPU time 40% of total response time
Average database request time 40% of total response time
Average wait time 100 ms
Average load time 50 ms
Time per database 5 ms
Direct reads 2 ms
Sequential reads 10 ms
Changes and commits 25 ms
Roll-in time or roll-out time 10 ms
Response time for main menu 100 ms
Figure 2 Update Work Process Statistics

Description Maximum Values
Average response time 500 ms
Average database request time 10% of total response time
Average wait time 100 ms
Average load time 50 ms
Direct reads 10 ms
Sequential reads 15 ms
Changes and commits 40 ms
reported by ST03 would be 10 seconds. And if the One more point to always note in Workload
transaction that took 82 seconds was processing 200 Analysis is whether the response times recorded are
order line items, while the others were processing for a transaction, program, function module, or dialog
2-3 line items, you would be experiencing acceptable step. R/3 normally records statistics at the dialog step
performance. Furthermore, when looking strictly at level, and then consolidates those where appropriate.
the average response times for VA01, you wouldnt An SAP transaction, program, or function module can
necessarily know whether the 82-second job ran in have any number of dialog steps depending on the
the foreground or background. This could easily work being performed by the user.
make online response appear poor when, in fact,
it is within acceptable guidelines and service level So what is acceptable performance? Take a look
agreements. at Figure 1 and Figure 2. I recommend further

investigation when you begin to notice the types of Analyzing R/3 Buffer and Memory
conditions listed here more than occasionally. Performance
The statistics presented in Figures 1 and 2 can Transaction ST02 (Tune Summary) can be used to
also be found for batch/background work processes. tune R/3 memory and buffers. Tuning memory and
When analyzing response times for batch work pro- buffers is very complex and tedious. Ultimately, all
cesses, you must determine acceptable performance memory and buffer allocations, whether at the SAP
statistics based on your particular jobs, technical or operating system level, must be satisfied by
environment, user demands, and budget. the same physical memory, so you must always tune
these as a unit. And with R/3 memory and buffers,
this concept is even more important. Changes in
Also consider the following when reviewing
one area will always affect something else. There
batch/background statistics:
are hundreds of profile parameters related to system
performance, and the majority of these directly
! Most batch jobs are reported as a single dialog
affect memory.
step, and therefore have misleading average
response times when compared to online
You should also note that most of these param-
jobs that normally have a minimum of four
eters, and the guidelines associated with them,
dialog steps.
assume your memory is plentiful and properly
managed.
! Most online programs are working with just
a few line items for each transaction versus
In Figure 3 you will find some baseline sugges-
several hundred or several thousand for each
tions for R/3 buffer analysis.
batch job.
As you are monitoring and tuning your system,
! Many batch programs are simply displaying or
be sure to note any unusual processes that may have
reporting data with no updating of files.
occurred during the times being reviewed. Processes
that may invalidate your analysis include transports,
Some additional tips for analyzing both dialog and
table and tablespace reorganizations, most database
batch programs:
maintenance, data conversions, one-time-only pro-
cesses, and interfaces from other systems.
! Because they simply read and display data,
response times for query or report programs
should have a lower percentage of CPU time
and higher percentage of database request time
As you are monitoring and tuning your
than other processes.
system, be sure to note any unusual
processes that may have occurred
! Programs that perform complex calculations,
during the times being reviewed.
scheduling, or allocation routines should have
Processes that may invalidate your
a higher percentage of CPU time and lower
analysis include transports, table and
percentage of database request time.
tablespace reorganizations, most
database maintenance, data
! Custom programs not stored in the buffer, and
conversions, one-time-only processes,
programs that generate new code with each
and interfaces from other systems.
execution, may have high load times. Most
others should average near zero.

Figure 3 Rudimentary R/3 Buffer Analysis

Element Analysis
Hit ratio The hit ratio reflects the buffers efficiency. Whenever a user or function module
requests data or additional objects, the system will search the appropriate R/3
buffer. When the system is first started, buffers are empty, and hit ratios are zero.
Ensure your system has been active for at least a full business cycle before you
begin your analysis. Also avoid analyzing buffers during unusual processing
periods. For a stable system, investigate when buffer efficiency appears to be
declining over time, or when hit ratios consistently fall below 95 percent.
Nametab, CUA, screen, These buffers should see little growth in a production environment and can
and calendar therefore be configured with 5-10 percent freespace. Most of the other buffers will
need 20 percent freespace or more.
Directory entries All buffers need lots of free directory entries to perform their job. The more
modules and functions you use, the more object addresses you will need to store in
directories. Memory space requirements for storing the entry is minimal, so dont
hesitate to increase the number of directory entries for any buffer.
Object swaps A large number of object swaps is an indication of poor tuning or the need for more
resources. Some swaps are unavoidable, but if you force all users and processes
to share the same buffers, the system may spend more time moving objects in and
out of memory than actually accomplishing work. Object swap totals are cumulative
from system startup, therefore you should expect to see these numbers grow over
time. SAPs Variant Product Configurator, and other functions that generate code
in real time, will increase swaps in the program buffer. Swaps that occur for short
periods of time (e.g., during month-end close) should generally not pose problems
and may not benefit from tuning efforts.
Roll and paging Analyze roll and paging area memory in detail when the percentage of current
area memory use consistently exceeds 80 percent or when a large portion of processing occurs
on disk rather than in real memory.
Extended memory Analyze extended memory in detail when use consistently exceeds 75 percent.
Work processes in PRIV mode usually result from problems with extended
memory allocations and related parameters.
Heap memory Batch programs can use large amounts of heap memory and therefore cause
OS-level swap space requirements to increase. When you see large amounts of
heap memory being used, make sure you have enough OS swap space to keep
from freezing your operating system. Investigate non-background processes that
allocate large amounts of heap memory.
Call statistics You can use call statistics to analyze table buffers and efficiency of ABAP
programs. Investigate low hit ratios and high numbers of fails. Unusually high
numbers for SELECT are often caused by programs performing large numbers
of table scans, improper use or unavailability of appropriate indexes, or improper
search techniques.
SAP R/3 table statistics Use transaction ST10 to review table call statistics. ST10 will show the number of
table updates, direct reads, and sequential reads, and the number of calls and rows
affected. These statistics can be invaluable when you are considering buffering a
table, adding an alternate index, or stripping data and tablespaces.

Resizing Symptoms
Most any system has room for optimization, and I firmly believe in making the most of what you already
have, but at some point your system will need more hardware. And after all, client/server technology
was founded on the premise that hardware is cheap, so lets look at some hardware solutions for poor
performance. The table below shows some key statistics that often indicate problems with current
(or lack of appropriate) hardware components.
When to Consider More Hardware
Symptoms Possible Hardware Solution
Consistently high OS-level paging; lack of swap More memory.

space; high usage of roll and paging area memory
allocated on disk instead of real memory.
Consistently low CPU idle times in OS06. More servers/separation of workloads; faster
servers to increase total throughput.
Slow average response times in OS06 for disks. Faster disks/controllers; more disks/controllers for
stripping of data, improved logical volumes,
tablespacing, etc.
R/3 response in ST03 is good, presentation server Network switches, more bandwidth, faster lines;
response is good, total response time is poor; slow separate LANs, WANs, etc.
times for LAN pings in OS06.
Good overall response times for R/3 and the More servers to support Application and Web Gates;
network; poor response times for mySAP.com more/better frontend processors and Web servers.
and Web-based users.
High CPU processing times that are inconsistent Faster processors and/or more CPUs.
with the amount of work performed (and your pro-
grams are properly written/tuned).
Poor response times for, or caused by, batch pro- More servers and/or work processes to allow com-
cesses, RFCs, Workflow, ALE, EDI, etc. plete separation of work.
High wait times in ST03. More R/3 work processes, and therefore more
memory and/or servers.
Memory management problems (e.g., PRIV mode More memory and/or servers.
in SM51, overloaded extended memory in RZ03)
after exhaustive analysis of profile parameters.
Lack of workspace for the database and/or R/3. More memory and/or servers.
High object swaps in ST02 due to sharing of More servers and/or separation of work.
buffers.
Poor buffer performance/hit ratios in ST02. More memory and/or servers (separate workloads).

Capacity Planning
As I mentioned, tuning R/3, or any system, is a A Six-Step Process
difficult proposition. Although I would seriously
The process of resizing an existing system and sizing
consider more hardware during my reviews, I
wouldnt go out and buy hardware as soon as a brand-new system is basically the same. We can
the statistics in the table to the left appear. summarize the process in six steps2:
Memory and CPU can often overcome a variety
of performance problems in the short term, but 1. The hardware vendors SAP R/3 Competency
if you have bad code, sooner or later you will Center provides you with a survey asking for
have to rewrite it. the number of users and their activity levels,
transaction types and counts, modules you plan
Hardware is often the appropriate solution when
performance problems are not limited to a to customize, interfaces, and other items
specific module or group of programs. This is that characterize the unique computing require-
especially true when you notice response times ments of your environment.
slowly decreasing for R/3s key programs that
have been in production for months or years. 2. You (the customer) accurately complete the
survey and return it to the hardware vendor.
The most common need for hardware arises
when adding new users or functionality. Each
active R/3 user consumes several megabytes
3. The hardware vendor takes your estimates and
of memory, even if they log on and do nothing. crafts an initial design of your environment, using
An inactive R/3 work process will consume custom tools and techniques to predict the perfor-
approximately 13 MB of memory. The more mance of their specific hardware.
complex the work being performed, or the larger
the files being processed, the more memory 4. You meet with the vendor to scrutinize the survey
both of these will consume. So, as you add results and initial system design. Most customers
users or increase the complexity of functions opt to have an SAP capacity planning expert
performed, you will have to add R/3 work participate in this process as well.
processes and memory. At some point you will
reach the practical capacity of your physical
memory or servers processing capability.
5. The vendor provides a final proposal that includes
a system configuration, price, and delivery
Because most hardware vendors still suggest schedules.
limiting the total number of work process on a
server to 25, you can reach the capacity of an 6. You verify the results and turn in your purchase
application server in short order. Even in less- order!
consuming modules like FI, an R/3 dialog work
process can generally handle 10 or fewer
concurrent, active users before wait times (the
In a previous article,3 I presented the details for
time spent waiting for a previous job or user these steps while discussing capacity planning of
function to finish before you gain access to the new systems.
work process) become an issue. Ill let you
struggle with some of the math and move on.
Just remember, all hardware and operating 2
Admittedly, these six steps belie the complexity of a real-world
systems are different, as is every program and capacity planning exercise. If you have never participated in such an
function you execute. If this job were easy, exercise, this listing would lead you to believe that you advance from
everybody would be doing it and we would all one step to the next. Thats not the case. You typically cycle through
be paid minimum wage! many of these activities several times to achieve accurate results.
3
Size Does Matter Strategies for Successful SAP R/3 Capacity
Planning, SAP Professional Journal, Premiere Issue.

In that article, I explained how to fill out the CCMS will provide historical statistics for trans-
vendor surveys, the sizing tools and techniques they actions, programs, function calls, etc. Be careful to
use, and how to validate their proposals to ensure note the level at which you are viewing and compar-
they understood your business before they designed ing these statistics. It is all too easy to confuse
your system. transactions, programs, function modules, and
dialog steps.
The key to capacity planning for both new and
existing systems is the accuracy of workload esti- If youve been through the vendors survey pro-
mates. Therefore, I will focus on Step 2, gathering cess before, you will remember the grueling task of
statistics needed to complete the survey. For your trying to get some of these statistics from users and
new system, you probably had no idea what R/3 consultants. Remember how hard it was just to get
transactions you would implement and use, or how the end users to tell you how many people will be
much workload these would consume. So, the hard- using the system, what transactions they normally
ware vendors used a variety of techniques, such as execute, and when they normally use the system?
user-based sizing, to estimate resource demands. With an existing system you can use CCMS to gather
this information, but dont ignore the users. After
For existing systems, most of this information is you collect your statistics and feel you understand the
available in excruciating detail via R/3s Computing workloads, review your estimates with the end users.
Center Management System (CCMS). Capacity They can quickly verify your user and transaction
planning, whether for conventional or Web-based counts to ensure you have gathered the correct
environments, consists of estimating the individual information.
workloads and resources they consume, understand-
ing the timing of demands for these resources, and The information available in CCMS will be over-
comparing this to the maximum capacity of your whelming, so keep reminding yourself of what you
available resources. are after and try not to get sidetracked with the other
details. For capacity planning, the following tips may
help you in your analysis:
Using CCMS to Estimate !"""Collect statistics for the few transactions in each
Workloads module that represent the majority of the workload.
Normally three to five transactions will represent
I could easily write an article or two describing 75-80 percent of the total workload for a module.
CCMS and how to use all the transactions and Estimate the remaining transaction volumes as a
information provided, but for now I will have to percentage of the volume from the most common
assume some knowledge and keep to the subject of transactions. For example, you may find that with
capacity planning. If you arent experienced with every 1,000 sales orders entered in the Sales and
CCMS, review SAPs standard R/3 documentation Distribution module, users tend to add two material
(search for CCMS and youll get a ton of masters.
responses), log on to your test/training/development
system and play around, and you will soon be com- !"""Note whether program/transaction statistics
fortable with its capabilities. Most of the information represent dialog or batch processing and the time
you will need can be collected from transactions frames for executions.
ST02 (Tune Summary), ST03 (Workload Analysis),
ST04 (Database Performance Analysis), ST07 ! Study time periods with poor performance, deter-
(Application Monitor), and OS06 (Operating mine the typical workloads, and try to determine
System Monitor). which, if any, resources are creating your bottlenecks.

Much of this information can be found via transaction - CPU idle times that are consistently below
OS06. You can study CPU idle times by specific 30 percent for some or all servers
time periods to see when the activity is the heaviest.
You can then match this time frame with response - Servers with multiple CPUs that are consistently
times, memory usage, system paging statistics, disk using the maximum number of CPUs available
response times, and a multitude of other factors to
- Disk response times that are consistently slow
analyze performance.
- Update response times that are significantly
!"""Review your notes from BC315 Workload slower than read-only times
Analysis training for a refresher on performance
and tuning. - Network response times (e.g., ping times) that are
consistently slow
!"""Determine whether poor performance is general
or specific in nature: - Servers with older/slower processors that are
consistently under-performing
- Is a single function/program slow?
Throughout all of the performance discussions,
- Are all functions in a module slow?
you are probably wondering what I consider slow or
- Are all functions in the entire system slow poor performance. Without hours of discussions and
(check the performance of Main_menu)? charging you a ridiculous sum of money for profes-
sional services, I cant answer that question. Fast or
- Are problems related to individuals or groups of slow depends on your companys goals, habits, and
specific users, servers, networks, disk drives or expectations. I can only recommend you set realistic
controllers, tables, tablespaces, buffers, memory performance goals before you ever undertake a tuning
pools, batch programs, dialog programs, etc.? or capacity planning exercise otherwise you can
spend your entire life and budget chasing faster
- Are specific work processes or types of process-
performance.
ing slow (batch, dialog, spool, update, message)?
- How do file-maintenance programs compare to
display-only programs?
- Do program or table sizes make a difference?
Hardware Needed for
Upgrades
!"""Determine whether hardware resources would
help. Do you need to purchase more memory or The final estimating of resource needs for upgrades is
simply reallocate the existing memory with R/3 and no easier than for new systems. You must do your
operating system startup profiles? The following are homework and spend lots of time analyzing the busi-
performance symptoms commonly solved by appro- ness and all available statistics. You will also need to
priate hardware purchases in a properly tuned system: optimize your system before and after the upgrades
are completed. This has never been proven better
- Object swapping in R/3 buffers than with the move from Oracle 7.x to 8.x database
engines. In the 8.x version of Oracle, the basic file
- PRIV memory mode for work processes retrieval method is changed from rule-based to
- Excessive memory paging/swaps cost-based optimization. Without going into techni-
cal detail, this means many of your poorly performing
- Need for more servers to support more R/3 work programs will start working better, while many others
processes and/or users (e.g., high wait times) will suffer tremendously.

When analyzing existing systems, there is cer- especially on the database server, improves
tainly a lot more information on which to base your performance almost every time.
capacity planning estimates. No more crystal balls to
determine what transactions the users will execute !"""Faster CPUs/processors, especially on the
and how many times a day. And even if youre database server, improve performance almost
the very first productive customer to accept a new every time.
release of R/3 from SAP, benchmark tests and other
statistics will be available to help you make an !"""More CPUs will improve performance until you
educated guess. reach the point where one to two CPUs remain idle
during peak processing periods.
I recommend you start with the following tips,
compare your current business functions and user !"""More servers, and the use of logon load balancing
habits with system statistics, and complete your esti- to separate similar workloads, will increase the shar-
mates by documenting all of your assumptions and ing of buffers/memory and improve performance.
risks. Then sit down with your hardware vendor and
!"""Most upgrades affect the network, especially
SAP to refine the list and your estimates. Every
frontend networks.
system and budget is different, and you will just have
to decide for yourself how much time and effort to
Given the move to Internet-based environments,
spend on this process.
we can make one final assumption: adding Web-
based technology will require complete analysis of
!"""Read all available SAP Online Support System
frontend processes and hardware associated with it.
(OSS) notes, release notes, and documents concerning
Your hardware needs will depend on the functions
your particular upgrade.
being processed and your choices associated with
security, backup and recovery, high availability, ease
!"""Modules with more complex processes typically
of maintenance, and related techniques. Lets com-
need more memory (e.g., servers supporting SD users
pare conventional R/3 to Internet/Web-based
need more memory than FI servers).
R/3 systems and identify the new resources you
will need.
!"""Modules supporting users from only one module
(e.g., SD) need less memory than servers supporting
multiple modules (e.g., FI, SD, PP).
!"""The more/larger the data tables you process, the Identifying R/3 Workloads
more memory you will need. and Resource Requirements
!"""Increasing the size of tables, or number of In a conventional R/3 environment, work starts when
accesses, generally requires more and/or faster disk an end user initiates an R/3 transaction on the work-
drives and controllers, as well as system memory for station, terminal, PC, or interfaced system. This
buffering of tables. presentation server will then call an R/3 application
server to initiate work. The R/3 application server
!"""Upgrades to databases (e.g., Oracle 8 versus will dispatch the necessary workloads to the database
Oracle 7) require more memory for database server and return all appropriate information to the
servers, and often more disk space to store new presentation server for redisplay. This cycle repeats
tables and indexes. until the user completes the task.
!"""Adding and properly allocating memory, Ignoring multiple, logical systems on physical

servers (e.g., multiple instances of R/3 on a single Web-based environments For these environ-
server), the common workloads for conventional ments (mySAP.com, Workplace, B2B, Employee
three-tiered R/3 will be something like the following: Self Service, etc.), the three-tiered architecture
and basic components of R/3 remain unchanged.
Presentation server The presentation server The impact of these new frontends and interfaces
will map/transform data to predefined R/3 screens is felt primarily at the presentation layer of an
via SAP GUI and send the appropriate requests SAP environment.4 Workloads within the presen-
for more information, screens, and reports to the tation layer will depend on the complexity of
work dispatcher. The dispatcher, residing in your Web pages/screens, formatting of data, and
the application layer of R/3, will control and the related processing that takes place before the
partition all work, dispersing the components to transaction is sent to R/3. For B2B systems, the
appropriate R/3 function modules and servers. end result will depend on where and how you and
Presentation servers, in addition to whatever your business partners share information and
requirements they have for non-SAP activities functionality.
(Windows, NT, Excel, etc.), need enough
memory and CPU resources to display graphics A request for information or processing within
and transfer data between screens. Although R/3 will still involve sending a request for informa-
most PCs benefit greatly from more memory and tion or a transaction to an application server and
faster processors, the minimum requirements for receiving some data in return. However, with Web-
these servers is quite small. based processes, the transformation of data to and
from screens on your PC is much more complex.
Application servers The work dispatcher on a Users can define an unlimited number of styles and
central instance of an R/3 application server presentation formats for their data in a variety of
will receive information and work requests from formats and protocols (e.g., SAP GUI, HTML,
the presentation servers. Via a multitude of Microsoft, Netscape).
transactions, programs, and function modules, the
application server will verify new data entered by Additionally, the presentation server will need to
the user, determine the appropriate business evaluate each user request and decide whether the
functions to be performed, dispatch any requests transaction is requesting information that resides on
for data to the database server, validate all new the Web server, within R/3, or on another companys
and existing data, perform calculations or addi- system (e.g., direct access to a vendors inventory
tional processing of information, dispatch updates system), a business information warehouse, or data-
and additional data requests to the database base that has been added to the current environment
server, and return the appropriate information for B2B processing (e.g., copies of a vendors master
to the presentation server. catalog). The presentation server will then (re-)map
the data in the proper format for transfer, choose the
Database server The database server will appropriate communication protocol (e.g., TCP/IP,
support workloads from the database engine ISAPI, NSAPI, CGI), and route the requests to the
(e.g., Oracle, DB2, MS/SQL, Informix) and R/3s appropriate server/system. When interfacing with
database interface processes. All input/output multiple systems, this may require the presentation
activity for information will transpire on this server to store and execute several system protocols,
server. The workloads will basically be those of Web browsers, and data transfer routines.
a file server merely transporting data from the
physical disk drives via buffers and caching
techniques through the database engine and on to 4
Could there be any stronger testimony to the merits of SAPs three-
tiered architecture?!
the application server.

Figure 4 Key Components of Web-Based R/3 Systems
Microsoft WGate
Web Server ISAPI
SAP
Windows NT Server
SAP GUI
TCP/IP
Netscape WGate AGate SAP SAP
RFC
Web Server NSAPI
Windows NT Server Windows NT Server
SAP
Any WGate
SAP Application Servers
Web Server CGI
and Database
Windows NT Server
Your presentation layer of R/3 will now include Interchange), B2B, standard R/3, or most any
an entire set of resources to prepare data prior to e-commerce you choose to explore. Figure 4 can
execution of core R/3 processes. This includes PCs, be supported with a variety of hardware platforms.
network servers, Web servers, AGate (Application If your total workloads are small enough and you
Gate) servers, and WGate (Web Gate) servers. Many purchase hardware that can truly be partitioned,
of these items will have duplicate or multiple names you could employ this on one very large physical
and abbreviations. The terminology alone will be server. This design is obviously vulnerable to a
your biggest obstacle. multitude of problems, but also offers a variety of
advantages. The key to capacity planning, which
How you choose to meld your logical and physi- really incorporates system design, is to recognize
cal designs will determine how many pieces of equip- how the physical and logical characteristics work
ment you need and how powerful they must be to together to effectively support all your needs with
support all of these new processes. As with any a modular design.
system, you should consider where and how many
security firewalls you want; whether you prefer
single, large servers over multiple, small servers;
backup and recovery; high availability; ease of main- Tying Budgets to
tenance; network loads; and, of course, performance. System Expansion
Figure 4 shows an environment capable of Once youve armed the hardware vendor with all
supporting mySAP.com, EDI (Electronic Data your workload statistics and system preferences, they

will craft an initial design of your system. I recom- planning processes that mimic your companys
mend you work with your vendor to design a system business models are the best way I know to make
that mirrors your current and future business models. that connection.
Start with logical design techniques and match typical
user or business work patterns with the appropriate
system components supporting the work.
The key to capacity planning, which
For example, if your users are physically located really incorporates system design, is to
on separate floors or buildings (e.g., accounting recognize how the physical and logical
separate from production), group their presentation characteristics work together to
servers, and related equipment, into separate LANs. effectively support all your needs
If two groups can easily be serviced by a single net- with a modular design.
work router, fine, but keep track of them and/or
define them in the system as separate logical groups.
Then, as work activity grows and your network
becomes overloaded, you simply add a new router
and make a few updates to switch an entire group to Summary and Conclusions
the new equipment.
Because practice makes perfect, I strongly recom-
As you become comfortable with your modular mend you adopt the same capacity planning process
system, you will find the budgeting process also for new and existing systems. In this and previous
becomes much easier. When end users start planning articles,5 Ive outlined specific steps and explained
expansions of their business and define new users and how you normally cycle through each step several
transactions, you will be able to pinpoint the physical times before becoming comfortable with the end
demands on the system and tie equipment needs results. Adopting formal practices for capacity plan-
directly to their expansion. The conversion to dollars ning will increase your speed and accuracy with each
needed for the expansion becomes quick and easy, planning session, as the organization and your ven-
as you merely call the vendors, explain where dors become more familiar with the relationships
the system will see more workloads, and get between business activities, system performance,
a proposal. and technical resources.
My experience, working with management and With modular design and associated tracking of
budget processes, has shown that when you can tie SAPs CCMS data, you can establish baseline statis-
your budget and resource needs directly to specific tics for linking capacity planning to performance and
business expansions and support of their system, you tuning activities. You can further expand these
will get the money you really need. Too many IT efforts and define relationships between end-user
managers play the annual budget game by asking for activities, R/3 workloads, and the budgets needed to
15 percent for additional growth and overhead. support your plans.
They always complain when corporate steering com-
mittees and budget teams decide everyone must make You can apply these capacity planning techniques
sacrifices and force them to settle for the standard to any new technology and business applications,
10 percent increase. These same non-technical man-
agers are usually more than willing to approve money
5
for systems that support their own departments Size Does Matter Strategies for Successful SAP R/3 Capacity
Planning, SAP Professional Journal, Premiere Issue, and A Three-
and pet projects, but only when they can see the Step Process for Averting Downtime When Modifying Your R/3
connection. Modular design of systems and capacity System, SAP Professional Journal, March/April 2000.

whether they reside in conventional R/3 or Web-

based environments. You will see additional benefits Kurt Bishop is a member of SAP Americas
as you ease the pain of system maintenance and Remote Consulting Team. This team, whose
upgrade planning. I believe, over time, you will find members are trained in both application and
it easy to add increasing levels of detail to your statis-
technical support of the R/3 system, provides a
tics and resulting estimates for specific hardware and
software equipment. variety of consulting and support services for
customers and colleagues. Kurt started his career
This pinpoint accuracy will decrease the time you with SAP in 1994 providing project management
need to convert managements dream of expansion to consultation for customers with a specialization
the reality of cold, hard cash. This will leave you in technical project management. After two
time to negotiate prices with vendors instead of stay- years in this position, he began concentrating on
ing late to throw darts at hardware diagrams, as you
performance and tuning. By popular demand from
try to guess where the next performance bottleneck
will occur. Or, you could simply use the extra time to customers and SAP employees throughout North
work on some other important tasks. Maybe Ill see America, he has concentrated his skills on
you at the lake? capacity planning services, where he works to
standardize and improve the process for both
customers and vendors.
Prior to joining SAP, Kurt spent seven years as a

management consultant for one of the Big Six
consulting firms. In this capacity, he was involved
in both management and information systems
consulting for a broad range of firms and
industries. He spent considerable time developing
strategic systems plans for some of the nations
most prestigious firms, as well as assisting many
clients in reengineering their business practices
and related support systems. He also has eight
years of experience in the trenches of
information systems for the oil and gas industry,
including positions from programmer analyst to
project manager, where he developed the skills
that prepared him for consulting. His skills are
also augmented with four years in manufacturing
and materials management, where he served as
Production Manager. Kurt can be reached
at kurt.bishop@sap.com.


Professional
Past Issues Index
Premiere Issue September/October 2000

Extending and Modifying the SAP Standard with Business Add-Ins 18 Techniques for Locating the Underlying Data of a Screen Field
and the New Modification Assistant Ensuring the Accuracy of Address Information with SAPs Central
Real-Time, Outbound Interfaces to Non-R/3 Systems Made Simple Address Management
with Change Pointers, Message Control, and Workflow Is It Time to Revisit Your SAP Security Infrastructure?
Size Does Matter Strategies for Successful SAP R/3 Enabling Point-and-Click Data Entry Assistance for Your
Capacity Planning BAPI Applications
An Insiders Guide to the SAP Change and Transport System (CTS) SAP Document Output for the Internet: Targeting PDFs
BAPI Basics When Programming with Java
November/December 2000
November/December 1999 Gearing Up for a Test-Drive of Linux for SAP
Achieving a More Manageable and Reliable R/3 Spool Server A Developers Guide to the New ALV Grid Control
Landscape Using Release 4 Output Classifications, Logical Servers, Readying to Resize Your R/3 Platform
and Alternate Servers
Need to Understand a BAPIs Parameters?
An Introduction to SAPs New and Improved Frontend Printing Test-Drive the BAPI Inside SAP!
Simplifying BAPI Programming with Components Defining SAP Service Level Agreements:
Enhancements in Customizing: Business Configuration Sets, An IT Managers Survival Guide
the Customizing Cross-System Viewer, and the Activity Log
From New Graphical Tools to SAP Smart Forms January/February 2001
The Next Generation of SAPscript Everything a BAPI Programmer Needs to Know About
the Business Object Repository
January/February 2000
Simplifying Ad Hoc Queries and Web Reporting with
Lessons in Logon Load Balancing SAPs New InfoSet Query
Extending SAP Business Workflow with Web Forms Web-Enabling SAP R/3 with Java A Guide for the Uninitiated
A Beginners Guide to Accessing BAPIs with the Dynamic Documents: Completing the New Face of Reporting
SAP DCOM Connector Write Costing-Based CO-PA Reports Your Readers Will Trust
Leveraging the R/3 Warehouse Management Structure with Five Secret Tricks to Building General Ledger Reconciliation
the MM-MOB and WM-LSR Interfaces into Your Profitability Analysis Data
ABAP Programming An Integrated Overview
March/April 2001
March/April 2000 Data Archiving Essentials What Every Administrator Needs to Know
SAP Desktop Office Integration (SAP DOI) An Easier Way for Need to Get Your Customizing and Testing Ready for a Global Rollout?
ABAP Programmers to Integrate Desktop Applications with R/3 Use BC Sets and the Test Organizer to Smooth the Way!
Destination and Session Management for the SAP DCOM Connector COM4ABAP: A Simpler, Cleaner, Universal Approach to Harnessing
Strategies for the Successful Management of an SAP System COM Objects in ABAP
Implementation On Time and On Budget A Beginners Guide to Building Workflows with the Workflow Builder
A Three-Step Process for Averting Downtime When Modifying Create and Maintain Forms Without Programming?
Your R/3 System Its a Snap with SAP Smart Forms!
Paving the Way for a Smooth and Successful Integration of
Your EDI and SAP Systems May/June 2001
Ready to Build Your First MiniApp? Its Quick and Easy
May/June 2000 with the ABAP Workbench!
A Custom Performance Test Is It for You? Data Downloads to Excel Made Simple with SAPs Desktop Office
BAPI Programming with Java Beyond the Basics Integration (DOI) A Programmers Guide
Building Your Own BAPIs A Step-by-Step Guide Get Double Productivity from the Classroom:
A Case Study in SAP R/3 Organization Structure Design: Master the Art of Speed-Learning Popular Courses
Taking FI/COs One-to-Many Path to Speedier Global Rollouts Such As BW, APO, CRM, and More!
Better Management of Change Requests with Extended Evaluating, Incorporating, Altering, and Testing Headquarters-Defined
Transport Control Customizing: Lessons for Subsidiaries
No Service Reps Required! Learn How to Supply 24x7 Sales Order
July/August 2000 Information Online with the Sales Order Status IAC
Optimizing, Monitoring, and Fine-Tuning a Newly Upgraded
Release 4.x Spool Service
Transaction Handling in SAP R/3 What Every Programmer Needs
to Know
Selecting the Optimal System Landscape for Your SAP R/3
Upgrade Project
Customizing in Release 4.6 It Gets a Whole Lot Easier!
Upgrading to R/3 Release 4.5 and Beyond:
An ABAP Developers Guide
59

Professional
YES. Please enroll me for a risk-free, one-year subscription to SAP Professional Journal.
If at any time I am not completely satisfied, I can cancel my subscription and receive a full refund.
INDIVIDUAL SUBSCRIPTION $495 U.S.

A one-year Individual Subscription includes SAP Professional Journal (delivered six times per year) and
Web access to SAP Professional Journals download area.
Name Title
Company
Address
City State/Prov Zip/Postal Code
Country E-mail
Phone ( ) Fax ( )
VOLUME DISCOUNT SUBSCRIPTION $1,195 U.S.

Savings of more than 50% can be obtained by ordering a five-person subscription at your company location.
A volume discount subscription includes SAP Professional Journal (delivered six times per year) and Web
access to SAP Professional Journals download area. For groups larger than five, or for more information
on electronic site licenses, contact Stuart Robinson at (781) 320-9465 x266 or stuartr@SAPpublications.com.
YES. Please send me the following issues of SAP Professional Journal. Each issue is $89.
View a complete table of contents for each issue on page 59 or at www.SAPpro.com.
Premiere Issue (SAP990901) May/Jun 2000 (SAP000501) Jan/Feb 2001 (SAP010101)
Nov/Dec 1999 (SAP991101) Jul/Aug 2000 (SAP000701) Mar/Apr 2001 (SAP010301)
Jan/Feb 2000 (SAP000101) Sep/Oct 2000 (SAP000901) May/Jun 2001 (SAP010501)
Mar/Apr 2000 (SAP000301) Nov/Dec 2000 (SAP001101)
PLEASE RETURN THIS FORM WITH PAYMENT TO:

SAP Professional Journal, P.O. Box 90608, Washington, DC 20077-7637, USA,
or fax to (301) 816-0037
Check enclosed, payable to SAP Professional Journal
Purchase Order enclosed, payable to SAP Professional Journal
Master Card Visa American Express Diners Club
Card Number Exp. Date
Name on Card Signature

DD8933
Questions? Call us at (877) 947-3012 or (301) 287-2678

60

SAP EssentialGuideToSapUpgrades

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SAP EssentialGuideToSapUpgrades

Uploaded by

Copyright:

Available Formats

The Essential Guide to

SAP R/3 Upgrades

P.O. Box 90608 Washington DC 20077-7637

Upgrading to R/3 Release 4.5 and Beyond:

Selecting the Optimal System Landscape

Readying to Resize Your R/3 Platform

The Essential Guide to SAP R/3 Upgrades

ABAP developers play a critical role in this process. You need to

(complete bios appear on page 26)

No portion of this publication may be reproduced without written consent. 3

upgrading to R/3 Release 4.5. We provide an over-

! Preparation: Here you create your upgrade plan.

4 www.SAPpro.com 2001 SAP Professional Journal. All rights reserved.

No portion of this publication may be reproduced without written consent. 5

Figure 1 A Typical Upgrade Team

ABAP Developers Analyze custom programs and modifications

Technical Project Lead Coordinate development tasks

Basis Administrators Set up upgrade system landscape

Customizers/Configurators Configure system

Project Manager Manage the overall project scope

Functional Team Lead Coordinate configuration tasks

A typical upgrade team includes the participants Preparing an Inventory of

6 www.SAPpro.com 2001 SAP Professional Journal. All rights reserved.

A Helpful ABAP Utility 5

Gathering information on custom repository objects 6

No portion of this publication may be reproduced without written consent. 7

Figure 2 Upgrade Impact on Common Object Types

Custom Reports Minimal Typically simple syntax errors only.

8 www.SAPpro.com 2001 SAP Professional Journal. All rights reserved.

Figure 3 Example of Man-Hour Analysis for Custom Development Objects

Reports 250 0.5 125

No portion of this publication may be reproduced without written consent. 9

Figure 4 Example of a Budget Plan for Upgrading

System Preparation Development 468 $800 $374,400

Figure 5 Example of a Resource Plan for Upgrading

10 www.SAPpro.com 2001 SAP Professional Journal. All rights reserved.

No portion of this publication may be reproduced without written consent. 11

projects). Understand and communicate to Create Test Plans

12 www.SAPpro.com 2001 SAP Professional Journal. All rights reserved.

An Upgrade Transaction Primer SPDD and SPAU

No portion of this publication may be reproduced without written consent. 13

The second option is more complex and involves

14 www.SAPpro.com 2001 SAP Professional Journal. All rights reserved.

Figure 6 Viewing the SPDD Modification Issues List

Figure 7 Comparing Object Version Differences

No portion of this publication may be reproduced without written consent. 15

Figure 8 Changing Keyword Descriptions via CMOD

Avoiding Modifications You can easily avoid modifications by changing

16 www.SAPpro.com 2001 SAP Professional Journal. All rights reserved.

Figure 9 Viewing the SPAU Modification Issues List

No portion of this publication may be reproduced without written consent. 17

Like most of us who are upgrading from a

2. Select Edit Expand subtrees from the !"Tip

18 www.SAPpro.com 2001 SAP Professional Journal. All rights reserved.

an upgrade to a subsequent system, that system will Upgrade Development Objects

No portion of this publication may be reproduced without written consent. 19

SELECT SINGLE FROM PLPO WHERE Tips for Adjusting SAPscripts

20 www.SAPpro.com 2001 SAP Professional Journal. All rights reserved.

No portion of this publication may be reproduced without written consent. 21

Figure 11 Obtaining a List of Query Objects via RSAQSUMM

22 www.SAPpro.com 2001 SAP Professional Journal. All rights reserved.

Figure 12 Converting Query Objects via RSAQUM40

Activate Customer Enhancements Another post-upgrade task you will

No portion of this publication may be reproduced without written consent. 23