Dilema when having to change universe for a given report... any help? 1

[shqiptar]

Hello,

I would like to confirm the following:

We are releasing version 2 of a product, with a completely new db (passing from SqlServer to Oracle), where most fields are the same as V1, but not all...

- Clients are using existing reports (plenty) which are relatively complicated...
- The name of the universe can possibly change

How can we ease the transition between v1 and v2? Obviously we don't want to redevelop the reports...

1. Either we modify the old universe in order for all the objects to point to the fields of the new db. In that case, the reports need no modification whasoever
2. Or we just make sure that the new universe has the same object names and switch universe for each dataprovider.

The first one may seem easier, but I suspect maintenace problems will be around the corner. For the second I risk getting the message saying "obsolete objects... " and see my objects disappear.

The second one also makes me wonder: AFAIK, when changing universe, BO tries to map objects of both universes based on the names, isn't it? Because if it tries with internal IDs... (...yuk... shudder...)

I am using BO version 5.1

Anyone having had the same dilemma, any advice?

Thanks a lot,

Toni

 

[blom0344]

Toni,

I would copy the existing universe, modify it to fit the new RDBMS and then point an existing document to the test-universe.
I suspect you may run into trouble when you are using database functions that are specific for Sql Server. There seems to be also an issue with SQL server outer joins being inproperly handled in some BO versions.

In any case, this is a painfree exercise, cause NOT saving a document will allow to reverse the process.

I believe BO maps objects also according to the specific class in which they reside...

Ties Blom
Information analyst

 

[shqiptar]

Hi,

Thanks for your answer.

Yes, all the db specific functions would have to be modified, but this is not a problem. It still would consist of modifying just the universe.

As for the BO mapping of objects, it does not seem to be based on the class. I changed universe for a data provider, after adding the missing objects to a new 'Technical class', and BO found them fine.

Toni

 

[blom0344]

The fact that designer allows for identical named objects as long as they are store within different classes would suggest that class is part of the mapping...

Ties Blom
Information analyst

 

[bertdijks]

The mapping in the reports is based on the ID of the object in the repository. For the universe the report looks to the universe name.

If you make an identical universe with the same object names, the report will recognise the universe, but not the objects!

My suggestion is to change the existing universe (save the old version!!!) Keep the same name, and keep the same objects. Do not make copies of them, because they will get an new ID! You will not have to change your reports!

 

[blom0344]

Bert,

If your explanation is true It would imply that one cannot change universes within a document?

I have used this option quite a few times, never had any problems with the document not recognizing the objects in the newly assigned universe...



Ties Blom
Information analyst

 

[sh4kil]

You can create two universes independently and have same object names (say in different classes) and Reporter will pick up the objects.

If you have two objects within a universe with the same name but different classes then BO will display an error message.

It would seem that when you switch universes then BO uses the names and not the IDs. Once a universe has been assigned then the IDs are used thereafter.

My suggestion is to create a copy of the universe and change the objects for Oracle functions where need be. Give this universe a V2 name, etc and then you can switch universes manually, or via a VBA script on all reports that need pointing the new universe.

 

[AndreasSchneider]

How universe switching works in version 5.x.and 6.x

Once a universe has been exported to the repository it is assigned a hidden universe ID. Data providers built on such a universe are actually pointing to the universe ID.

If a data provider points to a universe ID, which Business Objects does not find anymore in the repository (for example because the user does not have access rights to the universe domain hosting the original universe), then BusObjects will start searching by the universe name (file name) across all available universe domains to which the user has been granted access - often this is how Dev/Test/Production environments are implemented: One BusObjects repository with separate universe domains and document domains for Dev/Test/Production.

Regarding objects:
If a data provider finds the universe by universe ID then objects in the data provider will be mapped to objects in the universe based on the hidden object ID. Therefore one should never delete and re-create universe objects, but move them instead, classes play no role as objects are referenced by the hidden object IDs.

If a data provider switches to a universe by universe name (because the original universe with the universe ID is not accessible) objects in the data provider will be mapped to universe objects by name only.

Therefore I would alway recommend never to use duplicate object names in a universe even if the objects are in different classes.

Remember, with BusObjects XI the repository structure changes.