Convertir vos univers .unv en .unx : le guide pragmatique

Si vous exploitez encore des univers .unv dans votre environnement SAP BusinessObjects, vous avez probablement déjà vu passer l’information : la version BI 2025 ne les supporte plus. Seuls les univers .unx, créés ou convertis avec Information Design Tool, sont acceptés. C’est une échéance réelle, et elle est plus proche qu’on ne le pense.

Cet article est un retour d’expérience concret sur la conversion d’univers .unv vers .unx. Pas de théorie générale — des problèmes réels et des solutions testées.

Pourquoi la conversion n’est pas un simple clic

SAP fournit un outil de conversion intégré dans Information Design Tool (IDT). En théorie, il suffit d’importer un .unv et IDT génère un .unx équivalent. En pratique, cet outil fonctionne correctement pour les univers simples (mono-source, jointures standards, objets calculés basiques). Dès que la complexité augmente, les problèmes s’accumulent.

Les contextes et alias sont le premier point de friction. Dans Universe Design Tool, les contextes résolvent les boucles dans le schéma de la base de données. IDT a une approche différente des contextes et la conversion automatique ne les transpose pas toujours correctement — surtout quand un univers utilise des alias sur des alias, ou quand les contextes sont imbriqués. Le résultat est un univers .unx qui compile sans erreur mais qui produit des requêtes SQL différentes, avec des résultats potentiellement faux.

Les objets calculés avec des fonctions @ (comme @Select, @Where, @Variable) sont le deuxième problème. Ces fonctions propres à l’écosystème .unv n’ont pas toujours d’équivalent direct en .unx. La conversion les traduit en syntaxe IDT, mais la logique sous-jacente peut être altérée — en particulier les @Variable qui référencent des LOV (listes de valeurs) ou des filtres prédéfinis.

Enfin, les univers multi-sources (data federations) nécessitent un traitement spécifique. Un univers .unv est par définition mono-connexion. Si vous avez des univers qui combinent des données de plusieurs sources via des liens, la conversion vers .unx doit repenser l’architecture de la connexion en utilisant les data foundations multi-sources d’IDT.

La méthode qui fonctionne : par lots, avec validation croisée

L’approche que nous recommandons repose sur trois principes. D’abord, ne jamais convertir tous les univers en une seule fois. On procède par lots de 5 à 10 univers, en commençant par les plus simples (mono-source, peu d’objets calculés) pour monter en gamme.

Ensuite, chaque univers converti est validé par comparaison de requêtes. On identifie les 5 à 10 rapports WebI les plus utilisés qui consomment cet univers. On exécute ces rapports sur le .unv original et sur le .unx converti, et on compare les résultats. Toute différence — même d’une seule ligne — déclenche une investigation avant de passer à la suite.

Enfin, les rapports WebI doivent être repointés en masse vers les nouveaux univers .unx. SAP fournit une API pour cela, mais des outils comme Wiiisdom 360View ou BI Platform Support Tool (BPST) le font de manière plus fiable, avec des fonctions de rollback. Le repointing peut être réalisé par lots sur des week-ends pour éviter tout impact sur les utilisateurs.

Le calendrier réaliste

Pour un environnement de taille moyenne (30 à 50 univers, 500 à 1 000 rapports WebI), la conversion complète prend typiquement 3 à 5 mois en parallèle de la production. Ce calendrier inclut la conversion proprement dite, la validation par comparaison, le repointing des rapports, et les correctifs post-migration. Ce n’est pas un projet à temps plein — c’est généralement réalisé par un consultant à mi-temps ou intégré dans le contrat TMA.

La leçon clé : ne pas attendre le jour de la migration vers BI 2025 pour découvrir les problèmes de conversion. Lancez le chantier au moins 6 mois avant toute mise à jour de version majeure.