The challenge of converting a UNV to UNX.... (I)

building semantic layer
1

Hi folks,

After several weeks doubting about if begin to migrate our BO XI 3.1 platform we have finally decided to jump into the swimming pool :slight_smile: and these are the consequences:

Following SAP Guidelines we have began by moving all contents from our old 3.1 CMS to new 4.0 release using UMT (Upgrade management Tools). Everything has worked fine as this level, probably because as I discovered later, this tool is not done a complete upgrade of all CMS contents.

Effectively our main headheaches began when to convert the old UNV universes to the current 4.0 universe format (UNX). This step is not assumed automatically by the UMT and we understood quickly why…

Following again SAP Best Practice Guidelines we converted a first UNV universe using the IDT tool. Apparently everything worked fine (no errors appeared during conversion. Great!). We didn’t still realize that issues would only appear when checking the integrity of the converted universe. What follows is a draft list of them. Some of them has been fixed other still remains over our table:

  1. Table Structure Errors: I don’t understand why what you have to refresh again all Data Foundation Structure because data type seems not have been properly converted (?).

  2. List of Values: We don’t yet understand why :slight_smile: but converted universe contains LOV’s that didn’t exist in the old one (Fantastic!). What is more we noticed problems to edit LOV objects based on attributes PK’s. For all this reasons we decided to recreate “again” manually all our LOV’s. At this stage we began to understand what the words “migration” means…

  3. Automatic conversion @prompt expression into paramterers: Forget to use this option available during the conevrsion process. In our case (even if ticked) it didn’t convert any damned @prompt into a parameter. What is worse is, all objects that were used to encapsulate the @prompts (in the select property) appeared with empty contents after the migration.
    In order to fix that we decided to replace manually all our old dimension @prompts -based objects by creating named parameters.

At this stage we had nearly fixed a long set of integrity check errors ( recreating “manually” 40% of elements of the new Universe). What else could happen us?

  1. Use of Stored Procedures: IDT gave an error when a given dimension contains a T-SQL function in the Select clause. We don’t use this approach usually and it seems that the workaround is ignore the IDT alert (the query engine has no problem to parse the generated query in the reports).

  2. Long text data type: IDT converts all long text data types into BLOB (bravo!). In this case solution works fine if you manually fix what IDT has damaged by changing manually again the data type.

Well, and this is enough by the moment. I’m thinking in creating a blog to
explain my sorrows with the universe conversion…

If someone has faced previous problems I would appreciate any additional opinion about how to fix them.

P.D: At last but not the least, the most funny feature of IDT comes when you try to move a folder in the repository Resource. Have you tried? It show a pop-up saying “Feature coming soon”, ja,ja!!

alf_gon (BOB member since 2010-10-22)

2

You know you don’t have to convert from UNV to UNX, right? If you want to continue using your old universes, you certainly can. You won’t get some of the new features like multi-source universes, but you also won’t have the laundry list of issues. :wink:

Dave Rathbun :us: (BOB member since 2002-06-06)