How to work with 3rd-party-supplied universes most efficiently

Many SAP BusinessObjects users work with universes that are supplied by 3rd-party companies, and I have come across this most often with councils and social care teams. Companies and systems like LiquidLogic, CoreLogic/Servelec/Mosaic, SWIFT, Frameworki and Northgate provide end-users with SAP BusinessObjects universes that allow reports to be created from their databases.

However, those universes often limit what can be reported on, or how the data is represented. Those councils with in-house BI teams skilled in data-analysis want to add more value and intelligence to their reporting.

One way of doing this is to amend the universes and add to them. This can lead to problems though as the suppliers also update the universes regularly and send new versions with added objects and tables.

How do you maintain both sets of changes without creating a maintenance nightmare or redoing a whole lot of effort?

Let’s look at one way of streamlining the combining of universe updates

You have already got a universe from your supplier, and it is very complex (much more complex than the dummy universes in these screenshots!), and you have new ones sent to you every 6 months that contain changes – either added objects and fields or whole new tables.

It is published to the repository already and uses a single ODBC/OLEDB/JDBC connection. As I am focussing on the social care providers here then the format of your universe is most likely to be the legacy .unv format. This is because the provider cannot guarantee all customers have moved to BusinessObjects 4.x and have access to .unx editors.

You want to add objects to it from the same tables, but also maybe alias tables or add new tables from the same database, but not have to rebuild these new objects, joins and calculations each time you get a new universe supplied.

As you already have the supplied universe, we will create a new universe using the same BOBJ connection. This will contain the additional universe objects, tables and joins.

Go to the Links tab of the parameters screen.

Click ‘add link’ and find the main universe file in its repository folder.

Select it and click 'open'.

Click ‘ok’ and magically your existing objects will be in the universe already along with the existing tables and joins! The objects from the original universe will be greyed out and the table headers written in blue. You won’t be able to edit these objects directly in this universe, only in the original version.

You can add new universe objects (dimensions, measures and filters, etc) from the tables in the original universe and hide objects not needed in the new linked universe.

You can add whole new tables from the underlying database and create objects from those new tables.

Once you have added all that you need, export the new universe as normal. Users will need to have rights to both universes so it is best to put them in same place for general access, or a different place if the new objects are to be restricted to advanced users.

Now you can run queries against the new universe and have access to all the objects at once.

Ongoing universe maintenance with versions

So what happens when your universe supplier sends through a new version of the original universe with added tables and objects?

In order to benefit from these new objects and tables in your existing linked universe you need to take a few actions. Rename this new universe in the ‘parameters’ window to be the same name as your original universe from the supplier.

Before you start you should be confident that this new universe does not break or remove any objects, tables or joins that are key for your reporting – this should, if possible, be tested in a development environment.

Export it to the same location/folder as the existing universe. At this point you will be challenged to confirm that you do want to overwrite the existing version (it may be prudent to take a back-up of the old one first by exporting a copy to a second location that no end users have access to).

Choose yes to overwrite the existing universe.

Now that your supplier universe has been updated with the new one, import the universe that contains the link to the supplier’s universe and see that this now contains the additional tables and fields.

Using this method you can maintain a library of additional objects that the 3rd-party does not include in their universe, and ensure it is consistently applied across successive versions of the supplier’s universes.