Migrer de SAP BO vers Power BI, automatiquement

 



 

 

Migrer de SAP BO vers Power BI, automatiquement, au forfait


SAP avait annoncé par le passé la fin de vie de SAP BO.

Finalement, la roadmap a un peu changé, puisqu’il s’agira d’aller vers SAP BusinessObjects BI 2025 (qui est pour le moment un nom de code).

 

Cependant, une liste de composants ne seront pas inclus dans la version BI 2025, dont Universe Design Tool (pour la construction des .unv), les univers multi sourcés, etc. Ces composants resteront dans la version BI 4.3, mais le support de maintenance prendra fin en 2025.  
Et le reste n’est pas forcément très clair, même si SAP annonce vouloir se concentrer sur les outils les plus adoptés.

 

Par ailleurs, la "self BI" est plébiscitée par les équipes métiers, mais aussi par l’IT qui se réjouit de donner de l’autonomie aux équipes.  

 

Cela étant dit, c’est un chantier monumental qui se profile, et qui effraie les équipes à juste titre : certains de nos clients ont plus de 100 000 dashboards BO en production. Le mouvement pourrait être très long et excessivement coûteux. 

 

Dans cette logique, Ellipsys a créé une solution de migration pour la couche de dataviz qui s'appuie sur les données de la solution {openAudit}.

Cette fonctionnalité est à l'oeuvre pour un client important, en association avec notre module de nettoyage / simplification de la couche SAP BO. 

 

Dans le cas présent, il s'agira de migrer des milliers de dashboards SAP BO vers Power BI, en automatisant la totalité du processus 😊.

 

Ci-dessous, les quelques points saillants de notre méthodologie dans le cadre de ce projet :  

 

Analyse automatisée de la plateforme BO 

 

 

Pour analyser la complexité des rapports, nous nous appuyons sur les différentes tables qui sont générées directement par {openAudit} après le parsing quotidien de la plateforme SAP BO.

 

Nous récupérons globalement les informations suivantes :

 

Au niveau de l'intelligence du dashboard

  • La liste des expressions et des variables utilisées et leur niveau d'imbrication ; 
  • La liste des fonctions BO de base utilisées dans ces expressions et ces variables ;  
  • Le sourcing (lineage) de chaque élément publié (que ce soit directement dans les blocs, les filtres, les input parameters, les merged dimensions, les alerters, etc.)

 

Au niveau du layout 

  • Le nombre d'onglets, de blocs imbriqués, de sections ;
  • Le nombre et type de tables (HTable, VTable, XTable) et de graphiques dans le layout ;
  • La liste des filtres dans les éléments.

 

Au niveau des sources 

  • Le nombre de data providers et de dimensions liées ;
  • Le nombre d'objets des Data Providers non publiés (inutiles pour la publication) ;
  • Les contextes utilisés ;
  • La liste des prompts utilisés dans les rapports ;
  • Les liens entre data providers, ou entre statements, pour les data providers multi-statements ;
  • La définition des SQL personnalisés (surcharge ou freehand SQL). 

 

{openAudit} va identifier au départ des dashboards à migrer, la liste des objets qui seront nécessairement migrés.

 

L'idée est de construire une couche sémantique optimisée dans la technologie cible. 

 

Depuis cette liste, nous déterminons : 

  • La liste des champs et donc des tables utiles ;
  • La liste des jointures pour relier ces tables ;
  • La liste des contextes BO à reproduire ;

 

Cette première liste nous permettra ensuite de jauger la complexité de la couche sémantique à reproduire dans la cible :

  • Liste des tables dérivées impactées;
  • Les objets imbriqués ou liés ;
  • Les objets agrégés (aggregate_aware) ;
  • Les vues et SQL source à modifier pour répondre à la cible.

 

 

La migration vers Power BI 


Migration des dashboards et de l'intelligence

{openAudit} va convertir les objets dans les tables du data model de chaque dashboard et organiser la data prep pour reproduire l'intelligence des documents BO en DAX et/ou Code M.

Certaines optimisations sont également mises en oeuvre pour alléger la data prep.

Migration du layout

{openAudit} convertit le layout BO directement dans le PBIX qui sera exporté dans Azure. L'organisation des composants est également respectée. L'utilisateur bénéficie en plus des fonctionnalités natives de PowerBI (filtres dynamiques, slicers, drill, etc) qui enrichissent l'expérience utilisateur.

 




Commentaires

Posts les plus consultés de ce blog

La Data Observabilité, Buzzword ou nécessité ?

BCBS 239 : L'enjeu de la fréquence et de l'exactitude du reporting de risque

Le data lineage, l’arme idéale pour la Data Loss Prevention ?