Migrate from SAP BO to Looker, automatically

 

Migrate from SAP BO to Looker,  by automating the process, on a fixed price basis

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 by 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.     Migrating to Looker

Migration of universes  {openAudit} will reproduce the views and Explores from Looker with all the intermediate steps to delegate the merging of data from BO data providers into the target DB (via explore overloads). The objects are also redefined in Looker view fields and the entire classification of these objects is reproduced in the target. “Semantic” intelligence is also converted into lookML (nested objects, aggregate aware, specific SQL, etc.).

Migration of dashboards and intelligence {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.

Layout migration {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.

Specificity of the output in 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).