Summary

The objective of the document is to give information on the activities performed during and after BI 7.4 upgrade.

System Information

Before Upgrade: SAP BI 7.0 SP 22 – SAPKW70022

After Upgrade: SAP BI 7.4 SP 7 – SAPKW74007

Introduction

This part involves few important activities of pre-upgrade.

  

Planning the upgrade is a significant task and should be in an organized manner. We have planned our SAP BI 7.4 upgrade in three different phases and with reasonable time difference between each to identify issues and resolving them.

 

  • Hardware Upgrade which involves Oracle patching as well (This might not be happening in all systems. Based on the requirement, business will decide in doing this)
  • Stack Split (ABAP and Java stacks)
  • Application Upgrade

          Online Upgrade of ABAP stack

          Offline Upgrade of ABAP stack

          Online Upgrade of Java Stack

          Offline Upgrade of Java Stack

BI activities in first and second phase is all about testing the system after the activities. The actual activities starts before and after SAP Application upgrade.

Hardware Upgrade and Stack Split

As I have already mentioned, this is not mandatory for all systems. It is based on how old or how powerful your system is.

Our system is pretty old and so we have decided to do the hardware upgrade and stack split at the same time in order to reduce cut over

  

Basically from BI perspective, we don’t have to do much during this activity except for testing.

The common issues that we have faced in all environments are below. Again, this is particular to issues that we have faced in our system. There might be less or more than what we have listed.

  

  • Source system connections will get affected which basis will correct in few minutes, but this has to be first in your checklist
  • Since we have done the stack split, portal and bookmarks might not work which is also a basis configuration settings.
  • Integrated planning function tcode RSPLAN might not work and will give an error saying “Cannot find a J2EE Engine”. The issue was during the split the WebDynpro RFCs get deleted and need to be recreated.

Capture.PNG

  • Once the stack split is completed successfully, we have got a new portal link and it worked fine, but when we try to execute the reports from Query designer, the screen was as below. The reason for this issue is same as for No 3. WebDynpro RFCs get deleted during stack split and need to be recreated.

Capture1.PNG

  • Process chains/jobs scheduled will be in released state and will never start. Basis team has reset the parameter rdisp/btctime in RZ10 and RZ11 from 0 to 60 which resolved the issue

Capture2.PNG

  • We had few APD jobs which updates data from BI query to AL11. These jobs failed after the hardware upgrade and the reason for this failure is
    /interface (or the location in AL11 of your APD jobs) was not mounted on the BI servers. Basis has done this mounting activity and the issue was resolved.

Application Upgrade

The below is the rough information on different phases in SAP application upgrade.

Capture3.PNG

Most of these are done by basis and a BI consultant’s involvement should be there in Checks phase, Pre-processing and Post processing phase.

Checks Phase – Pre upgrade Task

Basis will perform few activities from their end and before moving to the pre-processing phase, below activities should be performed from BI side

We can access this information using the Tcode /N/ASU/UPGRADE. Below is the screenshot and detailed information is also given. ***

Capture4.PNG

Please note that we need to access this tcode 000 client and not in the default client. But the activities should be performed from the default client (which is 100, I believe this is same for all)

Below are the details of the activities which has to be performed based on your system.

1. Check some notes before upgrade (Basis):

Check OSS Notes:

     Note 586648 – Invalid SID entries in /BI 0/SIOBJNM

     Note 1022704 – Upgrade Phase EHP_INCLUSION und SPSTACK_REQUEST

     Note 1088717 – Active services for Web Dynpro ABAP in transaction SICF

     Note 1390477 – Additional info for upgrade to SAP NetWeaver 7.3 ((((using SUM)

     Note 1403832 – Central Note: Upgrade Systems on SAP NetWeaver 7.3

     Note 1539356 – Upgrade to NW 7.3 with SEM-BW, FINBASIS, SAP_BS_FND, WEBCUIF

     Note 1405878 – SAP Solution Manager – Basic functions SP22 and higher

     Note 1484437 – BI_CONTT 77.35: Information about installation and upgrade

     Note 1543092 – BI Administration Cockpit: Upgraded from 7.00 to 7.30 release

     Note 1562522 – SAPINST aborts during central instance installation

     Note 1603103 – SMSY: NetWeaver 7.3 upgrade

     Note 16366053 – Upgrade to SAP NetWeaver 7.30: BW server: Useful note

     Note 1627683 – SCWB/SNOTE/SPAU: Changed development package

     Note 1528990 – SP Equivalence for update/upgrade to SAP NW 7.30

     Note 1636841 – Version management: Compatibility with SAP BASIS 777.x00

2. Add-On Compatibility of SAP NetWeaver: (Basis)

Check OSS Notes:

     Note 1532805 – Add-On Compatibility of SAP NetWeaver 7.3

     Note 1826531 – Add-on compatibility of SAP NetWeaver 7.4 – ABAP

3. Deactivate the Real Time Data Acquisition (BI – Not Required)

Trans: RSRDA. Though this is not active in our system, the upgrade will perform this step and therefore nothing is required to be done, apart from for your information. This task is automated in the Database Migration Option (DMO) in SUM and also in the task list SAP_BW_BEFORE_UPGRADE.  You do not have to perform this task manually if you are using one of these tools.

4. Check activate of ODS objects: (BI)

Trans: SE38/SA38 -> RSAODSACTIVATE

Report RSAODSACTIVATE checks whether your ODS objects are actively
present. Before you can perform the upgrade, all requests must be activated in
all ODS objects or deleted from the M table.  Alternatively you can go to
RSA1 => Administration => DataStore Objects.   This check is
automated in the upgrade process. Make sure that it does not report errors
before you start the upgrade.

5. Upgrade Check Report RSUPGRCHECK, isn’t valid for our release.  Step needs to be confirmed (Basis)

6. Remove temporary BI tables, this deleted any temporary BI tables and is a Basis step.  (Basis)

7. Check/Repair Status of Info Objects: (BI)

 

To avoid a data loss, upgrade shutdown, and long runtimes, check the status of your InfoObjects before the upgrade.  

Proceed as follows:

Call transaction RSD1 -> All InfoObjects -> Update.

Activate all information objects that are not assigned with a green light.

Then choose Extras -> Reorganize InfoObject tables to reorganize the InfoObject tables.

For more information, see SAP Note 458363.

8. Check inconsistencies with RSZ* Tables: (BI)

Trans: SE38/SA38 -> ANALYZE_RSZ_TABLES

Report ANALYZE_RSZ_TABLES is designed as a check-tool for detecting and solving different types of inconsistencies in the main query definition database tables. Execute the report to check possible inconsistencies with RSZ* Tables. Please read SAP Note 792779 for more information.  The program is recommended for BW system administrators.

9. Activate Info Objects (BI)

Trans: SE38/SA38 -> RSDG_IOBJ_ACTIVATE:

Activate Info Objects without automatic transport connection.

10. Clean/delete the messages for error (BI)

Trans: SE38/SA38 -> RSB_ANALYZE_ERRORLOG/RSBM_ERRORLOG_DELETE

You can use the report RSB_ANALYZE_ERRORLOG to analyse which DTPs have created how many single record error messages, and to how many requests these messages are distributed. You can use the report RSBM_ERRORLOG_DELETE for single DTPs to delete the messages for requests up to a specified date.

If numerous single record errors are frequently created for specific DTPs, you should analyse the relevant requests in more detail and, if required, eliminate the error cause (for example, adjusting the transformation routines).

11. Clean-up entries from table RSIXWWW: (Not Required)

SE38/SA38 -> RSRA_CLUSTER_TABLE_REORG (Just for your information, and you might like to see what it says, as this step will
be run during the upgrade)

Cluster table RSIXWWW contains large datasets that you can no longer access. This results in bottlenecks with the disk space.  Use the report RSRA_CLUSTER_TABLE_REORG to delete the entries that are no longer required in table RSIXWWW.  This task is automated in the Database Migration Option (DMO) in SUM and also in the task list SAP_BW_BEFORE_UPGRADE.  You do not have to perform this task manually if you are using one of these tools. 

12. Check code pages setting (Basis)

SE38/SA38 -> RSCPINST

RSCPINST is a setup and diagnostic tool for NLS configurations. Specify the set of languages needed, and the tool determines the settings required for a consistent NLS configuration. Modifications to the application profile parameters must be carried out manually.

13. Check Master Data consistency (BI)

 

Check the consistency of master data by executing report RSDMD_CHECKPRG_ALL. Execute in background (‘Execute in Background’) in order to avoid timeout.  If the report returns errors run the report again with the ‘Repair’ option flagged.

14. Clean-up background jobs (Basis)

 

SE38/SA38 -> RSBTCDEL2

Clean unused jobs if possible – check especially logs from job BI_WRITE_PROT_TO_APPLLOG. 

Related Documents

http://scn.sap.com/docs/DOC-58813 – BI Activities involved in SAP BI 7.4 upgrade – Part 1

To report this post you need to login first.

1 Comment

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

  1. THY RAPORLAMA

    Hi,

     

    While upgrading the production system, do we have to restrict access of users to reports during the asu preparation steps?

    (0) 

Leave a Reply