C'est quoi vos besoins plus précisement?

Faire une surcouche Univers à un cube OLAP c'est pas forcément ni très simple, ni très facile à maintenir.

Nous utilisons aujourd'hui BO.
Demain, nous aurons probablement un module BI 'tout fourni' avec un Dataware qui alimente un cube MSOLAP.
L'outil de reporting de Microsoft Reporting Services n'étant pas orienté utilisateurs, et pas pratique pour des rapports complexes, nous nous sommes dit que BO, utilisé aujourd'hui répond mieux à nos attentes.

2 scénarios possibles :
¤ pluggé BO sur le DW (qui est fait pour alimenter le cube et non pour la lecture directe dessus)
=> perte du cube MSOLAP, construction des univers, impact sur temps de réponse des requêtes

¤ pluggé BO directement sur le cube (hors Voyager qui n'est trop limitatif pour nos besoins)
=> et dans ce cas, je souhaiterai avoir des retours d'expériences sur le sujet. Est-ce que c'est lour à mettre en place, est-ce que c'est limitatif ? Connaissez-vous des entreprises qui l'ont fait ? Qu'en pensent-ils ? etc.

Merci d'avance ;-) En espérant avoir été claire sur la démarche de ma question !

j'ajoute que si c'est pour faire du WEBI les univers multidim sur la base de SSAS fonctionnent bien sur laXI/R3 , par contre sur les versions antérieures XIR1/R2 cette fonctionnalitée n'est pas présente. donc pas besoin d'aller chercher un autre produit vous avez tout ce qu'il vous faut.

Je voulais dire BO XI R3.1 en webi ou webi (client lourd !) ;-)

J'ai même implémenté une telle surcouche pour un client.

L'ennui c'est que tout moteur de génération SQL dynamique de type 'couche' y compris les Univers BO doivent implémenter des stratégies. Si pour les bases de données rélationnelles, cette implémentation est pluttot facile, pour les multi-dim c'est tout le contraire, l'Univers aura un mal de chien à 'avaler' le MDX proprement. De plus , sauf erreur de ma part, il n'y a aucune recupération 100% automatique des dimensions, mesures etc. donc vous devez recréer des 'hiérarchies' etc dans l'organisation de l'univers.

Implicitement, si vous changez des choses dans les données source , il faut modifier le cube , ensuite l'univers , ensuite tout ce qui est basé dessus.

Finalement , la fin de ce projet c'est que certains se connectaient en direct via Excel vers le Cube afin de recupérer certaines modifications non-encore impactées dans l'univers , et une bataille de 'qui a le bon chiffre' est ressurgie.

Trop de données tue la donnée. C'est valable pour les métadonnées aussi et cubes OLAP ou couches sémantiques, le problème est le même. Mettre trop de tiers entre la donnée source et le rapport cible multiplie la maintenance, les risques d'erreurs etc.

@Marie

Nous avons aussi tenté d'acceder aux données du cube MS avec l'outil BO (Voyager) mais sans succès véritable (les temps de réponse étaient déplorables). On a aussi envisager la solution de l'univers pointant directement sur la source OLAP mais là, Stefan a déjà bien expliqué l'inadéquation de la solution. Que faire alors si l'on veut réellement acceder aux données du cube MS OLAP ?

==> Utiliser un client OLAP tiers : je vous recommande d'aller sur le site ssas-info.com (section client OLAP) qui vous donnera une vue assez complète de ce que l'on peut utiliser.

==> Utiliser Excel et les addin : Je parle de la version 2007 (dans les versions antérieures, c'était moins convivial). Là encore sur le web, je vous conseille les articles de R. Harduin
sur http://bi-art.over-blog.com/

==> Utiliser Microsoft Office Web Component : même si c'est un peu basique, ça a le mérite d'être gratuit et de s'utiliser facilement. En gros, cela vous offre un objet type Pivot Table amélioré.

==> Pour finir, SAP Business Objects annonce un nouveau produit en remplacement de Voyager mais il faudra patienter car la sortie n'est pas prévue avant 2010.