If you are considering leaving SAP BO.... automation is possible!

 

If you are considering leaving SAP BO... SAP had previously announced the end of life of SAP BO. Finally, the roadmap has changed a little, since it will involve moving towards SAP BusinessObjects BI 2025 (which is currently a code name).   However, a list of components will not be included in the BI 2025 version, including Universe Design Tool (for building .unv), multi-sourced universes, etc. These components will remain in BI version 4.3, but maintenance support will end in 2025.   And the rest is not necessarily very clear, even if SAP announces that it wants to focus on the most adopted tools.   Furthermore, “self BI” is popular with business teams, but also with IT, which is delighted to give teams autonomy.     That being said, it is a monumental project that is looming, and which rightly frightens the teams: some of our clients have more than 100,000 BO dashboards in production. The movement could be very long and excessively expensive.    With this in mind, Ellipsys has created a migration solution for the dataviz layer which relies on data from the {openAudit} solution. This functionality is at work for a major client, in association with our SAP BO layer cleaning/simplification module.    In this case, it will involve migrating thousands of SAP BO dashboards to Looker and Power BI, automating the entire process 😊.   Below are some highlights of our methodology as part of this project:     Automated analysis of the BO platform      To analyze the complexity of the reports, we rely on the different tables which are generated directly by {openAudit} after the daily analysis of the SAP BO platform.   We generally collect the following information:   In terms of dashboard intelligence The list of expressions and variables used and their level of nesting;  The list of basic BO functions used in these expressions and variables;   The sourcing (lineage) of each published element (whether directly in blocks, filters, input parameters, merged dimensions, alerters, etc.)   In terms of layout  The number of tabs, nested blocks, sections; The number and type of tables (HTable, VTable, XTable) and graphics in the layout; The list of filters in the elements.   At the source level  The number of data providers and related dimensions; The number of unpublished Data Provider objects (useless for publication); The contexts used; The list of prompts used in reports; Links between data providers, or between statements, for multi-statement data providers; The definition of personalized SQL (overload or freehand SQL).    {openAudit} will initially identify the dashboards to be migrated, the list of objects that will necessarily be migrated.   The idea is to build an optimized semantic layer in the target technology.    From this list, we determine:  The list of fields and therefore useful tables; The list of joins to connect these tables; The list of BO contexts to reproduce;   This first list will then allow us to gauge the complexity of the semantic layer to reproduce in the target: List of impacted derived tables; Nested or linked objects; Aggregate objects (aggregate_aware); Views and source SQL to modify to meet the target.     Migration (e.g. to Looker / Power BI)  Migration of dashboards and intelligence BO > Looker  : {openAudit} obviously translates all the useful intelligence of the dashboards into lookML and recreates the links between looks via intelligent filters. Each tab of a BO document becomes a Looker dashboard. Tab consistency is restored by linking them together in Looker.   BO > PowerBI  :  {openAudit}  will convert the objects in the data model tables of each dashboard and organize the data prep to reproduce the intelligence of BO documents in DAX and/or Code M. Certain optimizations are also implemented to reduce data prep. Layout migration BO > Looker  : {openAudit} will translate the BO layout into LookLM while respecting the organization of the components and then will reproduce the different tables, sections, graphs according to the existing Looker components.   BO > PowerBI  : {openAudit} converts the BO layout directly into the PBIX which will be exported to Azure. The organization of the components is also respected. The user also benefits from PowerBI's native functionalities (dynamic filters, slicers, drill, etc.) which enrich the user experience. Output specifics  BO universe dimensions and measurements will be organized the same way in Looker. The BO documents will be transformed into several dashboards in Looker: one per BO report (tab), with a menu to navigate between them. Aggregate Aware, dashboard variables and derived SQL are reproduced as is in Looker. The source database syntax is translated into the native syntax of the target DB (usually bigQuery). As the BO semantic layer cannot be completely centralized in PowerBI, the information will be transferred to a Power BI Stand-alone (PBIX) dashboard. It is also possible to reproduce the universe in an Analysis Services cube so that the Power BI dashboards can consult it live. The strategy for attacking data in PowerBI can adapt according to the level of performance and autonomy desired in the report by playing on the import or direct access of data and the merging of this data.