Migration DataViz - migrer de SAP BO vers GCP Looker
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.
{openAudit} analyse ces composants afin de reconstruire les dépendances entre les sources de données, les univers, les rapports et les usages observés.
Point clé : les univers et les objets métier constituent généralement la principale source d’information pour reconstruire le modèle cible.
Prérequis d’analyse SAP BusinessObjects
L’analyse repose sur l’accès aux services SAP BusinessObjects, aux référentiels techniques et à la base d’audit.
Les extracteurs sont exécutés dans l’environnement du Client. Les métadonnées collectées peuvent être anonymisées avant traitement.
Bon à savoir : seules les métadonnées techniques sont exploitées.
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 techniques et les usages observés sont consolidés dans un référentiel.
Rationalisation
Les logs d’audit sont croisés avec les métadonnées de la plateforme.
Les rapports inutilisés ou cassés, les rapports répliqués, les objets non consommés, les univers obsolètes, etc. sont identifiés avant migration.
Résultat : réduction massive du volume à migrer.
Conversion vers Looker
Les Data Providers, les objets métier et les requêtes sont convertis vers les composants Looker.
Les dimensions, mesures, jointures et calculs sont reconstruits dans les modèles LookML.
Les dashboards, filtres, prompts, tableaux, graphiques et mécanismes de navigation sont reconstruits à partir des rapports SAP BusinessObjects.
L’organisation fonctionnelle des univers est reprise dans les dossiers, Explores et catalogues métier de la plateforme cible.
La conversion s’appuie sur {oa-lake} : les requêtes, calculs et variables sont encapsulés sous forme de pipelines SQL, et les objets métier des univers alimentent la couche sémantique interopérable d’{oa-lake}. Looker se connecte à ce modèle prêt à l’emploi (voir ci-dessous).
Point clé : les objets fonctionnels et les composants de restitution sont reconstruits à partir des univers et rapports SAP BusinessObjects.
Validation
Les migrations peuvent être réalisées en double exécution SAP BusinessObjects / Looker.
Les indicateurs produits par les deux plateformes sont comparés pendant les phases de recette.
Prompts SAP BusinessObjects
Les invites SAP BusinessObjects sont converties vers les filtres natifs de Looker.
Les listes de valeurs et paramètres de saisie sont conservés.
Objets métier et modèles LookML
Les requêtes, objets métier, dimensions, mesures et jointures sont convertis vers les composants LookML.
Structure fonctionnelle
L’organisation des univers est reconstruite sous forme d’Explores, de dimensions et de mesures.
Pivots et analyses matricielles
Les tableaux croisés et analyses multidimensionnelles sont convertis vers les mécanismes de pivot de Looker.
Graphiques
Les courbes et analyses comparatives sont reconstruites à partir des indicateurs identifiés dans les rapports.
Bar charts
Les bar charts sont adaptés aux composants de visualisation Looker.
Pie charts
Les pie charts sont convertis vers les visualisations natives de Looker.
{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.
C’est pourquoi chaque migration DataViz s’appuie désormais sur le middleware {oa-lake}, qui joue deux rôles :
- Encapsuler l’intelligence. Les requêtes, calculs, variables et règles métier extraits par {openAudit} sont transcrits en SQL et exécutés dans {oa-lake} sous forme de mini pipelines SQL (un mini ETL), au lieu d’être réécrits dans l’outil cible.
- Préserver la couche sémantique. La couche sémantique construite au fil des années dans la plateforme source (univers, Frameworks, modèles) est reconstituée dans la couche sémantique interopérable d’{oa-lake}, qui alimente ensuite l’outil cible.
Looker 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.
- Définir une fois, utiliser partout : client, contrat, produit… une seule définition, valable pour tous les outils consommateurs.
- KPI et sécurité centralisés : des indicateurs calculés une seule fois et une sécurité appliquée uniformément, quel que soit l’outil de restitution.
- Data prep rationalisée : des mini pipelines SQL mutualisés remplacent la préparation dispersée dans chaque outil.
- Outils BI interchangeables : Power BI, Looker, DigDash ou tout autre outil se connecte à un modèle déjà prêt, sans redéfinir la logique métier.
- Piloté comme du code : pipelines SQL et modèle sémantique en YAML/JSON, versionnés dans Git et déployés par Terraform.
- Prêt pour l’IA : les mêmes données et la même sémantique alimentent la BI, les LLM et les agents IA.
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.
Découvrir {oa-lake} → · Interopérabilité SQL et couche sémantique →
