Child pages
  • Bex Analyzer 2004s - Upgrade and Migration
Skip to end of metadata
Go to start of metadata

The information from this page is particularly useful if you use Bex Analyzer and you want to upgrade your BI system to 7.0 or you want to start with the new Bex Analyzer 7.0 tools.

There is a very useful presentation regarding the Bex Analyzer 2004s in the link below:

Variable Screen displayed in BEx Analyzer 3.x for BI 7.0 Systems:

  • You can check in note 924316 that some changes were necessary in variable screen for BEx Analyzer 3.x in BI 7.0.

Migrated workbooks: 

  • It is not possible to open an already migrated workbook in 3.x again. This workbook is only available in Bex Analyzer 7.0 after the migration.
  • The easiest way to determine whether a workbook has been migrated or not, is that you cannot open the new workbooks with Bex Analyzer 3.x anymore.
  • You can use authorization as per note 1226980  in order to restrict the upgrade behavior.

*  You can find more information in the online documentation below:

            http://help.sap.com/saphelp_nw70/helpdata/EN/44/04aa891f49603be10000000a1553f6/frameset.htm

Variant Migration

  • As the variants in NetWeaver 2004s BI systems are stored in a different storage than BW 3.x variants, the variants are no longer visible in Netweaver 2004s BI Systems using the Bex 7.0 report tools. But they are still visible when using BW 3.x runtime. You can find more inforamtion in note 1003481 about the procedures to upgrade the 3.x variants to the new 7.0 concept.

Checks BEFORE upgrade for critical queries

If you have critical queries in your 3.X system and would like to ensure that they can be migrated to the 7.X system, there are 3 SAP Notes which are particularly useful: 1228378, 1148496 and 1135759.

Given in Note 1148496, RSR_GENREP_CHECK program is used to evaluate the 'size' of a 3.X query when it has been generated. This is a precautionary sstep when the migration to 7.X is planned. It does not check for syntax errors. For example, if you use 'before aggregation', this would not be found.

As a suggestion, it may be an idea to run the following steps:             
1. Execute RSR_GEN_DIRECT_ALL_QUERIES to generate all the queries.         
2. Then execute RSR_GENREP_CHECK to understand the limits.                 
Any queries still showing in an error list then need to be investigated individually to see where the errors lie. As above, this would then be where you would find any syntax errors (eg before aggregation being used)                          
                                                                           
Sequence of program functionality :                                        
The RSR_GEN_DIRECT_ALL_QUERIES runs with chosen selection criteria from SE38 and generates each query which falls within the selections. When all of the queries are generated, then the RSR_GENREP_CHECK will evaluate the size limit of these queries. If you use the steps above, then there shouldn't be any short dumps indicating that the query doesn't exist as these would be found previously in the first step.       
                                         

Back to FAQ

  • No labels