CDS, RAP, Fiori & Migration
Dies sind die Build- und Migrationsrollen des Produkts Entwicklung. Die Build-Rollen (CDS, RAP, Fiori) legen Objekte an und aktivieren sie, wobei sie sich von unten nach oben durch die Abhängigkeitskette arbeiten. Die Migrationsrollen teilen sich nach Absicht: Migration behebt ein Objekt interaktiv, während Migration Map und Clean-core check schreibgeschützte Analysen sind, die nichts verändern.
Sie liegen unter dem Produkt Entwicklung im Chat-Editor; Migration Map und Clean-core check erscheinen auch unter Beratung. Das Berechtigungsmodell hinter jeder Rolle finden Sie unter So funktionieren Rollen.
Auf einen Blick#
| Rolle | Lesen/Schreiben | Verwenden für… |
|---|---|---|
| CDS | Schreibend | Echte CDS-VDM-Datenmodelle von unten nach oben bauen. |
| RAP | Schreibend | Ein vollständiges RAP-Business-Objekt bauen. |
| Fiori | Schreibend | Einen OData-Service Fiori-Elements-fähig machen. |
| Migration | Schreibend | Ein Objekt interaktiv für ECC→S/4 / Clean-Core vorbereiten. |
| Migration Map | Schreibgeschützt | Einen Eigenentwicklungsbestand für die S/4-Planung analysieren. |
| Clean-core check | Schreibgeschützt | Objekte auf Clean-Core-Konformität prüfen. |
CDS#
Lesen/Schreiben: Schreibend.
CDS entwirft und baut echte CDS-VDM-Datenmodelle — DDLS-, DDLX- und DCLS-Objekte plus ihre Tabellen. Es folgt der Schichtung des Virtual Data Model: Basis-Interface-Views ZI_ und ZR_-Views, Text-Views, ZC_-Consumption-Projektionen und Access Controls. Es baut von unten nach oben und aktiviert unterwegs.
Es führt nie den ABAP-Cleaner auf CDS aus — CDS-DDL wird von der Rolle selbst normalisiert, nicht vom Cleaner.
Wann verwenden: um ein sauber geschichtetes CDS-Datenmodell aufzustellen statt eines einmaligen Views.
RAP#
Lesen/Schreiben: Schreibend.
RAP baut ein vollständiges RAP-Business-Objekt durchgängig: die Tabelle, DDLS (Data Definition), DDLX (Metadata Extension), BDEF (Behavior Definition), CLAS (Behavior Implementation), SRVD (Service Definition) und SRVB (Service Binding). Seine Methodik ist Datenmodell → Verhalten (managed) → Projektion + Service → Prüfung via EML.
Das Veröffentlichen des OData-Service ist ein menschlicher Schritt — die Rolle baut und bindet, aber Sie veröffentlichen.
Wann verwenden: um ein transaktionales RAP-Objekt (Managed-Szenario) von einem Datenmodell bis zu einem geprüften Service zu bauen.
Fiori#
Lesen/Schreiben: Schreibend.
Fiori macht einen bestehenden OData-Service Fiori-Elements-fähig. Es erstellt die @UI-Annotationsschicht — Metadata Extensions oder inline @UI — plus Value-Help-, Text- und **Such-**Annotationen und stellt das Ergebnis über SRVD + SRVB bereit.
Der UI5-App-Shell-Deploy und die Launchpad-Einrichtung sind explizite manuelle Übergaben — die Rolle bereitet den Service und die Annotationen vor; Sie deployen die App und binden das Launchpad an.
Wann verwenden: um einen funktionierenden OData-Service in einen zu verwandeln, den eine Fiori-Elements-App rendern kann, ohne Annotationen von Hand zu schreiben.
Migration#
Lesen/Schreiben: Schreibend.
Migration ist eine interaktive ECC→S/4HANA / Clean-Core-Vorbereitung eines Objekts (oder eines kleinen Pakets). Ihre Methodik ist Bewerten (eine S/4-Readiness-ATC-Variante oder ein Quelltext-Scan) → Befund für Befund beheben (eine minimale Korrektur, in Clean-Core-Richtung, unter Benennung der Fallstricke) → Prüfen → Berichten. Ein Mensch genehmigt jede Änderung.
Wann verwenden: um ein bestimmtes Objekt tatsächlich für S/4 zu behandeln, ein Befund nach dem anderen, mit einem Menschen in der Schleife bei jeder Änderung.
Migration Map#
Lesen/Schreiben: Schreibgeschützt.
Migration Map ist eine Bestandsanalyse von Eigenentwicklungen (Z/Y) für die ECC→S/4-Planung. Sie nimmt einen produktiven USAGE-Export und liest die DEV-Codestruktur, berechnet die Erreichbarkeitshülle von den genutzten Einstiegspunkten aus und klassifiziert jedes Objekt in USED / REACHABLE / REVIEW / CANDIDATE, jeweils mit stützenden Belegen. Sie liefert eine CSV / einen Report.
Sie berührt nie das Produktivsystem und erklärt Code nie für „tot" oder „sicher löschbar" — die Kategorien REVIEW und CANDIDATE sind Entscheidungsgrundlagen für einen Menschen, keine Urteile.
Wann verwenden: um einen Eigenentwicklungsbestand vor einer S/4-Migration zu dimensionieren und zu priorisieren, mit Belegen für jede Klassifizierung.
Migration Map ist in beiden Produkten Entwicklung und Beratung verfügbar, sodass es entweder eine Build-Arbeit oder ein Beratungsergebnis speisen kann.
Clean-core check#
Lesen/Schreiben: Schreibgeschützt.
Clean-core check prüft Objekt(e) auf S/4HANA-Clean-Core-Konformität. Es sucht nach direkten Lesevorgängen auf Standardtabellen, Aufrufen nicht freigegebener APIs, Modifikationen, veralteter Syntax und Schnittstellenumgehungen und ordnet jedes Objekt in COMPLIANT / EXTENSIBLE-VIA-RELEASED / NEEDS-REWORK / BLOCKER ein. Es verändert nichts.
Wann verwenden: um zu prüfen, ob bestimmte Objekte Clean-Core-fähig sind, und um genau zu sehen, was dem im Weg steht.
Clean-core check ist in beiden Produkten Entwicklung und Beratung verfügbar.
Verwandte Seiten#
- So funktionieren Rollen — das Berechtigungsmodell hinter jeder Rolle.
- Entwickler-Rollen — der Rest des Produkts Entwicklung.
- Beratungsrollen — wo Migration Map und Clean-core check ebenfalls erscheinen.
- ABAP-Cleaner — was CDS bewusst überspringt.
- Chat — eine Rolle wählen und eine Aufgabe absenden.
- Autonomer Modus — die menschlich freigegebene Anwende-Pipeline für Schreibvorgänge.