Le coté législatif de la lutte contre le carbone se précise... le seul problème, c'est que les gouvernements sont nationaux mais que les entreprises sont globales, et devront faire face à de diverses obligations d'informations. Dans le même temps, les clients et actionnaires sont de plus en plus friands de chiffres précis et fiables sur le sujet (certains clients commencent à exiger un impact CO2 sur les factures fournisseurs

Pour ce faire, les entreprises se dotent d'outils, qui ont dans un premier temps pour but de mesurer pour chaque étape des process de l'entreprise l'impact en terme de CO2, puis dans un second temps améliorer cette trace...

Et c'est la qu'interviennent les outils de BI... collecter, transformer, 'budgéter', agréger les données pour permettre une analyse pertinente (comparer impact carbone VS rentabilité des produits par exemple, émission de carbone par site de prod, par technologie...)

Le marché est énorme, certains analystes anticipent un marché de plus 10 milliards de US$ en 2012.

Quoi de mieux d'un bon outil de BI pour collecter puis analyser les données ! SAP avec Business Objects est sur les rang, entre autre en fournissant une solution de portail déclaratif et analytique CO2 au CDP (Carbon Disclosure Project), une ONG Américaine qui collecte les déclarations d'émissions de CO2 d'un nombre important de sociétés Américaines

(D'abord, merci à tous ceux qui ont trouvé le PDF des tables BI tellement intéressant qu'ils se le sont appropriés - n'hésitez pas a citer Censio si nos articles vous sont utiles!)

Pour un objet SAP, le préfixe des tables est /BI0/

Pour les objets spécifiques, le préfixe est /BIC/

Table des SID: /BI0/S* or /BIC/S*

Table des SID pour les attributs dépendents du temps: /BI0/Y* or /BIC/Y*

Table des SID pour les attributs non-dépendent du temps: /BI0/X* or /BIC/X*

Table des SID pour les hiérarchiese hierarchy: /BIO/K* or /BIC/K*

Table avec la structure des SID pour les hiérarchies: /BIO/I* or /BIC/I*

Vues sur l’infoobjet: /BI0/M* or /BIC/P*

Table de master data pour les attributs non dépendents du temps: /BI0/P* or /BIC/P*

Table de master data pour les attributs dépendents du temps: /BIO/Q* or /BIC/Q*

Table des texts: /BI0/T* or /BIC/X*

Table des hiérarchies: /BIO/H* or /BIC/H*

Table des dimensions d’infocube: /BIO/D* or /BIC/D*

Table de faits d’infocube: /BIO/F* or /BIC/F*

Table de faits compressée d’infocubes: /BIO/E* or /BIC/E*

Table shadow de la table de faits: /BIO/4F* or /BIC/4F*

Table shadow de la table de faits compressée: /BIO/4E* or /BIC/4E*

Destinations OpenHub: /BIO/OH* or /BIC/OH*

Namespaces spécifiques (partenaire ou client): /XYZ/

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.

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

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

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.