DDIC der Zukunft (Vergleich)
Wie geht es eigentlich mit dem DDIC in Zukunft weiter und können wir schon Heute die neuen Features für uns nutzen? In diesem Teil vergleichen wir die Welt von Heute mit der von Morgen und wo du alle Features findest.
Inhaltsverzeichnis
In diesem Artikel vergleichen wir die Features aus der Welt von Heute und aus der Welt von Morgen und zeigen dir, wo du alle wichtigen Punkte findest.
Einleitung
In den letzten beiden Artikeln hatten wir vor allem darüber geschrieben, wie die Welt heute aussieht und wie wir Datenmodelle über Tabellen erstellen. Im zweiten Artikel hatten wir uns dann angeschaut, wie die Welt von morgen aussieht, wenn wir nur noch mit "CDS-only" arbeiten und dort entsprechende neue Artefakte verwenden. Damit solltest du beide Welten einmal näher kennengelernt haben und die verschiedenen Details kennen. Deshalb wollen wir uns in diesem Artikel noch einmal anschauen, wo du die verschiedenen Features in den beiden Welten findest und wie du diese besser nutzen kannst, ohne dabei komplett verloren zu gehen.
Vergleich
In diesem Kapitel schauen wir uns die unterschiedlichen Features an und wo du sie im neuen Modell findest. Dabei gehen wir auch auf kleine Unterschiede ein.
Mandant
In der alten Welt wurde das Mandantenfeld als separates Feld in der Tabelle definiert. Hierbei handelt es sich um eine redundante Arbeit, die in jeder Tabelle durchgeführt werden musste und vor allem bei Anfängern öfters mal vergessen wurde. In der neuen Welt wird dies über eine Annotation abgebildet und diese automatisch auf CLIENT_DEPENDENT gesetzt. Das heißt, das Mandantenfeld wird mit erzeugt und kann damit nicht vergessen werden. Daher müssen in Zukunft mandantenunabhängige Tabellen separat und wirklich explizit dafür gekennzeichnet werden.
Beziehung
Beziehungen können auf Ebene der Tabellen-Entities endlich direkt modelliert werden. In der Vergangenheit konnte man zwar einen Foreign Key definieren, dieser war aber nicht wirklich eine Beziehung, über die wir auch auf Daten zugreifen konnten. Die Vorteile von Core Data Services und den definierten Assoziationen sind, dass wir diese hier direkt auf Tabellenebene vordefinieren können und auf den ersten Blick sehen, wie das Datenmodell der verschiedenen Tabellen zusammenhängt.
Datentyp
Der Datentyp wird beim Simple Type direkt hinter der Definition des Simple Typs angegeben. In der Domäne wird dazu ein Formular angeboten. Dort kann der Datentyp über eine Liste ausgewählt und die Länge über das Feld eingestellt werden. Die Einstellung hier wird typischerweise in einem Editor durchgeführt, so wie eigentlich alle CDS Artefakte.
Fixwerte
Schauen wir dann auf das Thema Fixwerte oder Konstanten, dann können wir in der Domäne die Fixwerte in einer Liste definieren. Hier steht der Wert gegenüber dem Text, den wir ausgeben möchten. Im Simple Type handelt es sich um ein Enum. Dort können wir ebenfalls Werte definieren, müssen aber auch immer eine Konstante haben, die einen initialen Wert hat. Grundsätzlich können wir hier auch die Texte über das End User Label definieren, die wir später in der Ausgabe erhalten.
Ausgabe
Die Ausgabe wird ebenfalls auf Domänenbene definiert. Hier stehen verschiedene Ausgabekriterien zur Verfügung, wie zum Beispiel die Ausgabelänge und eine Konvertierungsroutine, mit der erweiterte Formatierungen möglich sind. Im Simple Type wird das als Annotation definiert. Hier gibt es über den ABAP Catalog entsprechende Typspezifikationen, die wir angeben können.
Änderungsbelege
Wollen wir für ein Feld die Änderungsbelege aktivieren, müssen wir dies im Datenelement tun. Dort gibt es unter den zusätzlichen Einstellungen eine Checkbox, die wir aktivieren können. Auf Ebene des Simple Typs machen wir das ebenfalls über eine Annotation und können dort das Flag aktivieren. Damit brauchen wir keine Unterscheidung zwischen Datenelement und Domäne, wenn wir dieses Attribut haben wollen.
Texte
Die Ausgabetexte für das UI werden ebenfalls über eine Annotation gepflegt, wenn wir auf den Simple Type schauen. Dabei gibt es ein Mapping gegenüber den Texten aus dem Datenelement, wobei es aktuell kein Element für den Langtext gibt. Was wir in einer Fiori-Anwendung nicht unbedingt benötigen, hier reichen meistens drei Texte völlig aus. Auch wenn die Werte hardcodiert aussehen, kann später über die Translation-App die Übersetzung gemacht werden.
Case Sensitive
Die Groß- und Kleinschreibung ist ein wichtiger Bestandteil, wenn es darum geht, Texte und Langtexte zu erfassen. In der klassischen Welt hatte dies oft zu Fehlern und Problemen geführt, wenn vergessen wurde, auf Domänenbene das Flag zu setzen, dass das Element Groß- und Kleinschreibung beherrscht. In der neuen Welt ist das etwas anders: Hier ist jedes angelegte Element, welches textartige Inhalte zur Verfügung stellt, mit aktivierter Groß- und Kleinschreibung versehen. Grundsätzlich müsste hier die Großkonvertierung aktiviert werden, allerdings ist die Annotation leider nicht für ABAP Cloud freigegeben. Hier müsste über entsprechende Determinations im RAP sichergestellt werden, dass eine Großkonvertierung erfolgt, beziehungsweise mit Funktionen auf der Core Data Services-Ebene.
Berechtigung
Tabellen werden standardmäßig nicht mit einer Berechtigungsprüfung ausgeliefert, sodass wir nur Inhalte sehen, für die wir auch berechtigt sind. Daher müssen wir für eine klassische Tabelle immer nach dem Lesen die Berechtigungsprüfung durchführen und entsprechende Einträge herausfiltern. Das führt zu Problemen, wenn wir die Berechtigungsprüfung vergessen. In Table Entities können wir deshalb auch direkt ein Access Control definieren und dort die Berechtigungsprüfung hinterlegen. Wollen wir keine Berechtigungsprüfung, müssen wir diese aktiv beim Lesen deaktivieren. Daher ist automatisch erst einmal beim Lesen auch die Berechtigungsprüfung aktiv.
Konstanten
Haben wir Fixwerte in einer Domäne hinterlegt, wollen wir diese meistens auch in unserem Programm verwenden oder validieren. Dabei mussten wir häufig Konstantenstrukturen anlegen, die dann die Werte der Domäne wiederum abbilden und auf die wir dann in unserem Code zugreifen können. Haben wir ein Simple Type Enum definiert, können wir dieses direkt verwenden, um auf die Konstanten zuzugreifen, die im Enum definiert sind. Das erspart uns erstens den Aufwand, die Konstantenstruktur anzulegen, und zweitens ist der verwendete Typ immer aktuell.
Benefits
Was bekommst du eigentlich heute, wenn du bereits auf Core Data Services umsteigst? Grundsätzlich ist das Datenmodell, also die Objekte, die dir heute angeboten werden, schon in einem sehr guten Zustand, solange du auf einem aktuellen System arbeitest.
- Wenn du mit Table Entities arbeitest, kannst du direkt Datenbeziehungen abbilden, erhältst automatisch Security und das Thema Typsicherheit. Denn in Table Entities sind nur aktuelle Felder wie das Datum, die Uhrzeit und der Timestamp möglich, hier also nur die aktuellsten Typen, die auch typsicher sind. Du kannst Annotationen verwenden, die gleichzeitig Constraints auf der Datenbank sind und damit auch Fehler produzieren, wenn Werte ungleich der definierten Werte eingegeben werden.
- Du kannst dein gesamtes Datenmodell direkt so bauen, wie es später auch in den Core Data Services verwendet werden soll. Das heißt, Groß- und Kleinschreibung für die Feldnamen und Entity-Namen ist bereits aktiv. Heute kannst du viel längere Namen für die Entitäten verwenden, was das Ganze etwas sprechender macht und diese kryptischen, kurzen Tabellennamen obsolet macht.
Offene Punkte
Schauen wir auf die noch offenen Punkte, die aktuell nicht unterstützt werden.
- Es wird zum Beispiel in der RAP-Entwicklung die Enumeration noch nicht wirklich fürs UI unterstützt. Hier muss man in Datentypen konvertieren und dann auch im UI entsprechende Wertehilfen bauen. Das wünschen wir uns natürlich Out of the Box, wenn wir eine Annotation auf Datenbankebene definieren.
- Aktuell gibt es auch noch keine Tabellentypen auf CDS-Ebene. Das heißt, wenn du die Strukturen und Definitionen später dann zum Beispiel auch in klassischen Objekten wie Funktionsbausteinen oder der Dynpro-Entwicklung verwenden willst, wird dies nicht funktionieren.
- Ebenso können die Tabellen noch nicht an jeder Stelle verwendet werden, wo du auch eine Tabelle eintragen kannst. Nehmen wir zum Beispiel bestimmtes Customizing, wo du eine Art Exit-Tabelle hinterlegen kannst: Hier würde die Wertehilfe wahrscheinlich deine Table Entity nicht finden.
Fazit
Grundsätzlich können wir sagen: Das Datenmodell wird sich in Zukunft ändern und mehr auf Core Data Services basieren. Bist du bereits auf einem 2025er-Release unterwegs, kannst du eigentlich sehr viele Objekte schon sehr gut nutzen, um damit Datenmodelle und RAP-Anwendungen zu bauen. Bist du auf einem älteren Release unterwegs, kannst du zwar die Core Data Services verwenden, aber eine Modellierung auf Table-Entity-Basis funktioniert hier noch nicht. Daher sollte es auch erst einmal ein Blick in die Zukunft sein.
