Skip to Content

BW technical Upgrade from BW3.X to BI7.

BW Upgrade involves, upgrade of BW system from a previous version to a newer version.

Clients generally go for upgrade primarily for the reason that SAP stops supporting the

previous version after a time frame to encourage clients to enhance their system and use new

functionalities in the newer version.

This document covers the steps involved in the BW technical upgrade. Upgrade activity is generally split into three different set of activities.

1. Pre Upgrade activities
2. Actual system upgrade which is usually carried out by basis team experts.
3. Post Upgrade activities

Approachwise there are two ways which normally followed during the upgrade

1. Upgrading the complete landscape as is without copying production landscape, so that all the systems sandbox, development, quality and production will be upgraded simultaneously.
2. Production landscape is copied on fresh landscape say sandbox/Development/Test/quality servers and upgrade those servers.

During Pre Upgrade activities following steps could be followed

1. Check the source system connectivity and activate/replicate it in case it is necessary.
2. Post refresh of the system we need to verify whether all the objects are refreshed correctly or not. If anything is inactive, we need to manually activate same and save it in the transport request.
3. Run program RSUPGRCHECK to find inconsistent Info cubes, ODS, Info objects,

Multiproviders, Update and Transfer Rules and then activate the relevant objects.
4. Checking consistency of master data:- Run program RSDMD_CHECKPRG_ALL for
consistency test.
5. Check DDIC Database Consistency: – Run report RUTMSJOB to ensure DDIC database
6. Check M status for ODS – Check whether M tables of ODS are empty or not. Loading and activation status should be shown green.
7. Check for invalid temp tables – This can be done through SE14 transaction and in extras option.
8. Checking double entries in the table – Execute program ANALYZE_RSZ_TABLES in SE38 to find double entries.

9. Activation of Infocubes – We can ensure all the infocubes are activated through transaction RSDG_CUBE_ACTIVATE.
10. Right code page setting – Execute program RSCPINST for Right Code Page Setting.
11. DSO Activation – Can be carried out through RSDG_ODSO_ACTIVATE transaction.
12. Repairing of any Info object can be carried out through RSD1 transaction.
13. Activate all Transfer Structures: – Run program RS_TRANSTRU_ACTIVATE_ALL in SE38 to activate all Transfer Structures.
14. Activate all Communication Structure: – Run program RS_COMSTRU_ACTIVATE_ALL in SE38 to activate all Communication Structures.
15. Multiprovider activation: – Run program RSDG_MPRO_ACTIVATE to activate all Multiproviders.
16. Conversion of Inconsistent Characteristic Values with a Conversion Routine: – Run
program RSMDCNVEXIT for converting inconsistent characteristic values with a conversion
17. Convert Data Classes of Info Cubes: – Run program RSDG_DATCLS_ASSIGN for the
BI: Converting Data Classes of Info Cubes. Check whether everything is available with
DDIM, DFACT and for ODS it is DODS (*table DD09L).

Above all the activities will ensure normally smooth upgrade during the actual upgrade activities which is normally carried out by basis experts.

Upgrade of BW server:

This is activity mainly carried out by basis team. During actual upgrade activities are again
classified into two different sets. One set of activity can be carried out during the system
Uptime and for second set of activity system downtime will be required. SPAU-SPDD needs to
be carried out during and post upgrade of the server. Time required for this phase will vary
depending upon the severity of the issues appearing during the SPAU-SPDD phase.

Once upgrade is carried out we normally need to carry out post upgrade activities which most of them are similar to pre-upgrade checks only.

Post Upgrade activities :
When we will start with rsa1 for the first time BI content gets activated in the background initially.
2. We need to check the source system connections.

3. Info package Group and process chain comparison: – Info packages are available with
RSA1OLD transaction and under tab ‘Administration’ all Loading things can be seen. Process
chains can be verified through RSPC transaction. Post refresh need to verify by carrying out
some sample data loading through process chains and Info package group.
4. There are some additional authorizations which need to be provided to access PSA or to carry out any new developments.

5. Activation of Bex History: -Run program RS_PERS_ACTIVATE to activate Bex history.

6. Update rule activation: -Run transaction RSAU_UPDR_REACTIVATE_ALL to reactivate
all update rules.
7. Program RSR_VARIANT_XPRA:- Run report RSR_VARIANT_XPRA in se38 for the query
8. Activate all BI Business Content Statistics Cube. Again this is project specific and not the mandatory step.

BI Cockpit Activation:- Run program RSTCC_ACTIVATEADMINCOCKPIT_NEW

9. Bex setting – We can run RRMX_CUST transaction and carry out relevant setting.

BI content activation various authorization issues can be solved by referring to SAP notes 1159976,965386,161292

10. Infoset activation – You can refer to SAP notes 1161444, 1010566 in case there are any activation issues.

Security aspect post upgrade

BI7 demands many new authorisations to be provided for BW object development. You need to ensure that all such authorisations are provided in the Build server itself and need to be carried forward to Production/Quality server whichever are required. Old authorisations can be still used by switching to 3.x authorisation concept. New analysis authorisation concept also can be used. It all depends on the scope of the project. But for day to day normal working in BI7.x you need to have more authorization compared to 3.x version.

Transport Layer

SE21 is Package builder for Transports. As per Technical naming convention of the new system transport layer needs to be renamed. Also all the objects needs to be changed as per new naming convention else during the actual development correction all the objects will be repaired which should be avoided. Similar set up needs to be done for Security transport layer as well. There are certain authorisation needs to be provided during the transport movement for eg Administration of RFC destination S_RFC_ADM needs to be provided.

Other Important points

1. Before actual upgrade of ECC and BW, delta queue should be made empty.

SMQ1, LBWQ, RSA7 entries should be made blank by executing the data loads multiple times. LO Cockpit jobs to be run multiple times to push the queue to RSA7 from LBWQ. This will ensure that there is no data loss incurring during the upgrade activity as well as upgrade is not stopping/interrupting due to this data. This is important when R/3 and BW server both are getting upgraded at the same time.

2. BW Threshold value for data loading should be maintained through RSCUSTV6.

3. Mapping of logical system should be carried out in RSLOGSYSMAP. Without these mapping all the transport movement will fail.

4. Data packet size needs to be redefined in table ROIDOCPRMS in BI7 and ECC as per

Data loading performance in the BW system. This table mainly contains following


MAXSIZE – Maximum size of a data package in KB

STATFRQU – Number of packages that are transferred before statistical information is sent

MAXLINES – Maximum number of records sent in one data package

MAXPROCS – Maximum number of dialog work processes for each upload request used to send the data to the BW system. To ensure the performance and stability of the upload process, it is important that this table is set up correctly.

1 Comment
You must be Logged on to comment or reply to a post.