| ABAP | |
| Date de première version | |
|---|---|
| Influencé par | Cobol |
| Licence | Licence propriétaire |
| Site web | scn.sap.com/community/abap |
| modifier |
|
ABAP est un langage de programmation propriétaire, faisant partie de l'ensemble logiciel SAP. Il s'agit actuellement du langage utilisé dans la programmation des Web Application Server faisant partie de la plateforme NetWeaver pour la réalisation de progiciels.
Sa version ABAP/4 est objet, le chiffre 4 faisant de plus référence à son appartenance à la classe des langages de quatrième génération.
L'acronyme ABAP signifiant à l'origine Allgemeiner Berichtsaufbereitungsprozessor (processeur générique pour la préparation de rapport) et a par la suite été anglicisé en Advanced Business Application Programming.
ABAP est l'un des successeurs du Cobol et est apparu dans les années 1980 dans la vague des langages de quatrième génération (L4G). Il s'agit d'un dérivé du langage permettant de réaliser des sorties de données (appelées rapports) de l'application SAP R/2, sur lequel de nombreuses multinationales avaient bâti leur architecture d'application professionnelle. ABAP a par la suite été maintenu comme langage de référence pour les applications SAP R/3 qui sont apparus en 1992.
À l'origine, ce langage comprenait le concept de Base de données logique qui devait permettre à tout utilisateur de créer lui-même les rapports dont il avait besoin. Il s'est avéré en fait que développer des programmes avec ce langage ne pouvait être fait en pratique que par des professionnels disposant d'une solide expérience.
Le langage a été par la suite étendu pour englober un modèle de données orienté objets (ABAP Objects) à partir de sa version 4.5, pour être finalement intégré comme langage d'un produit plus général appelé NetWeaver. Ce dernier utilise aussi bien ABAP que Java.
C'est un langage interprété.
Le code source : il est écrit directement dans un composant de SAP appelé SAP Workbench et il sera stocké dans la base d'information de l'outil. Ce langage, de même que java, a besoin d'être compilé pour pouvoir être exécuté. Cependant, à la différence de java, avant chaque utilisation d'un programme, le processeur SAP vérifie qu'il possède la dernière version du programme. Si ce n'est pas le cas, ce dernier est recompilé à la volée.
Le dictionnaire de données (DDIC) : la base de données est masquée pour le programmeur. Il y accède donc au travers de clauses faisant partie du langage lui-même. De même, la gestion du modèle de données est réalisée au travers d'un composant qui créera ou modifiera lui-même les tables de données. Ce dictionnaire de données comprend :
Un outil de transport. À chaque modification d'un programme, celui-ci doit être transporté de l'environnement dans lequel il est créé vers un environnement de test puis dans l'environnement de production (chacun de ces environnements dispose de jeux de données distincts, il peut exister plus de trois environnements dans un système d'information donné). Cette opération est réalisée par la mise en œuvre d'un ordre de transport.
La communication avec les bases de données se fait via des requêtes SQL. Dans les premières versions de SAP, elles sont très simplifiées mais augmentent en complexité dans les nouvelles versions notamment avec les dernières versions de SAP ECC (EhP8) et bien évidemment avec S/4HANA.
ABAP jusqu'à l'apparition de NetWeaver était la brique constituante des systèmes SAP R/3. Il permet de réaliser :
ABAP a évolué pour intégrer la programmation objets. Tous les concepts de la programmation objets se retrouvent dans ABAP Objects. ABAP Objects constitue une extension du langage ABAP, avec lequel il est totalement compatible : ainsi il est possible qu'un programme comporte à la fois une partie procédurale et une partie orientée objets, car le déroulement procédural du programme peut à tout moment instancier une classe puis appeler les méthodes de l'objet qu'il vient de créer.
La migration vers SAP S/4HANA a modifié les missions des consultants techniques : contrairement aux spécialistes de la configuration des processus métier, ils adaptent le code ABAP existant aux exigences de la nouvelle plateforme. Sur le marché français du conseil SAP indépendant, les développeurs ABAP pour S/4HANA figurent parmi les spécialisations les mieux rémunérées, aux côtés des experts BTP et des architectes de migration. Selon l'étude ASUG citée par smartShift, 95 % des organisations interrogées créent et exploitent leur propre code ABAP étendant les applications SAP.
L'ampleur de ce travail peut être considérable : lors de la migration de Deutsche Bahn vers S/4HANA, plus de 15,3 millions de lignes ABAP ont été analysées dans les applications d'entreprise. L'architecture de la base de données SAP HANA permet de déplacer une partie du traitement des données du niveau applicatif vers le niveau base de données, notamment en utilisant les CDS et les procédures AMDP. Le modèle ABAP Cloud, malgré son nom, autorise le développement d'applications pour des systèmes déployés localement, et pas seulement pour l'environnement cloud.
Dans le développement moderne, le modèle RAP est utilisé, permettant d'exposer des objets métier sous forme de services OData, notamment consommés par les applications SAP Fiori. Lors de la modernisation des extensions personnalisées, on applique l'approche Clean Core : les modifications existantes sont classées du niveau A au niveau D selon leur compatibilité avec les mises à jour et le degré d'attachement au noyau du système. En mai 2026, des outils de développement ABAP sont apparus dans Visual Studio Code ; la première version prenait en charge le développement bout en bout d'applications basées sur RAP.
Le grand classique :
REPORT Z_XX_TRANSACTION.
*
* -- Commentaire de ligne
*
PARAMETERS p_input TYPE c LENGTH 16 DEFAULT 'Hello World!'.
*
*-- Affichage du résultat :
*
WRITE: / 'L''entrée était : ', p_input.
REPORT Z_XX_TRANSACTION.
*
* -- Déclaration de données
*
TABLES:
tstc. "Tables des transactions
* Tables internes pour l’exemple
DATA :
"Transactions
gt_tstc TYPE TABLE OF tstc,
gs_tstc TYPE tstc,
"Descriptions de transactions
gt_tstct TYPE TABLE OF tstct,
gs_tstct TYPE tstct.
*
" -- Début de la déclaration de l'écran de sélection
SELECT-OPTIONS s_tcode FOR tstc-tcode OBLIGATORY.
*
*
*------------------
START-OF-SELECTION. " -- Début de l'extraction des données
*------------------
CLEAR: gt_tstc,
gt_tstct.
SELECT
FROM tstc
FIELDS *
WHERE tcode IN @s_tcode
INTO TABLE @gt_tstc.
IF sy-subrc IS INITIAL. " Si la sélection s'est bien passée
SORT gt_tstc BY tcode. " On trie la table par nom de transaction (facultatif)
*
SELECT
FROM tstct
FIELDS *
FOR ALL ENTRIES IN @gt_tstc
WHERE tcode = @gt_tstc-tcode
AND sprsl = @sy-langu
INTO TABLE @gt_tstct.
IF sy-subrc IS INITIAL.
SORT gt_tstct BY tcode. " On trie la table par nom de transaction
" (obligatoire pour lecture dichotomique plus bas)
ENDIF.
ENDIF.
*
*
*------------
TOP-OF-PAGE.
*------------
" -- Haut de page (sur chaque page)
WRITE / 'Programme exemple : liste de transactions '.
SKIP. "Saut de ligne
ULINE. "Ligne continue horizontal
*
*
*------------
END-OF-PAGE.
*------------
" -- Bas de page (sur chaque page)
ULINE.
*
*
*-----------------
END-OF-SELECTION. "Traitement des données après sélection
*-----------------
LOOP AT gt_tstc INTO gs_tstc. "Boucle sur les transactions
" Recherche de la description
READ TABLE gt_tstct
WITH KEY tcode = gs_tstc-tcode
INTO gs_tstct
BINARY SEARCH. "Lecture dichotomique ⇒ meilleure performance
IF NOT sy-subrc IS INITIAL. " Erreur
WRITE : / "Saut de ligne
sy-vline, "Barre verticale
gs_tstc-tcode, sy-vline, "Code puis barre
(25) '-- Pas de description --', "Largeur du texte spécifiée
sy-vline. "Barre verticale
ELSE.
WRITE : / "Saut de ligne
sy-vline, "Barre verticale
gs_tstc-tcode, sy-vline, "Code puis barre
(25) gs_tstct-ttext, "Description sur 25 caractères
sy-vline. "Barre verticale
ENDIF.
ENDLOOP.
Ce qui donne pour l'écran de sélection :
Et pour le résultat :