Checklist d

Catégorie

ABAP Cloud

Publié

15. Feb. 2026

Auteur

Cette checklist d’implementation aide les chefs de projet et les developpeurs a ne rien oublier d’important dans les projets ABAP Cloud. De la preparation initiale du systeme au developpement RAP jusqu’au Go-Live, toutes les etapes critiques sont couvertes.

Vue d’ensemble : Les cinq phases

┌─────────────────────────────────────────────────────────────┐
│ Phase 1: Preparation du projet                               │
│ ────────────────────────────────                             │
│ • Paysage systeme & autorisations                           │
│ • Structure des packages & conventions de nommage           │
│ • Configuration des outils de developpement                 │
└──────────────────────────────────────────────────────────────┘
                              ▼
┌─────────────────────────────────────────────────────────────┐
│ Phase 2: Modele de donnees                                   │
│ ────────────────────                                         │
│ • Conception des tables & elements de donnees               │
│ • CDS Views & associations                                  │
│ • Identifier les Released APIs                              │
└──────────────────────────────────────────────────────────────┘
                              ▼
┌─────────────────────────────────────────────────────────────┐
│ Phase 3: Developpement RAP                                   │
│ ──────────────────────                                       │
│ • Behavior Definition & Implementation                       │
│ • Validations, Determinations, Actions                      │
│ • Authorization & Feature Control                           │
└──────────────────────────────────────────────────────────────┘
                              ▼
┌─────────────────────────────────────────────────────────────┐
│ Phase 4: Service & UI                                        │
│ ────────────────────                                         │
│ • Service Definition & Binding                              │
│ • Annotations UI                                            │
│ • App Fiori Elements                                        │
└──────────────────────────────────────────────────────────────┘
                              ▼
┌─────────────────────────────────────────────────────────────┐
│ Phase 5: Assurance qualite & Go-Live                         │
│ ───────────────────────────────────                          │
│ • Tests unitaires & ATC                                     │
│ • Performance & Securite                                    │
│ • Transport & Documentation                                 │
└──────────────────────────────────────────────────────────────┘

Phase 1 : Preparation du projet

Paysage systeme & autorisations

Verification	Description	Statut
☐	Version du langage ABAP Cloud activee dans le systeme
☐	Les utilisateurs developpeurs ont S_ABPLNGVS pour les packages Cloud
☐	Route de transport definie (DEV → QAS → PRD)
☐	Acces ADT/BAS configure pour tous les developpeurs
☐	Repository Git cree (si abapGit est utilise)

Creer la structure des packages

" Structure de package recommandee pour un projet ABAP Cloud
"
" $Z_PROJET (Superpackage)
" ├── Z_PROJET_MODEL
" │   ├── Tables (ZTAB_*)
" │   ├── CDS Views (ZI_*, ZC_*)
" │   └── Elements de donnees
" │
" ├── Z_PROJET_BDEF
" │   ├── Behavior Definitions
" │   └── Behavior Implementations (ZBP_*)
" │
" ├── Z_PROJET_SERVICE
" │   ├── Service Definitions
" │   └── Service Bindings
" │
" └── Z_PROJET_TEST
"     └── Classes de test unitaire (ZTC_*)

Definir les conventions de nommage

Type d’objet	Prefixe	Exemple
Table de base de donnees	`ZTAB_`	`ZTAB_BOOKING`
Interface View (CDS)	`ZI_`	`ZI_Booking`
Consumption View	`ZC_`	`ZC_Booking`
Behavior Pool	`ZBP_`	`ZBP_I_Booking`
Service Definition	`ZSRV_`	`ZSRV_Booking`
Service Binding	`ZUI_`	`ZUI_Booking_O4`
Classe de test unitaire	`ZTC_`	`ZTC_Booking_Test`

Phase 2 : Modele de donnees

Checklist de conception des tables

Verification	Description
☐	Cle primaire definie (CLIENT + champs cle)
☐	Champs techniques presents (CREATED_BY, CREATED_AT, …)
☐	Elements de donnees utilises plutot que types integres
☐	Relations de cle etrangere documentees
☐	Delivery Class correctement definie (A, C, L, …)

Exemple : Definition de table

@EndUserText.label : 'Reservations"
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
define table ztab_booking {
  key client       : abap.clnt not null;
  key booking_uuid : sysuuid_x16 not null;
  booking_id       : ze_booking_id;
  customer_id      : ze_customer_id;
  flight_date      : abap.dats;
  @Semantics.amount.currencyCode : 'ztab_booking.currency_code"
  price            : abap.curr(15,2);
  currency_code    : abap.cuky;
  status           : ze_booking_status;

  " Champs techniques
  created_by       : abp_creation_user;
  created_at       : abp_creation_tstmpl;
  last_changed_by  : abp_locinst_lastchange_user;
  last_changed_at  : abp_locinst_lastchange_tstmpl;
}

Checklist CDS View

Verification	Description
☐	Root View Entity avec `define root view entity`
☐	Access Control defini (`@AccessControl.authorizationCheck`)
☐	Annotations semantiques (`@Semantics.amount`, `@Semantics.quantity`)
☐	Associations vers les entites dependantes
☐	Champs cle correctement marques

Exemple : CDS View Entity

@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Reservation"
define root view entity ZI_Booking
  as select from ztab_booking
  composition [0..*] of ZI_BookingItem as _Items
  association [1..1] to ZI_Customer    as _Customer
    on $projection.CustomerId = _Customer.CustomerId
{
  key booking_uuid    as BookingUuid,
      booking_id      as BookingId,
      customer_id     as CustomerId,
      flight_date     as FlightDate,
      @Semantics.amount.currencyCode: 'CurrencyCode"
      price           as Price,
      currency_code   as CurrencyCode,
      status          as Status,

      " Champs admin
      @Semantics.user.createdBy: true
      created_by      as CreatedBy,
      @Semantics.systemDateTime.createdAt: true
      created_at      as CreatedAt,
      @Semantics.user.lastChangedBy: true
      last_changed_by as LastChangedBy,
      @Semantics.systemDateTime.lastChangedAt: true
      last_changed_at as LastChangedAt,

      " Associations
      _Items,
      _Customer
}

Released APIs pour les donnees SAP

Donnees SAP	Released API (Niveau A)	Ne pas utiliser (Niveau D)
Materiel	`I_Product`	`MARA`, `MAKT`
Client	`I_Customer`	`KNA1`, `KNB1`
Fournisseur	`I_Supplier`	`LFA1`, `LFB1`
Document de vente	`I_SalesOrder`	`VBAK`, `VBAP`
Info utilisateur	`CL_ABAP_CONTEXT_INFO`	`SY-UNAME`, `USR02`

Plus d’informations sur les Released APIs dans l’article Concept de niveau Clean Core.

Phase 3 : Developpement RAP

Checklist Behavior Definition

Verification	Description
☐	Type d’implementation choisi (`managed` ou `unmanaged`)
☐	`strict ( 2 )` pour la derniere version RAP
☐	Persistent Table ou Draft Table definie
☐	Lock Master/Dependent correctement configure
☐	Authorization Master defini
☐	Validations pour les champs obligatoires
☐	Determinations pour les valeurs automatiques
☐	Actions pour les processus metier

Exemple : Behavior Definition

managed implementation in class zbp_i_booking unique;
strict ( 2 );

define behavior for ZI_Booking alias Booking
persistent table ztab_booking
draft table ztab_book_d
lock master total etag LastChangedAt
authorization master ( instance )
etag master LastChangedAt
{
  create;
  update;
  delete;

  " Valeurs de champ automatiques
  field ( readonly ) BookingUuid, CreatedBy, CreatedAt,
                     LastChangedBy, LastChangedAt;
  field ( numbering : managed ) BookingUuid;

  " Support Draft
  draft action Edit;
  draft action Activate optimized;
  draft action Discard;
  draft action Resume;
  draft determine action Prepare;

  " Validations
  validation validateCustomer on save
    { field CustomerId; create; }
  validation validateFlightDate on save
    { field FlightDate; create; update; }

  " Determination pour Booking-ID
  determination setBookingId on modify
    { field BookingUuid; create; }

  " Actions
  action ( features : instance ) confirm result [1] $self;
  action ( features : instance ) cancel result [1] $self;

  " Composition
  association _Items { create; }

  mapping for ztab_booking
  {
    BookingUuid   = booking_uuid;
    BookingId     = booking_id;
    CustomerId    = customer_id;
    FlightDate    = flight_date;
    Price         = price;
    CurrencyCode  = currency_code;
    Status        = status;
    CreatedBy     = created_by;
    CreatedAt     = created_at;
    LastChangedBy = last_changed_by;
    LastChangedAt = last_changed_at;
  }
}

Checklist Behavior Implementation

Verification	Description
☐	Chaque validation a une gestion `failed` et `reported`
☐	Les determinations remplissent tous les champs automatiques
☐	Les actions verifient les preconditions (`IF booking-Status = ...`)
☐	Feature Control pour la disponibilite dynamique des actions
☐	Les messages utilisent l’interface `if_abap_behv_message`

Exemple : Validation

METHOD validateCustomer.
  " Lire toutes les reservations pertinentes
  READ ENTITIES OF ZI_Booking IN LOCAL MODE
    ENTITY Booking
      FIELDS ( CustomerId )
      WITH CORRESPONDING #( keys )
    RESULT DATA(lt_bookings).

  " Verifier les donnees client
  SELECT CustomerId FROM ZI_Customer
    FOR ALL ENTRIES IN @lt_bookings
    WHERE CustomerId = @lt_bookings-CustomerId
    INTO TABLE @DATA(lt_valid_customers).

  LOOP AT lt_bookings INTO DATA(ls_booking).
    IF NOT line_exists( lt_valid_customers[ CustomerId = ls_booking-CustomerId ] ).
      APPEND VALUE #( %tky = ls_booking-%tky ) TO failed-booking.
      APPEND VALUE #( %tky = ls_booking-%tky
                      %msg = new_message_with_text(
                               severity = if_abap_behv_message=>severity-error
                               text     = |Client { ls_booking-CustomerId } non trouve| )
                      %element-CustomerId = if_abap_behv=>mk-on
                    ) TO reported-booking.
    ENDIF.
  ENDLOOP.
ENDMETHOD.

Authorization & Feature Control

METHOD get_instance_authorizations.
  READ ENTITIES OF ZI_Booking IN LOCAL MODE
    ENTITY Booking
      FIELDS ( Status )
      WITH CORRESPONDING #( keys )
    RESULT DATA(lt_bookings).

  LOOP AT lt_bookings INTO DATA(ls_booking).
    APPEND VALUE #(
      %tky = ls_booking-%tky
      %update = COND #( WHEN ls_booking-Status = 'CONFIRMED"
                        THEN if_abap_behv=>auth-unauthorized
                        ELSE if_abap_behv=>auth-allowed )
      %delete = COND #( WHEN ls_booking-Status = 'CONFIRMED"
                        THEN if_abap_behv=>auth-unauthorized
                        ELSE if_abap_behv=>auth-allowed )
      %action-confirm = COND #( WHEN ls_booking-Status = 'NEW"
                                THEN if_abap_behv=>auth-allowed
                                ELSE if_abap_behv=>auth-unauthorized )
      %action-cancel = COND #( WHEN ls_booking-Status <> 'CANCELLED"
                               THEN if_abap_behv=>auth-allowed
                               ELSE if_abap_behv=>auth-unauthorized )
    ) TO result.
  ENDLOOP.
ENDMETHOD.

Phase 4 : Service & UI

Checklist Service Layer

Verification	Description
☐	Service Definition creee avec `define service`
☐	Toutes les entites necessaires exposees
☐	Service Binding pour OData V4 (recommande)
☐	Service Binding active et teste
☐	Fiori Preview fonctionne dans ADT

Exemple : Service Definition

@EndUserText.label: 'Booking Service"
define service ZSRV_Booking {
  expose ZC_Booking as Booking;
  expose ZC_BookingItem as BookingItem;
  expose ZI_Customer as Customer;
}

Checklist annotations UI

Verification	Description
☐	`@UI.headerInfo` pour l’en-tete d’entite
☐	`@UI.lineItem` pour la vue liste
☐	`@UI.facet` pour la structure Object Page
☐	`@UI.selectionField` pour les criteres de filtre
☐	`@UI.identification` pour les champs Object Page
☐	`@UI.fieldGroup` pour le groupement logique

Exemple : Metadata Extension

@Metadata.layer: #CUSTOMER
annotate view ZC_Booking with
{
  @UI.facet: [
    { id: 'GeneralInfo',
      purpose: #STANDARD,
      type: #IDENTIFICATION_REFERENCE,
      label: 'General',
      position: 10 },
    { id: 'Items',
      purpose: #STANDARD,
      type: #LINEITEM_REFERENCE,
      label: 'Positions',
      position: 20,
      targetElement: '_Items' }
  ]

  @UI.headerInfo: {
    typeName: 'Reservation',
    typeNamePlural: 'Reservations',
    title: { value: 'BookingId' },
    description: { value: 'CustomerId' }
  }

  @UI: { lineItem: [{ position: 10 }],
         selectionField: [{ position: 10 }],
         identification: [{ position: 10 }] }
  BookingId;

  @UI: { lineItem: [{ position: 20 }],
         selectionField: [{ position: 20 }],
         identification: [{ position: 20 }] }
  CustomerId;

  @UI: { lineItem: [{ position: 30 }],
         identification: [{ position: 30 }] }
  FlightDate;

  @UI: { lineItem: [{ position: 40, criticality: 'StatusCriticality' }],
         identification: [{ position: 40, criticality: 'StatusCriticality' }] }
  Status;
}

Phase 5 : Assurance qualite & Go-Live

Checklist tests unitaires

Verification	Description
☐	Classe de test avec `FOR TESTING` et `RISK LEVEL HARMLESS`
☐	Validations testees (cas positifs & negatifs)
☐	Determinations testees
☐	Actions testees avec transitions de statut
☐	Au moins 70% de couverture de code atteinte

Exemple : Test unitaire

CLASS ztc_booking_test DEFINITION
  FOR TESTING
  RISK LEVEL HARMLESS
  DURATION SHORT.

  PRIVATE SECTION.
    CLASS-DATA:
      environment TYPE REF TO if_cds_test_environment.

    CLASS-METHODS:
      class_setup,
      class_teardown.

    METHODS:
      setup,
      test_create_booking FOR TESTING,
      test_validate_customer_invalid FOR TESTING.
ENDCLASS.

CLASS ztc_booking_test IMPLEMENTATION.
  METHOD class_setup.
    environment = cl_cds_test_environment=>create_for_multiple_cds(
      VALUE #( ( i_for_entity = 'ZI_BOOKING' )
               ( i_for_entity = 'ZI_CUSTOMER' ) ) ).
  ENDMETHOD.

  METHOD class_teardown.
    environment->destroy( ).
  ENDMETHOD.

  METHOD setup.
    environment->clear_doubles( ).
  ENDMETHOD.

  METHOD test_create_booking.
    " Preparer les donnees de test
    DATA(lt_customers) = VALUE zt_customer( ( customer_id = 'CUST001' ) ).
    environment->insert_test_data( lt_customers ).

    " Executer l'operation RAP
    MODIFY ENTITIES OF ZI_Booking
      ENTITY Booking
        CREATE FIELDS ( CustomerId FlightDate Price CurrencyCode )
        WITH VALUE #( ( %cid = 'CID1"
                        CustomerId = 'CUST001"
                        FlightDate = sy-datum + 30
                        Price = '500.00"
                        CurrencyCode = 'EUR' ) )
      MAPPED DATA(mapped)
      FAILED DATA(failed)
      REPORTED DATA(reported).

    " Assertions
    cl_abap_unit_assert=>assert_initial( failed ).
    cl_abap_unit_assert=>assert_not_initial( mapped-booking ).
  ENDMETHOD.

  METHOD test_validate_customer_invalid.
    " Operation RAP avec client invalide
    MODIFY ENTITIES OF ZI_Booking
      ENTITY Booking
        CREATE FIELDS ( CustomerId FlightDate )
        WITH VALUE #( ( %cid = 'CID1"
                        CustomerId = 'INVALID"
                        FlightDate = sy-datum + 30 ) )
      MAPPED DATA(mapped)
      FAILED DATA(failed)
      REPORTED DATA(reported).

    " Assertion: La validation doit echouer
    cl_abap_unit_assert=>assert_not_initial( failed-booking ).
  ENDMETHOD.
ENDCLASS.

Verification ATC

Verification	Description
☐	ATC sans erreurs de priorite 1
☐	Pas de findings Niveau D (acces directs aux tables)
☐	Pas de findings Niveau C (objets non classifies)
☐	Variante de verification `ABAP_CLOUD_DEVELOPMENT` utilisee

Checklist Go-Live

Verification	Description
☐	Tous les tests unitaires reussis
☐	ATC sans findings critiques
☐	Tests de performance effectues
☐	Test end-to-end en QAS reussi
☐	App Fiori testee fonctionnellement
☐	Transport Request documente
☐	Plan de rollback disponible
☐	Documentation technique mise a jour
☐	Formation utilisateurs effectuee

Reference rapide : Do’s & Don’ts

Do’s

Utilisez strict ( 2 ) dans les Behavior Definitions
Definissez @AccessControl.authorizationCheck: #CHECK
Utilisez le Managed Scenario avec Draft si possible
Implementez le Feature Control pour les Actions
Ecrivez des tests unitaires avant le transport
Utilisez les Metadata Extensions pour les annotations UI

Don’ts

Pas de SELECTs directs sur les tables SAP
Pas de SY-UNAME, utilisez CL_ABAP_CONTEXT_INFO
Pas de CALL FUNCTION pour les BAPIs standard
Pas de COMMIT WORK dans le contexte RAP
Pas de textes en dur, utilisez les classes de message
Pas de variables globales dans les Behavior Classes

Conclusion

Cette checklist couvre les aspects les plus importants d’une implementation ABAP Cloud. Utilisez-la comme guide pour votre projet et adaptez-la si necessaire a vos exigences specifiques.

Les cinq phases offrent un deroulement clair :

Preparation du projet : Creer les bases
Modele de donnees : Base solide avec CDS Views
Developpement RAP : Implementer la logique metier
Service & UI : Fournir l’application
Assurance qualite : Assurer la stabilite

Pour des informations approfondies sur des sujets specifiques, voir :

Modele 3-Tier en ABAP Cloud - Patterns d’architecture
Concept de niveau Clean Core - Classification des APIs
Bases RAP - RESTful Application Programming
ATC (ABAP Test Cockpit) - Analyse statique de code