Upgrade BW 3.x auf BW7

Aus SAP BW Wiki

Wechseln zu: Navigation, Suche



This Wiki contains my team’s experiences in upgrading our Business Warehouse System from 3.0B to BW 7.0.

Hopefully it will be useful to anyone else who's about to embark on this. If there's anything I've missed or got wrong, then please feel free to edit it or contact me and I'll try to explain.

Rob Moore - BW Manager, Edwards Limited.

Overview & Scope

This was to be a technical upgrade of BW only. The new BW 7.0 web functionality & tool suite which requires the Java stack rather than the ABAP stack was out of scope. We had heard that the latter was where most of the problems with the upgrade lay. Our plan is to wait for this part of BW 7.0 to become more stable. Also it has a big front end change and the business didn't have sufficient resource to cope with that much change management.


  • 3.0B at the end of its maintenance
  • Opportunities to do better reporting
  • Options to utilise BI Accelerator


  • Our R/3 system was at 4.6C and was not going to be upgraded. We have APO at version SCM4.0.
  • Our BW system is approximately 300 GB, with 125 global users. It was at version 3.0B SP 18
  • We have Development, Acceptance and Production environments.

Resource & Timescales

The Project ran for 3.5 months from Feb to May 2007. We used the following resources. The percentages are the approx. amount of their time spent on the project.

  • Project Manager * 1 – 70%
  • BW technical team * 3 – 50%
  • ABAP coder * 1 – 10%
  • SAP Systems Development expert * 1 – 20%
  • Basis * 1 – 25%

High Level Plan

These are the basic areas. We planned to complete this process for each environment in turn, learning our lessons at each stage and incorporating into revised plans for the next environment. However we did the Support Packs and Plug-Ins in quick succession on all environments to keep our full transport path open as long as possible.

  1. Upgrade BW to the minimum support pack.
  2. Install R/3 Plug-ins PI 2004.1
  3. Run PREPARE on BW
  4. Dbase upgrades (Database & SAP Kernel upgrade)
  5. System Upgrade

Summary Task List

This list contains all the basic tasks that we performed. A more detailed check list is shown below for each of the headings.

#Support Pack Hike

We moved only to the minimum acceptable SP as this seemed most likely to avoid any problems with the 3.0B system prior to the upgrade.

  • Apply OSS 780710 & 485741
  • Run Baseline for Regression tests
  • Full Backup
  • Apply SP's (we were at SP18, going to SP20)
  • SPAU list review
  • Regression testing

#Plug-in installation

  • Apply SAP note 684844
  • Import and patch Basis plugin PI 2004.1
  • SPAU list review

#PREPARE process

  • BW Pre-Prepare tasks
  • BW - Inconsistent Data fix
  • Review of results
  • Any showstoppers from PREPARE?

#Dbase upgrades

  • Database Upgrade (FixPak)
  • SAP Kernel Upgrade

#System Upgrade

  • Reverse Transport of Queries
  • Reconnect DAB & SAB to AAE
  • Run Baseline for Regression tests
  • Full Backup
  • Run the Upgrade
  • SPAU list review
  • Regression testing

Lessons Learnt

  • Testing is all! We picked up on a lot of issues, but would have picked up more if we'd had a full copy of our production environment to test over.
  • Our approach of doing a full upgrade on each environment before moving to the next one paid dividends in giving us experience of issues and timescales.
  • Write everything down as you go, so that by the time you get to upgrading production you've got a complete list of what to do.
  • We succeeded because we had people on our team who had enough experience in Basis and BW to be able to troubleshoot issues and not just read the manual.
  • The SAP upgrade guide is pretty good, if you can understand what they're on about...
  • Remember the users! The fact that the loads have been successful doesn't count for anything unless the users can see the data in Excel! There's a tendency to get caught up in the technology and forget that it's all just a means to an end.

Issues & Fixes

I've listed the main issues that we encountered. I have not listed the various issues where Transfer rules became Inactive, DataSources needed replication or we had to reinstall some minor Business Content.

Unfixed Issues

We could not fix these issues, seems like SP 13 will help.

  • <Issue>
    • <Remarks>
  • Can’t delete individual request from ODS
    • After PREPARE had been run, if we had a load failure and needed to set an ODS request to Red and delete it, we found that we could not. We raised an OSS with SAP but although they tried hard we couldn't get round it. We reset the PREPARE and still the issue persisted. Ultimately we just lived with the problem for a week until we upgraded production.
  • Error when trying to save query to itself
    • Any query with a re-usable structure cannot be saved (more thsan once!)
      • OSS 975510 fixed the issue in Dev and Acc, but NOT in Production! SP 13 may solve this once it's released.
  • Warning message when running some queries post-upgrade
    • Time of calculation “Before Aggregation” is obsolete. Not a big issue so we haven't fixed this one yet!
  • Process Chain Scheduling – Timing error
    • Process chains get scheduled for the NEXT day sometimes and has to be manually reset.
      • See OSS 1016317. Implement SP13 to fix this. We will live with it for now .

Fixed Issues

  • <Issue>
    • <Remarks>
      • <Fix>
  • Duplicate Fiscal Period values in Query
    • If you open up a drop down box ("Select Filter Value") for Fiscal Year/Period to filter your query, you are presented with duplicate entries for Month & Year.
      • Due to Fiscal Year Period InfoObject taking data from Master Data not InfoProvider. Thus it picks up all available periods not just Z2.
  • Auto-Emails being delayed
    • Emails coming from BW from process chains are delayed 2 hours on BW before being released
      • Due to userids that send these emails (e.g. ALEREMOTE) being registered on a diffferent timeazone (i.e. CET) from the BW system (i.e. GMT)
  • “Pgm_Not_Found” short dump
    • Whenever a query is run via RRMX or RSRT
      • Call transaction RS_PERS_ACTIVATE to Activate History and Personalisation
  • Characteristics not found
    • When running a query the warning message Characteristic does not exist is displayed for the following: 0TCAACTVT, 0TCAIPROV, 0TCAVALID
      • We activated the three characteristics listed and the warnings stopped. NO need to make them authorisation-relevant at this stage.(also did 0TCAKYFNM)
  • System generated Z pgms have disappeared
    • Post-upgrade the system Z-pgms ceased to exist
      • Discovered in Development so we compared with pre-upgraded Production and then recreated them or copying them from production.
  • Conversion issues with some Infoobjects
    • Data fails to Activate in the ODS targets
      • For the InfoObjects in question, set the flag so as not to convert the Internal values for these infoobjects
  • InfoObject has Conversion routine that fails, causing load to fail
    • The routine prefixes numeric PO Numbers with 0’s. SD loads were failing as it was not able to convert the numbers. Presumably the cause of the failure was the running of the Pre-Prepare RSMCNVEXIT pgm.
      • Check the Tick box in the Update rule to do the conversion prior to loading rather than the other way round.
  • Requests fail to Activate on numeric data
    • Request loads OK (different from above issue) but fails to Activate
      • Forced conversion within the update rules using Alpha routine. Deleted Request and reloaded from PSA.
  • Database views missing after pre-PREPARE work
    • Views got deleted from database, although not from data dictionary
      • Recreated the views in the database using SE14.
  • Workbook role assignations lost
    • We lost a few thousand workbook assignments when we transported the role they were attached to into Production
      • The workbooks did not exist in Development, thus they all went AWOL. We wrote an ABAP program to re-assign them in production

Regression Testing Process


We were limited to what we could do here. We didn't have a sandbox environment available. Nor did we have the opportunity to have a replica of our production data to test with, due to lack of disk space in Acceptance and lack of sufficient Basis resource.

Set up

We manually replicated our production process chains into test. We didn't have any legacy InfoPackages to worry about. We asked our super-users for a list of their "Top 10" most important queries and did a reverse transport of the queries from Production back into test (as we do not generally have a dev/acc/prodn process for managing queries, and they are mostly created solely in prodn). We made sure every application was represented. In retrospect we should have done some Workbooks as well, although that didn't give us any problems.


Prior to the various changes we loaded data via the Process chains and ran the example queries to give ourselves a baseline of data to test against. After the change we ran the same queries again and compared the results against the baseline. We tried to keep R/3 test environments as static as possible during this, although it wasn't always the case & we often had to explain away small changes in the results. After upgrading BW Development we connected it to Acceptance R/3, so that we had pre-upgrade (BW Acceptance) and post-upgrade (BW Development) both taking data from the same place so we could compare and contrast results on both BW systems. We did the same thing once BW Acceptance had been upgrading by connecting it (carefully!) to Production R/3. To get round the lack of disk space we tested by Application and deleted the data once that Application had been signed off. Once we got to System test we involved super-users to sign off some of the testing.


We chose to implement the new security schema rather than choosing the option to stick with old. For us, with a relatively small number of users we felt we could get away with this & if it all went wrong, just temporarily give users a higher level role than they needed. Our security roles are not complex: we have end user, power-user and InfoProvider roles for each BW application, together with some common default roles for all. In the event we simply modified the default "Reports" role that all our users are assigned, transported it and it all went smoothly. Apart from the fact that everyone's workbooks are assigned to this role and so we "lost" them all !

Transport Freeze

Once you've upgraded Development you've lost your transport path. We planned around this as best we could and when absolutely necessary, developed directly in Acceptance or Production, applying those changes back to Development once the project was complete. Depending on what other BW projects you have running this may or may not cause you pain!

Web Applications


We had various dashboards designed via Web Application Designer. All these continued to function on the upgraded system. However there were various formatting changes that occurred e.g. Bar graphs were changed to line graphs, text formats on axes changed etc. SAP provides an upgrade path for moving your Web applications by running various functions. However we took the view that we would simply re-format our dashboards manually, as we didn't have very many to do. Plus the external IGS (see below) powered all our environments and needs upgrading separately as part of the SAP method. Thus we couldn't have tested the SAP path in Development without risking Production. Sticking with manual mods was a lower risk approach for us. We did find we had to re-activate some templates from BC to get some of the reports to continue to work.

Internet Graphics Server (IGS)

We had an external IGS server with v3.0B. Post-upgrade the IGS becomes part of the internal architecture of BW and thge external server is redundant. We found no issues with this; after the upgrade BW simply stops using the external IGS and no separate config was needed.

Detailed Task Lists

Support Pack Hike (detail)

  • Apply OSS 780710 & 485741
  • Communicate outage to users
  • Warning msg on screen
  • Stop the jobs which extract data into delta queues
  • Clear the delta queues by loading into BW
  • Check RSA7 in PAE that delta queues are now empty
  • Run Baseline for Regression tests
  • Stop Delta queues
  • Lock Out users
  • Full Backup
  • Apply SP's
  • Upgrade the SAP kernel from 620 to 640
  • SPAU list review
  • Apply OSS Notes 768007 & 861890
  • Unlock Test users (inc. RFC id's on R/3)
  • Regression testing
  • Regression sign-off
  • Remove warning msg
  • Unlock users
  • User communication

Plug-in installation (detail)

  • Communicate outage to users
  • Warning msg on screen
  • Apply SAP note 684844
  • Lock out users
  • Full Backup
  • Empty CRM queues
  • Import and patch Basis plugin PI 2004.1
  • SPAU list review
  • Apply OSS 853130
  • Switch back on flag in TBE11 (app. BC-MID)
  • Remove warning msg
  • Unlock users
  • User communication

Dbase upgrades

Dbase upgrades (detail)

  • Communicate outage to users
  • Warning msg on screen
  • Run Baseline for Regression tests
  • Stop the Data extract jobs
  • Full Backup
  • Lock Out users
  • Apply FixPak13SAP to DB2 database
  • Upgrade the SAP kernel from 620 to 640
  • Apply OSS 725746 - prevents RSRV short dump
  • Unlock Test users (inc. RFC id's on R/3)
  • Regression testing
  • Regression sign-off
  • Remove warning msg
  • Unlock users
  • User communication

PREPARE Process (detail)

  1. Pre-PREPARE Process
  • Repair Info objects and recreate the views
  • Communicate outage to users
  • Warning msg on screen
  • Run Baseline for Regression tests
  • Stop the Data extract jobs
  • Lock Out users
  • Full Backup
  • If there conversion process runs longer delay the regular backup
  • Re-run Baselines and sign off
  • If there conversion process Fails repeat the steps on Sunday after the regular backup
  1. BW work
  • Back up customer-specific entries in EDIFCT (note 865142)
  • Activate all ODS objects
  • Execute report RSUPGRCHECK with flag "ODS objects" (note 861890)
  • Check Inconsistent InfoObjects - Upgr Guide 4.4; OSS 46272; Convert Data Classes of InfoCubes - Upgr Guide 4.3
  • Execute report SAP_FACTVIEWS_RECREATE (note 563201)
  • Make sure Delta queues are empty (RSA7)
  1. Basis Work
  • Full Backup of BW
  • Lock users
  • Unlock id's RFC id's and designated test users
  • Confirm backup complete OK
  • Apply OSS 447341 Convert Inconsistent Characteristic Values - Upgr Guide 4.5
  • Confirm OK to PREPARE
  • Review of results

System Upgrade (detail)

  • Communicate outage to users
  • Process errors from PREPARE
  • Check disk space availability for PAB
  • Warning msg on screen
  • Reverse Transport Queries from PAB to SAB & DAB
  • Change BW to R/3 connection
  • Get backup put on hold, for Ops to release later
  • Ensure Saturday night backup is cancelled
  • Final run of PREPARE
  • Run Baseline for Regression tests
  • Clear Delta Queues
  • Delete Local Transports
  • Remove process chains from schedule
  • Lock Out users (with some exceptions)
  • Confirm to Ops and Angie that we're ready
  • Full Backup
  • Incremental backup of Unix files
  • Back up kernel
  • Unpack latest 700 kernel to upgrade directory
  • Check ids required for upgrade are unlocked
  • Check no outstanding updates
  • Turn off DB2 archiving
  • Open up the client for changes
  • Stop saposcol, & delete from exe directory
  • Run the Upgrade
  • Execute the saproot.sh script
  • Perform the database-specific actions
  • Perform follow-up activities for the SAP kernel
  • Reimport additional programs
  • Import Support Packages
  • Call transaction SGEN to generate ABAP loads
  • Transport Management System (TMS)
  • Handover to BW Team
  • SPAU list review
  • Apply OSS Notes from SPAU
  • Process Function Module XXL_FULL_API (part of SPAU)
  • Restore table EDIFCT (if required)
  • Transport Fixes from our BW Issue list
  • Convert the chart settings - manually
  • Perform activities in the Authorization Area
  • Activate hierarchy versions
  • Update the where-used list
  • Execute the conversion program for the product master
  • Transport New roles to PAB
  • Unlock selected users
  • Regression testing
  • Regression sign-off
  • Go / No Go decision
  • Restore if required
  • Remove warning msg
  • Tell Ops that the CR is now complete
  • Lock down PAB
  • Unlock users
  • User communication
  • Perform the follow-up activities for SAP Solution Manager
    • Reschedule background jobs
    • Reschedule weekly backup on Ctrl-M
  • Drinks all round.
Persönliche Werkzeuge