CDS-Views als Reporting-Schicht in S/4
CDS-Views ersetzen klassische ABAP-Reports schrittweise – als deklarative, datenbanknahe Reporting-Schicht. Wir entwickeln virtuelle Datenmodelle entlang Ihrer Standard-Tabellen, exponieren sie via OData für Fiori Elements und Analytics, und halten gleichzeitig die alten Reports am Leben, wo sie noch gebraucht werden. Das ist kein Big Bang auf SAC, sondern eine Migration mit Bestandsgarantie.
Warum CDS jetzt der richtige Ort ist
Klassische ABAP-Reports haben das Reporting in den letzten zwanzig Jahren getragen. Mit S/4HANA verschiebt sich aber das Fundament: Universal Journal ist ein flacher Speicher, HANA bringt native Analytik, Fiori Elements braucht OData-Quellen. Wer jetzt noch jede Auswertung als Z-Report schreibt, baut technische Schulden auf – duplizierte Logik, schwer wartbare Selektionen, mehrfache Aggregations- Stufen.
CDS-Views lösen das. Sie sind deklarativ, leben im Standard- Datenmodell, sind versioniert und können direkt für Fiori, Analytics Cloud, Datasphere und für eigene REST-Endpunkte verwendet werden.
So bauen wir das
1. Inventar der bestehenden Reports
Wir starten mit einer Liste der Top-30 Z-Reports – die, die wirklich genutzt werden. Aus Transport- und Nutzungs-Statistiken (ST03N, SCM-Reports) extrahieren wir, was den höchsten Wert für eine CDS-Migration hat: viele Aufrufer + komplexe Joins + langsame Laufzeit. Das ist die Reihenfolge.
2. Virtual Data Model pro Domäne
Pro Modul-Domäne (FI/CO, SD, MM, PP) bauen wir ein 3-Schicht-CDS- Modell:
- Basic-View – direkt auf Standard-Tabelle, nur Feld-Auswahl und Annotationen (keine Joins). Bleibt stabil, ändert sich mit dem Standard.
- Composite-View – verbindet Basic-Views aus mehreren Tabellen zu einem fachlich sinnvollen Bild (z.B. "Kundenauftrag mit Position und Lieferung").
- Consumption-View – die Ebene die Fiori Elements oder OData- Konsumenten sehen. Mit @UI-Annotations, Sortier-Defaults, Filter-Vorgaben.
Diese Schicht-Trennung ist nicht Zier – sie erlaubt, dass Standard- Änderungen nur die Basic-Views anfassen, nicht das ganze Reporting.
3. Analytical CDS für Embedded Analytics
Für KPIs und aggregierte Auswertungen nutzen wir Analytical CDS-
Views mit @Analytics.dataCategory: #CUBE und passenden
Dimensions-Views. Das ist die Grundlage für SAC-Live-Verbindungen
und für Embedded Analytics in Fiori. Keine Datenkopie, keine
Aggregations-Tabellen – direkter Zugriff auf den Universal Journal.
4. OData-Service automatisch generiert
Aus dem Consumption-View entsteht der OData-Service per Annotation. Fiori Elements rendert daraus eine vollständige Listen- oder Object- Page-App, ohne handgeschriebenes UI5. Das verkürzt die Time-to-Market für einfache Auswertungs-Apps erheblich.
5. Alte Reports laufen weiter
Wir entfernen keine Z-Reports im ersten Schritt. Migration läuft in Wellen: erst Bottom-Up (Basic-Views), dann Composite, dann Consumption, dann werden alte Reports nach und nach durch Fiori-Apps ersetzt. Ihr Fachbereich sieht die neue Auswertung, prüft sie eine Sprint-Phase lang gegen den alten Report, schaltet dann um. Das ist die Migration ohne Kontroll-Verlust.
Trade-offs ehrlich genannt
CDS-Views haben Grenzen:
- Echtzeit-Joins über sehr viele Tabellen kosten HANA-Speicher – manchmal ist eine materialisierte View oder ein Calculation View in HANA das bessere Werkzeug
- Komplexe iterative Logik (z.B. Stücklisten-Auflösung mit Rekursion) gehört nicht in CDS – dort bleibt eine ABAP-AMDP- oder Function-Library-Logik die richtige Wahl
- Schreibende Zugriffe kommen via RAP (siehe nächster Use-Case), nicht via CDS allein
Wir benennen diese Grenzen früh – kein "alles in CDS"-Versprechen.
Wer mit uns arbeitet
Dieses Angebot richtet sich an ABAP-Leads die ihre Reporting-Landschaft auf S/4-konform umstellen wollen, an Tech-Architekten die die Analytics-Schicht neu strukturieren, und an Data-Officer die das Universal Journal sauber anschliessen möchten. Eine Reporting- Standortbestimmung (60 Min) mit Ihren Top-Reports ist der Einstieg – wir schauen welche davon CDS-Kandidaten sind und in welcher Reihenfolge.
