I read some of the posts on universe linking, but not all.
We are thinking about linking universes for the reason of simplicity. The concept is that it is much more simple to maintain one dimension universe than maintain the dimensions in several universes. We create reports for 4 departments, and in the end there will be a universe for each department. The question is that is it worth to go for linking for this reason.
Another question is whether it is possible to create derived object int he dimension universe, which contains objects from the dimension and the fact universe, or it is only possible in the derived universe?
Will it cause problems to export the linked universe to a different repository? We develop the universe on a developer server and then export it to the real server.
Well we have linked universes. I have a universe for people, a universe for vehicles etc and a universe for events that links into people and vehicles. I work in development and migrate to production without any problems in XIr2.
Glad to see that Linked universes are working for you, they are fairly simple to set up and maintain but most members on the BOB board may agree that there are some other migration related factors to consider when creating linked universes.
Do you need custom LOVs from the kernel universe in your derived ones? These will not be accessible in your derived universe.
Will your universe have context’s in them? If so, joins from the kernel will need to be included in contexts in the derived universe.
Will your linked universes use the same connection? They better.
Seriously though, if you have simple universes without contexts in them, or use custom lovs, use the same data connection, and your mindful in your universes design you should be fine.
I understand that recreating joins and contexts is necessary in the derived universe is, but it is not a problem.
What is a problem, that I will have objects, which use tables both from dimension universe and the JEL universe. Now I want to maintain these objects in the linked universe, not in the derived one. Two problems arise First, is this possible at all? Second the expressions in these objects can be quite complex, and I need to verify (parse) somehow that these expressions are correct
I copy here an example. This expression is in the Select part, and it uses tables from both universe (DENOM_DEV_ELADOTT, DENOM_DEV_ELADOTT is from the dimension universe, JEL.FCT_FORGALOM is from the JEL universe):
sum(decode(DENOM_DEV_ELADOTT.DEV_ISO_KOD,'HUF',JEL.FCT_FORGALOM.ERTEK_ELAD*CASE
WHEN JEL.FCT_FORGALOM.TORLES_MODOS='T' THEN (-1) ELSE 1
END,decode(DENOM_DEV_VETT.DEV_ISO_KOD,'HUF',JEL.FCT_FORGALOM.ERTEK_VETT*CASE
WHEN JEL.FCT_FORGALOM.TORLES_MODOS='T' THEN (-1) ELSE 1
END)))
Also I need some clarification on migrating, because I might misunderstand something. Universe migrating is connected with database migrating or it is just moving the universe from one repository into an other? If the second, it is a problem, because we develop the universe in the developer server (a different database) and then moving it to the real one.
A custom LOV is a update to the default List of Values for your universe object. An custom LOV example may be to create an object that, in addition to displaying each of the distinct values from the reporting database to the user (at query run time) would also display a custom value like ALL or ‘*’ in the list. In this way your users could select the ‘ALL’ and return all of the values for the object. You can get started on this by reviewing the second and third points in the Designer FAQ. If your using XI3 optional prompts can be leverage to eliminate the need for this specific custom LOV example (but there may be others that you still need).
One of the nice benefits of linked universes is that (updated) Objects in the kernel universe are automatically updated in the derived universes, reducing maintenance on the derived universes. I see by your SQL example that your using an Oracle database (decode function). I suggest that you consider using CASE statements instead as they are supported by Oracle and most other databases. In this way if your database ever migrates off Oracle, you will have less universe updated work to do.
Universe migration is simply moving universe files from one repository to another (via the import wizard). You should consider how you will name your universe connections in each environment to have the universe connect properly to the reporting database. Some environments insist on using connection names indicating the data base type like Connection Dev, or Connection Prod. This approach requires updating the universe connections after the migration.
Another approach is to use the same universe connection name in each environment so that the connection does not have to be changed after the migration.
I am interested in the last part of your message, Joe. We developing on the developer server, the connection name is dw_sys_dev. After that we migrate the universum to the real server, where the connection name is simply dw_sys. Will the linking cause problems during the migration? Can it jeopardize the functioning of the other universes?
The main issues with migrating linked universes are the custom lov and context concerns noted earlier. The connections used must be the same for both the master and derived universes in each environment.
After your initial migration, you will need to update your connection for your real server. This just requires a few minutes to perform and I suspect that you will have to make the update each time you migrate them (I have not migrated linked universes yet), let us know. The risk is that if the dev connection is used in the real environment, your data will not be coming from where you intend it to be coming from for each universe.
We began to test how to migrate the linked universes between the two repository. So far we cannot export even the kernel universes, because it gives the following error message:
'You are not authorised to use this document (FRM 00008).
Details: the universe belongs to another CMS.You cannot open it unless you are connected to the same CMS from which it was imported.’
The process for modificating the universe is that we modify it on the developer server and then migrate it into the live enviroment. This means a migration every week. If I have to rebuild the contexts each time, then the linked universe concept is not worth to use.
By the way, does anybody know a method of how to insert tables, joins and contexts (maybe even objects and classes) automatically using excel and VBA SDK? It would be even better to save the table, join, context structure of the old universe, pick out the needed tables, joins and contexts and upload it into the new universe. I aware that I can include universe, but I want a different approach. This method (if it exists) would solve the problem of rebuilding the contexts after migration to the live enviroment.
Successfully solved the migration issue yesterday. The universe have to be saved with shared connection and the universe have to be saved with “save for all users” box marked.
Not counting this issue, the migration went without problem. The order of the universe didn’t matter (mentioned in this topic: Universe Linking) nor the contexts disappeared. There wasn’t any need to update the links. We use BO XI R2
Meanwhile I’ve found some useful links in BOB downloads in connection with universe creation automatization:
One question about linked universes: I have created custom hierarchies in the derived universes, but when i link these derived universe to core universe, i don’t see those custom hierarchies. Do they not propagate to the core universe once linked? Do we need to recreate custom hierarchies again??
Once custom hierarchies are created in the core universe, they should be available in the derived universes only (top down model). They do not move from a derived to a core (kernel) universe (bottom up), thats why these universes are called derived.
So… if you want to use a custom hierarchy to be used in (any) derived universe, they need to all be created in the core universe.
Note that the Core and Derived universes do NOT have to have the same connection as long as the connections go to databases with the same STRUCTURE.
Because of legacy contractual requirements, we have a separate database for each of our clients. Each database has the same structure. We can’t change the connection in a universe based on security because we have some internal users who need to be able to run queries for all of the clients (separately or combined!) So, we have a core universe that connects to one database and each of the other clients has a universe that’s linked to the core but connects to that client’s database.
Besides having to maintain the context separately in each universe, the only issue we’ve run into is that sometimes the client universes get corrupted if we only migrate the core universe between environments or if we migrate just one client without the core. So, we always migrate the core AND the client universes at the same time.
Finally I created my linked universe. There is one dimension universe, several core universe and a derived (linked) universe. I created the contexts in the derived universe, everything else (classes, objects, joins, tables) are in the core or in the dimension universe.
Now my problem is, that when i try to remove one of the core universes from the derived universe, I get an error message, even if I delete the contexts connected with that specific universe. Anybody knows how to solve this problem and what is behind it?
I have to recreate the whole linked universe if I want to delete one of the core universes.
I tried to do this, I customized the LOV in my master universe by doing UNION SELECT ‘ALL’ from DUAL for my account id object.
And I don’t have account id object with the same definition (as in Core Universe) in my Derived universe. To my surprise, I was still able to access this CUSTOM LOV in my report developed on Derived universe.
Just wanted to let you know. I am on BO XIR2, SP2.[/quote]
Its not possible to change the objects coming from the kernel universe. You can only change the objects which you created in the derived universe. You cannot change the structure of the classes (the tree) coming from the kernel universe.
(BOB member since 2009-06-23)
(BOB member since 2005-03-01)
(BOB member since 2002-08-19)
(BOB member since 2004-04-05)