Migration DataViz - migrer de SAP BO vers Power BI
Les patrimoines SAP BusinessObjects regroupent généralement plusieurs années de modélisation : univers, rapports Web Intelligence, objets métier, calculs, filtres, invites et couches sémantiques. La migration porte autant sur les univers, les objets métier et les règles de gestion que sur les rapports.
Les enjeux
- 10 à 20 ans d’intelligence métier accumulée dans les rapports et les univers, très difficile à reconstruire à la main.
- Risque de régression : une migration manuelle est longue et incertaine.
- Risque de non-adoption : les deux solutions coexistent trop longtemps et les utilisateurs ne basculent pas.
- Une migration qui n’en finit plus : de nouveaux rapports SAP BO se créent plus vite que les anciens ne sont migrés.
L’automatisation répond à ces quatre risques : analyser, simplifier, migrer les rapports, puis migrer la logique.
Prérequis d’analyse SAP BusinessObjects
L’analyse nécessite l’accès aux services SAP BusinessObjects, aux référentiels techniques et à la base d’audit. Les extracteurs s’exécutent dans l’environnement du Client et seules les métadonnées techniques sont exploitées, anonymisables avant traitement.
Analyse du patrimoine
L’analyse couvre les rapports Web Intelligence, les univers UNV et UNX, les Data Providers, les objets métier, les variables, les filtres, les invites et les composants graphiques. Les dépendances entre sources de données, objets métier et visualisations sont consolidées avec les usages observés dans un référentiel. Sondes et parsers couvrent trois niveaux :
- intelligence : expressions, variables, fonctions, formules et contextes de calcul des rapports Web Intelligence ;
- sources et données : Data Providers, univers (.unv / .unx), tables et dimensions associées, contextes, invites ;
- layout : onglets, blocs (tableaux, tableaux croisés, graphiques), sections, filtres.
Rationalisation
Le croisement des logs d’audit avec les métadonnées identifie rapports inutilisés, doublons, objets non consommés et univers obsolètes. Chaque rapport est qualifié selon quatre critères :
- Fiabilité : rapports en erreur, cassés ou dupliqués.
- Taille et complexité : onglets, Data Providers, variables.
- Antériorité : date de création, dernière modification, dernier rafraîchissement.
- Usage : fréquence de consultation, issue d’Auditor.
La complexité de chaque rapport est classée de 1 à 5 pour prioriser la migration.
Résultat : réduction du volume à migrer, souvent de plus de 80 %.
Conversion vers Power BI
Les Data Providers deviennent des datasets Power BI ; requêtes, calculs et variables sont convertis en SQL ou DAX ; les objets métier deviennent dimensions et mesures, avec conservation des dépendances entre univers, rapports et sources. Tableaux, graphiques, filtres, sections et mise en page sont reconstruits dans Power BI : la migration couvre la couche métier comme la couche de restitution.
Les rapports, migrés As Is : {openAudit} lit les métadonnées SAP BO et reconstruit chaque rapport Power BI (.pbix), avec un layout proche de l’original :
- onglets et blocs deviennent tableaux, tableaux croisés, graphiques et cellules, disposés comme dans l’onglet d’origine ;
- les sections SAP BO deviennent des slicers, filtres et invites des paramètres et interactions ;
- les variables sont traduites de la syntaxe BO en DAX ;
- dans le modèle sémantique, les Data Providers deviennent des dossiers et les objets gardent leur nom d’univers ;
- les rapports denses, à plusieurs blocs, conservent la même organisation.
La data prep, deux options : la logique encapsulée dans SAP BO (requêtes des Data Providers, objets, jointures et contextes des univers, variables, formules, filtres de requête, invites) est transcrite en SQL, Power Query (M) et DAX, puis déployée au choix :
- A. Dans Power BI : requêtes Power Query et mesures DAX, en Import ou en DirectQuery ;
- B. Dans {oa-lake} : pipelines SQL ouverts, portables et interopérables, sans lock-in, réutilisables par tout outil ; les objets métier des univers alimentent sa couche sémantique, à laquelle Power BI se connecte (voir ci-dessous).
Validation
Pendant la recette, SAP BusinessObjects et Power BI fonctionnent en double exécution et leurs indicateurs sont comparés.
Tables, filtres et slicers
Tables, filtres et sections SAP BusinessObjects convertis en composants Power BI.
Pie Charts
Graphiques
Dashboards
{oa-lake} : le socle de toute migration DataViz
Migrer d’un outil de reporting à un autre répond au besoin immédiat, mais déplace la logique métier dans un nouveau modèle propriétaire : au prochain changement d’outil, tout est à reconstruire.
Power BI se connecte à {oa-lake} et consomme un modèle déjà prêt : objets métier, KPI et sécurité ne sont plus enfermés dans un nouveau modèle propriétaire.
Point clé : migrer vers {oa-lake}, c’est migrer une dernière fois. La logique métier devient un actif de l’entreprise, indépendant des éditeurs.
Pourquoi {oa-lake} est le socle des migrations DataViz → · Découvrir {oa-lake} → · Interopérabilité SQL et couche sémantique →
