Migration of 3.x objects to BI 7.0

When we talk about migrating objects, it is always about the converting the rules, datasources and infosources. The info objects, info cubes, DOSs, Infosets and MPs are BI 7.0 compliant already.

    SAP has provided a Migration tool for this purpose which automatically does the job with little or no manual effort. During conversion most of the routines and formulas in the update rules and transfer rules automatically gets converted. The Migration tool cannot migrate scenarios of unlimited complexity. Therefore, the transformations created during the migration may be incomplete or incorrect in rare cases.

   A typical scenario is where the data is loaded from the source system in to a staging DSO(via a PSA or not) through an infosource and then from there is it further update in to one or more data targets (may be a second level DSO or a cube(s)). A migration of such a data flow would require the following actions...

1. Create a new infosource by copying the existing 3.x infosource.

2.  We start by converting the transfer rules into transformations. Choose "Create Transformation" from the context menu of the transfer rules. This results in a pop up message with two options, "Copy a 3.x infosource to new infosource" or "Use available infosource".

3. Select "Use available infosource" and select the new 7.0 infosource created in step 1.

4. An inactive transformation will be created based on the transfer rules. At this time you would know if the transformation requires a manual effort or not.A note 1052648 eloborates on different errors that can occur during the migration with a viable course of action for each case. Make necessary changes and activate the transformation.

5. From the context menu of the update rules choose "Create transformation".

6. Activate the inactive transformation.

At this stage you have the 7.0 infosource with transformations from the datasource and transformations to the data target. The data source is still in 3.x version. You would see that the update rules and transfer rules are still existing in parallel to the transformations.

7. Right click on the 3.x data source and choose "Migrate". In the next pop up screen choose With or Without export. The choice you make here will determine if you can bring back your 3.x datasource if needed. The "With Export" option will make it possible to revert back the migration process(using t-code RSDS) of the data source. Once the datasource is migrated to 7.0, the transfer rules are wiped out, using the "With Export" option the transfer rules can also be restored. When the datasource is migrated the Infopackage is automatically converted(you can see extra tabs in the infopack maintenance screen). And the "Only PSA" is selected automatically in the Update tab, since in 7.0 the infopacks load only to PSA.

8. The migration process will be complete with the creation of the DTP to load the data from the PSa to the data target.

If you have a second layer of data target and you have to convert that flow as well...

1. Convert the update rules between the first layer data target and the second layer data target to transformations using the above steps.

2. Create a DTP based on the transformations created above.

3. The DTP, by default, is a delta DTP. So when you execute the DTP for the first time it pulls everything from the first layer data target and that doubles up the records in the second layer data target. To avoid this, in the Execute tab of the DTP, change the Processing Mode to "No Data Transfer; Delta Status in Source: Fetched" and execute the DTP. You will see a request with 0 records loaded in the target with the status "delta status set in the source". This will set the delta pointer and the subsequent executions of the DTP will load the new records. If your first layer is a DSO, then choose the "Change Log" in the Delta Init Extraction From.. in the Extraction tab.

To guide you through the road blocks you can refer to Note 1052648.

Migration of 3.x BEx Queries to BI7.0 - Useful Tips

Normal process of migrating BEx Queries from 3.x version to 7.0 requires us to open the 3.x BEx Query using the BI7.0 Query Designer and Save it. This would migrate the 3.x Query to BI7.0. Once migrated, we will not be able to edit the Query using 3.x Query designer anymore. Similar to Query migration, 3.x BEx Workbook Migration requires opening of 3.x Workbook using the 7.0 BEx Analyzer and saving it.

Though the process of migration is simple, it becomes very tedious depending on the number of BEx Queries and Workbooks involved. Some useful tips discussed here would help reduce the time spent on trying to fix some of the common issues encountered as part of migration.

• Message no. TK112 - The objects R3TR ELEM abc und R3TR ELEM xyz cannot be edited together because the 1st objects's original is in this system, whereas the 2nd object's original resides in another system - When we try to migrate a 3.x BEx Query, we get this message  In order to get rid of this, we can follow the process below
  
  1. Open the 3.x Query using 3.x Query designer.
  2. Save the Query using 3.x Query designer and assign it to a Transport request.
  3. Open the same Query using the BI7.0 Query Designer.
  4. Save it using the BI7.0 Query Designer. 
• Delete Query Results option not available for BEx Workbooks in BI7.0 - In BW 3.5 we had an option to delete Query Result when saving a workbook. This would allow us not to display any Result data from a previous run when the workbook is opened. But in BI7.0, this option is not available. This could be because in BI7.0 when we open a Workbook with setting "Refresh Workbook on Open", it first displays the Variable selection screen. Only when we enter the selection values and hit enter, does the report shows up. Unlike in BW 3.5, when we open a workbook from server, first the report layout is displayed and only after that the Variable selection screen is displayed. In 3.5, we had an option to cancel the Variable screen pop up, which would leave us with the report layout. And if we did not delete results at the time of saving the workbook to the server, it would leave users with old data. But in BI7.0, when the cancel button is selected on the Variable screen, it leaves a blank report layout.
•  Default Values in Variable Selection Screen - In the DEV system, we migrated a Workbook. When the Workbook is saved using BI7.0 BEx Analyzer, it is saved with the values we have entered on the Variable screen. When this Workbook is transported to the target system, and when the Workbook is opened in the Target system, the Selection Values with which the Workbook was saved in DEV system show up in the Variable selection screen. This may not be useful most of the times because, the data in DEV system may not be the same as it is in QA or PRD system. In order to avoid this from happening, we can unchek the "Process Variables on Refresh" in the Workbook settings. OSS 1017248 provides more information on this.
• In order to have better performance when using BI7.0 BEx Analyzer, we need to make sure that we have .NET 2.0 framework with latest Service Packs installed. This is to avoid any memory leaks which would hamper the performance. 

Queries or Workbooks Migration - Errors and Fixes

While migrating Queries and workbooks after a technical upgrade from BW version 3.5 to Netweaver 2004s we faced certain issues which potentially could have been a show stopper, in terms of meeting with the tight deadlines of the deliverables.

I would like to share two such issues / errors which I could successfully resolve. I believe these are errors that many of us would come across as part of the Upgrade / migration process and hope the resolution provided would be of help to you all.

Case 1: Error in Object Editing.

As we all know - "To migrate a query to the new version we are required to open the query in the 7.0 version of Query Designer" and Save it. This would effectively migrate the 3.x query to the 7.0 Version. 

When I tried to migrate a 3.5 Query, the following message appeared "Edit objects separately since they belong to different original systems"

  

At first  assumed that some of the Query elements were saved in a different Transport request, but fixing that did not make any difference. Further Investigation lead to the conclusion that - While creating new queries certain changes were made to the Global structure. These changes made to the Global structure were not adjusted in the queries that were created earlier to the changes.

I our case, some of the newly created queries have Calculated Key figures that were created anew and saved under the Global structure, these changes were not reflected in the Global structure of queries that were created a long way back. 

So here is the solution-
-           Open the Query in 3.x version
-           Save the Query (Can be collected in a Transport Request)
-           Open the Query in 7.0 and Save again.

Case 2: Missing Text elements from Workbooks.

After migration of certain workbooks, we observed that the Variable entries that were supposed to be displayed as Text elements were missing.

Before 

We identified that applying OSS Note 1143771 would fix this error.
Applied the note and below is the workbook displaying the Text elements.
 
After

  

Issue: We were getting an Informative message 'Work Book contains links to other data sources, you want to Update or Don't Update?''. This is because of copying Logo from source file and pasted it into the work books as part of changes in the work books..
Solution: Changed Excel features--àEdit in the Menu bar-àLinks-àStartup Prompt-àDon't display the alert and don't update automatic links (second radio button)

 Lessons Learned:

Front end must be in the same version for all the systems while Migrating Queries and Work Books. (Especially when we are working on Global Standard Model--
onsite and offshore model)
--We had some issues due to mismatches of front end versions..

BI 7.0 –Initial Problems

After upgrading to BI 7.0, one should be prepared to face new challenges until the new functionality stabilizes.

It is true that our new BI friend may create subtle chaos in the beginning,however with the help of SAP the game is easier to play.

In this blog, I would like to bring forth the possible problems that we faced during the BI 7.0 upgradation along with the solutions provided by SAP fromEDW perspective.

Note: The below addressed issues are pertaining to post upgradation but not after migration to 7.0

During the upgradation phase, proper checks need to be performed to maintain the consistency of all BI objects;

Check BI 7.0 Upgrade checks.

 Now, let's move on to the core section of the blog:

Issues with DSO/ODS activation:

"Activation of M records from Data Store object (*DSO technical name*) terminated

Data package already saved in change log"

During the activation process, the data will be moved from new table (Activation Queue) to active table and change log.

But,in this case the data still persists in the new table and during the next activation step, it will try to write the same records to active table.

Solution:

•   Note 1144998 - Incorrect data for DataStores with option "Unique records"

"Table /BI*/A (*DSO technical name*) 40 unknown

Error has occurred in RSDRO_UPDATE_ODS (*DSO technical name*) RSAU 499"

Solution:

• Note 920420 - Conversion of DataStore objects not successful
• Note 861890 - ODS tables disappear during the upgrade

"Error during update of data records for data package and "Time limit exceeded".

No return of the split processes..."

Solution:

• Note 1118205 - RSODSO_SETTINGS Maintain runtime parameter of DataStore obj.
• Note 1042827 - BI 7.0 (SP14): DataStore object - Batch Manager
• Note 1067225 - BI 7.0 (SP15) DataStore default settings are not applied

"ODS activation failing with a short dump - SAPSQL_EMPTY_TABNAME

        (Or)

Version of Change Log (**Transfer structure name**) invalid refer to table RSTSOD

Error while calculating tables for Data Store (*DSO technical name*)"

Solution:

This is because there is more than one version of a PSA/change log for each DSO.

Program RSAR_RSTSODS_CHANGELOG_VRS part of up gradation activity should delete old change log versions, if unsuccessful will face aforementioned short dump.

• Note 1135256 - Change log versioned (repair tool for SAP DEV Support only)
• Note 974184 - Error when activating ODS data (RSAR 535)

"Error while inserting data records for data package                    

Data records already saved in the active table"

This is because of duplicate records in the active table.

Option1: Identify and delete the duplicate request, and then try re-activating.

Option2: If the DSO has unique status flagged, uncheck it.Try activating the requests.
Later reset the unique flag.

"Activation of empty requests fails with

Saving consolidated aggregation data was terminated"

Solution:

• Note 1081423 - No activation or rollback due to missing aggregation behav.

Unable to delete a request from DSO

"Requests can't be deleted from DSO. In SM37 the deletion job finishes, however in the job log it will show:                                                                            

Server group (for roll back): No Server Group configured

No batch process available"

Solution:

• Note 1007717 -Deleting from Data Store object: Termination w/o log
• Note 998704 - Deleting req from DataStore obj: Status at end of processing
• Note 1037507 - System Termination when you delete from DataStore objects
• Note 995237 -Check for empty RSODSACTDATA during activation

"Deletion of an empty request which was activated in BW 3.x leads to following error:

        Aggregation behavior of the InfoObjects not found"

Solution:

• Note 1081423 - No activation or rollback due to missing aggregation behav.

Issues with Process chain:

"Process chain scheduling to the present day using date and time feature in maintain variant >change scheduling,actually schedules it for next day."

Solution:

• Note 1016317 - SP13:PC: Start type 'Date & time' gets scheduled wrong

"Process chain scheduling results in dump- ABAP/4 processor: MESSAGE_TYPE_X"

Solution:

In the short dump analysis, the process fails at function module
RSS2_PSA_NEW_OLD_DS
call function 'RSDS_DATASOURCE_SINGLE_GET'

• Note 948189 - P9:PSA: Dump in the RSS2_PSA_NEW_OLD_DS function module

"Process chain maintenance transaction (RSPC) results in dump"

Solution:

• Note 946481 - Short dump in process chains, InfoSet maintenance, data flow

"Opening an info source goes for dump"

Solution:

• Note 989923 - P11:DWWB: InfoSource overview returns short dump in DWWB/AWB

Data load failures:

"The major problem just after the up gradation that one has to encounter is Data source replication"

Solution:

Use T-code RSDS for mass replication

Data source      : Enter as *(It will replicate all the data sources related to the mentioned  Source system)

Source system   : Enter the source system name

And then activate transfer rules using RS_TRANSTRU_ACTIVATE ALL

"Error generating program"

This is because transfer structure is not activate

Solution:

Replicate the data source and activating the transfer rules.

"SQL error in the database when accessing a table"

Solution:

Try re-running the load by reducing the Data packet size

"Extraction job fails in the source system.In the source system job log it shows:

No Authorization for info cube / data source (*Data source name*)"

Solution:

Check for missing authorizations in SU53 and communicate with your security team

"Error when reading from the PSA"

• Note 849857 - Potential data loss in PSA/change log

Other Helpful OSS note: 

• Note 1055827 - P15:PC: Restarting loading processes in background and dump

  

                         

Important OSS notes :

Note 955990 - BI in SAP NetWeaver 7.0: Incompatibilities with SAP BW 3.x

Note 948003 - Corrections to Data Warehousing Workbench BI7.0 (SP0