SAP Business Information Consulting

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…

La direction de SAP perdra à la fin du mois prochain une autre tête : Aliza Peleg, directrice des SAP Labs US (les fameux labo de Palo ALto)

C'est dans les SAP Labs, sous l'impulsion de Shai Agassi (voir post du 29 mars), que se développaient les outils middleware de SAP, qui ont transformé le SAP des années 90 en la suite composite que nous connaissons aujourd'hui.

Il semble que cette démission soit liée à de vives tensions entre les centres de décisions US et Waldorf... et marque un retour en force de l'Allemagne.

Suite à l'annonce de ce départ, SAP a rappelé que « la Silicon Valley reste éminemment stratégique pour SAP », qui y emploie près de 1600 personnes.

www.censio.fr

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

96 % des sociétés américaines envisagent de reprendre en interne tout ou partie des services externalisés, une fois leur contrat arrivé à échéance. Tel est le constat d'une étude menée par Compass Management Consulting.

Le problème semble venir des coûts, qui baissent bien au début du contrat (jusque -15%), mais qui ont une forte tendance à remonter par la suite (les dépenses de l'entreprise peuvent à terme être 30% plus élevées que celles d'un service bien géré en interne!)

Certaines sociétés échouent même dans leur projet d'externalisation en raison d'une mauvaise gestion de la relation avec leur fournisseur : manque d'investissement, absence de gouvernance du contrat et de support de leur part, incapacité du fournisseur à renouveler la technologie etc.
D'où une volonté affichée de re-insourcing des services.

Cette étude me semble plutôt en ligne avec ce que nous vivons sur les projets, en tout cas en ce qui concerne le constat : l'outsourcing ne génère pas obligatoirement des économies, et impose une attention constante... En ce qui concerne le re-insourcing, je pense que c'est une autre affaire...

Lien vers l'étude complète (en anglais)

Pour plus d'infos : www.censio.fr