Si vous envisagez de quitter SAP BO.... l'automatisation est possible

 

Si vous envisagez de quitter SAP BO ... 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 Looker et 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 (ex : vers Looker / Power BI)  Migration des dashboards et de l'intelligence BO > Looker : {openAudit} traduit bien évidemment toute l'intelligence utile des dashboards en lookML et recrée les liens entre les looks via des filtres intelligents. Chaque onglet d'un document BO devient un dashboard Looker. La cohérence des onglets est rétablie en les liant entre eux dans Looker.   BO > PowerBI : {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 BO > Looker : {openAudit} va traduire le layout BO en LookLM en respectant l'organisation des composants puis va reproduire les différentes tables, sections, graphes selon les composants existant de Looker.   BO > PowerBI : {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. Spécificités de l'output  Les dimensions et les mesures des univers BO seront organisées de la même manière dans Looker. Les documents BO seront transformés en plusieurs dashboards dans Looker : un par rapport BO (onglet), avec un menu pour naviguer entre eux. Les Aggregate Aware, les variables du dashboard et le SQL dérivé sont reproduits tels quels dans Looker. La syntaxe de la base de données en source est traduite en syntaxe native de la DB cible (généralement bigQuery). La couche sémantique BO ne pouvant être complètement centralisée dans PowerBI, les informations seront commuées en dashboard Power BI Stand-alone (PBIX). Il est aussi possible de reproduire l’univers en cube Analysis Services pour que les dashboards Power BI le consultent en direct. La stratégie pour attaquer les données dans PowerBI peut s'adapter en fonction du niveau de performance et d'autonomie souhaité dans le rapport en jouant sur l'import ou l'accès direct des données et la fusion de ces données.