Ce qui a changé entre BI 4.3 et BI 2025
Si vous utilisez le SQL à la carte (Free Hand SQL) dans Web Intelligence, vous allez remarquer un changement d’interface en passant à BI 2025. Et il ne s’agit pas d’un simple déplacement cosmétique.
Jusqu’en BI 4.3 SP4, l’éditeur de SQL à la carte se trouvait directement dans l’éditeur de requête.
On modifiait le script SQL, on validait, les objets du rapport restaient intacts. Les dimensions qu’on avait converties en indicateurs, les méthodes d’agrégation personnalisées, tout ça survivait aux modifications du SQL. Le comportement était prévisible.
À partir de BI 4.3 SP5 et dans BI 2025, SAP a déplacé l’accès à l’éditeur SQL à la carte. Pour modifier la requête, il faut maintenant passer par le menu « Modifier la source ».
Le problème concret
Le menu « Modifier la source » n’a pas été conçu pour ça. Son workflow est celui d’un changement de source de données, pas d’une simple édition de requête. Et ce workflow embarque un effet de bord que l’ancien emplacement n’avait pas : il réinitialise la personnalisation des objets du rapport.
En pratique, ça veut dire qu’à chaque fois que vous modifiez votre SQL à la carte, toutes les personnalisations que vous aviez faites sur vos indicateurs et vos dimensions sont perdues. Si vous aviez changé la méthode d’agrégation d’un indicateur (passage d’une somme à une moyenne, par exemple), il faut le refaire.
Si vous aviez transformé une dimension en indicateur pour un usage spécifique dans le rapport, c’est perdu aussi.
Sur un rapport simple avec deux ou trois objets, c’est agaçant. Sur un rapport complexe avec des dizaines d’indicateurs personnalisés, c’est un vrai problème de productivité. Chaque modification du SQL devient une opération à risque où il faut noter tous les paramètres avant de toucher à quoi que ce soit, puis tout reconfigurer après.
Effet de bord ou choix de conception ?
Difficile de trancher. Le déplacement de l’éditeur SQL vers le menu « Modifier la source » ressemble à une conséquence non anticipée d’un refactoring d’interface plutôt qu’à une décision volontaire de SAP. Le fait que le comportement ait fonctionné correctement pendant toute la durée de vie de BI 4.3 (jusqu’au SP4 inclus) renforce cette hypothèse.
Plusieurs utilisateurs ont déjà remonté le problème à SAP. Le canal officiel pour signaler cette régression et pousser SAP à la corriger est SAP Influence. Si vous êtes concerné, voter sur la demande existante est le moyen le plus efficace de faire bouger les choses : lien vers la demande SAP Influence.
Ce que ça implique pour vos projets de migration
Si vous préparez une migration de BI 4.3 vers BI 2025 et que vos rapports Web Intelligence utilisent du SQL à la carte, ce point mérite d’être identifié en amont. Ce n’est pas un bloquant de migration, mais c’est le genre de régression qui génère de la friction quotidienne pour les utilisateurs une fois en production. Mieux vaut le savoir avant et adapter vos procédures de recette plutôt que de le découvrir quand un utilisateur appelle le support pour signaler que son rapport « ne fonctionne plus comme avant ».
Deux précautions à prendre : d’abord, inventorier les rapports Webi qui utilisent le SQL à la carte avant la migration. Ensuite, documenter les personnalisations d’indicateurs et de dimensions sur ces rapports pour pouvoir les restaurer si nécessaire après passage en BI 2025.
Nos consultants SAP BusinessObjects accompagnent régulièrement des migrations BI 4.3 vers BI 2025 et connaissent ce type de pièges. Si vous voulez anticiper plutôt que subir :
