Me revoilà pour compléter vos connaissances naissantes de l’univers ABAP !

Précédemment nous discutions de loin des différentes utilisations de l’ABAP dans SAP. Mais nous ne sommes pas encore entrés dans les détails du langage, ni même dans sa vision globale.

À mes yeux, l’ABAP est un langage de programmation orienté base de données. En effet, la plu part du temps, les données manipulées sont issues d’une sélection en base ; et la volumétrie est souvent énorme. Ce qu’il faut comprendre par là, en tout cas ce que j’ai dû comprendre en arrivant sur l’ABAP (moi qui venait de passer 2-3 ans à coder du PHP scolaire [donc mauvais]), c’est qu’on ne se contente pas de faire un pauvre SELECT pour obtenir des données suite à une saisie utilisateur et ensuite retraiter ces informations pour les ressortir à l’écran (ou mettre à jour la base).

Ce que je viens d’écrire est assez fouilli je pense. Alors, reformulons.
Les objets principalement manipulés en ABAP sont les tables internes. Ce sont des tableaux. Des tableaux de structures. Une structure étant composée de champs. En gros, une table interne est un peu l’équivalent d’une table de base de données, mais dont la portée est locale à l’exécution du programme (et du contexte dans lequel elle est déclarée).

Et donc, l’ABAP va générer ces tables internes, les manipuler, s’en servir pour mettre à jour la base de données, etc.

À part cet aspect, je pense que le langage ABAP est relativement proche des autres langages : procédural mais avec une couche orienté objet.

Syntaxiquement parlant, j’ai été rebuté lors de ma première approche du langage. Les instructions se terminent par un point. Pas d’accolades, pas de point virgule, pas de ++. Des opérateurs de comparaison étranges : EQ, NE, GT, LE… (respectivement : égal, non égal, strictement supérieur, inférieur ou égal). Des instructions et notations ambigües (l’instruction CHECK condition quitte un bloc de traitement, donc une boucle, un sous-programme, une méthode, un programme : le fonctionnement est dépendant du contexte [heureusement, cette instruction est deprecated à présent]).

Et puis, au bout d’un certain temps, on s’y habitue. On s’y fait, on s’y plaît presque, et on découvre la façon d’optimiser au mieux les traitements. Comme je le disais, les contraintes de volumétrie peuvent être énormes (imaginez une base de données contenant 30 millions de clients, devant gérer la facturation…). Des outils standard sont fournis pour paralléliser les traitements, d’autres spécifiques peuvent être développés pour améliorer encore plus les temps de traitement.

Allez, promis, l’article qui suit abordera la syntaxe proprement dite de l’ABAP.