SAP Business Information Consulting

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

Avec la dernière version BW, Entreprise Portal est devenu le support des applications web BW.
Pour les gens provenant du monde BW, il est peut être encore difficile de faire ses premiers pas dans le monde du Portail.

En effet, il y a une ribambelle d'options et à moins d'avoir déjà travaillé sur la plateforme, difficile de deviner comment modifier certains éléments.

1er point : organisation de votre portail
Faisons un point sur les nouveaux vocabulaires apparaissant pour les personnes venant du monde BW ..

Iview est la représentation d'une application (BW, R/3, Intranet, Internet

Page : organisation de la page du portail contenant les iviews

Workset : bundle de pages Portail réutilisables dans plusieurs rôles

Role : point d'accès (niveau autorisation dans le portail) et 1er niveau d'organisation de vos pages portails et apparaît en forme d'onglet au 1er niveau

Grosso modo : pour vos premiers pas, vous avez besoin de créer une iview de type BW, puis l'incorporer à une page et enfin, de l'ajouter à un rôle pour être visible.

2e point : customization du layout portail
Nous imaginons mal que vous désirez garder le format SAP pour le layout du portail mais plutôt le personnaliser aux couleurs de votre entreprise.

Pour cela, 2 choses à modifier :
- la page d'accueil
- le look and feel portail

Dans le 1er cas, il vous faudra créer une archive web en utilisant Netweaver Studio en incorporant les nouvelles images. Enfin, mettre à jour, les paramètres suivants :
ume.logon.branding_image et ume.logon.branding_text.

Dans le 2nd cas, il faut accéder au point de paramétrage situé dans l'administration du système. Via l'application Thème Portail, vous aurez à loisir de modifier le style de vos pages de navigations.

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

Considérez ces phrases :
Un ABAPeur écrit du code
Un ABAPeur malin écrit du code documenté
Un bon ABAPeur malin écrit du code documenté et dont l’état d’exécution peut être vérifié
Un très bon ABAPeur malin écrit du code documenté et dont l’état d’exécution peut être vérifié même en production.

Le langage ABAP est un bon langage. Simple, concis, puissant. Par endroit élégant même.
L’environnement d’exécution aussi. Un bon debugger, des points d’arrêt, …

Pratique, les points d’arrêt. Je me ballade dans mon code, je trouve un endroit intéressant, un petit clique sur ‘STOP’, je lance le programme, et voilà, il s’arrête.
Et si mon programme est super compliqué ? Très long ?
Et si je sais, moi programmeur, que s’il y a des problèmes, ça risque fort d’être juste LA ? Ben je mets un break point. Assez simple. Une instruction ABAP simple : BREAK-POINT.

Si je veux que le break point ne soit actif que pour moi, je fais plus simple. Je fais BREAK WALKER. (BREAK {user} ).

C’est pas mal. Ca m’aide à tomber juste au bon endroit pour debugger mon programme.

Mais je peux aussi faire valider son état. Je peux utiliser les assertions. Si je veux être sûr que l’utilisateur ne saisit pas plus de 1000 lignes dans ma facture (un vieux bug dans les versions anciennes de R/3) je peux écrire quelque chose du genre : ASSERT nb_lignes <>dans le code ABAP, et d’activer le checkpoint associé.

Ceci est possible à l’aide des LOG-POINT. Dans la transaction SAAB, si un programme avec un checkpoint atteint une instruction LOG-POINT, une entrée sera créée dans un log spécifique.

Mais le point fort, c’est qu’on peut aussi écrire dans le log des valeurs de variables :
LOG-POINT ID {checkpoint} FIELDS Field1, Field2, …, FieldN

De cette façon, on peut voir l’évolution de nos variables.

Le seul problème, c’est que, pour économiser l’espace disque, SAP agrège les entrées dans le log pour un seul LOG-POINT – on ne verra que la dernière entrée. Dommage.

Enfin, sauf si on utilise la dernière option de LOG-POINT, l’option SUBKEY. SUBKEY permet de modifier la clé de l’entrée dans la table de log (ce qui bien sûr a pour effet de créer une nouvelle ligne à chaque appel.

Imaginons le code suivant, par exemple :
DO 100 TIMES.
LOG-POINT ID TOTO FIELDS sy-index.
ENDDO.

Dans le log, on verra que le log point a été atteint, 100 fois, et la valeur associée à l’enregistrement sera 100 (la dernière valeur vue).

Si par contre on écrit :
DO 100 TIMES.
LOG-POINT ID TOTO SUBKEY sy-index FIELDS sy-index.
ENDDO.

On aura 100 entrées dans le log.

Dernier point, l’impact sur la performance. SAP nous assure que ces instructions, si le checkpoint n’est pas actif, n’auront AUCUN impact sur la vitesse d’exécution du programme. Pour ma part, je n’ai pas fait de tests…

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...

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

Lorsque l'on installe une nouvelle version de SAP, surtout avec NW2004s, on se retrouve face à face à une question structurante pour le projet - est-ce que j'utilise la Nouvelle Techno du jour, ou est-ce que je reste avec la technologie que je connais, et surtout que je sais qui marche.

Avec NW2004s, il y a (au moins) deux domaines où cette question peut légitimement se poser:
* Pour le développement web, avec la nouvelle technologie WebDynpro (contre BSP auparavant)
* Pour l'outil de planification et de simulation, BI/IP (pour Business Intelligence, Integrated Planning), contre SEM/BPS (ou BW/BPS)

Les attraits de ces nouvelles technologies sont nombreux, les risques aussi. Assez rares sont les 'early adopteurs' qui ne rencontrent pas de problèmes avec ces solutions.

Cependant, avec BIIP, et surtout depuis le SP10 de NW2004s, la solution semble très stable, et surtout performant. Nous venons de terminer la recette d'une solution d'élaboration de budget, qui utilise BIIP pour tout ce qui est saisie web. Pour donner une idée de la taille du projet, il y a plus de 20 requêtes BEx en mode "planification", réparties sur 6
applications WAD. Ceci permet la saisie de budget, annuel ou mensuel, de tendance, des données actualisées, etc.

Sur un autre domaine, nous sommes en train de passer en recette un projet similaire d'élaboration de budget, sur un modèle légèrement plus simple, mais qui se base sur la hiérarchie des centre de coûts (ceux qui l'ont pratiqué sauront que parfois, les hiérarchies réservent des surprises). BIIP nous a permis de monter cette solution, qui répond parfaitement aux besoins des utilisateurs, très rapidement, et avec une quantité de
développements très réduite.

Dans un futur article, nous regarderons plus en détail les développements BIIP, les possibilités qu'offre cette technologie, les avancés par rapport à SEM/BPS, et les inconvénients qui subsiste (car inconvénients il y en a). Mais pour l'instant, le ressenti sur le projet quant à la maturité, la stabilité et la puissance de l'outil, BIIP tient ses promesses.