Je connais peu de développeurs ABAP qui tarissent beaucoup d’éloges sur ce langage de programmation ou sur le progiciel SAP en général. Effectivement, à l’utilisation, il y a pas mal de petites choses gênantes, qui semblent mal pensées, voire conçues expressément pour compliquer la tâche des intégrateurs…
Mais il y a néanmoins des choses bien faites, et, une fois n’est pas coutume, il convient parfois de les relever !
Commençons par l’accessibilité au code source. L’ensemble du progiciel est codé en ABAP. Et l’ensemble du code source est visible, utilisable, voire modifiable. Toutes les fonctions développées sont appelables (en fonction de leur contexte d’exécution évidemment). Ainsi, si on a besoin de comprendre comment fonctionne un traitement standard (ie. qui existe d’origine dans la solution SAP), il suffit de trouver le code source associé et de l’analyser, pour éventuellement le ré-utiliser ou le copier pour l’adapter au besoin du client.
Autre bon point, concernant justement la façon de trouver le code source ABAP parmi la multitude de lignes de code, mais pas que. Je parle du debugger. Cet outil fantastique est intégré dans SAP et accessible extrêmement facilement. Et il permet de visualiser le code source en cours d’exécution, de voir et/ou modifier le contenu des variables (y compris les instances de classes), de naviguer dans la pile d’appel et de sauter à une instruction en aval ou en amont, et bien d’autres choses. À l’occasion je tâcherai d’écrire un article plus détaillé sur le debugger ABAP.
Je voudrais également citer la navigation dans l’outil, qui est très bien pensée. En effet, il suffit de double-cliquer pour accéder à tout et n’importe quoi. C’est un peu flou ? Pas de panique, j’approfondis par l’exemple.
Vous étudiez un code source suite à un bug remonté. Vous êtes devant une variable, mais vous ne connaissez pas son type. Double-cliquez ! L’environnement de travail (IDE fourni en standard également et codé lui-même en ABAP) affiche alors la partie du code source où la variable est déclarée.
Vous voulez à présent connaître son type exact, car le nom que vous y voyez (exemple : ma_var TYPE mon_type.) n’est pas très parlant ? Double-cliquez ! Vous êtes transféré sur la déclaration du type en ABAP s’il s’agit d’un type local, ou dans le dictionnaire de données s’il s’agit d’un type global (je simplifie volontairement les notions).
Imaginons qu’il vous faille modifier ce type pour corriger le bug, avant cela, il vous faut déterminer les impacts d’une telle modification. Pour cela, il faut notamment savoir où est utilisé ce type de données. S’il est local à un programme, il suffit de… double-cliquer ! S’il est global, un bouton est accessible. Dans les deux cas, le cas d’emploi (use cases) sera recherché et les occurrences seront affichées (à utiliser avec précaution, car les utilisations dynamiques du type ne peuvent évidemment pas être trouvées).
Pour terminer ce petit aperçu des choses bien faites dans SAP : le CTRL-Y. Ce raccourci clavier permet d’effectuer une copie « matricielle ». Pour faire une comparaison, c’est comme dans une feuille Excel. Il suffit de copier plusieurs lignes et/ou cellules (une cellule pouvant également être un champ d’un formulaire de saisie/visualisation) avec le CTRL-Y puis de la coller dans plusieurs autres lignes et/ou cellules pour que le système les copie les données en respectant dans la mesure du possible le format de départ. C’est très utile par exemple pour copier le contenu d’une feuille Excel dans une table de la base de données, ou bien pour copier une interface de module fonction vers un autre (par interface on entend ici la liste des paramètres d’entrée/sortie).
J’oublie sûrement d’autres points positifs qui mériteraient d’être retrouvés dans d’autres IDE (peut-être certaines de ces idées existent déjà ailleurs ?), mais je pense que les principales sont là.