Le modele 3-Tier dans ABAP Cloud : Migration structuree depuis Classic ABAP

Catégorie

ABAP Cloud

Publié

15. Feb. 2026

Auteur

Le modele 3-Tier est un modele d’architecture eprouve pour la migration progressive de Classic ABAP vers ABAP Cloud. Il permet une coexistence structuree des deux mondes et definit des responsabilites claires pour chaque couche. Cet article explique les trois Tiers, montre des exemples de code pratiques avec le scenario de reservation de vol et donne des conseils sur l’organisation des packages.

Pourquoi un modele Tier ?

La migration de Classic ABAP vers ABAP Cloud n’est pas une tache qui peut etre accomplie du jour au lendemain. Dans la plupart des entreprises, il y a des millions de lignes de code custom qui doivent etre modernisees progressivement. Le modele 3-Tier offre une approche structuree pour cela :

Separation claire entre le code pret pour le cloud et le code legacy
Migration controlee sans risque de big-bang
Reutilisabilite des fonctionnalites existantes via des wrappers
Conformite ATC grace a une separation propre des couches

Vue d’ensemble des trois Tiers

┌─────────────────────────────────────────────────────────┐
│ TIER-1 : ABAP Cloud                                      │
│ ───────────────────                                     │
│ • Nouveaux developpements                                │
│ • RAP Business Objects                                  │
│ • Uniquement des APIs Released                          │
│ • Version du langage ABAP Cloud                         │
│ • Perenne et pret pour le cloud                         │
└─────────────────────┬───────────────────────────────────┘
                      │ Appels uniquement via des APIs Released
                      ▼
┌─────────────────────────────────────────────────────────┐
│ TIER-2 : API-Wrapper                                     │
│ ───────────────────                                     │
│ • Encapsule les fonctionnalites Classic ABAP            │
│ • Fournit des APIs Released (C1-Contract)               │
│ • Pont entre Cloud et Classic                           │
│ • Contient la logique de transformation                 │
└─────────────────────┬───────────────────────────────────┘
                      │ Appels internes
                      ▼
┌─────────────────────────────────────────────────────────┐
│ TIER-3 : Classic ABAP                                    │
│ ───────────────────                                     │
│ • Code legacy existant                                  │
│ • APIs non-released                                     │
│ • Acces directs a la BD                                 │
│ • Migre ou retire progressivement                       │
└─────────────────────────────────────────────────────────┘

TIER-1 : ABAP Cloud

Le TIER-1 est la couche superieure et contient exclusivement du code conforme a ABAP Cloud. C’est ici que tous les nouveaux developpements sont effectues, et des regles strictes s’appliquent :

Caracteristiques du TIER-1

Version du langage : ABAP for Cloud Development
APIs : Uniquement des APIs Released (C1-Contract)
Modele de programmation : RAP (ABAP RESTful Application Programming Model)
Environnement de developpement : ABAP Development Tools (ADT)

Exemple de reservation de vol : RAP Business Object

" TIER-1 : Vue CDS pour les reservations de vol (ABAP Cloud)
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Reservation de vol"
define root view entity ZI_FlightBooking
  as select from zflight_book
{
  key booking_id     as BookingId,
      flight_id      as FlightId,
      customer_id    as CustomerId,
      booking_date   as BookingDate,
      @Semantics.amount.currencyCode: 'CurrencyCode"
      price          as Price,
      currency_code  as CurrencyCode,
      booking_status as BookingStatus
}

La Behavior Definition associee definit la logique metier :

" TIER-1 : Behavior Definition
managed implementation in class zbp_i_flightbooking unique;
strict ( 2 );

define behavior for ZI_FlightBooking alias FlightBooking
persistent table zflight_book
lock master
authorization master ( instance )
{
  create;
  update;
  delete;

  " Action pour confirmer la reservation
  action confirmBooking result [1] $self;

  " Validation des donnees de reservation
  validation validateCustomer on save
    { field CustomerId; }

  " Mapping pour les champs legacy
  mapping for zflight_book
  {
    BookingId     = booking_id;
    FlightId      = flight_id;
    CustomerId    = customer_id;
    BookingDate   = booking_date;
    Price         = price;
    CurrencyCode  = currency_code;
    BookingStatus = booking_status;
  }
}

Pour plus d’informations sur RAP et les Business Objects, consultez l’article Fondamentaux RAP.

TIER-2 : API-Wrapper

Le TIER-2 est le pont entre ABAP Cloud et Classic ABAP. Ici, des classes wrapper sont creees qui encapsulent les fonctionnalites Classic et les exposent en tant qu’APIs Released.

Caracteristiques du TIER-2

Version du langage : Standard ABAP (Classic)
Statut API : Released (C1-Contract)
Objectif : Encapsulation et transformation
Verification ATC : Doit etre propre pour le release

Exemple de reservation de vol : API-Wrapper

" TIER-2 : Classe Wrapper pour l'acces aux donnees de vol
" Statut API : Released (C1-Contract)
CLASS zcl_flight_api DEFINITION
  PUBLIC
  FINAL
  CREATE PUBLIC.

  PUBLIC SECTION.
    TYPES:
      BEGIN OF ty_flight_info,
        flight_id    TYPE zflight_id,
        carrier_id   TYPE s_carr_id,
        connection   TYPE s_conn_id,
        flight_date  TYPE s_date,
        seats_free   TYPE s_seatsocc,
        price        TYPE s_price,
        currency     TYPE s_currcode,
      END OF ty_flight_info,
      tt_flight_info TYPE STANDARD TABLE OF ty_flight_info WITH EMPTY KEY.

    " API Released pour le TIER-1
    CLASS-METHODS get_available_flights
      IMPORTING
        iv_carrier    TYPE s_carr_id OPTIONAL
        iv_date_from  TYPE s_date OPTIONAL
        iv_date_to    TYPE s_date OPTIONAL
      RETURNING
        VALUE(rt_flights) TYPE tt_flight_info
      RAISING
        cx_flight_not_found.

    CLASS-METHODS check_seat_availability
      IMPORTING
        iv_flight_id  TYPE zflight_id
        iv_seats      TYPE i
      RETURNING
        VALUE(rv_available) TYPE abap_bool.

  PRIVATE SECTION.
    " Helpers internes pour l'acces au TIER-3
    CLASS-METHODS _fetch_from_legacy
      IMPORTING
        iv_carrier   TYPE s_carr_id OPTIONAL
      RETURNING
        VALUE(rt_data) TYPE tt_flight_info.
ENDCLASS.

CLASS zcl_flight_api IMPLEMENTATION.
  METHOD get_available_flights.
    " Appelle la logique TIER-3 et transforme les donnees
    DATA(lt_legacy_data) = _fetch_from_legacy( iv_carrier ).

    " Filtrage et preparation pour les consommateurs Cloud
    LOOP AT lt_legacy_data INTO DATA(ls_flight).
      IF ( iv_date_from IS INITIAL OR ls_flight-flight_date >= iv_date_from )
         AND ( iv_date_to IS INITIAL OR ls_flight-flight_date <= iv_date_to ).
        APPEND ls_flight TO rt_flights.
      ENDIF.
    ENDLOOP.

    IF rt_flights IS INITIAL.
      RAISE EXCEPTION TYPE cx_flight_not_found.
    ENDIF.
  ENDMETHOD.

  METHOD check_seat_availability.
    " Wrapper pour la verification de disponibilite legacy
    DATA(lo_legacy) = NEW zcl_flight_legacy( ).
    rv_available = lo_legacy->check_seats(
      iv_flight_id = iv_flight_id
      iv_seats     = iv_seats
    ).
  ENDMETHOD.

  METHOD _fetch_from_legacy.
    " Appel TIER-3 - APIs non-released encapsulees
    " Acces direct a SFLIGHT (non released)
    SELECT flight_id, carrid, connid, fldate, seatsocc, price, currency
      FROM sflight
      WHERE carrid = @iv_carrier OR @iv_carrier IS INITIAL
      INTO CORRESPONDING FIELDS OF TABLE @rt_data.
  ENDMETHOD.
ENDCLASS.

TIER-3 : Classic ABAP

Le TIER-3 contient le code legacy existant qui sera progressivement modernise ou retire. Ce code utilise des APIs non-released et des acces directs a la base de donnees.

Caracteristiques du TIER-3

Version du langage : Standard ABAP (Classic)
APIs : Non-released, objets SAP internes
Acces : Acces directs a la BD, BAPIs, Function Modules
Objectif : Migration vers le TIER-1 ou encapsulation par le TIER-2

Exemple de reservation de vol : Code legacy

" TIER-3 : Classe Legacy (appelee uniquement par le TIER-2)
CLASS zcl_flight_legacy DEFINITION
  PUBLIC
  FINAL
  CREATE PUBLIC.

  PUBLIC SECTION.
    METHODS check_seats
      IMPORTING
        iv_flight_id TYPE zflight_id
        iv_seats     TYPE i
      RETURNING
        VALUE(rv_available) TYPE abap_bool.

    METHODS book_flight_legacy
      IMPORTING
        iv_flight_id  TYPE zflight_id
        iv_customer   TYPE kunnr
        iv_seats      TYPE i
      EXPORTING
        ev_booking_id TYPE zbook_id
      RAISING
        cx_booking_failed.
ENDCLASS.

CLASS zcl_flight_legacy IMPLEMENTATION.
  METHOD check_seats.
    " Acces direct a une table non-released
    SELECT SINGLE seatsmax, seatsocc
      FROM sflight
      WHERE flight_id = @iv_flight_id
      INTO @DATA(ls_flight).

    IF sy-subrc = 0.
      rv_available = xsdbool( ls_flight-seatsmax - ls_flight-seatsocc >= iv_seats ).
    ENDIF.
  ENDMETHOD.

  METHOD book_flight_legacy.
    " Appel BAPI legacy
    CALL FUNCTION 'BAPI_FLIGHT_BOOKING_CREATE"
      EXPORTING
        flight_id      = iv_flight_id
        customer       = iv_customer
        seats_required = iv_seats
      IMPORTING
        booking_number = ev_booking_id
      EXCEPTIONS
        flight_full    = 1
        OTHERS         = 2.

    IF sy-subrc <> 0.
      RAISE EXCEPTION TYPE cx_booking_failed.
    ENDIF.
  ENDMETHOD.
ENDCLASS.

Pour des informations detaillees sur la distinction entre Classic et Cloud ABAP, voir ABAP Cloud vs Classic ABAP.

L’objet d’autorisation S_ABPLNGVS

Un element central pour le controle des versions de langage est l’objet d’autorisation S_ABPLNGVS. Il controle quelle version du langage ABAP un developpeur peut utiliser dans quels packages.

Champs de l’objet d’autorisation

Champ	Signification	Valeurs
`ACTIVITY`	Activite	`01` (Creer), `02` (Modifier), `03` (Afficher)
`DEVCLASS`	Package	Nom du package ou `*` pour tous
`ABPLNGVS`	Version du langage	`STANDARD`, `ABAP_FOR_CLOUD_DEVELOPMENT`

Exemple de configuration

Role : Z_ABAP_CLOUD_DEVELOPER
─────────────────────────────────
S_ABPLNGVS:
  ACTIVITY: 01, 02, 03
  DEVCLASS: ZT1_*
  ABPLNGVS: ABAP_FOR_CLOUD_DEVELOPMENT

S_ABPLNGVS:
  ACTIVITY: 01, 02, 03
  DEVCLASS: ZT2_*, ZT3_*
  ABPLNGVS: STANDARD

Cette configuration permet :

Developpement ABAP Cloud uniquement dans les packages avec le prefixe ZT1_
Classic ABAP dans les packages avec les prefixes ZT2_ et ZT3_

Conseils pratiques pour l’organisation des packages

Une structure de packages bien pensee est essentielle pour la mise en oeuvre reussie du modele 3-Tier.

Convention de nommage recommandee

Z<PROJET>_<TIER>_<DOMAINE>

Exemples :
─────────────────────────────────────────────
ZFB_T1_BOOKING     → TIER-1, Reservation de vol (ABAP Cloud)
ZFB_T1_REPORTING   → TIER-1, Reporting (ABAP Cloud)
ZFB_T2_FLIGHT_API  → TIER-2, Flight API Wrapper
ZFB_T2_CUSTOMER    → TIER-2, Customer API Wrapper
ZFB_T3_LEGACY      → TIER-3, Code Legacy
ZFB_T3_MIGRATION   → TIER-3, Objets a migrer

Structure de packages pour la reservation de vol

$ZFB (Superpackage)
├── ZFB_T1 (Package principal TIER-1)
│   ├── ZFB_T1_BOOKING
│   │   ├── ZI_FlightBooking (CDS Entity)
│   │   ├── ZBP_I_FlightBooking (Behavior Impl.)
│   │   └── ZUI_FlightBooking_O4 (Service Binding)
│   ├── ZFB_T1_CUSTOMER
│   │   └── ... (Gestion des clients)
│   └── ZFB_T1_REPORTING
│       └── ... (Evaluations)
│
├── ZFB_T2 (Package principal TIER-2)
│   ├── ZFB_T2_FLIGHT_API
│   │   ├── ZCL_FLIGHT_API (Released Wrapper)
│   │   └── ZIF_FLIGHT_API (Interface)
│   └── ZFB_T2_PRICING
│       └── ZCL_PRICING_API (Calcul des prix)
│
└── ZFB_T3 (Package principal TIER-3)
    ├── ZFB_T3_LEGACY
    │   ├── ZCL_FLIGHT_LEGACY
    │   └── ZFLIGHT_BOOKING_FORM (ancien Report)
    └── ZFB_T3_DEPRECATED
        └── ... (objets retires)

Definir la version du langage par package

Dans les proprietes du package dans ADT :

ZFB_T1_BOOKING:
  Proprietes → ABAP Language Version → "ABAP for Cloud Development"
  → Le compilateur applique les regles ABAP Cloud !

ZFB_T2_FLIGHT_API:
  Proprietes → ABAP Language Version → "Standard ABAP"
  → Permet Classic ABAP, mais l'API doit etre released

ZFB_T3_LEGACY:
  Proprietes → ABAP Language Version → "Standard ABAP"
  → Liberte complete, mais utilise uniquement en interne

Structure des composants logiciels

Pour les projets plus importants, l’organisation en composants logiciels est recommandee :

" Composants logiciels pour le systeme de reservation de vol
"
" Composant : ZFLIGHTBOOKING
" ───────────────────────────────────────────
" Transport Layer : ZDEV
" Delivery Unit : ZFLIGHTBOOKING_DU
"
" Structure :
" ├── Couche Application (TIER-1)
" │   └── Package : ZFB_T1 (ABAP Cloud)
" │
" ├── Couche API (TIER-2)
" │   └── Package : ZFB_T2 (Standard + Released)
" │
" └── Couche Legacy (TIER-3)
"     └── Package : ZFB_T3 (Standard, non released)

Regles de dependance

┌─────────────────────────────────────────────────────────┐
│                    Appels autorises                      │
├─────────────────────────────────────────────────────────┤
│ TIER-1 → TIER-2    ✅ (via APIs Released)               │
│ TIER-1 → TIER-3    ❌ (interdit - Erreur ATC !)         │
│ TIER-2 → TIER-3    ✅ (encapsulation interne)           │
│ TIER-3 → TIER-2    ⚠️ (possible, mais non recommande)   │
│ TIER-3 → TIER-1    ❌ (Dependance circulaire)           │
└─────────────────────────────────────────────────────────┘

Strategie de migration : Du TIER-3 au TIER-1

La strategie a long terme est la migration progressive du TIER-3 vers le TIER-1 :

Phase 1 : Identification
─────────────────────────
• Analyser le code TIER-3
• Effectuer les verifications ATC
• Documenter les dependances

Phase 2 : Wrapper (TIER-2)
─────────────────────────
• API-Wrapper pour les fonctions critiques
• Definir les APIs Released
• Ecrire les tests

Phase 3 : Migration (TIER-1)
─────────────────────────
• Nouvelle implementation RAP
• Remplacer les wrappers TIER-2
• Desactiver le code legacy

Phase 4 : Nettoyage
─────────────────────────
• Supprimer le code TIER-3
• Retirer les wrappers TIER-2
• Seul le TIER-1 reste

Pour un guide de migration detaille, voir Guide de Migration ABAP Cloud.

Conclusion

Le modele 3-Tier offre une approche structuree pour la migration vers ABAP Cloud :

TIER-1 (ABAP Cloud) : Nouveaux developpements perennes
TIER-2 (API-Wrapper) : Pont vers le monde legacy
TIER-3 (Classic ABAP) : Code ancien a migrer

Grace a une organisation claire des packages avec les prefixes T1/T2/T3, l’objet d’autorisation S_ABPLNGVS et une encapsulation API coherente, la modernisation progressive reussit sans risque.

Important : SAP a depuis introduit le concept de niveaux Clean Core (A-D) comme alternative simplifiee qui reduit la complexite du modele 3-Tier. Examinez les deux approches et choisissez celle qui convient a votre projet.