SAP Business Information Consulting

Une sortie prévue avant la fin de l'année, l'Ehp2 pour Netweaver devrait apporter de nouvelles fonctionnalités.

Pour rappel, les Ehp pour Enhancement Package, constituent un lot de nouvelles fonctionnalités que SAP met à disposition à fréquence régulière (beaucoup plus régulière pour la partie ERP en tout cas)

Parmi les nouveautés, c'est en Abap que SAP a mis cette fois le paquet :

- Auto-complétion du code


- Design UML pour le développement des classes


- Nouvelles possibilités en terme de matchcode


- Gestion du glisser-dépasser dans les listes



A suivre ...

SAP et Teradata viennent d'annoncer qu'ils allaient lancer une offre conjointe sofware + hardware pour la BI...

Teradata va revendre SAP NetWeaver Business Warehouse et les outils décisionnels de Business Objects en association avec son Active Enterprise Data Warehouse.

Bien entendu, ce rapprochement est un peu provoqué par Oracle qui continue à muscler son offre en offrant de plus en plus de solution clefs en main hardware + software (et le récent rachat de Sun va probablement encore accélerer le processus)

De plus, le marché bruissait régulièrement de rumeur sur un rachat de Teradata par SAP, surtout depuis que Teradata a pris son indépendance fin 2007.

Ne vous êtes-vous jamais interrogé sur le fonctionnement du delta des extracteurs logistiques ? et oui, ça marche, mais ça a un coté un peu magique...

Si c’est le cas, cet article devrait vous apporter quelques éclaircissements.

Les principaux domaines concernés sont les suivants :

Domaines (N° application)

Sales and Distribution SD - (11, 13, 08)

Materials Management MM - (03, 02)

Logistics Execution LE - (12)

Quality Management QM - (05)

Plant Maintenance PM - (04, 17)

Customer Service CS - (18)

Project System PS - (20)

SAP Retail (40, 43, 44, 45)

Ces extracteurs utilisent le type de delta « ABR », de son nom technique.

Vous pouvez vérifier le type de delta utilisé par votre DataSource :

• en consultant directement votre DataSource, dans l’onglet « Extraction » :

• ou bien, dans la table « ROOSOURCE », dans le champ « DELTA » :

C’est le champ technique « BW Delta Process: Update Mode » (0RECORDMODE) qui permet de déterminer comment une entrée est mise à jour dans le processus de delta.

Le delta « ABR » construit des deltas comprenant trois types d’entrées différentes :

• « After image » : statut après une modification,

• « Before image » : statut avant une modification (quantité avec valeur négative),

• « Reverse image » : statut pour une suppression (quantité avec valeur négative).

petite remarque, ABR = After, Before, Reverse... pour une fois que c'est explicite et en anglais !

Le champ 0RECORDMODE peut donc avoir ici trois valeurs possibles :

• « X » = before image => la ligne est ignorée,

• « » = after image => la ligne est chargée et tous les champs sont mis à jour,

• « R » = reverse image => la ligne est supprimée.

Le champ ROCANCEL, qui fait partie de la DataSource, détermine les modifications côté R/3. Ce dernier a la même fonction que 0RECORDMODE côté BW.

En conséquence, le champ 0RECORDMODE doit être correctement mappé avec le champ ROCANCEL.

Attention, si vous êtes en BI V7, le mapping ne saute pas tout de suite aux yeux. Vous devez sélectionner les règles de type technique pour voir apparaître le champ 0RECORDMODE et pouvoir correctement le mapper.

A retenir :

Ce type de delta peut aussi bien être utilisé pour charger un DSO qu’un InfoCube.

De même, il supporte aussi bien les mises à jour de type ajout (« add ») ou bien remplacement (« overwrite »).

(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/

Un des reproches récurent fait à BW par les autres éditeurs d’outil BI était l’absence de push… ce manque a été comblé en version 3.5 avec l’arrivée de la fonction « Broadcast » (fonction qui a été améliorée en 7.0)

Le broadcast, qu’est-ce que c’est ?


Le broadcast permet la diffusion de données depuis BW à un ensemble de destinataires (utilisateurs et non utilisateurs BW). Le broadcast peut être configuré pour être diffusé de façon unique, basée sur un calendrier régulier (1/sem, 1/mois…), si un évènement se produit (définit par l’utilisateur) et en temps qu’élément d’une process chain.

De quelles sources ?

L’information diffusée par le broadcaster peut provenir de différentes sources : requêtes Bex, vues, classeurs (nouveauté apparue dans cette dernière version du BEx Report Designer), Web template, report formaté, applications Web.

Pour les utilisateurs BI administrator la transaction RSMON permet également d’accéder au broadcaster.
Sous quels formats ?
L’utilisateur peut depuis la version Netweaver 7.0 diffuser des documents sous format PDF. N’oublions pas les autres formats toujours accessibles html, mhtml, fichiers ZIP, fichiers excel, ps et pcl.

Comment les diffuser ?

Une large gamme de choix de diffusion est disponible :

Impression : Adobe PDF, Common Printer Language (psl), Post Script (ps). Possibilité d’imprimer en pdf une application dans son intégralité, impression pdf individuelle de chaque élément composant l’état et paramétrage de la mise en page via une boîte de dialogue.

Email en masse (ou Data bursting) : diffusion d’information spécifique à chaque utilisateur via les données de base avec adaptation possible du format de sortie à chaque destinataire. L’information visible par un groupe de users est donc restreinte par le système.

Email par exception : créations d’alertes basées sur des exceptions définies (par exemple dans le query designer)

Portail : les états sont accessibles sur le portail (par exemple sur les différents services des collaborative rooms comme le chat, les forums de discussions, messageries instantanée…)

Multiple distribution : par exemple portail + impression

Etats pré calculés : remplissage de pré calculs et de cache.

Lien direct aux données online: c’est une des méthodes de diffusion les plus sécurisées. Le destinataire doit cependant avoir un accès online au système avec un identifiant et mot de passe. Dans ce cas l’utilisateur aura la dernière version actualisée des données (si par exemple une modification a été faite entre le moment de l’envoi du mail et l’ouverture de celui-ci).
Le broadcast permet la diffusion d’information spécifique à chaque type d’utilisateur

Source : SAP

Quelle est la valeur ajoutée du broadcast pour l’utilisateur ?

Le broadcast réduit significativement le temps passé à rechercher l’information nécessaire aux analyses business. Avec le broadcast, l’information parvient à l’utilisateur. Il augmente la probabilité que les données BI soient en effet utilisées par les utilisateurs. Il permet aux données BW d’être accessible immédiatement par les utilisateurs. ceux ci pouvant partager des données BW entre eux et avec d’autres acteurs externes.

Le plus du broadcast :

Le broadcast est à portée de main d’utilisateurs occasionnels, d’utilisateurs non-BW, d’utilisateurs en déplacements professionnels ou de dirigeants peu familiers avec BW.

Que doit retenir de tout ça ?

Le broadcast apporte un réel changement de mentalité dans les méthodes de diffusion de l’information BI. Comment être le plus réactif possible sur le marché sans perdre un temps fou à passer en revue les informations indispensable au business ? La réponse est sans hésiter : le broadcast. En effet, l’utilisation du Bex Broadcaster pour vos reports de cœur de métier va nettement simplifier les problématiques liées à la sécurité d’accès aux données BI et permettre une diffusion rapide des reports (on gagne également en productivité des systèmes sources en limitant les accès directs au système).

Cette approche de « push » de l’information permet indéniablement une analyse plus fine des données indispensables au business tout en réduisant le temps passé à la rechercher.

Voici un petit document fort utile, évitant de trop chercher la signification des tables dans SAP BW (ça correspond à la version 3.x mais en grande partie valable encore pour BI7)

Dès la fin du mois, un package comprenant des évolutions applicatives pour Netweaver et SAP BW devrait sortir (sous le nom de Enhancement Package 1). Vous pouvez trouver la liste des évolutions dans la présentation suivante sur SDN

A la clé, des évolutions de plusieurs types :
- pour le reporting : copier / coller de listes dans la fenêtre de selection du Bex Analyzer, copie de workbooks, broadcast des vues
- pour le datawarehouse : contrôle d'existence de attributs dans le DTP,  possibilités de filtre pour supprimer les informations dans la PSA
- Intégration Business Objects Polestar et BI Accelerator
- Optimisation de l'interface MDX pour Web Intelligence et SAP BPC
- Fonctionnalités d'écriture pour SAP BPC (pré_requis)

Ce package marque aussi la fin des évolutions sur les outils de reporting Bex pour laisser la place aux outils Business Objects (Crystal Reports et Xcelsius)

En manque de sensations fortes ou votre solution manque de punch ?
Changez votre moteur avec BI Accelerator (BIA).

C’est presque vrai !

En effet, en aucune manière, vous ne devez renoncer aux approches traditionnelles d’optimiser votre solution dans les différentes étapes de construction d’une solution BI (optimisation des dimensions, de la requête, des paramètres systèmes ou même de la définition des besoins) avant de songer à d’autres solutions techniques.

Il serait dommage d’investir dans une nouvelle solution sans avoir au moins traité ou audité les goulots d’étranglements ! Qui plus est, pour rappel, avant toutes opérations, SAP BW va d’abord voir si la requête que vous utilisez est déjà présente dans la mémoire cache. Si toutefois, vous aviez déjà tout essayé, BIA est fait pour vous

Néanmoins, avec une totale utilisation des ERPs et la croissance du nombre des utilisateurs, il faut désormais gérer une quantité beaucoup plus importante d’informations.
La problématique devient alors la gestion des temps de réponse.
La disponibilité de vos informations depuis SAP BI est aujourd’hui critique et doit gérer des agrégations en téraoctet ?
Vos cubes grossissent exponentiellement de mois en mois ?
Vous désirez conserver un historique de vos informations assez conséquent pour ne pas avoir à les effacer ?

Voici les questions à se poser avant la mise en place d’une solution qui optimise vos temps de réponse.

Alors vient la réponse de SAP à ces problématiques, BI Accelerator.
Avec la baisse du prix de la mémoire (comparé aux disques), il devient intéressant d’utiliser cette première afin de stocker les informations lors de l’exécution d’une requête, surtout que les accès y sont beaucoup plus rapides (à l’instar du livecache de la solution SAP SCM).


source : SAP

SAP propose un système 64 bit basé sur une solution développé avec Intel.
Cette solution a pour originalité de stocker les informations sous forme d’index, rangés et compressés par un moteur TREX. De ce fait la recherche d’informations ou les navigations de type drill down se fait beaucoup plus rapidement.

BIA est un système distribué ce qui lui permet d’être presque disponible 7j/7 et 24H/24 pour peu que la configuration achetée soit adéquate afin de fournir une grande disponibilité des informations.

Le système est par ailleurs évolutif car il est possible pendant l’utilisation, de rajouter des éléments de mémoire ou de processeur.
Attention BIA ne fonctionne qu’avec Netweaver 7.0 et ne fonctionne pas encore sur des objets de type datastore (ODS).

Quelles sont les avantages ?
- Des requêtes plus rapides en traitement et en temps de réponse (jusqu’à 10 fois)
- Réduction des temps de roll up des aggrégats
- Moins de maintenance au niveau BW côté paramétrage
Pour en citer quelques unes : plus besoin de maintenir des aggrégats, de gérer le cache olap (sauf si vous n’utilisez pas BIA bien sur)
- Moins de maintenance au niveau administration, il n’y a pas besoin d’optimiser le système BW ou la base de données puisque BIA s’occupe de tout. (par exemple, faire du partitionnement physique au sein de Netweaver BI)
- Le système d’exploitation est Linux, ce qui a pour avantage à ne pas devoir payer de licence dessus.

Pour rappel, BIA ne fait pas partie de Netweaver et requiert l’acquisition de licences.

SAP publie un retour d'expérience fait aux Etats Unis, ici

Pour plus d’informations, Censio s’associe avec SAP pour vous présenter plus en détail le produit.
N’hésitez donc pas à nous contacter.

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

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