Blog éclectique & sans sujet précis

(Le brouillon de ce billet a attendu publication depuis au bas mot un an et demi. N’ayant plus accès à du SAP, et n’ayant aucune intention de m’y remettre, je renonce à le compléter et le jette dans les index des moteurs de recherche. Le contexte reste le SAP R/3 que j’ai connu en 2006, il faudrait voir les dernières versions.)

Comme dirait Kooorrg, cet article contient 10% de râlage.

J’ai déjà clamé ici ma déception de SAP et de l’ABAP. Du point de vue du développeur, SAP est un mélange d’archaïsmes des années 80 traînés de force dans les années 90, et l’ABAP est un des langages les plus limités que je connaisse (et pourtant le PL/SQL d’Oracle, le concurrent, n’est pas très sexy) ; sauf peut-être sa version objet, dont la puissance certaine est étouffée par la verbosité du langage et l’over-engineering qu’on y sent à plein nez^[1].

Cette fois je vais tenter d’être positif : SAP a ses bons côtés, des bonnes idées qui facilitent la vie et mériteraient d’être reprises chez le concurrent (je ne me souviens pas de les y avoir vues sur Oracle Applications). Cet ERP n’est pas devenu numéro 1 uniquement par sa richesse fonctionnelle et son marketing abrutissant^[2].

Les variantes

Les variantes constituent un simple gadget au premier abord, mais elles se révèlent en fait très pratiques et font gagner un temps fou. En arrivant dans un écran, l’utilisateur doit choisir parfois une flopée de paramètres : type de commande, fourchette de dates, clients, pays... La saisie faite, il sauvegarde (Ctrl-S directement dans le formulaire de saisie), il donne un nom à la variante, et ce masque de recherche peut alors être réutilisé par la suite.

C’est très utile pour éviter de ressaisir les mêmes valeurs chaque matin ou lors de dizaines de tests identiques en développement. Indispensable également pour cadrer ou modifier ce que l’utilisateur doit entrer, en lui imposant un masque précis sur son écran standard (par défaut ou pas).

(Seul reproche : pour qu’un masque soit utilisable sur une transaction pour tous les utilisateurs, il faut que son nom commence par CUS&, ce n’est pas une case de paramétrage à cocher et pas intuitif...)

Double clic

Dans beaucoup d’écran, mais pas tous, un double-clic sur un objet (par exemple un numéro de client) peut mener directement sur l’écran de visualisation dudit client. Très pratique, même si l’hyperlien n’est pas un concept révolutionnaire.

À l’inverse, sous Oracle Applications 11i (fondamentalement un « client lourd » en Java), je voyais en permanence les utilisateurs noter un numéro de commande ou de produit au stylo sur leur sous-main, changer d’écran (voire de « responsabilité », les menus n’intégrant pas tous les écrans accessibles à l’utilisateur), et re-rentrer le numéro sur le masque de recherche. Oracle Appli a rattrapé son retard sur ce point dans les modules récents purement « web ».

Matchcode

Non disponible partout, hélas, le matchcode permet de spécifier des critères de recherche beaucoup plus fins qu’une simple fourchette. Par exemple, dans un champ de recherche de numéros de commandes, un matchcode pourrait être « commandes de 500 à 999 sauf de 800 à 803, plus la 1012, moins la 503 ».

Impossible de faire ça simplement avec Oracle Applications à ma connaissance.

Les mandants

Une base SAP divise ses tables en « mandants ». Chacun correspond à ce que j’appelle une « vision du monde », à savoir un ensemble de données et (parfois) des objets comme des rapports. Peuvent cohabiter dans un même système un mandant de paramétrage, un mandant de développement sans donnée importante, et un mandant de test avec ses données réalistes.

Un rafraîchissement d’un environnement de développement ou recette depuis la production peut se limiter à écraser les données d’un mandant par les nouvelles sans effacer ce qu’il y a ailleurs (paramétrage…).

Techniquement, ce mandant est la première colonne de chaque clé primaire des tables de la base.

Le concept ne va pas complètement au bout, dans le sens où il existe des objets « intermandants », par exemple les programmes, fonctions... en ABAP. On ne peut donc pas aller jusqu’à avoir une version de développement et une de production d’un programme sur un même système. De plus, certains outils de développement dépendent quand même du mandant (par exemple l’antédiluvien SAPscript).

Les transports

Chez le client Oracle Applications où j’ai presté, les mises en production consistaient en une copie manuelle des scripts shell et PL/SQL entre les machine de dév’ et machine de prod’. Avec CVS ou un autre outil le principe serait resté le même : l’intégrité du système est gérée à l’extérieur, et différents systèmes sont techniquement et logiquement isolés (peut-être y a-t-il des outils dédiés ?).

SAP fonctionne par contre par transport d’ordres. C’est le bon côté d’un système qui se veut totalitaire et exige que tout passe par lui : au moins il peut imposer une certaine cohérence et un certain contrôle sur sa propre évolution. De plus, il tient compte de l’existence de plusieurs systèmes SAP les uns à côté des autres.

Les « ordres » regroupent du paramétrage, ainsi que des ensembles de programmes d’un même ensemble ou dépendant les uns des autres. Les ordres tiennent compte des numéros de version, donc un programme peut être dans trois versions différentes sur les environnements de développement, test et production sans mélange. Les utilisateurs autorisés au sein du système approuvent et déclenchent le transfert des ordres entre dév’, recette, prod’...

Les problèmes récurrents sont plus liés au principe qu’à l’outil : dépendances non techniques à vérifier, ordre des transports à maintenir, etc.

Enregistrements de transactions

Quand il s’agit d’importer des données, SAP est très ouvert... pourvu que l’on parle son langage ! En clair il faut formater les fichiers sous forme d’Idocs ou de fichier Batch Input, un style assez pénible avec des lignes d’entêtes et d’autres de détail. Il y a plusieurs autres outils d’import comme les deux précités ; en fait cela dépend du module et de ce qu’on veut importer, le choix n’a rien d’évident. Comme souvent dans SAP, la méthode dépend de la strate géologique impliquée. Il y a sans doute des web services pleins de XML plus standards à présent dans des développements récents, je doute que cela touche les modules anciens de finance ou de ventes. (D’ailleurs, l’interfaçage avec SAP est une option ruineuse pour nombre de produits de manipulation de données comme les ETL.)

En dernier recours existe un outil antédiluvien mais bien pratique, un bête enregistreur de transactions à l’écran, qui génère un exemple de fichier qui va bien, et que l’on peut utiliser comme modèle pour rejouer des transactions comme si elles étaient entrées manuellement à l’écran, en déclenchant tous les triggers, user exits, etc. Un peu rustique avec quelques côtés sombres, mais ça marche bien et ça a le grand mérite d’exister.

Tous ces outils d’import nécessitent un apprentissage car leur utilisation n’a rien d’intuitive (enfin, peut-être que si après des années sur SAP, je me suis arrêté à 11 mois et demi...). Le cours SAP dédié à ces choses dure une semaine alors qu’un jeu d’API bien foutues ou de tables d’import aurait rempli correctement le besoin. (Comme chez le concurrent Oracle Applications par exemple ; je me suis battu avec ses API et imports à cause de leurs bugs et limites, rarement pour me demander avec quoi importer des données. Seul manque réel d’Oracle Appli : l’outil de simulation d’entrée par les écrans utilisateurs.)

Cadobonus

PS : En bonus, 10 Golden Rules for Bad User Interface dans un contexte SAP. Des généralités vagues avec lesquelles tout le monde sera d’accord. Il est rigolo de constater que SAP R/3 suit méticuleusement presque toutes ces anti-règles.