Faut-il vraiment convertir nos bons vieux univers sous SAP BI 4 ?

Déjà quelques années depuis le lancement de la suite BI 4 de SAP et l’arrivée des univers de format UNX dans nos vies. Alors que les univers de format UNV sont toujours supportés, on peut se demander quelles sont les raisons qui pourraient nous décider à convertir nos univers d’un format vers l’autre.

Bien entendu, lors de la création d’un nouvel univers, c’est facile. On utilise le nouvel outil pour tirer partie des nouvelles fonctionnalités. Mais lorsqu’on a 20, 50, 100 univers ou plus, quels univers convertir ou non ? Lesquels convertir maintenant et lesquels peuvent encore attendre.

Raisons pour convertir

Il n’y a pas de liste exhaustive qui permet d’identifier les univers à convertir rapidement et absolument. Par contre, il y a quelques éléments qui sont à considérer.

Premièrement, valider quels sont les outils de la suite qui supportent le format UNX, mais qui ne supportent pas le format UNV. Par exemple, Crystal Report Enterprise n’utilise que les univers en format UNX. Si vous désirez utiliser cet outil, vous devrez aller de l’avant avec la conversion de vos univers.

Également, les univers liés ne sont plus supportés dans le format UNX, mais ils peuvent être convertis. C’est donc une bonne idée de le faire rapidement. Un univers dérivé lié à un ou plusieurs univers « core », intégrera l’ensemble de ceux-ci.

Suite à la conversion de chacun de vos univers, prenez le temps d’actualiser la structure et de vérifier l’intégrité de l’ensemble des éléments. Pour finir, chacun des documents associés à l’univers original devra être modifiés pour s’assurer qu’ils utilisent le nouvel univers. Ceci générera des coûts qu’il ne faut pas sous-estimer.

Raisons pour reconstruire

Dans certains cas, les univers ne peuvent même pas être convertis, car ils contiennent des éléments qui ne sont pas supportés par le nouveau format. Par exemple, les univers ayant comme source des procédures stockées (ou stored procs) ne pourront pas être migrés, il faudra les reconstruire complètement.

Dans le cas des univers OLAP, ceux-ci ne peuvent être convertis et pour profiter au maximum des nouvelles fonctionnalités (univers généré automatiquement à partir de la structure du cube), ce sera une bonne idée de les reconstruire également.

Une autre raison de reconstruire un univers, c’est la possibilité d’utiliser les univers multi-sources, alors que l’univers original n’est que simple source. Pour finir, prenez le temps d’analyser vos univers pour voir s’il y en a qui sont de piètre qualité. Le temps est peut-être venu d’investir un peu pour les améliorer et du même coup, revoir les modèles de données sous-jacents.

Univers simple ou multi-sources

Une fois qu’on a décidé de reconstruire un univers, la première question qu’on se posera, c’est : « Doit-il être multi-sources ? ».

Sans prendre la décision à votre place, voici qui pourra peut-être vous aider. Une fois le choix fait, plus possible de revenir en arrière. Un univers simple-source le restera toujours. Aussi, alors qu’un univers simple-source produira un SQL optimisé selon la base de données sous-jacente, un univers multi-sources produira de simples énoncés SQL répondants au standard ANSI-92. Ceci exige un peu plus de travail lors du développement et pourrait mener éventuellement à des problèmes de performance. Donc, ne choisissez pas de concevoir un univers multi-sources sans réellement en avoir besoin ou encore pire, « au cas où » !

En conclusion

En bout de ligne, ce que vous ferez avec vos univers ne doit pas être décidé à la légère. Chaque univers doit être analysé afin de déterminer s’il devra être converti, reconstruit ou conservé tel quel et pendant combien de temps. Intégrer le tout dans un plan de migration ou une feuille de route stratégique peut vous aider à planifier ces conversions et l’ensemble des efforts qui en découleront.