Migrating MultiProvider to CompositeProvider -> keep navigational attributes

[andreas_lcher]

For migrating a MultiProvider to a CompositeProvider SAP offers program RSO_CONVERT_IPRO_TO_HCPR which does this task automatically. Recently I had the following scenario: I had to migrate a MultiProvider to a CompositeProvider which should get the same technical name as the MultiProvider. I didn’t want to use a new technical name with copies of the queries built on top of the MultiProvider because this would cause a lot of manual effort in redesigning the BI Portal. The program mentioned above has some limitations concerning the migration of navigation attributes. It does only work correctly when every single InfoProvider which is included in the MultiProvider contains the navigational attributes of the MultiProvider. If this condition is not met the navigational attribute is converted to a globally unique name. This means a lot of manual effort in redesigning the queries on top of the MultiProvider. To make sure that every navigational attribute is converted in a correct way I designed the following approach:

 

1. RSA1: Copying the MultiProvider which has to be migrated (mp_original) to mp_copy -> this step is done for test purposes


2. RSZC: Copying of al Bex-elements from mp_original to mp_copy -> this step is done for test purposes as well


3. RSA1: Creation of an InfoCube ic_temp. For this InfoCube I used MultiProvider mp_original as a template. This ensures that the structure of InfoCube ic_temp is identical to the structure of MultiProvider mp_original


4. RSA1: Add ic_temp to mp_original


5. RSA1: Remove all InfoProviders from mp_orignal except of ic_temp


6. RSA1: Identifying all characteristics for MP_ORIGINAL -> Create proposals for all


7. RSA1: Select all keyfigures in for MP_ORIGINAL -> Create proposals for all

--> Step 4-7 ensures that all navigational attributes of mp_original exists in every underlying InfoProvider

8. SE38: Execute program RSO_CONVERT_IPRO_TO_HCPR

Parameters:

Source InfoProvider:                    MP_ORIGINAL

Target-CompositeProvider:         MP_ORIGINAL

Backup-InfoProvider:                  MP_BACKUP

Execution Mode:                        Transfer InfoProvider and queries, retain                                                                     query names

 

9. BW Modelling Tools: Remove ic_temp from mp_original


10. BW Modelling Tools: Add all InfoProviders to mp_original which are included in mp_copy


11. BW Modelling Tools: Create the mappings of characters and keyfigures for mp_original as defined in mp_copy


12. Frontend-Tool (i.e. analysis for office): Compare the query results of mp_original with these of mp_copy


13. RSA1: if the query test is successful mp_copy with all Bex-Elements, mp_backup and ic_temp can be deleted

This approach requires some manual effort (especially no. 11) but I think it is worth, especially when there are a lot of queries built on to of the MultiProvider. By simply migrating a MultiProvider to an CompositeProvider a check of every single query would be necessary to ensure that there are no globally unique objects used instead of the technical names of the navigational attributes.

I hope this approach is helpful for you as well.

 

Kind regards,

Andreas