037: Core Data Service [Basics] - View and View Entity

Einleitung

In der letzten Folge hatten wir uns den Dependency Analyzer etwas genauer angeschaut. Dabei fiel am Ende auf, dass es Entitäten und etwas unlesbare Namen in der Anzeige gab. Wir sind damals nicht näher auf die Details eingegangen, was wir nun in dieser Folge nachholen wollen. Heute schauen wir uns die klassischen Views an und vergleichen sie mit den neuen CDS View Entities.

VIEW

Legen wir zuerst einmal einen neuen View auf der Positionstabelle an. Dabei vergeben wir einen Namen und eine Beschreibung, wie wir es auch bisher getan haben. Am Ende sehen wir die Template-Auswahl und können zwischen verschiedenen Vorlagen wählen. Dabei stehen uns die View Entity, die Root Entity und der klassische Define View zur Verfügung. Hier sieht man eigentlich schon die Unterschiede zwischen den verschiedenen Entitäten im Detail. Wir legen also die neue Entität an und haben im ersten Schritt erst einmal das falsche Template gewählt. Nachdem wir uns für das falsche Template entschieden haben, müssen wir aber nicht zwingend den neuen View löschen, sondern können einfach eine Anpassung vornehmen. Dazu kopieren wir uns den Namen der neuen Entität und die Quelle der Selektion. Im nächsten Schritt löschen wir den kompletten Inhalt des neuen Views und können über den Quick Fix eines der entsprechenden Templates wählen, welches wir dann wiederum einfügen wollen. Hier verwenden wir den View und lassen uns das Template in den aktuellen Editor einfügen.

Wieso können wir das eigentlich tun? Das liegt daran, dass ein View erst einmal eine Definition ist und wir den Inhalt selbst bestimmen können, bevor wir ihn aktivieren. Entsprechend können wir den Namen des Views übernehmen, auch wenn der Standard bei der Formatierung manchmal Probleme bereitet. Die Tabelle wurde ebenfalls nicht automatisch übernommen oder fehlt im Template, daher fügen wir die Datenquelle jetzt wieder manuell ein. Im nächsten Schritt können wir per Strg + Leertaste alle Felder der Tabelle automatisch einfügen lassen. Das System legt dabei auch direkt das passende Mapping für uns an. Nach der Formatierung bemerken wir jedoch den ersten Unterschied, denn wir erhalten immer noch eine Fehlermeldung: Im oberen Teil ist der SQL View Name noch leer. Dieser wird bei klassischen Views zwingend benötigt, um das entsprechende Objekt im Dictionary anzulegen. Wir vergeben hier also einen Namen, stellen aber schnell fest, dass wir hier auf 16 Zeichen beschränkt sind, im Gegensatz zu den bis zu 32 Zeichen, die uns für die eigentliche CDS-Entität zur Verfügung stehen.

Als nächsten Schritt fügen wir noch eine Funktion ein und erzeugen einen berechneten Schlüssel in der Entität. Dabei verwenden wir die Funktion concat und fügen die Dokument-ID und die Produkt-ID zusammen. Das Ergebnis speichern wir unter einem neuen Alias. Im nächsten Schritt nehmen wir diese neue ID und wollen sie in Kleinschreibung konvertieren, um sie als zusätzlich formatierte ID im View zu haben. Allerdings werden wir feststellen, dass wir hier einen Fehler erhalten, da das Feld des Alias nicht gefunden werden kann. In klassischen Views ist es nämlich nicht möglich, einen Alias direkt in derselben Selektionsliste weiterzuverwenden. Zum Abschluss aktivieren wir den gesamten View, was jedoch etwas länger als gewöhnlich dauert. Das ist einer der Nachteile einer klassischen View: Die Aktivierung benötigt mehr Zeit, da im Hintergrund zusätzlich das klassische Dictionary-Objekt (die SQL-View) generiert werden muss.

Als nächsten Schritt rufen wir noch einmal den Dependency Analyzer auf und lassen uns den Dependency Graph anzeigen. Hier sehen wir die Entität und die entsprechende Tabelle, die wir definiert haben. Zusätzlich können wir nun zwischen den verschiedenen Namen hin- und herschalten. Wir sehen einerseits den Namen der Entität und, wenn wir umschalten, den Namen des SQL-Views, den wir vorher definiert haben. Rufen wir zum Abschluss noch einmal die Data Preview auf und lassen uns die Ergebnisse anzeigen. Der View funktioniert einwandfrei: Wir sehen die Daten und könnten damit nun eine detaillierte Analyse durchführen.

Migration

Damit haben wir den View erst einmal erstellt und aktiviert. Bei der Bearbeitung sind uns bereits erste Unterschiede aufgefallen: So mussten wir einen SQL-View-Namen vergeben, wodurch zusätzlich zu unserer eigentlichen Definition ein weiteres Artefakt im System angelegt wurde. Wenn wir nach diesem SQL-View suchen, werden wir ihn auch als klassisches Objekt im ABAP Dictionary wiederfinden. Neben der Anlage ist uns auch aufgefallen, dass wir bestimmte Funktionen nicht nutzen können, wie zum Beispiel den Zugriff auf lokal definierte Felder, die innerhalb desselben Statements schlichtweg nicht erkannt werden. Hier muss man klar sagen: Es handelt sich um eine veraltete Art von Views, die man in einem aktuellen System eigentlich nicht mehr neu anlegen sollte. Eine Ausnahme besteht nur dann, wenn man den technischen SQL-View-Namen zwingend benötigt, beispielsweise für spezielles Customizing oder ältere Frameworks. Daher schauen wir uns im nächsten Schritt an, wie du von den klassischen Views auf die modernen CDS View Entities migrieren kannst.

Für die Migration bietet SAP verschiedene Werkzeuge an. In diesem Fall verwenden wir das integrierte Tool in den ABAP Development Tools, welches du per Rechtsklick im Kontextmenü findest. Dort starten wir über "Migrate to CDS View Entity" den entsprechenden Wizard und können direkt mit der Prüfung im Simulationsmodus beginnen. Dabei wird erst einmal geprüft, ob alle Voraussetzungen erfüllt sind und ob die verwendeten Funktionen in der aktuellen Definition bereit für die Umwandlung in eine View Entity sind.

Die Simulation wird ausgeführt, und wir erhalten nach dem Durchlauf ein entsprechendes Protokoll. Hier können wir prüfen, welche Fehler aktuell noch im View vorliegen. Zum Beispiel fehlt hier noch die Zuordnung zur Währung und zur Mengeneinheit. In diesem Fall gehen wir in den alten Positions-View und übernehmen die Association sowie die entsprechenden Felder und Annotationen aus dem bestehenden View. Allerdings wird uns nach der Aufnahme auffallen, dass die Association so nicht funktioniert: Wir verwenden hier bereits ein neueres Statement, welches in klassischen Views noch nicht unterstützt wird. Daher müssen wir eine Anpassung vornehmen und das alte Association-Statement verwenden. Sind wir damit fertig, aktivieren wir den View noch einmal und starten das Migrationstool erneut im Simulationsmodus. In diesem Fall erhalten wir zwar wieder eine Fehlermeldung auf oberster Ebene, schauen wir uns aber die Details an, sehen wir, dass alle Einzelprüfungen in Ordnung sind. In der finalen Preview siehst du nun genau, was im View angepasst wird: Im Grunde werden verschiedene Annotationen entfernt und der eigentliche SQL-View wird aus dem System gelöscht.

Daher können wir zum Abschluss die Migration nun im Echtmodus starten. Nachdem die Migration durchgelaufen ist, werfen wir noch einen Blick in das Protokoll. Wir sehen zwar einen Fehlereintrag, meist ein Hinweis auf den weggefallenen SQL-View, aber ansonsten wurde der View erfolgreich migriert. Die neue Entity befindet sich aktuell noch im inaktiven Zustand, daher müssen wir sie zuerst aktivieren. Sobald das erledigt ist, können wir einige moderne Anpassungen im View vornehmen. Zum Beispiel können wir die Association nun in der neuen, besseren Form verwenden. Ein echtes Highlight: Wir können den zuvor auskommentierten Code wieder einkommentieren. Wie ihr seht, können wir jetzt direkt im Statement auf das lokal definierte Feld zugreifen und es weiterverarbeiten. Das war im alten View technisch nicht möglich. Schauen wir uns zum Abschluss die Data Preview an: Alle Informationen sind da, und auch die berechneten Felder werden sauber erzeugt und korrekt befüllt.

Zusammenfassung

Zum Abschluss schauen wir uns noch einmal den passenden Artikel auf Software-Heroes.com an. Diesen findest du in der Sammlung zu den Core Data Services unter dem Eintrag für die View Entity. Hier ist noch einmal aufgelistet, was den klassischen View eigentlich ausmacht: Er besteht aus der CDS-Entität und einem zusätzlichen DDIC-Artefakt, dem sogenannten SQL-View. Nach der Migration haben wir diesen SQL-View entfernt und haben nur noch die reine View Entity im Zugriff. Ein entscheidender Vorteil davon ist, dass die Aktivierungszeiten stark verkürzt werden. Zudem werden Funktionalitäten möglich, die vorher in dieser Form schlichtweg nicht unterstützt wurden.

Am Ende des Artikels findest du noch einmal eine Übersicht der Vorteile bei der Verwendung der neuen Artefakte. Zum einen profitierst du von schnelleren Aktivierungszeiten, da die Generierung des SQL-Views entfällt. Zudem sind Änderungen direkt über den Quelltext der Entität leichter handhabbar. Es gibt jedoch auch eine striktere Syntax-Prüfung – so müssen beispielsweise Währungs- und Mengenfelder korrekt zugeordnet sein. Ein weiterer Pluspunkt: Wir können Funktionen nun problemlos verschachteln (Nesting), typisierte Literale verwenden und genießen ein vollständig automatisches Mandanten-Handling. Zusammengefasst bieten die neuen View Entities ein deutlich größeres Portfolio an Funktionalitäten und ein effizienteres Handling in der Entwicklung. Daher unser Rat: Warte nicht mit der Migration, sondern verwende bereits heute die neuen CDS View Entities, sofern sie in deinem System verfügbar sind.

Damit haben wir uns in dieser Folge angeschaut, was Views und View Entities eigentlich sind, wo genau die Unterschiede liegen, wie sie genutzt werden und was du für die Zukunft beachten solltest. Wir sind damit am Ende dieser Folge angelangt. Ich bedanke mich ganz herzlich fürs Zuschauen. Bis zum nächsten Mal.

YouTube
Video