En bref
RAP (RESTful Application Programming Model) est le modèle de développement natif de S/4HANA. Il unifie en un seul paradigme la couche données (CDS Views), le comportement métier (Behavior Definition) et l'exposition OData V4. Il alimente Fiori Elements et garantit la compatibilité Clean Core. Sur S/4HANA, tout nouveau développement d'application devrait passer par RAP.
Le développeur ABAP qui arrivait sur un projet S/4HANA il y a encore quelques années se retrouvait face à un archipel de technologies : BOPF pour les objets métier, Web Dynpro pour les interfaces, Module Pool pour les transactions classiques, BAPIs pour les intégrations. Chaque technologie avait son propre modèle de programmation, ses propres outils de debug, sa propre courbe d'apprentissage.
SAP a tiré les leçons de cet écosystème fragmenté. Le RESTful Application Programming Model, introduit avec S/4HANA 1909 et devenu incontournable à partir de 2021, unifie l'ensemble sous un modèle cohérent et orienté API-first. Une Business Object (BO) RAP encapsule la structure de données, les règles métier et l'exposition OData V4. Fiori Elements consomme directement ces métadonnées pour générer les interfaces standard.
L'architecture RAP en quatre couches
1. La couche Data, CDS View
Tout Business Object RAP commence par une CDS View (Core Data Services). Elle définit la structure des données : quelles tables lire, quelles associations naviguer, quels champs calculer. Sur cette vue de base, on empile une Interface View puis une Projection View orientée consommation.
Les annotations @UI définissent directement dans la CDS la disposition de l'interface : quels champs apparaissent dans la liste, quels champs dans le formulaire, quels filtres sont disponibles par défaut. C'est le principe de l'annotation-driven UI, Fiori Elements consomme ces métadonnées pour générer l'interface, sans une ligne de JavaScript.
2. La couche Comportement, Behavior Definition
La Behavior Definition (BDEF) est le contrat du Business Object : elle déclare quelles opérations sont permises (create, update, delete), quels champs sont en lecture seule, quelles actions métier existent (approve, submit, reject), et quelles validations ou déterminations sont déclenchées. Elle est écrite dans un langage déclaratif propre à RAP, différent de l'ABAP classique.
3. La couche Implémentation, Behavior Implementation Class
La classe d'implémentation (une classe ABAP standard annotée FOR BEHAVIOR OF) contient la logique métier concrète : que fait l'action ApproveOrder ? Quelle est la règle de validation ValidateAmount ? Cette classe implémente les méthodes déclarées dans la BDEF et bénéficie de toute la puissance de l'ABAP orienté objet.
4. La couche Exposition, Service Definition + Service Binding
Le Business Object n'est pas exposé au monde extérieur par les annotations CDS. Deux objets dédiés s'en chargent : un Service Definition qui déclare quelles Projection Views sont publiées dans le service, et un Service Binding qui choisit le protocole et le scénario d'usage, typiquement ODATA V4, UI pour alimenter Fiori Elements, ou ODATA V4, Web API pour les intégrations B2B. C'est le binding qui crée l'endpoint /sap/opu/odata4/... consommable par les clients.
RAP vs BOPF, Web Dynpro, Module Pool : quand utiliser quoi ?
Sur un système S/4HANA récent, les anciens modèles ne disparaissent pas du jour au lendemain. Voici le tableau de décision qu'on applique en mission chez Kaï :
| Besoin | Modèle recommandé | Pourquoi |
|---|---|---|
| Nouvelle application Fiori transactionnelle sur S/4HANA 1909+ | RAP Managed | Standard SAP cible, Clean Core, Fiori Elements directement consommable |
| Exposition d'une logique BAPI / legacy en API moderne | RAP Unmanaged | Wrapping propre sans réécrire le legacy, OData V4 exposé proprement |
| Application historique en Web Dynpro à maintenir | Web Dynpro (sans la réécrire) ou migration RAP si refonte fonctionnelle | SAP maintient Web Dynpro mais ne fait plus évoluer. Migrer = projet à part entière |
| Batch, traitement de masse, logique sans UI | ABAP classique (avec objets SAP Released) | RAP n'apporte aucune valeur sans UI ; reste maintenable si on respecte Clean Core |
| Module Pool ou Dynpro existant | À planifier pour migration RAP | Plus aucun investissement SAP sur Dynpro ; risque de dette technique critique |
| BOPF existant en production | BOPF → RAP (refonte) | BOPF est officiellement déprécié au profit de RAP par SAP depuis S/4HANA 2020 |
La règle simple : tout nouveau développement Fiori sur S/4HANA part en RAP. Pour l'existant, on planifie la migration uniquement lors d'une refonte fonctionnelle, pas en mode "réécriture pour la réécriture".
Managed vs Unmanaged : deux scénarios
RAP propose deux modes de persistance selon la nature des données à manipuler.
Le mode Managed est le cas d'usage standard pour tout Business Object dont les données sont stockées dans des tables Z ou des extensions de tables standard SAP. Le framework gère automatiquement le CRUD, le lock, l'ETag et le Draft. Le développeur n'écrit que la logique spécifique : validations, déterminations, actions.
Le mode Unmanaged est réservé aux cas où le BO encapsule des données sans propriété directe sur leur persistance : appel de BAPIs existants, wrapping d'une interface legacy, données réparties sur plusieurs systèmes distants. Dans ce cas, le développeur prend en charge l'ensemble du cycle de vie, sauvegarde, lock, ETag, ce qui est sensiblement plus complexe.
Sur un nouveau projet S/4HANA, le choix par défaut est toujours le mode Managed. Le mode Unmanaged s'utilise uniquement quand les données ne peuvent pas être gérées directement par le framework.
Draft Handling : les saisies multi-étapes
L'une des fonctionnalités les plus puissantes de RAP est le Draft Handling : la capacité à sauvegarder temporairement un enregistrement en cours de saisie sans l'activer définitivement. L'utilisateur peut quitter l'application, revenir plus tard, reprendre sa saisie là où il l'a laissée. Fiori Elements gère l'indicateur visuel "Draft" automatiquement.
La persistance des brouillons, le nettoyage des drafts périmés, la gestion des conflits entre utilisateurs et le verrouillage sont pris en charge intégralement par le framework. Pour le développeur, activer le Draft revient à déclarer une table de draft dans la BDEF, quelques lignes de configuration pour une fonctionnalité qui aurait demandé des semaines de développement manuel sur Web Dynpro.
RAP et Fiori Elements : le duo gagnant
RAP seul ne produit pas d'interface. C'est en combinaison avec Fiori Elements que le modèle atteint sa pleine puissance. Fiori Elements propose quatre templates de pages standard :
- List Report : liste avec filtres et variant management, idéale pour les cockpits de gestion
- Object Page : fiche détail avec sections et facettes, pour la création et modification
- Analytical Page : vue analytique avec KPI cards et micro-charts, pour le reporting
- Overview Page : tableau de bord multi-cartes, pour les pages d'accueil métier
Ces templates se génèrent automatiquement à partir des annotations @UI des CDS Views. Aucun HTML ni JavaScript à écrire. Le résultat est une application Fiori conforme aux SAP Fiori Design Guidelines, responsive par défaut, accessible et maintenue à chaque upgrade SAP sans aucune intervention du développeur.
Par où commencer avec RAP ?
Le prérequis indispensable est la maîtrise des CDS Views. Sans comprendre les associations, les annotations et le concept de projection, il est impossible de construire un Business Object RAP correct. Si vos développeurs ne sont pas à l'aise avec les CDS, c'est le premier investissement à faire, une semaine de formation intensive suffit pour les fondamentaux.
L'outil de développement est Eclipse ADT (ABAP Development Tools), la SE80 ne supporte pas les artefacts RAP. SAP fournit dans ADT un Business Object Generator qui crée automatiquement l'ensemble des artefacts (Interface View, Projection View, BDEF, Behavior Implementation Class) depuis la structure de tables. C'est le point de départ recommandé pour tout nouveau Business Object.
Pour un développeur ABAP expérimenté maîtrisant déjà les CDS Views, la courbe d'apprentissage est de 4 à 6 semaines pour atteindre l'autonomie sur les cas d'usage standards. Le Draft Handling et les actions complexes demandent 2 à 3 semaines supplémentaires.
Pièges fréquents qu'on voit en mission
Cinq erreurs récurrentes qu'on corrige en mission chez nos clients sur S/4HANA :
1. Démarrer RAP sans maîtriser les CDS Views
L'erreur la plus fréquente. Les développeurs se jettent sur la Behavior Definition sans avoir compris les associations CDS, les annotations @UI, la différence Interface View vs Projection View. Résultat : du code RAP qui compile mais qui produit des interfaces Fiori bancales, des performances dégradées et un modèle ingérable à 6 mois. Règle simple : 1 semaine de CDS Views avant de toucher à RAP.
2. Confondre Service Definition et Service Binding
Le Service Definition déclare quelles vues exposer. Le Service Binding choisit le protocole (OData V4 UI vs Web API). On voit régulièrement des projets avec un Service Binding mal configuré qui empêche Fiori Elements de générer correctement la List Report (manque l'annotation @UI.lineItem côté Projection View, alors que la cause est en réalité un binding en mode "Web API" au lieu de "UI"). Une heure de debug pour rien.
3. Utiliser Unmanaged par défaut
Par confort ou par peur de "perdre le contrôle", certains développeurs partent en Unmanaged même quand les données sont stockées dans des tables Z. Conséquence : tout le CRUD, le lock, l'ETag et le Draft sont à implémenter à la main, des centaines de lignes de code qui auraient été gérées par le framework. Règle : tables Z = Managed par défaut, point.
4. Oublier le Authorization Control au niveau CDS
L'autorisation RAP se gère via les DCL (Data Control Language) au niveau CDS. Pas dans la Behavior Implementation. On voit fréquemment des projets où l'autorisation est codée à la main dans l'implémentation, ça marche, mais ce n'est pas étanche, et ça ne respecte pas le standard SAP qui privilégie l'autorisation déclarative.
5. Vouloir customiser Fiori Elements en SAPUI5 freestyle
"Fiori Elements n'affiche pas mon écran exactement comme je veux, je vais réécrire en freestyle." → Erreur. Dans 90 % des cas, le besoin est couvert par les annotations CDS appropriées (@UI.facet, @UI.selectionField, @UI.identification). Le freestyle SAPUI5 multiplie par 5 la dette technique. La règle : un mois d'investigation Fiori Elements avant de partir en freestyle.
Retour d'expérience, Projet Kuhn Group
Sur la migration S/4HANA Greenfield de Kuhn Group, l'ensemble des nouvelles applications spécifiques, une vingtaine d'apps métier couvrant SD, MM et PP, a été développé en RAP + Fiori Elements. Les résultats observés après 18 mois de production :
- Durée de développement réduite de 30 % par rapport aux estimations initiales basées sur Web Dynpro
- Zéro régression sur les apps RAP lors du passage S/4HANA 2020 → 2023
- Équipe interne Kuhn autonome sur la maintenance après 6 mois de transfert de compétences
- Toutes les apps conformes aux SAP Fiori Design Guidelines dès la mise en production
Le constat le plus frappant : lors du premier upgrade majeur, les apps RAP n'ont nécessité aucune correction. Les apps héritées en Web Dynpro ont requis 3 semaines de tests et 14 corrections de régression.
Questions fréquentes
RAP remplace-t-il complètement l'ABAP classique ?
Pour les nouvelles applications avec interface Fiori, oui. RAP est le modèle cible sur S/4HANA. Pour les batchs, traitements de masse et logiques sans interface utilisateur, l'ABAP classique reste pertinent, à condition d'utiliser uniquement les objets SAP Released.
Quelle est la différence entre RAP Managed et Unmanaged ?
En mode Managed, le framework RAP gère automatiquement le CRUD, le lock et l'ETag sur des tables Z. En mode Unmanaged, le développeur prend en charge l'ensemble du cycle de vie, utile pour wrapper des BAPIs existants ou encapsuler une interface legacy.
Faut-il connaître les CDS Views pour apprendre RAP ?
Oui, les CDS Views sont la fondation de RAP. Sans maîtrise des CDS (associations, annotations @UI, extension), il est impossible de construire un Business Object RAP correct. C'est le prérequis indispensable avant de se former à RAP.
Peut-on utiliser RAP sur SAP ECC ?
Non. RAP est exclusivement disponible sur S/4HANA (on-premise à partir de la version 1909). Sur ECC, les alternatives sont BOPF, Web Dynpro et Module Pool. RAP nécessite également Eclipse ADT, la SE80 ne supporte pas le développement RAP.
Combien de temps faut-il pour maîtriser RAP ?
Pour un développeur ABAP expérimenté maîtrisant déjà les CDS Views, la courbe d'apprentissage est de 4 à 6 semaines pour les cas d'usage standards. Le Draft Handling et les actions complexes demandent 2 à 3 semaines supplémentaires.
Vos équipes développent encore en Web Dynpro ou Module Pool sur S/4HANA ?
Discuter d'une formation RAP pour vos équipes