SAP BW 7.3 is composed of ABAP and Java, each with its own database. The SAP BW upgrade for ABAP from 7.3 to 7.4 and above is challenging as it involves equal efforts from—and coordination between—the SAP BW functional and Basis teams. To ensure that the SAP BW upgrade is successful, cooperation and communication between the two teams is vital. How the SAP BW upgrade tasks are categorized and how they should be divided between these two different teams can sometimes be confusing. I’ll provide some tips as to who should be executing the jobs/programs and how the responsibilities are divided in a way that makes the most practical sense.
The SAP BW upgrade for Java is pretty straightforward and follows the same steps as the ABAP upgrade—SAP has not made any changes to Java as it did with ABAP. I have provided more details about the SAP BW upgrade for ABAP as there are more changes, and also provide do’s, don’ts, and important tips to facilitate this upgrade.
DO clearly document each step as to which team will do what to alleviate any confusion.
DON’T have the SAP Basis administrator/developer execute SAP BW’s job/task/program—this execution is the responsibility of the SAP BW functional team. This should be made very clear to all the team members involved before the start of the upgrade.
(Note: For an SAP Basis administrator to execute SAP BW’s job/task/program, they need roles/authorization for executing it and they might not know if they are taking the right as this falls entirely under the SAP functional team’s area. As a result, the SAP functional team is more knowledgeable about this than the SAP Basis would be. Moreover SAP Basis administrators do not have the roles/authorization to the production server.)
Tip! >Schedule a meeting with the SAP BW functional ABAP and Basis teams and create a checklist for the upgrade. Checklists should be created based on documents such as the Master Guide, Upgrade Master Guide, and Upgrade/Update Guides. These guides can be downloaded from https://help.sap.com/nw74.)
The first step is to download the files needed for the upgrade.
Download Files
First, check to ensure that Solution Manager is connected to the system identifier (SID) that will be upgraded. This should already be in place. Once this has been confirmed, select the SID to be upgraded and generate the .xml files for the upgrade. Next, download the latest version of Software Update Manager (SUM), as recommended by SAP. SUM can be downloaded from https://support.sap.com/sltoolset.
(Note: The SUM tool is used for upgrading SAP BW systems. SUM is a multi-purpose tool that supports various processes, such as performing a release upgrade, installing enhancement packages, applying Support Package Stacks, installing add-ons, and updating single components.)
In my example scenario, one challenge I faced is that the content repository (CR)/common information model (CIM) content was not up to date on the SAP Solution Manager system. According to SAP’s best practices, the CR/CIM content should be updated in Solution Manager on a quarterly basis or at least three weeks before an upgrade starts. It’s part of the SAP Basis administrator’s routine job to address CR/CIM content on a quarterly basis. To ensure that this happens, download the files in advance after confirming with your company what version and patch level they would like to go to, and if it’s feasible to go to that version. In this case, since the CR/CIM content was not up to date, it had to be updated for Solution Manager in accordance with SAP Note 669669.
DO ensure that the current CR/CIM files are downloaded at least three weeks in advance of beginning the upgrade on the Solution Manager system.
DON’T wait until the last minute to download these files. This is because there could be network issues that may result in only partial files being downloaded (not complete files). If this happens, you need to additional time to ensure that all the files are downloaded completely in time for them to be used. Another reason to download early is if the network connection turns out to very slow. If this happens, you want to make sure there you’ve built enough time into the schedule so that these files can be downloaded in time.
(Tip! Every quarter, plan for CR/CIM updates to the Solution Manager system and other systems that require CR/CIM.)
Upgrade Phases
After SUM is started, it goes through all the below phases one by one in sequence. There are eight phases for an SAP BW upgrade, as follows:
- Initialization
- Extraction
- Configuration
- Checks
- Pre-processing
- Execution
- Post-processing
- Finalization
There is one important thing to keep in mind during these eight different phases. It critical that you note the timings of the upgrade as noted in Table 1. This helps companies with planning when upgrading their quality/acceptance systems and production systems.
|
Phase number
|
Phase
name
|
Phase
details
|
Start
date
|
End
date
|
Total
time
|
Remarks
|
|
1
|
Initialization
|
When the SUM
tool is started,
it starts the first phase,
initialization. This is the
start of the upgrade itself.
In this phase, the system
is checked to make sure it
is up and running; once that's
confirmed, the next phase
begins immediately.
|
|
|
|
|
|
2
|
Extraction
|
In the extraction phase,
the SUM tool scans the
download directory and
it extracts the files to the
Electronic Parcel Service (EPS)/in
(directory in Unix or Windows).
It requires the password of the user
ID DDIC, the required pre-upgrade
SAP Notes (during this phase, the
SUM tool automatically detects what
SAP Notes need to be applied to the
BW system), and the latest Support
Package Manager (SPAM) that is
needed. SPAM must be updated
before any upgrade. A SPAM update
contains updates and improvements
to SPAM. There is always one SPAM
update for each release. A SPAM
update is mandatory before any
support package upgrade.
|
|
|
|
|
|
3
|
Configuration
|
Determine what configurations
are going to be provided for the
upgrade. For example, these
questions need to be answered:
- Will archiving be set to
on or off?
- What will the strategy be
for system generation (SGEN),
Number of batch/background
(BTC) process uptime/downtime,
and Increment (Table) Conversion
(ICNV)? (Note: When a system
is upgraded, you need to execute
transaction code SGEN. BTC is the batch/background where the
SAP programs can be executed
in the background and the user
doesn’t have to be logged on for
the same. With transaction code
ICNV, you can perform conversions
before the upgrade—that is,
during production.)
- What will be the maximum
number of processing
allowed during the upgrade
in parallel import processes?
- What Support Package Data
Dictionary (SPDD)/repository
object (SPAU) numbers of the
transport requests will identify
any objects where the hot package
overwrites changes are made
through SAP Notes?
During this phase, it also has to be
decided whether to use near-Zero
Downtime Maintenance (nZDM),
which reduces significant downtime.
The benefit of nZDM is that table
structure adjustment is allowed,
including conversions and main Import.
Almost all the upgrade guidelines
from SAP recommend using nDZM.
|
|
|
|
|
|
4
|
Checks
|
Sum determines the locked SAP
objects in a transport request and
informs the system administrators
to release the transport request.
SUM also checks for database
space requirements and performs activation/conversion checks.
|
|
|
|
|
|
5
|
Pre-processing
|
The pre-processing phase is
a pre-downtime step. In this step,
the system is available to all the
users until the system is locked.
Once the system is locked, it cannot
be used for development. Pre-processing
is a crucial step for the upgrade
(as are the shadow instance load
and SPDD steps). During the shadow
instance, the system creates the
same system Identifier (SID) but a
separate instance. For example, if
your current instance is 00 and when
SUM requests the instance number
and you give 03, SUM creates a
shadow instance of 03 with a
separate shadow (ABAP) repository.
The ABAP repository is a specific part
of the database. It consists of
development objects such as programs,
database tables, and so on. This is the
last online phase; after this phase is
completed, the actual downtime
(execution) phase can begin.
|
|
|
|
|
|
6
|
Execution
|
This is the downtime phase
where the actual upgrade to the
system takes place. During this phase,
the shadow instance and real instance
are merged, and the table conversion
takes place. During this phase the system
is not available to anyone, including
system users.
|
|
|
|
|
|
7
|
Post-processing
|
This is the phase after
the upgrade has been
performed. During this phase
you can make SPAU changes
to the development system.
You must check that all objects
are identified in SPAU and decide
whether you need to reapply the
SAP Note or reset the code to the
original SAP settings. These can only
be done in the development system;
then the changes can be put in a
transport request and imported
to the quality and production systems.
|
|
|
|
|
|
8
|
Finalization
|
During this phase, provide a
summary of all the upgrade
phases and note that each
phase has been done successfully
and there were no issues reported
in any of the phases. This phase
takes less than 20 minutes to complete.
|
|
|
|
|
Table 1
A checklist of the eight phases for an SAP BW upgrade with brief descriptions
Table 1 lists each phase and what needs to take place during that phase and also includes blank columns to keep track of when tasks are started and finished, as well as space to keep notes.
When upgrading to SAP BW 7.4, there are two phases that are the most critical in the latest upgrade: the checks phase and the finalization phase. In both these phases, Basis administrators need to liaise closely with the SAP BW functional team.
In the following, I discuss the new and most important changes in the latest upgrade to SAP BW 7.4 Support Package (SP) 13 and above. The tasks SAP_BW_HOUSEKEEPING, SAP_BW_BEFORE_UPGRADE and SAP_BW_AFTER_UPGRADE are introduced in this SAP BW upgrade. These tasks are executed via SAP transaction code STC01 and the output can be viewed by executing transaction code STC02. All these tasks are executed by the SAP functional team.
The Checks Phase
At the end of the checks phase, the BW functional team needs to execute transaction code /ASU/Upgrade, and tasks SAP_BW_HOUSEKEEPING and SAP_BW_BEFORE_UPGRADE. The Basis team is responsible for uploading the /ASU/Upgrade template from SAP Note 1000009. Table 2 lists the different tasks and to which team—SAP BW functional or Basis—they are assigned in transaction code /ASU/Upgrade.
|
Team responsible
|
Task
|
|
Basis team
|
Initial system check using
transaction code SM21
(system logs) and transaction
code SICK. Check if there are
no unusual errors in systems logs.
This is a usual check Basis
Administrator do on daily basis
and normally no issues are expected.
|
|
Basis team
|
Check for any inconsistencies in the
secure storage with transaction code
SECSTORE
|
|
BW functional team
|
Re-activate the source system
|
|
BW functional team
|
Repair InfoObjects
|
|
BW functional team
|
Activate BEx history
|
|
BW functional team
|
Check compounding consistency
in MultiProviders
|
|
BW functional team
|
Application Link Enabling (ALE):
Generate and read change pointers
after the upgrade
|
|
BW functional team
|
Program for transformation activation:
Sometimes the object transported from
the development system to the quality
system is deactivated in the quality
system. When that happens, it needs
to be reactivated. This can be done
via transaction code SE38 and executing
program RSDG_TRFN_ACTIVATE.
|
|
BW functional team
|
Create dropped-fact views
|
Table 2
Team responsibilities and their tasks when executing transaction code /ASU/Upgrade
In an SAP transaction code /ASU/Upgrade, there is an option to select a tick mark (green checkmark) when a task is completed successfully. Use it so that both teams know that the task is completed. If this is not done, it makes it difficult to confirm if a task is completed or not. In my scenario, I had to inform the SAP BW team to use that option.
According to SAP’s upgrade documentation, SAP suggests executing either transaction code /ASU/Upgrade or task SAP_BW_BEFORE_UPGRADE via transaction code STC01. These are tasks that need to be executed after the checks phase is completed. SAP_BW_BEFORE_UPGRADE has a list of approximately 15 tasks that need to be completed by the BW functional team. After task SAP_BW_BEFORE_UPGRADE is completed, the BW functional team executes the task SAP_BW_HOUSEKEEPING. Task SAP_BW_HOUSEKEEPING is done manually, such as repairing indexes and cleaning statistical data. It has approximately 12 tasks. SAP_BW_HOUSEKEEPING is also executed via transaction code STC01 by the BW functional team.
DO discuss these tasks (SAP_BW_HOUSEKEEPING and SAP_BW_BEFORE_UPGRADE executed via transaction code STC01) with the SAP BW functional team and have them execute them. Also have the BW functional team check transaction code /ASU/Upgrade.
DON’T have the SAP Basis administrator execute these tasks as it’s the responsibility of the SAP BW functional team. However, do ensure that the SAP Basis team checks the tasks in transaction code /ASU/Upgrade and works closely with the SAP BW functional team. There are two tasks for SAP Basis administrators, as mentioned in Table 2.
(Tip! Check the output of the tasks with STC02 to be sure that that tasks were executed.)
The Finalization Phase
After the finalization phase, the SAP functional team executes transaction code /ASU/Upgrade and also executes task SAP_BW_AFTER_UPGRADE. This is the final and most important step of the upgrade, and is executed after the upgrade is complete. These tasks are executed via transaction code STC01. You can view the output by executing transaction code STC02. All these tasks are executed by the SAP BW functional team.
DO take screenshots of each step so that it’s well-documented during the upgrade process.
DON’T assume that these tasks are done. Check the output via transaction codes STC02 and /ASU/Upgrade. In my case, the Basis team didn’t assume that these tasks were completed in the development system unless they saw it themselves via transaction code STC02.
