SAP Business Information Consulting

Nous avons vu il y a quelques mois une première approche sur le design des cubes (cf article)

Interessons nous maintenant aux requêtes.

Le design des requêtes est une source fréquente de non performance... et bonne nouvelle, c'est aussi le plus facile à améliorer.

Voici quelques règles générales a appliquer :

1 - ne montrez que ce qui est necessaire. D'un point de vu performance, l'adage 'qui peut le plus, peut le moins' est une catastrophe.

Pour ce faire, utiliser au maximum les variables et les sélections en début de requête. Evitez autant que possible les exclusions, qui sont très pénalisantes.

2 - commencez par une vue aggrégée.

un risque fréquent lorsque l'on met en place un outil de BI, est la bonne vieille habitude des utilisateurs des listings... Beaucoup de gens sont convaincus qu'il ne peuvent pas bosser sans la liste des commandes sur 37 pages !

C'est ici qu'intervient le rôle de conseil du consultant. Faire de la BI, ce n'est pas lister les commandes (ou autre), c'est analyser de manière dynamique les données...

Il convient d'utiliser les possibiliter de drill down, d'alertes... afin d'avoir une vision claire des données (quitte à descendre au niveau de détail pour une sélection restrainte) et d'amener les utilisateur à cette nouvelle manière de travailler.

3 - utilisez 0INFOPROVIDER pour filtrer.

Nous avons vu dans notre article précédent qu'il était judicieux de toujours utiliser des multiproviders. Cependant, dans certain cas, une requêtes ne va utiliser qu'un nombre restreint de providers. Il convient alors de signaler ces cubes dans une selection sur l'objet 0INFOPROVIDER, de manière à ce que le système n'aille lire que les providers utiles.

4 - utilisez les statistiques BW

L'optimisation des requêtes doit êtres sélective, il n'est pas très utile d'optimiser une requête peu utilisée, alors qu'un gain de temps sur une requête lancée plusieurs dizaine de fois par jour sera indispensable.

Pour se faire, regardez les statistiques, surveillez l'utilisation des espaces, discutez avec les users.

5 - utilisez les aggrégats et maintenez les !

Un aggrégat est un très bon accélerateur de requête. Cependant, un système BI est un système vivant, qui évolue avec les besoins de l'entreprise et son de marché.

Par conséquent, vérifiez régulièrement que vos aggrégats répondent toujours aux besoins et qu'ils sont utiles. Remplacez les par des nouveaux si nécessaire.

****

Bien sûr, chaque cas est un peu particulier et demande une réponse adaptée, surtout dans le domaine de l'optimisation... mais ces quelques points vous aideront à vous faire une idée sur votre solution.

Si vous avez des questions, ou si vous souhaitez que nous procédions à un audit plus complet de votre solution, n'hésitez pas à nous contacter.

Plus d'infos sur notre site

Mail

Il y a quelques jours, SAP jetait le pavé dans la marre en chageant sa stratégie pour acheter Business Objects. Evidemment, beaucoup d'interrogations peuvent se poser sur les avantages et incovénients d'un tel rachat, ainsi que ses conséquences malheureuses.

SAP a promis d'en dire plus après que la fusion soit effective. Néanmoins, on sait déjà que BO serait une entité "indépendante" dans le groupe, au moins pour assurer la maintenance de ses produits existants, tel que son dernier BO XI.

Ce rachat n'est pas anodin et a plusieurs objectifs :

- se renforcer et accélérer le développement des outils analytiques et autres CPM
en effet, le transactionnel étant moins à la mode, SAP cherche à s'imposer comme un des leaders des outils nouvelles générations - se positionner sur le marché de la PME en offrant une version de BO accompagné de son dernier outil destiné au PME : SAP Business ByDesign.

- et bien sûr converger les carnets clients pour essayer d'imposer SAP aux entreprises qui ne l'auraient pas encore

Alors qu'est ce qu'il faut attendre des prochains mois ? Qu'est ce que SAP va faire des SAP BW (Netweaver BI), Integrated Planning, Outlooksoft, BO XI, Crystal reports, Acta et Cartesis ? (tous quasiment indépendants et pas encore vraiment compatibles à 100%)

La tâche de SAP sera difficile pour organiser son offre logicielle et nécessitera de longs mois afin de définir une stratégie et sa roadmap associée.

Il est à parier qu'il va y avoir de nombreux changements. La politique de SAP a toujours été de vendre sa plateforme d'intégration Netweaver. On peut sans doute deviner dans quelques années une fusion BW/BO avec le meilleur de chaque monde incluant l'intégration des dernières acquisitions. De même, SAP ne se séparera pas des clients BO non SAP. Il y aura un BW/BO spécial sans SAP.

En attendant, les applications actuelles ne devraient pas être obsolètes (en parlant de BW et BO XI). Le gain pour les 2 clientèles devrait être notable puisque l'on devrait assister à une meilleure convergence des 2 univers. Évidemment, on peut parier que SAP offrira une migration moins douloureuse dans le futur que si ses clients (BO et SAP) utilisent les dernières versions de chaque monde.

Et bien sûr vous avez tous fait récemment la difficile migration vers BO XI ou Netweaver 7.0 !

Bien sûr, tout cela n'est qu'un pari et reste le chemin le plus logique vers la consolidation des applications de Business Intelligence.

Alors attendons la prochaine roadmap SAP. De toute façon, vous n'avez pas encore tous forcément besoin, aujourd'hui, d'outils de CPM complètement intégrés avec la BI et tous les gadgets qui s'en accompagnent.

Et rappelons qu'il y a beaucoup de chances qu'il faille attendre quelques années avant de voir tout ça, donc la vie continue !

Comme SAP nous a habitué par le passé, les noms des versions pour les produits varient au grés des inspirations et des stratégies marketing, et il n'est pas toujours facile de s'y retrouver...
alors, SAP NetWeaver 2004s, SAP NetWeaver 7.0 (2004s), ou SAP NetWeaver 7.0 ?

et bien, le nom est SAP NetWeaver 7.0 et c'est officiel depuis mars 2007.

Petit résumé :
- cette version est née sous le nom SAP NetWeaver 2004s et contenait la version connue sous le n° 7.0 de BW (qui succède à la 3.5) - ramp up en oct 2005 et lancement officiel en juin 2006.
- Puis nous avons vu progressivement le nom évoluer vers SAP NetWeaver 7.0 (2004s). Il faut bien dire que comme le marché avait identifié le BW comme la version 7.0, le numéro 2004s avait un peu de mal à être mémorisé.
- En mars 2007, SAP a annoncé le nouveau patronyme de sa version et l'abandon des années dans les noms de versions

Pour rappel, Netweaver 7.0 contient :
- SAP Business Warehouse (BW),
- SAP Enterprise Portal (EP),
- Web Application Server (WAS),
- SAP Process Integration (XI, or eXchange Infrastructure)
- Master Data Management (MDM).

PS : juste pour le plaisir, mySAP ERP 2005 a changé de nom et est maintenant dénommée SAP ERP 6.0

Quelques petits trucs pour auditer - et améliorer en conséquence votre solution BW

1 - les cubes :

Pour les cubes, c'est assez simple : Exécuter le prog. SAP_INFOCUBE_DESIGNS sur votre système de production.

Ce programme bien utile, liste pour chaque cube un résultat de ce genre :

Mon_Cube rows: 3.027.600 density: 0,0 %

Mon_Cube /BIC/DMon_Cube1 rows: 38.417 ratio: 1 %

Mon_Cube /BIC/DMon_Cube6 rows: 522.950 ratio: 17 % ...

Mon_Cube /BIC/EMon_Cube rows: 0 ratio: 0 %

Mon_Cube /BIC/FMon_Cube rows: 3.027.600 ratio: 100 %

En orange : le nombre de lignes du cube. Ce nombre doit rester raisonnable. De manière générale, si on dépasse 20 millions de lignes, il est conseillé de couper le cube et de faire un multi-cube.

En Bleu : Pour chaque dimension, le nombre de lignes et le ratio dimension / table des faits. Attention, si ce chiffre dépasse 10%, vos performances diminueront... Il est peut être alors utile de regarder comment mieux définir les dimensions.

Que faire si le résultat n'est pas très bon ?

La réorganisation des dimensions ne peut se faire que sur un cube vide... première étape, si ce n'est déjà fait, créer un multi-provider et y transférer vos requêtes.

Ensuite, vous pourrez créer un second cube optimisé, le charger et faire un échange entre l'ancien et le nouveau cube au sein de votre multi-provider 'ni vu, ni connu'...

En Mauve : Les tables des faits E et F (la table F est la table classique, la table E est la table compressée).

Si votre table E est à 0 ligne, mettez en place la compression... vous gagnerez du temps !

****

Bien sûr, chaque cas est un peu particulier et demande une réponse adaptée, surtout dans le domaine de l'optimisation... mais ce petit test peut vous permettre de vous faire une idée du bon design de vos cubes.

Si vous avez des questions, ou si vous souhaitez que nous procédions à un audit plus complet de votre solution, n'hésitez pas à nous contacter.

Plus d'infos sur notre site

Pour ceux qui veulent faire des applications BIIP sous Excel, la façon de faire est à première vue assez déconcertante. D'abord on crée la requête avec le Query Designer (comme pour le Web) et ensuite, on ouvre cette requête sous Excel pour rajouter les fonctions. Or, quand on ouvre la requête sous Excel, on obtient....le résultat de la requête - ce qui n'est pas du tout pareil que le développement Web, où on obtient dans le WAD un gros carré.

Une fois la requête à l'écran, il suffit de passer en mode dessin pour rajouter les fonctionnalités (boutons de lancement de fonctions BIIP, par exemple).

Par exemple, on peut afficher le résultat d'une requête BEx. Cette requête va occuper les cellules A10 à F15. A côté de la requête (H12, par exemple), on peut placer un bouton, qui va lancer une séquence de planification. Cette séquence agissant sur les données affichées par la requête, le résultat est visible immédiatement.

Une des grosses différences entre le mode Web et le mode Excel est la gestion de la saisie utilisateur.

Par exemple, dans la séquence de planification, nous avons deux fonctions (COPY, puis DELETE). Dans la fonction COPY, nous voulons copier les données affichées (de 2007), vers une autre année, à saisir par l'utilisateur.
En Web, ceci se fait naturellement - dès qu'on lance la séquence de planification, le système "voit" qu'il faut demander à l'utilisateur une valeur de variable, et affiche un popup dans ce sens.
En mode Excel, c'est différent. Il faut indiquer à SAP où BIIP peut trouver la valeur requise par la variable, sur la feuille. Ceci doit avoir un format bien spécifique, format qui n'est pas très ergonomique pour les utilisateurs. Il peut être intéressant donc de dire à SAP d'aller chercher les valeurs dans des cellules loin de la partie 'utilisateur' de la feuille, ou bien dans des colonnes qui seront ensuite cachées. Ces zones réservées peuvent reprendre leurs valeurs dans les zones utilisateur.
On peut donc dire à SAP de prendre ses valeurs dans les cellules A1000 à C1001, et que la valeur de la cellule C1001 est en fait une référence à la cellule B15:

	A	B	C
1000	VAR_NAME	0	DEST_YEAR
1001	VAR_VALUE	0	=B15

Ceci est donc assez simple pour entrer une année, mais si l'on voulait que l'utilisateur saisisse une valeur de 0CALMONTH. SAP s'attend à recevoir la valeur en format INTERNE (soit 200705) et non format EXTERNE (05.2007). On ne peut pas demander à l'utilisateur de saisir la valeur en format interne (pas très ergonomique), mais on peut utiliser les fonctions standards d'Excel pour reformater sa saisie (notamment les fonctions concaténer, gauche, droite, etc). Ceci nous donnerait, dans la cellule C1001 ci-dessus, une entrée de

=concatener(droite(b15;4);gauche(b15;2))

A suivre...

De nombreuses possibilités sont offertes pour améliorer les performances d’une solution BW (Datawarehouse et requêtes). De l’optimisation à l’utilisation des fonctionnalités, le panel de possibilités est assez large.

Intéressons nous aux requêtes BW avant d’acheter des solutions de type BI Accelerator !

Vos requêtes sont longues à exécuter et vous ne savez pas comment et quoi faire pour diminuer les temps d’exécution.

1) Une requête web va plus vite qu’une requête Excel

En effet, une partie du calcul de l’affichage se fait sur Excel alors qu’en mode Web, le serveur prend la totalité des calculs.

2) Plus il y a d’éléments à afficher et plus c’est long !

C’est normal, entre une requête agrégée et une requête de type liste et détails, BW va mettre plus de temps. En cause : la lecture des différentes tables du schéma en étoile et le temps d’affichage des données. Pour expliquer le fonctionnement, lorsque vous exécutez une requête, BW va créer un fichier texte de l’ordre de quelques kilo octets lisibles l’outil de requêtage. Le temps sera bien plus long lorsqu’une liste de détails sera demandée. D’où la sempiternelle réflexion qui est : BW n’est pas optimisé pour faire de l’affichage de liste.

3) Le cache

Avez-vous déjà remarqué qu’une requête va plus vite à s’exécuter lorsque cela a déjà été fait une fois ? BW gère une mémoire cache en conservant les résultats de la dernière exécution lorsque bien sûr les informations n’ont pas été modifiées par un nouveau chargement. En version 2004s, il y a même la possibilité de gérer des caches delta. Pour obtenir les options, transaction RSRT, puis propriétés. Suivant la configuration de la taille de la mémoire cache, il y a plusieurs options :

- pas de cache Pour versions 3.x, si vous effectuez des chargements fréquents (ex 1 fois par heure), il vaut mieux désactiver le cache. - cache sans swap Lorsque le cache est plein, certaines informations sont retirées du cache par un algorithme particulier. Pour accéder aux informations supprimées, BW doit réalimenter le cache. - cache avec swap Lorsque le cache est plein, certaines informations sont sauvegardées dans un fichier et peuvent être rappelées ultérieurement.

- cache persistent Les informations de requêtes sont stockées dans une base de données ou un fichier.

- cross application cache persistent Les informations sont stockées sur un fichier dans le réseau informatique.

Ces 2 dernières options sont à considérer lorsque vous utilisez notamment plusieurs serveurs d’applications.

Bien sûr, il est possible d’industrialiser le lancement des requêtes pour que les utilisateurs aient accès directement aux données disponibles dans le cache soit via par le pré calcul de requêtes, soit par le broadcast.

4) Les modes de lecture

Dans la même lignée, on peut aussi modifier le volume de lecture des informations. Toujours dans la même transaction, il est possible de :

- Lire la totalité des informations relatives à une requête - Recalculer les informations à la navigation - Recalculer les informations au changement d’un nœud de hiérarchie

5) L’ordre des modes de lecture

Evidemment BW ne va pas utiliser toutes ces options à la fois. Il existe un ordre prédéfini d’ « essai » d’utilisation des options :

- Lecture du cache - BI Accelerator - Recalcul de la requête depuis un agrégat - Recalcul de la requête

Le constat est que dans un cadre BI 2004S, BI Accelerator n’est pas systématiquement la meilleure solution au niveau de l’optimisation et des coûts !

Une bonne optimisation du cache peut déjà permettre de faire des gains substantiels en temps de calcul des requêtes.

6) Création de requêtes sur un multiprovider

Lorsque vous faites une requête sur un multi-cube, BW va tenter de lire parallèlement les différentes sources.

Evidemment pour que ça aille plus vite, il serait sympathique d’aider BW pour qu’il trouve le chemin plus facilement en :

- rajoutant de manière explicite le nom du cube où est présent l’information - rajoutant via un user exit la manière de retrouver le cube où est présent l’information

N’oubliez pas que BW lance en parallèle la lecture des différentes informations mais lorsque c’est trop long, il abandonne et lance séquentiellement la lecture. Il est donc, évident qu’il faut désactiver la lecture parallèle lorsque le calcul est trop long. Petit test simple, voir comment se lit une requête à l’exécution via la gestion des processus dans SM50.

Il existe bien des moyens pour optimiser le calcul des requêtes. Malheureusement, cela restera toujours long si la partie datawarehouse est mal paramétrée et d’autres solutions peuvent alors intervenir : redimensionnement des cubes, partitionnement des cubes, découpage des cubes par pays jusqu’à la refonte de vos requêtes.

Evidemment, lorsque vous n’avez plus de solutions du tout et que vous êtes en 2004s, vous avez toujours la possibilité d’acheter un serveur dédié avec la solution BI-Accelerator. Son fonctionnement est quasi identique au mode cache, si ce n’est à la différence qu’il utilise un arbre de recherche de type TREX pour ranger les fichiers issus du calcul. Malheureusement, son coût n’est pas à la portée de toutes les bourses.

Si vous avez des questions ou besoin de conseils, n’hésitez pas à faire appel à Censio pour un audit rapide de vos solutions SAP BI.

Pour plus d'informations, http://www.censio.fr

Beaucoup d’interrogations se posent pour une montée de version vers BI 7.0. En effet, les fonctionnalités décrites par l’éditeur sont plutôt alléchantes : outils de reporting désormais fonctionnels, fonctions d’éditions et intégration web, BIIP, Webdynpro….

Il faut tout de même avant de se lancer dans une telle opération, se poser la question des pré-requis et des impacts de la montée de version. Et ce sont aussi également les questions que vous devez certainement vous poser sans avoir une idée précise des réponses, étant donné la sortie récente du produit.

Evidemment, nous n’allons pas détailler l’ensemble des points à vérifier mais parcourir les grandes lignes des pré-requis et changements.

1^er point : Hardware

Netweaver 2004s est un concentré de produits contenant plusieurs outils assez gourmands qu’il vous appartient d’installer ou non. Outre le BW classique, il comporte aussi des nouveautés indispensables : Entreprise portal (pour l’utilisation des requêtes en 7.0), J2EE (serveur Java pour l’utilisation des nouveautés), WAS (Web application server) … C’est à dire, beaucoup de produits et de puissance à fournir au niveau de votre système. Certains recommandent même un serveur "stand alone" rien que pour la mise en place du J2EE (option offerte lors de l’installation)

Au niveau de l’espace disque, SAP porte à 20% d’espace supplémentaire à fournir par rapport à un volume existant.

2^ème point : Les postes clients

Là aussi, une attention est à fournir, les outils type Bex, Wad nécessitent l’installation de programmes (type .Net) et des versions de Microsoft Office assez récentes. Il ne va pas sans dire que les postes clients doivent aussi être plus musclés pour accueillir ces nouvelles applications.

3^ème point : La migration

Que provoque la migration en terme d’impacts et que doit-on prendre en compte dans tout chiffrage ? Plusieurs points à ce niveau :

Mise à jour de votre base BW (pre-requis) Kernel, Oracle et plug-ins à mettre à jour. Pas de modifications de vos structures existantes.

Netweaver 2004s comprend une version émulée des versions 3.x. Vous pouvez donc conserver les structures actuelles ainsi que leurs fonctionnements. Néanmoins, si vous aviez, au prélable, des soucis de performance, il peut être intéressant de prévoir de refaire les flux en version 7.0 afin de bénéficier des optimisations possibles.

En résumé, si vous n’avez pas besoin des fonctionnalités 7.0, il est possible de continuer tel quel

Migration des requêtes.

Pour bénéficier des fonctionnalités de construction de requêtes, il est nécessaire de migrer les requêtes, cela consiste à ouvrir les requêtes une par une et à les resauvegarder. Cela permet de compiler le programme se cachant derrière en version 7.0. (Il en est de même pour les web templates) Vous pourrez alors passer par Entreprise portal pour accéder aux requêtes.

Migration des autorisations.

SAP a décidé de changer sa stratégie sur l’implémentation des autorisations. Outre de nouveaux objets d’autorisation, la limitation à des valeurs de caractéristiques a aussi changé. Il faudra donc prévoir lors de votre migration, un budget refonte des autorisations et recettes.

4^ème point : Après la migration

Autant le dire, il y a encore quelques bugs dans le système. Mais, à partir, du SP10, le système commence à être fiable. Il ne faut pas négliger de passer les support packages.

En conclusion, la migration vers Netweaver 2004s n’est pas une opération neutre, contrairement à un passage 3.0 vers 3.5. Il n’en reste pas moins vrai que bien budgété et bien planifié, le projet de migration peut aller vite !

Pour plus d’informations, n’hésitez pas à nous contacter.

http://www.censio.fr

contact@censio.fr