CDS, RAP, Fiori et migration
Voici les rôles de construction et de migration du produit Development. Les rôles de construction (CDS, RAP, Fiori) créent et activent des objets, en remontant de bas en haut la chaîne de dépendances. Les rôles de migration se distinguent par leur intention : Migration corrige un objet de façon interactive, tandis que Migration Map et Clean-core check sont des analyses en lecture seule qui ne modifient rien.
Ils se trouvent sous le produit Development dans le compositeur Chat ; Migration Map et Clean-core check apparaissent également sous Consulting. Pour le modèle de permissions qui sous-tend chaque rôle, voir Fonctionnement des rôles.
En un coup d'œil#
| Rôle | Lecture/Écriture | Utilisez-le pour… |
|---|---|---|
| CDS | Écriture | Construire de vrais modèles de données CDS VDM de bas en haut. |
| RAP | Écriture | Construire un objet métier RAP complet. |
| Fiori | Écriture | Rendre un service OData prêt pour Fiori Elements. |
| Migration | Écriture | Préparer un objet de façon interactive pour ECC→S/4 / Clean-Core. |
| Migration Map | Lecture seule | Analyser un parc de code personnalisé pour la planification S/4. |
| Clean-core check | Lecture seule | Auditer des objets pour la conformité clean-core. |
CDS#
Lecture/Écriture : Écriture.
CDS conçoit et construit de vrais modèles de données CDS VDM — objets DDLS, DDLX et DCLS ainsi que leurs tables. Il suit la stratification du Virtual Data Model : vues d'interface de base ZI_ et vues ZR_, vues de texte, projections de consommation ZC_ et contrôles d'accès. Il construit de bas en haut et active au fur et à mesure.
Il n'exécute jamais le nettoyeur ABAP sur le CDS — le DDL CDS est normalisé par le rôle lui-même, et non par le nettoyeur.
Quand l'utiliser : pour mettre en place un modèle de données CDS correctement stratifié plutôt qu'une vue ponctuelle.
RAP#
Lecture/Écriture : Écriture.
RAP construit un objet métier RAP complet de bout en bout : la table, le DDLS (définition de données), le DDLX (extension de métadonnées), le BDEF (définition de comportement), la CLAS (implémentation du comportement), la SRVD (définition de service) et le SRVB (liaison de service). Sa méthodologie est modèle de données → comportement (managed) → projection + service → vérification via EML.
La publication du service OData est une étape humaine — le rôle construit et lie, mais c'est vous qui publiez.
Quand l'utiliser : pour construire un objet RAP transactionnel (scénario managed) depuis un modèle de données jusqu'à un service vérifié.
Fiori#
Lecture/Écriture : Écriture.
Fiori rend un service OData existant prêt pour Fiori Elements. Il rédige la couche d'annotations @UI — extensions de métadonnées ou @UI en ligne — ainsi que les annotations d'aide à la valeur, de texte et de recherche, et expose le résultat via SRVD + SRVB.
Le déploiement de l'app-shell UI5 et la configuration du launchpad sont des transferts manuels explicites — le rôle prépare le service et les annotations ; c'est vous qui déployez l'application et raccordez le launchpad.
Quand l'utiliser : pour transformer un service OData fonctionnel en un service qu'une application Fiori Elements peut afficher, sans rédiger les annotations à la main.
Migration#
Lecture/Écriture : Écriture.
Migration est une préparation interactive ECC→S/4HANA / Clean-Core d'un seul objet (ou d'un petit package). Sa méthodologie est évaluer (une variante ATC de préparation à S/4 ou une analyse du source) → corriger constatation par constatation (une correction minimale, dans le sens clean-core, en signalant les pièges) → vérifier → rapporter. Un humain approuve chaque modification.
Quand l'utiliser : pour corriger réellement un objet précis en vue de S/4, constatation par constatation, avec une validation humaine sur chaque édition.
Migration Map#
Lecture/Écriture : Lecture seule.
Migration Map est une analyse du parc de code personnalisé (Z/Y) pour la planification ECC→S/4. Il prend un export USAGE de production et lit la structure du code DEV, calcule la clôture d'atteignabilité à partir des points d'entrée utilisés, et classe chaque objet dans USED / REACHABLE / REVIEW / CANDIDATE, chacun avec des preuves à l'appui. Il livre un CSV / rapport.
Il ne touche jamais à la production et ne déclare jamais un code « mort » ou « supprimable en toute sécurité » — les catégories REVIEW et CANDIDATE sont des éléments d'aide à la décision pour un humain, et non des verdicts.
Quand l'utiliser : pour dimensionner et prioriser un parc de code personnalisé avant une migration S/4, avec des preuves pour chaque classification.
Migration Map est disponible à la fois dans les produits Development et Consulting, il peut donc alimenter soit un effort de construction, soit un livrable de conseil.
Clean-core check#
Lecture/Écriture : Lecture seule.
Clean-core check audite un ou plusieurs objets pour la conformité clean-core S/4HANA. Il recherche les lectures directes de tables standard, les appels à des API non publiées, les modifications, la syntaxe obsolète et les contournements d'interface, et classe chaque objet en COMPLIANT / EXTENSIBLE-VIA-RELEASED / NEEDS-REWORK / BLOCKER. Il ne modifie rien.
Quand l'utiliser : pour vérifier si des objets précis sont prêts pour le clean-core, et voir exactement ce qui fait obstacle.
Clean-core check est disponible à la fois dans les produits Development et Consulting.
Pages associées#
- Fonctionnement des rôles — le modèle de permissions qui sous-tend chaque rôle.
- Rôles de développement — le reste du produit Development.
- Rôles de conseil — où Migration Map et Clean-core check apparaissent également.
- Nettoyeur ABAP — ce que CDS ignore délibérément.
- Chat — choisissez un rôle et envoyez une tâche.
- Mode autonome — le pipeline d'application soumis au contrôle humain pour les écritures.