ABAP Objet (ABAP OO) : guide pour DSI S/4HANA (classes, RAP, tests unitaires)

L'ABAP a 40 ans. Pendant deux décennies, le langage est resté principalement procédural : programmes monolithiques, includes, FORM / PERFORM, variables globales, sessions partagées. Cette époque produisait un code qui fonctionnait, mais qui résistait mal à l'évolution : pas de tests, peu de réutilisation, traçabilité difficile.

L'ABAP Objet (ABAP OO) a été introduit en 2000. Il a mis vingt ans à devenir vraiment incontournable. C'est S/4HANA qui a tranché : à partir de 2020, l'ensemble de la nouvelle pile technique SAP (RAP, AMDP, BAdI cloud, ABAP Unit, extensions CDS) est exclusivement orientée objet. Pour une DSI, ne plus disposer de développeurs ABAP OO compétents sur 2026, c'est s'exposer à un coût d'externalisation élevé et à des risques de qualité significatifs.

ABAP procédural vs ABAP Objet : ce qui change vraiment

Dans un programme ABAP procédural, la logique est organisée en blocs (modules, FORM, sous-programmes) qui se passent des données via des variables globales ou des paramètres. La portée est large : toute variable déclarée dans une dataset est accessible depuis n'importe quelle FORM. Le code est lisible verticalement, mais l'isolement des responsabilités est faible.

En ABAP Objet, l'unité d'organisation est la classe. Une classe encapsule un état (attributs) et un comportement (méthodes). L'accès à l'état est strictement contrôlé via la visibilité (public, protected, private). Deux instances de la même classe sont totalement indépendantes — l'une ne peut pas accidentellement écraser l'état de l'autre.

Les bénéfices concrets dans un projet S/4HANA :

• Réutilisation contrôlée : une classe métier (Order, Customer, Invoice) est utilisée depuis dix endroits sans risque d'effet de bord global
• Testabilité : une classe avec interface peut être mockée — c'est la base d'ABAP Unit
• Lisibilité : la signature d'une méthode déclare explicitement ses entrées, ses sorties, ses exceptions levées
• Maintenance : un changement d'implémentation dans une classe n'impacte pas les appelants tant que le contrat est respecté

Classes et instances

Une classe ABAP est un type. Pour l'utiliser, on en crée une instance via NEW (ou CREATE OBJECT en syntaxe historique). Chaque instance dispose de sa propre copie des attributs. Les méthodes d'instance opèrent sur cette copie via la référence me->.

Une classe peut aussi avoir des attributs et des méthodes statiques (mot-clé CLASS-DATA, CLASS-METHODS) qui sont partagés par toutes les instances et appelés sans instanciation : cl_kai_helper=>get_default_currency( ). Les méthodes statiques sont utiles pour les utilitaires sans état, mais sur-utilisées elles produisent du code difficile à tester — un anti-pattern fréquent à corriger en revue.

Conventions de nommage standard sur un projet S/4HANA :

• ZCL_KAI_* pour une classe globale spécifique
• ZIF_KAI_* pour une interface globale
• ZCX_KAI_* pour une exception de classe
• LCL_* pour une classe locale au sein d'un programme

Héritage et interfaces : les deux outils d'abstraction

L'héritage (mot-clé INHERITING FROM) permet à une classe de réutiliser et spécialiser le comportement d'une classe parente. ABAP Objet supporte l'héritage simple uniquement — une classe ne peut hériter que d'une seule classe parente. Cette contrainte est volontaire : elle évite le « diamant » d'héritage multiple qui a posé tant de problèmes en C++.

Une interface (INTERFACE … ENDINTERFACE) définit un contrat de signatures de méthodes sans implémentation. Une classe peut implémenter plusieurs interfaces simultanément via INTERFACES zif_a, zif_b, zif_c. C'est la réponse pragmatique au besoin d'héritage multiple.

Règle de pouce :

• Préférer une interface quand on veut découpler un contrat d'appel des implémentations possibles (cas idéal pour les mocks de tests unitaires)
• Préférer une classe abstraite quand plusieurs implémentations partagent une logique commune qu'on veut factoriser

Polymorphisme et classes abstraites

Le polymorphisme est la capacité d'appeler la même méthode sur des objets de types différents et d'obtenir des comportements adaptés. En ABAP OO, on l'obtient via deux mécanismes complémentaires :

• Redefinition : une classe fille redéfinit (REDEFINITION) une méthode héritée et fournit son propre comportement
• Implémentation d'interface : plusieurs classes implémentent une même interface chacune à sa manière

Une classe abstraite (ABSTRACT) ne peut pas être instanciée directement. Elle sert de base à des classes concrètes qui complètent l'implémentation. Une méthode abstraite n'a pas de corps — chaque classe fille est tenue de la redéfinir. C'est l'outil idéal pour exprimer « il existe un cycle de validation commun, mais chaque type d'objet métier a sa règle spécifique ».

Exceptions de classe (CX_)

Les exceptions classiques ABAP (transmises par SY-SUBRC ou via RAISING … en mode legacy) sont obsolètes sur du code RAP. Le standard est aujourd'hui le système d'exceptions de classe — toutes les exceptions héritent de CX_ROOT.

Trois familles principales :

• CX_STATIC_CHECK : exceptions vérifiées par le compilateur (le développeur est obligé de les déclarer ou de les attraper)
• CX_DYNAMIC_CHECK : exceptions vérifiées à l'exécution (la déclaration est optionnelle)
• CX_NO_CHECK : exceptions techniques (échecs système, erreurs de connexion DB) non capturées par défaut

Voici un exemple de classe ABAP OO complète : une classe ZCL_KAI_SALES_ORDER qui implémente une interface ZIF_KAI_VALIDATABLE, hérite d'une classe abstraite ZCL_KAI_BUSINESS_OBJECT, et lève une exception métier dédiée.

"! <p class="shorttext">Exception métier - Commande client</p>
CLASS zcx_kai_sales_order DEFINITION
  PUBLIC INHERITING FROM cx_static_check FINAL CREATE PUBLIC.
  PUBLIC SECTION.
    INTERFACES if_t100_message.

    METHODS constructor
      IMPORTING textid    LIKE if_t100_message=>t100key OPTIONAL
                previous  LIKE previous OPTIONAL
                order_id  TYPE vbeln    OPTIONAL.

    DATA order_id TYPE vbeln READ-ONLY.
ENDCLASS.

"! <p class="shorttext">Business Object - Commande client</p>
CLASS zcl_kai_sales_order DEFINITION
  PUBLIC INHERITING FROM zcl_kai_business_object CREATE PUBLIC.
  PUBLIC SECTION.
    INTERFACES zif_kai_validatable.

    METHODS constructor
      IMPORTING io_repository TYPE REF TO zif_kai_repository.

    METHODS approve
      RAISING zcx_kai_sales_order.

  PRIVATE SECTION.
    DATA mo_repository TYPE REF TO zif_kai_repository.
    DATA ms_header     TYPE zsales_order_header.
ENDCLASS.

CLASS zcl_kai_sales_order IMPLEMENTATION.
  METHOD zif_kai_validatable~validate.
    IF ms_header-net_amount IS INITIAL.
      RAISE EXCEPTION TYPE zcx_kai_sales_order
        EXPORTING order_id = ms_header-vbeln
                  textid   = zcx_kai_sales_order=>empty_amount.
    ENDIF.
  ENDMETHOD.

  METHOD approve.
    zif_kai_validatable~validate( ).
    " ... logique d'approbation
  ENDMETHOD.
ENDCLASS.

ABAP Unit : tester comme on code en TypeScript

ABAP Unit est le framework de tests unitaires intégré au runtime ABAP depuis 2006. Sur S/4HANA, son usage est devenu standard — et obligatoire dans certains contextes (BAdI cloud, ABAP for Cloud). Pour une DSI, c'est l'investissement avec le meilleur ratio coût / qualité sur un parc de spécifiques.

Une classe de test est une classe locale annotée FOR TESTING à l'intérieur de la classe testée :

• Méthodes de test : annotées FOR TESTING, exécutées indépendamment
• Setup / Teardown : SETUP et TEARDOWN appelées avant et après chaque méthode
• Mocks : générés via cl_abap_testdouble=>create( … ) ou des classes test doubles maison
• Assertions : cl_abap_unit_assert=>assert_equals( ) et compagnie

Sur un projet S/4HANA correctement industrialisé, on attend un taux de couverture d'au moins 70 % sur la logique métier des Behavior Implementation Classes RAP, et 90 % sur les utilitaires partagés. Sous ces seuils, la dette de tests devient un facteur de régression à chaque upgrade SAP.

ABAP OO et RAP : indissociables

La Behavior Implementation Class — le cœur de la logique métier d'un Business Object RAP — est obligatoirement une classe ABAP globale annotée FOR BEHAVIOR OF. Elle implémente des méthodes correspondant aux actions, validations et déterminations déclarées dans la BDEF.

Sans maîtrise solide d'ABAP OO, écrire un RAP correct est impossible. Les concepts clés sollicités quotidiennement :

• Interfaces pour découpler la classe d'implémentation des contrats RAP
• Exceptions CX_ pour propager proprement les erreurs métier vers le framework
• ABAP Unit pour tester unitairement les actions et validations
• Dependency injection pour mocker les accès base de données dans les tests

Pourquoi l'ABAP OO est obligatoire sur S/4HANA

Au-delà des bénéfices intrinsèques (testabilité, maintenance, lisibilité), trois facteurs rendent l'ABAP OO non négociable sur S/4HANA :

1. RAP est exclusivement orienté objet. Toute nouvelle app Fiori s'écrit en RAP, donc en classes
2. L'ABAP for Cloud (BTP ABAP Environment, RISE with SAP) restreint les langages autorisés. Le procédural y est massivement limité, l'OO y est la norme
3. La stratégie Clean Core (voir notre article dédié) impose des objets Released — qui sont quasi exclusivement des interfaces et classes

Pour une DSI qui gère un parc historique d'équipes ABAP procédurales, la trajectoire recommandée est un plan de formation sur 6 à 12 mois : une semaine de formation initiale par développeur, suivie de coaching sur projet sur un premier RAP simple, puis montée en autonomie sur les patterns avancés. Sur la migration Kuhn Group, l'équipe interne ABAP a été montée en compétence sur ce modèle en 9 mois, à l'issue desquels elle a repris la maintenance de l'ensemble du périmètre RAP sans intervention externe.