Les premiers pas
ABAP (Advanced Business Application Programming) est le langage de programmation propriétaire développé par SAP AG pour personnaliser et étendre les fonctionnalités des systèmes SAP. Depuis sa création en 1983, ABAP a évolué d'un simple langage de génération de rapports vers un langage de programmation complet supportant les paradigmes procédural et oriente objet.
Un programme ABAP est une unité de code entreposée dans la base de données du système SAP, et non dans des fichiers externes comme la plupart des langages de programmation. Cette architecture permet une intégration étroite avec le système de transport SAP, facilitant le déploiement des développements entre les environnements (développement, qualité, production).
Chaque instruction ABAP se termine obligatoirement par un point (.). Ce point joue le rôle de délimiteur d'instruction, similaire au point-virgule dans d'autres langages comme C ou Java. Les instructions peuvent s'étendre sur plusieurs lignes sans caractère de continuation particulier, ce qui améliore la lisibilité du code pour les instructions complexes.
ABAP n'est pas sensible a la casse : les mots-clefs, les noms de variables et les identificateurs peuvent être écrits en majuscules, minuscules ou en casse mixte. Cependant, par convention, les mots-clefs ABAP sont généralement écrits en majuscules pour les distinguer des identificateurs définis par le programmeur.
L'éditeur ABAP intégré à l'environnement SAP GUI offre des fonctionnalités avancées comme la coloration syntaxique, la vérification en temps réel, et l'accès direct au dictionnaire de données (DDIC) pour consulter les définitions de tables et de types.
Types de programmes
Le système SAP distingue plusieurs types de programmes ABAP, chacun ayant un rôle spécifique dans l'architecture applicative. Le choix du type de programme dépend de la nature de l'application a développer et de son mode d'interaction avec l'utilisateur.
| Type | Description |
|---|---|
| REPORT | Programme de type rapport (liste), exécutable directement. C'est le type le plus courant pour les développements Z. |
| PROGRAM | Programme exécutable similaire a REPORT, souvent utilise pour les programmes sans sortie de liste standard. |
| INCLUDE | Module de code réutilisable, inséré dans d'autres programmes. Ne peut pas être exécute seul. |
| MODULE POOL | Programme de dialogue (écrans dynpro), type M. Utilise pour les transactions avec plusieurs écrans. |
| FUNCTION | Groupe de fonctions contenant des modules de fonction. Entrepose dans des groupes de fonctions. |
| CLASS POOL | Classe globale ABAP Objects, type K. |
Les programmes REPORT constituent le type le plus fréquemment utilise pour les développements spécifiques. Ils sont conçus pour extraire des données de la base de données, les traiter et les présenter sous forme de liste a l'utilisateur. Les rapports peuvent être exécutes directement via la transaction SE38 ou SE80, ou associés a un code de transaction personnalisé.
Les programmes INCLUDE servent a structurer le code en unités logiques réutilisables. Contrairement aux autres types de programmes, un INCLUDE ne peut pas être exécute de manière autonome ; il doit être incorpore dans un programme principal via l'instruction INCLUDE. Cette approche favorise la maintenance du code en séparant les déclarations de types, les définitions de données et les sous-programmes dans des fichiers distincts.
Les MODULE POOL sont utilises pour les applications de dialogue nécessitant une interface utilisateur graphique avec plusieurs écrans (dynpro). Ces programmes implémentent la logique métier derrière les transactions SAP et gèrent les interactions complexes avec l'utilisateur a travers des enchaînements d'écrans.
Les groupes de fonctions encapsulent des modules de fonction réutilisables. Un module de fonction est une unité de code indépendante, avec une interface bien définie (paramètres d'importation, d'exportation, de modification et exceptions). Les modules de fonction peuvent être appelés depuis n'importe quel programme ABAP ou exposes comme services RFC (Remote Function Call) pour les intégrations système.
Les CLASS POOL contiennent les définitions de classes globales ABAP Objects. Ces classes sont accessibles depuis tous les programmes du système et constituent la base de la programmation orientée objet en ABAP. Elles supportent l'héritage, l'encapsulation, le polymorphisme et les interfaces.
Structure générale
Un programme ABAP bien structure suit une organisation logique facilitant la compréhension, la maintenance et l'évolution du code. Cette structure n'est pas imposée par le compilateur mais représente une convention de programmation largement adoptée par la communauté SAP.
Un programme ABAP se compose généralement de plusieurs zones :
L'ordre de ces zones est important : les déclarations doivent précéder leur utilisation. Bien que certains compilateurs ABAP tolèrent des déclarations tardives, il est fortement recommande de grouper toutes les déclarations en début de programme pour une meilleure lisibilité.
La zone d'ouverture contient l'instruction REPORT ou PROGRAM identifiant le programme et définit ses propriétés globales comme la classe de messages ou le format de la liste de sortie.
La zone de déclarations regroupe toutes les définitions de types personnalisés (TYPES), les déclarations de variables (DATA), les constantes (CONSTANTS) et les structures complexes. Cette zone peut également contenir les déclarations de tables internes et de ranges.
La zone d'écran de sélection définit les paramètres de saisie que l'utilisateur devra renseigner avant l'exécution du rapport. Ces éléments incluent les champs simples (PARAMETERS) et les intervalles de sélection (SELECT-OPTIONS).
La zone d'événements contient les blocs de code associes aux différents événements du cycle de vie du programme (INITIALIZATION, AT SELECTION-SCREEN, START-OF-SELECTION,...). Chaque événement déclenche l'exécution du code correspondant a un moment précis.
La zone des sous-programmes (FORM...ENDFORM) regroupe les procédures locales au programme. Ces sous-programmes permettent de structurer la logique métier en unités fonctionnelles réutilisables au sein du même programme.
Instruction REPORT
L'instruction REPORT est la pierre angulaire de tout programme de type rapport en ABAP. Elle doit apparaître comme première instruction exécutable du programme et définit les caractéristiques globales de l'application.
Le nom du programme spécifié dans l'instruction REPORT doit correspondre exactement au nom technique du programme entreposé dans le Repository SAP. Cette cohérence est vérifiée par le système lors de l'activation du programme.
Syntaxe complète :
|
REPORT nom_programme [MESSAGE-ID classe_messages] [NO STANDARD PAGE HEADING] [LINE-SIZE largeur] [LINE-COUNT hauteur[(reserve)]] [DEFINING DATABASE nom_ldb]. |
Options :
| Option | Description |
|---|---|
| MESSAGE-ID | Classe de messages pour les instructions MESSAGE. |
| NO STANDARD PAGE HEADING | Supprime l'entête de page standard SAP. |
| LINE-SIZE | Largeur de la liste en caractères (maximum 1023). |
| LINE-COUNT | Nombre de lignes par page et lignes réservées pour le pied de page. |
| DEFINING DATABASE | Associé une base de données logique (LDB). |
L'option MESSAGE-ID est particulièrement importante pour les programmes utilisant l'instruction MESSAGE pour afficher des messages à l'utilisateur. La classe de messages (par exemple ZMV) regroupe les textes de messages dans le Repository et facilite leur maintenance et leur traduction.
L'option NO STANDARD PAGE HEADING désactive l'entête de page automatique que SAP génère par défaut. Cet entête contient le titre du rapport, le nom du système, la date et l'heure. En désactivant cet entête, le développeur peut créer son propre entête personnalisé via l'événement TOP-OF-PAGE.
Les options LINE-SIZE et LINE-COUNT contrôlent les dimensions de la liste de sortie. LINE-SIZE définit la largeur maximale en caractères (par défaut 83), tandis que LINE-COUNT spécifie le nombre de lignes par page et optionnellement le nombre de lignes réservées pour le pied de page.
Exemples :
- REPORT ZMONPROG.
-
- REPORT ZRAPPORT_VENTES MESSAGE-ID ZMV
- NO STANDARD PAGE HEADING
- LINE-SIZE 132
- LINE-COUNT 65(3).
Dans le second exemple, le rapport utilise une largeur de 132 caractères (format paysage), 65 lignes par page dont 3 sont réservées pour un éventuel pied de page.
Instruction PROGRAM
L'instruction PROGRAM est fonctionnellement similaire a REPORT mais son utilisation est généralement réservée aux programmes qui ne produisent pas de sortie de liste standard. Elle est souvent employée dans les programmes d'arrière-plan (batch), les programmes de traitement de données ou les programmes auxiliaires.
Historiquement, REPORT était destiné aux programmes interactifs avec sortie liste, tandis que PROGRAM convenait mieux aux traitements par lots (batch). Aujourd'hui, cette distinction est moins stricte et les deux instructions peuvent être utilisées de manière interchangeable dans la plupart des cas.
Syntaxe :
| PROGRAM nom_programme [MESSAGE-ID classe_messages]. |
L'instruction PROGRAM accepte moins d'options que REPORT car elle ne présuppose pas une sortie liste. Les options relatives au formatage de la liste (LINE-SIZE, LINE-COUNT, NO STANDARD PAGE HEADING) ne sont donc pas disponibles.
Exemple :
- PROGRAM ZMONPROGRAMME MESSAGE-ID ZM.
Dans la pratique moderne, REPORT est utilise pour la grande majorité des développements, même pour les programmes de traitement par lots (batch), car il offre plus de flexibilité pour la gestion des messages et la sortie éventuelle d'informations de suivi.
Convention de nommage
Les conventions de nommage en SAP jouent un rôle crucial pour distinguer les objets standards des développements spécifiques (customizing) et pour maintenir une organisation cohérente du code. Ces conventions sont parfois imposées par le système et parfois recommandées comme bonnes pratiques.
Dans un système SAP, les objets client (développements spécifiques) commencent par Y ou Z. Cette règle est appliquée par le système SAP lors de la création de nouveaux objets dans l'espace de noms client. Les lettres Y et Z ont été réservées par SAP pour garantir qu'aucun objet standard n'entrera jamais en conflit avec les développements spécifiques lors des mises a niveau du système.
- ZRAP_COMMANDES : Rapport sur les commandes
- ZCLI_FOURNISSEUR : Classe fournisseur
- ZFM_CALCUL_TVA : Groupe de fonctions pour la TVA
Les noms sans préfixe Y/Z sont réservés aux objets standards SAP. Modifier ces objets (a l'exception des user-exits et des BAdI prévus à cet effet) constitue une modification du standard et peut entraîner des problèmes lors des mises a niveau.
Au-delà du préfixe Y/Z, de nombreuses organisations adoptent des conventions internes pour structurer leurs noms d'objets. Une convention courante inclut :
- Un préfixe d'application (exemple: ZSD_ pour Sales & Distribution)
- Un indicateur de type d'objet (ex: _R pour rapport, _F pour fonction)
- Un nom descriptif en anglais ou dans la langue locale
Par exemple : ZSD_R_SALES_ANALYSIS pourrait designer un rapport d'analyse des ventes dans le module SD.
Pour les variables locales, les conventions SAP recommandent des préfixes indiquant la portée et le type :
- gv_ : variable globale (global variable)
- lv_ : variable locale (local variable)
- gt_ : table interne globale (global table)
- lt_ : table interne locale (local table)
- gs_ : structure globale (global structure)
- ls_ : structure locale (local structure)
- gc_ : constante globale (global constant)
- p_ : paramètre d'écran de sélection
- s_ : select-option
Exemple complet
Voici un exemple de programme ABAP complet illustrant la structure et les bonnes pratiques de codage. Ce programme démonstratif charge une liste de clients et l'affiche a l'écran en fonction des critères de sélection saisis par l'utilisateur.
L'exemple montre l'organisation typique d'un rapport ABAP avec ses différentes zones clairement délimitées par des commentaires. Cette structure facilite la navigation dans le code et la maintenance future du programme.
- *----------------------------------------------------------------------*
- * Programme : ZEXEMPLE_STRUCTURE
- * Auteur : Developpeur SAP
- * Date : 2024
- * Description : Exemple de structure d'un programme ABAP
- *----------------------------------------------------------------------*
- REPORT ZEXEMPLE_STRUCTURE MESSAGE-ID ZM
- NO STANDARD PAGE HEADING
- LINE-SIZE 80.
-
- *----------------------------------------------------------------------*
- * Declarations globales
- *----------------------------------------------------------------------*
- TYPES: BEGIN OF ty_client,
- numero TYPE I,
- nom TYPE C LENGTH 30,
- ville TYPE C LENGTH 20,
- END OF ty_client.
-
- DATA: gv_compteur TYPE I,
- gt_clients TYPE TABLE OF ty_client,
- gs_client TYPE ty_client.
-
- CONSTANTS: gc_max_clients TYPE I VALUE 100.
-
- *----------------------------------------------------------------------*
- * Ecran de selection
- *----------------------------------------------------------------------*
- PARAMETERS: p_ville TYPE C LENGTH 20.
-
- *----------------------------------------------------------------------*
- * Evenement INITIALIZATION
- *----------------------------------------------------------------------*
- INITIALIZATION.
- p_ville = 'PARIS'.
-
- *----------------------------------------------------------------------*
- * Evenement START-OF-SELECTION (traitement principal)
- *----------------------------------------------------------------------*
- START-OF-SELECTION.
- PERFORM charger_donnees.
- PERFORM afficher_liste.
-
- *----------------------------------------------------------------------*
- * Sous-programmes
- *----------------------------------------------------------------------*
- FORM charger_donnees.
- " Chargement des donnees (simulation)
- gs_client-numero = 1.
- gs_client-nom = 'Dupont'.
- gs_client-ville = p_ville.
- APPEND gs_client TO gt_clients.
- ENDFORM.
-
- FORM afficher_liste.
- LOOP AT gt_clients INTO gs_client.
- WRITE: / gs_client-numero, gs_client-nom, gs_client-ville.
- ENDLOOP.
- ENDFORM.
Dans cet exemple, on remarque plusieurs éléments importants :
- L'entête de programme documente l'auteur, la date et la finalité du programme.
- Les déclarations TYPES définissent des structures personnalisées avant leur utilisation dans DATA.
- Les noms de variables suivent les conventions (gv_ pour les variables globales, gt_ pour les tables, gs_ pour les structures).
- L'événement INITIALIZATION initialise les valeurs par défaut avant l'affichage de l'écran de sélection.
- Le traitement principal est encapsulé dans des sous-programmes (FORM) pour une meilleure structuration.
Instruction INCLUDE
L'instruction INCLUDE est un mécanisme fondamental pour la modularisation du code ABAP. Elle permet d'insérer le contenu d'un programme INCLUDE à l'emplacement de l'instruction, comme si le code était directement écrit à cet endroit. Cette technique favorise la modularité et la reutilisation du code entre plusieurs programmes.
Lors de la compilation, le système SAP remplace chaque instruction INCLUDE par le contenu du programme référence. Cette opération est transparente pour le développeur et n'a aucun impact sur les performances d'exécution.
Syntaxe :
| INCLUDE nom_include. |
Un programme de type INCLUDE (type I) ne peut pas être exécute de manière autonome. Il ne contient généralement pas d'instruction REPORT ou PROGRAM et se compose uniquement de déclarations ou de sous-programmes destines a être incorpores dans d'autres programmes.
Exemple d'utilisation :
- REPORT ZMONPROG.
- INCLUDE ZMONPROG_TYPES. " Declarations de types
- INCLUDE ZMONPROG_DATA. " Declarations de donnees
- INCLUDE ZMONPROG_FORMS. " Sous-programmes
L'utilisation d'INCLUDEs permet de diviser un programme volumineux en plusieurs fichiers logiques, facilitant le travail collaboratif et la maintenance. Chaque développeur peut travailler sur un INCLUDE différent sans risquer de conflits.
SAP a établi des conventions de nommage pour les INCLUDEs étant largement adoptées dans les programmes standards et recommandées pour les développements spécifiques :
Convention SAP pour les includes :
- nom_TOP : Déclarations globales (types, données, constantes)
- nom_FXX : Sous-programmes (F01, F02, ...)
- nom_IXX : Modules PBO/PAI (I01, I02, ...)
- nom_OXX : Modules PBO (O01, O02, ...)
- nom_EXX : Evénements (E01, E02, ...)
Par exemple, un programme ZMM_COMMANDES pourrait avoir les INCLUDEs suivants :
- ZMM_COMMANDES_TOP : Déclarations globales
- ZMM_COMMANDES_F01 : Sous-programmes de lecture des données
- ZMM_COMMANDES_F02 : Sous-programmes d'affichage
- ZMM_COMMANDES_E01 : Gestion des événements utilisateur
Cette organisation permet de localiser rapidement le code recherche et facilite grandement la maintenance des applications complexes.
Ordre d'exécution
La compréhension de l'ordre d'exécution des événements est essentielle pour développer des programmes ABAP corrects et efficaces. Contrairement a de nombreux langages ou le code s'exécute séquentiellement du début à la fin, ABAP utilise un modèle événementiel ou différents blocs de code sont déclenchés a des moments spécifiques du cycle de vie du programme.
L'exécution d'un programme ABAP de type rapport suit un ordre précis pouvant être décomposé en plusieurs phases :
- 1. Chargement du programme en mémoire
- 2. Exécution du bloc LOAD-OF-PROGRAM (si présent)
- 3. Exécution du bloc INITIALIZATION
- 4. Affichage de l'écran de sélection
- 5. Exécution du bloc AT SELECTION-SCREEN
- 6. Exécution du bloc START-OF-SELECTION
- 7. Exécution du bloc END-OF-SELECTION
- 8. Fin du programme
Examinons chaque phase en détail :
Phase 1 - Chargement : Le système charge le programme compile depuis la base de données vers la mémoire de travail. Les variables sont initialisées a leurs valeurs par défaut.
Phase 2 - LOAD-OF-PROGRAM : Cet événement est rarement utilise. Il est déclenché une seule fois lors du premier chargement du programme dans une session utilisateur.
Phase 3 - INITIALIZATION : C'est le premier bloc exécute dans le flux normal. Il permet d'initialiser les valeurs par défaut des paramètres d'écran de sélection et de préparer l'environnement d'exécution. Les valeurs affectées aux paramètres dans ce bloc apparaîtront comme valeurs par défaut à l'écran.
Phase 4 - Ecran de sélection : Le système affiche l'écran de sélection (s'il existe) et attend la saisie de l'utilisateur. L'utilisateur remplit les critères et appuie sur Exécuter (F8).
Phase 5 - AT SELECTION-SCREEN : Ce bloc est déclenché après que l'utilisateur a valide l'écran de sélection. Il permet de valider les saisies, d'afficher des messages d'erreur ou de modifier les valeurs avant le traitement principal.
Phase 6 - START-OF-SELECTION : C'est le coeur du programme. Ce bloc contient la logique principale : lecture des données, traitements, calculs et préparation de la sortie. Pour les rapports utilisant une base de données logique (LDB), c'est a ce moment que les données sont lues.
Phase 7 - END-OF-SELECTION : Ce bloc est exécute après la fin de START-OF-SELECTION. Il est utilise pour les traitements finaux comme le calcul des totaux, l'affichage des statistiques ou la génération de la sortie finale.
Phase 8 - Fin : Le programme se termine et libère les ressources mémoire.
Dans un programme simple sans événements déclarés explicitement, le code est exécuté séquentiellement comme s'il était contenu dans un bloc START-OF-SELECTION implicite. Cela permet d'écrire des programmes simples sans se soucier des événements.
Il existe d'autres événements spécifiques a certains contextes :
- TOP-OF-PAGE : En-tête de chaque nouvelle page de liste
- END-OF-PAGE : Pied de page
- AT LINE-SELECTION : Action double-clic sur une ligne
- AT USER-COMMAND : Action sur un bouton ou menu personnalisé
- AT PFnn : Action sur une touche de fonction
La maîtrise de ces événements permet de créer des rapports interactifs offrant une expérience utilisateur riche et intuitive.