As you already have read in the latest Business Intelligence Statement of Direction, SAP has decided to release an updated version of the BI suite code named SAP BusinessObjects BI 2024 to provide more time to our on-premises customers to adopt SAP Analytics Cloud.
As described in the statement, our BusinessObjects BI customers will benefit from an extended maintenance for their favorite and most used solutions.
To maximize the value for our customers, we will focus ongoing investments on the most-widely adopted SAP BusinessObjects BI solutions:
• SAP BusinessObjects Web Intelligence,
• SAP BusinessObjects Information Design Tool and single source .unx universes,
• SAP Crystal Reports (on Windows only*),
• SAP Analysis for Microsoft Office,
• SAP BusinessObjects BI platform
This also means some of the BI suite components will no longer be maintained after 2027, as SAP BusinessObjects BI 4.3 is planned to be supported until end of 2027.
As a reminder, these are the components we plan to remove from SAP BusinessObjects BI 2024:
SAP Crystal Reports for Enterprise,
Multi–source universes and associated connectivity,
SAP BusinessObjects Analysis, edition for OLAP,
SAP BusinessObjects Live Office.
SAP BusinessObjects Universe Design Tool and .unv universes
In this post we will see how you can replace your Multi Source Universes with our supported Analytics solutions.
What is a multi source universe
Multi source universes are a way to create one single universe on top of heterogeneous data sources in BusinessObjects Information Design Tool (IDT). Data Federator technology has been used to implement this universe type, allowing Universe designers to access and merge different data bases at Semantic Layer level. End users would not see that complexity when using the universe in Web Intelligence.
With the end of maintenance of this technology, you will need to chose an alternative solution to federate your data, as only single source universes will be supported after BI 4.3.
Depending on your tools landscape and configurations, you will find below the most appropriate alternative to adopt.
Different Multi Source Universes types
Multi Source Universes (MSU) can be built on top of Relational or OLAP data sources. In this post we will focus on Relational Universes.
Even though the primary use case of multi source universes is to access multiple and distinct data sources, it is a fact that a lot of our customers have used this option on top of a single connection. This means they selected this option when creating the Universe, just in case they would add another connection later on, which never happened.
As it is not possible to change this option once the universe is saved, the only way to transform this Multi Source Universe (MSU) into a Single Source Universe (SSU) is to rebuild the universe.
Indeed the SQL syntax used by MSU is a special syntax that is translated by DF engine depending on the target DBs, while a SSU uses the native SQL syntax of the underlying connectivity.
These are the main differences you will find between MSU and SSU SQL syntax:
In any SQL expression you will find the function @Catalog() as a prefix to identify the connection to use among the several connections of the MSU (even if there is only one).
If you have defined Derived tables, you may have checked the option “Standard SQL 92” instead of “DB specific”. This standard SQL 92 may not work in the SSU DB.
Some of the MSU operators or functions may differ from the one of your target DB. You can find the list of all MSU existing operators and functions in the MSU SQL editor:
This means you will need to remove or replace all these specific MSU SQL expressions found in your MSU when creating the corresponding SSU.
This is a simple process you can follow to replace the MSU with a SSU to get rid of the MSU syntax:
Make a copy of your MSU
Use “Find and Replace” function, both in Business Layer and Data foundation to remove the @Catalog() function from all your SQL expressions.
Create an empty New SSU Universe with the same connection as your MSU.
Copy/paste your whole data foundation from the MSU to the SSU.
Copy/paste your whole business layer from the MSU to the SSU.
Check the Derived tables SQL
Launch an integrity check to see if all the expressions are correct.
Replace all errors found in SQL with corresponding native SQL expression
This process can be done manually, or automated via a script using the Designer SDK. This can be very useful when you have complex universes or many MSU to convert.
If your universe is a "real" MSU, meaning it contains several connections with joins between the distinct data bases, you cannot simply replace it by another universe.
One of the solutions is to build several universes, but there are some other options that could be easier to implement and smoothly fit into your IT strategy. You can replicate the data federation process using another SAP technology.
These are the possible options you may want to investigate:
Without modifying your data layer (DB)
Create several universes
One MSU will require the creation of N distinct Universes, 1 by existing connection in your MSU.
Once you have created these several universes, you will need to replace the queries built on top of the MSU in your Web Intelligence reports.
One MSU query will probably be splitted in several queries, logically 1 query by new SSU.
The federation will then be obtained at the report level by using the "merge dimensions" feature. If you are using the new data manager available in Web Intelligence 4.3 SP3, it will be even easier to merge your data from different queries.
Use SAP Datasphere
Datasphere is the latest Business Data Fabric tool of SAP, and enables you to create a Semantic Layer on top of any combination of supported date sources.
Here again you wan leave your data where it resides, and you will create a new model in Datasphere based on the needed federated data.
You can then create a universe in IDT connected to the Datasphere model, and use it in Web Intelligence to replace the MSU in your reports.