CDS Views S/4HANA : guide complet (Interface, Projection, annotations @UI)

Quand un développeur ABAP arrive sur un projet S/4HANA, la première question qu'on lui pose n'est plus « tu sais coder en ABAP ? » mais « tu maîtrises les CDS Views ? ». Ce changement de pied résume à lui seul la trajectoire technique imposée par SAP depuis dix ans. La couche d'accès aux données est passée de la vue SE11 — simple jointure SQL relationnelle — à un modèle déclaratif beaucoup plus riche qui pilote l'ensemble de la pile technique : depuis le moteur HANA en bas, jusqu'à l'interface Fiori Elements en haut.

Les CDS Views (Core Data Services) sont aujourd'hui le seul vrai chemin de développement standard sur S/4HANA. Comprendre leur architecture, leurs annotations et leurs patterns d'usage est devenu un prérequis pour toute DSI qui veut maîtriser ses spécifiques et conserver une stratégie Clean Core. Cet article propose une vision d'ensemble structurée, orientée décision technique.

CDS View : qu'est-ce que c'est vraiment ?

Une CDS View est un objet d'ABAP Dictionary défini dans un fichier source DDL (Data Definition Language). Le fichier est édité dans Eclipse ADT — la SE80 ne supporte pas les CDS. À l'activation, SAP génère côté base HANA une vue native correspondante, plus une ou plusieurs représentations utilisables côté ABAP (entity, table type, structure DDIC).

Fondamentalement, une CDS View est une requête SQL enrichie. Elle déclare des champs source, des jointures, des filtres, des agrégations. Elle ajoute ensuite des éléments qui n'existent pas en SQL classique :

• Associations : relations nommées entre entités, résolues à la demande lors de l'exécution
• Annotations : métadonnées injectées dans le code (interface, analytique, sémantique, sécurité)
• Expressions de session : accès au contexte ABAP (utilisateur, langue, date système) depuis le SQL
• Type-safety : intégration native avec les types ABAP, héritage des Domain et Data Elements

Cette richesse explique pourquoi les CDS Views deviennent rapidement la colonne vertébrale d'un projet S/4HANA. Elles servent à la fois de modèle de lecture analytique, de fondation pour les Business Objects RAP, de source des KPI Smart Business et de couche d'exposition OData V4.

Interface View vs Projection View : la séparation des responsabilités

La bonne pratique SAP — formalisée dans le Virtual Data Model (VDM) — repose sur une séparation stricte entre deux couches de CDS :

L'Interface View (préfixe I_)

L'Interface View porte la modélisation des données. Elle définit les tables source, les jointures, les associations vers les entités liées, et déclare les annotations sémantiques (@Semantics) — quels champs représentent une devise, une quantité, une unité, une référence chronologique. Elle ne contient aucune annotation d'interface. Elle est conçue pour être réutilisée par de multiples consommateurs : Projection Views, KPI, Embedded Analytics, autres CDS.

La Projection View (préfixe C_)

La Projection View hérite d'une Interface View et porte le contrat de consommation. Elle ne sélectionne qu'un sous-ensemble des champs, masque les éléments techniques, et ajoute les annotations @UI et @ObjectModel qui pilotent le rendu Fiori Elements. C'est ensuite un Service Definition + Service Binding de type ODATA V4 qui expose la Projection sous forme de service OData V4 — les annotations CDS ne créent pas le service, elles enrichissent ses métadonnées. Une même Interface peut alimenter plusieurs Projections (List Report, Object Page, vue analytique) — chaque Projection adaptant le modèle à un usage précis.

Cette séparation découple le modèle de données (stable, partagé) du modèle de consommation (volatil, spécifique à un cas d'usage). Faire l'impasse — créer une seule CDS qui mélange jointures et annotations @UI — fonctionne le premier jour, devient ingérable au troisième écran et bloque toute évolution au sixième mois.

@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Commande Client - Interface'
@VDM.viewType: #BASIC

define view entity I_KaiSalesOrder
  as select from vbak as Header
  association [0..*] to I_KaiSalesOrderItem as _Items
    on $projection.SalesOrder = _Items.SalesOrder
  association [0..1] to I_Customer        as _Customer
    on $projection.SoldToParty = _Customer.Customer
{
  key Header.vbeln       as SalesOrder,
      Header.erdat       as CreationDate,
      Header.ernam       as CreatedByUser,
      Header.kunnr       as SoldToParty,
      @Semantics.amount.currencyCode: 'TransactionCurrency'
      Header.netwr       as NetAmount,
      Header.waerk       as TransactionCurrency,

      _Customer.Name1    as SoldToPartyName,
      _Items, _Customer
}

Annotations @UI, @Analytics, @ObjectModel

Le vrai différenciateur des CDS Views, ce sont les annotations. Elles transforment une simple vue SQL en source de vérité pour la stack applicative complète. Trois familles dominent :

@UI : pilotage de l'interface Fiori Elements

Les annotations @UI décrivent comment chaque champ doit apparaître à l'écran. Position dans la liste (@UI.lineItem), position dans la fiche détail (@UI.identification, @UI.fieldGroup), filtres par défaut (@UI.selectionField), libellés, ordre, criticité visuelle. Toutes ces métadonnées sont lues par Fiori Elements à l'exécution pour générer l'interface — aucun code UI5 n'est nécessaire.

@Analytics : Embedded Analytics et KPI

Les annotations @Analytics qualifient une CDS pour la consommation analytique : cube de faits (#CUBE), dimension (#DIMENSION), requête analytique (#QUERY). Couplées aux annotations @DefaultAggregation, elles alimentent les outils Embedded Analytics, KPI Smart Business et SAC live connection.

@ObjectModel : relations métier et hiérarchies

Les annotations @ObjectModel portent la sémantique métier : quelle entité est la racine d'un Business Object, quels sont les éléments d'identification, quelles associations représentent une composition (parent-enfant verrouillé) plutôt qu'une simple référence. C'est sur ces annotations que s'appuie la BDEF RAP pour générer le bon comportement.

D'autres familles existent (@Semantics pour les unités et devises, @Search pour la recherche enterprise, @AccessControl pour les DCL d'autorisation) mais @UI, @Analytics et @ObjectModel forment le noyau dur que tout développeur S/4HANA doit maîtriser.

Associations vs joins SQL : pourquoi c'est fondamental

Le concept d'association est probablement la plus grande rupture conceptuelle entre les vues SE11 et les CDS Views. Une association déclare une relation nommée entre deux entités (cardinalité, clé de jointure) sans déclencher immédiatement la jointure. La résolution est paresseuse (lazy) : tant qu'aucun champ de l'entité associée n'est sélectionné, aucun join n'est ajouté à la requête SQL exécutée sur HANA.

Conséquence directe : une CDS exposant cinquante associations vers des tables de référence ne paie le coût que des associations effectivement consommées. Sur un List Report Fiori où l'utilisateur n'affiche que cinq colonnes parmi quarante disponibles, HANA n'exécute que les jointures pertinentes. Sur des volumes de plusieurs millions de lignes, le gain est massif — couramment un facteur 5 à 10 sur les temps de réponse.

La règle de pouce sur un projet S/4HANA : par défaut, on utilise des associations. Le join SQL classique n'est réintroduit qu'en cas de besoin d'agrégation transverse, ou quand on a explicitement besoin de toutes les combinaisons croisées.

Code-pushdown HANA : la promesse tenue

Sur une architecture classique ABAP + Oracle, le serveur applicatif récupérait les données brutes et faisait les calculs en mémoire. Cette architecture est obsolète sur S/4HANA. Le principe du code-pushdown consiste à déléguer un maximum de logique à HANA, qui dispose d'une puissance de calcul colonnaire bien supérieure à celle de l'AS ABAP.

Toute CDS View est par construction exécutée sur HANA. Les expressions, agrégations, filtres et jointures sont compilés en SQL natif HANA. Quand on a besoin de logiques plus complexes (calculs procéduraux, appels récursifs), on combine une CDS Table Function à une méthode AMDP écrite en SQLScript — l'ensemble continue de s'exécuter exclusivement sur HANA.

Le piège classique reste d'introduire un anti-pattern ABAP : SELECT * dans une table interne, puis LOOP AT avec des calculs en mémoire. Le pushdown est cassé, HANA renvoie tous les enregistrements, le serveur applicatif fait le travail. Sur des volumes significatifs, c'est ce qui distingue une app qui répond en 200 ms d'une app qui timeoute à 30 secondes.

CDS Views avec RAP : la chaîne complète

Les CDS Views sont la fondation obligatoire du RESTful Application Programming Model. Un Business Object RAP s'appuie sur deux CDS :

• Une Interface View qui modélise les données et leurs compositions (header / items)
• Une Projection View qui ajoute les annotations @UI et le comportement transactionnel

La Behavior Definition (BDEF) est ensuite attachée à la Projection View. Le service binding expose l'ensemble en OData V4. Fiori Elements consomme les métadonnées et génère l'interface. Sans CDS Views correctement modélisées en amont, toute cette chaîne s'effondre — pas de RAP, pas d'OData V4, pas de Fiori Elements.

Sur la migration S/4HANA Greenfield de Kuhn Group, plus de 90 % des nouvelles CDS Views ont été conçues selon le pattern Interface + Projection. Le bénéfice mesuré au bout de 18 mois : chaque nouvelle app Fiori Elements réutilise en moyenne 60 % de CDS Interfaces existantes — la dette de modélisation est nulle.

Migration des vues SE11 vers CDS

La question revient sur tous les projets de bascule ECC → S/4HANA : faut-il convertir l'ensemble des vues SE11 historiques en CDS ? La réponse pragmatique est non. Une SE11 qui fonctionne, qui n'est appelée que par des programmes batch maintenus en ABAP classique, et qui ne nécessite ni exposition OData ni intégration analytique, n'a aucune raison d'être migrée.

La règle qui guide la décision tient en trois points :

1. Toute nouvelle vue est créée en CDS, sans exception. Les ATC checks Clean Core bloquent la création de nouvelles SE11.
2. Les vues SE11 lues par des apps Fiori, des KPI ou des services OData sont reconstruites en CDS dès leur première évolution fonctionnelle.
3. Les vues SE11 héritées et stables sont conservées tant qu'elles ne posent pas de problème. La dette technique se traite à mesure qu'elle remonte, pas par chantier de Big Bang.

Sur un projet récent chez un client industriel équivalent à Kuhn Group, sur 430 vues SE11 historiques, seules 67 ont effectivement été reconstruites en CDS sur 24 mois — celles qui croisaient un cas d'usage Fiori ou analytique. Les autres ont continué de servir tranquillement les batchs et programmes de support.