Migrer de SAP BO vers Looker, automatiquement

 

Migrer de SAP BO vers Looker,  en automatisant le processus, 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 Business Objects 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'œuvre 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 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 Looker Migration des univers  {openAudit} va reproduire les vues, et les Explore de Looker avec toutes les étapes intermédiaires pour déléguer la fusion des données des data providers BO dans la DB cible (via des surcharges d'explore). Les objets sont également redéfinis en champs de vues Looker et toute la classification de ces objets est reproduite dans la cible. L'intelligence "sémantique" est également convertie en lookML (objets imbriqués, agregate aware, SQL spécifiques, etc).   Migration des dashboards et de l'intelligence {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.   Migration du layout {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.   Spécificité 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).