033: Core Data Service [Basics] - Consumption Modeling
In dieser Folge schauen wir auf die Modellierung eines Consumption Views und schauen uns verschiedene Punkte, wie Funktionen, Assoziationen, Session Variablen und virtuelle Felder an.
Inhaltsverzeichnis
Einleitung
In dieser Folge gehen wir auf die Modellierung von Core Data Services auf dem Consumption Layer ein. Dabei nehmen wir unser angelegtes Datenmodell vom letzten Mal und generieren einen neuen View, an dem wir uns einige Beispiele anschauen.
Consumption View
Dazu legen wir uns auf dem Interface View für die Positionen einen neuen View an. In diesem Fall möchten wir einen Consumption View anlegen, den unsere Anwendung später verwenden soll. Bei Consumption Views gehen wir davon aus, dass wir diese speziell für Anwendungsfälle und Anwendungen erstellen. Damit sind sie genau für einen Anwendungsfall zugeschnitten und meist nicht zur Wiederverwendung oder zur weiteren Modellierung gedacht. Auf Ebene eines Consumption View würden sich auch rechenintensive und performance-lastige Operationen befinden.
Wir sollten bei der Anlage daran denken, dass wir eine View Entity anlegen wollen, da dies der Standard auf den aktuellen Releases ist. Haben wir den View angelegt, dann bereinigen wir einige Annotationen, die wir im Moment nicht benötigen und machen den View damit leichter lesbar für die nächsten Schritte. Um anderen Entwickler mitzuteilen für was der View eigentlich gedacht ist, ergänzen wir den ViewType des virtuellen Datenmodells im Header der CDS Views. Nun können wir den View weiter bereinigen und entfernen in diesem Fall die Assoziationen und die Menge plus Einheit, da wir diese später nicht benötigen.
Assoziationen
Als Anforderung hatten wir erhalten, dass wir auch die Partner ID mit in den Daten ausgeben sollen. Dazu benötigen wir nun keinen Join, sondern verwenden die Assoziation, die wir bereits im Datenmodell angelegt haben. Über den Unterstrich können wir die Verbindungen sehr leicht identifizieren. Der Partner kommt aus dem "Header", entsprechend können wir das Feld einbinden. Geben wir keinen Alias an, dann erhält das Feld den originalen Namen, die Assoziation ist dabei nicht Teil des Namens. Rufen wir nun den Data Preview auf, dann ist nun die PartnerID teil der Daten.
Funktionen
Wenn du mit Core Data Services arbeitest, dann stehen dir auch verschiedene Funktionen, ähnlich wie in ABAP, zur Verfügung. Als nächste Anforderung sollen wir nun den vollen Namen des Partners angeben. Per Assoziationen können wir über den Header zum Partner navigieren und finden dort den Namen. Allerdings ist die Information aktuell auf zwei Felder aufgeteilt, die wir nun in einem Feld zusammenbringen wollen. Dafür gibt es nun die CONCAT Funktionen. Die erste Funktion fügt zwei Felder zusammen, wir haben aber keine Möglichkeit den Namen sauber zu trennen. Mit der zweiten Funktion können wir die Felder verknüpfen und eine gewisse Anzahl Leerzeichen zwischen die beiden Felder bringen. Dazu geben wir zuerst die beiden Felder an, die wir verknüpfen wollen, dann die Anzahl der Leerzeichen und zum Abschluss müssen wir dem neuen Feld einen Alias geben. Ohne den Alias wirft das System einen Fehler. Schauen wir uns wieder das Ergebnis an, dann befindet sich nun hinter dem Partner auch der vollständige Name.
Session
Als nächste Anforderung sollen wir zur Produkt ID auch den Namen des Produktes ausgeben. Wir bereits zuvor, können wir über die verschiedenen modellierten Assoziationen navigieren, um den Produkttext in unserem View einzubinden. Haben wir dies gemacht, erhalten wir allerdings eine Warnmeldung, dass sich durch diese Beziehung die Kardinalität ändern könnte. Aktivieren wir den View und schauen uns den Preview an. Im Gegensatz zu den bisherigen Tests hat sich die Ergebnismenge erhöht und passt nun nicht mehr auf eine Seite. Schauen wir uns die Daten im Detail an, dann haben wir nun die verschiedenen Sprachen als Produkttext und der eigentliche Schlüssel passt nicht mehr zum View. Belegnummer und Position sind im Moment nicht mehr eindeutig und mehrfach belegt. Der Core Data Service kann damit umgehen, allerdings ist dies beim Zugriff nicht mehr ganz korrekt.
In diesem Fall wollen wir eigentlich nur dem Anwender die aktuelle Anmeldesprache anzeigen. Dazu grenzen wir die aktuelle Text Assoziation ab, ähnlich wie eine Tabelle mit den eckigen Klammern. Dabei wollen wir auf die Sprache einschränken. Dazu steht uns die $session Variable bei der Modellierung zur Verfügung. In der Session findest du wichtige Informationen zur Anmeldung des Users, wie die User ID, den Mandanten, das aktuelle Datum, aber auch die Anmeldesprache. Diese verwenden wir nun für den Zugriff. Die Warnmeldung bleibt zwar bestehen, aber wenn wir den Preview des Views ausführen, dann werden wieder die korrekten Daten geladen und der Produkttext ist in Englisch.
Rufen wir zum Test den View einmal auf dem gleichen System mit einer anderen Anmeldsprache auf. Dazu navigieren wir auf das System und starten den Data Preview direkt per ALT + F8 und geben unseren Core Data Service an. Nach Ausführung erhalten wir den Preview der Daten in Deutsch und erhalten die passenden Übersetzungen für das Produkt. Die Daten sind so weit immer noch korrekt.
Alias
Als weitere Anforderung sollen wir die Namen einiger Felder anpassen, da der Aufrufer andere Felder erwartet. Auch hier haben wir kein Problem und können einfach einen neuen Alias verwenden. Da wir auf Basis des Views nicht weiter modellieren, haben wir später auch keine Probleme im Datenmodell. Bei Feldumbenennungen solltest du innerhalb deines Modells immer vorsichtig sein, vor allem wenn die Felder dann zusätzlich in Berechtigungsprüfungen verwendet werden.
Neue Felder
Als letzte Anpassung sollen wir neue Felder im Modell zur Verfügung stellen. Die Felder gibt es aktuell nicht im Datenmodell oder auf der Datenbank. Dazu sollen wir über die Menge den Rang einer Position ableiten. In diesem Fall verwenden wir die Funktion CASE und vergleichen hier die Menge gegen unsere KPIs. Ist die Anzahl größer oder gleich 5, dann handelt es sich um ein "High" Performer. Bei zwei für einen "Medium" Performer und alles unter 2 für einen "Low" Performer. Für das neue Feld vergeben wir noch einen Alias, um die Nutzung klarzumachen.
Zum Abschluss möchte der Aufrufer das aktuelle Datum haben, um nach Abzug der Daten auch den Snapshot mitzusichern. Dafür können wir wieder auf die Session zugreifen und dem Feld einen Alias für das Ausführungsdatum geben. Über diesen Weg können wir Felder und Informationen zur Verfügung stellen, die so nicht auf der Datenbank vorhanden sind, sich aber aus dem Kontext oder anderen Felder ableiten lassen.
Zusammenfassung
Zum Abschluss führen wir den Data Preview aus und schauen uns die fertigen Daten an. Wir haben unseren ersten Consumption View zur Verfügung gestellt und alle Anforderungen abgearbeitet. Dabei haben wir auf die Informationen im Datenmodell zugegriffen, Session Informationen verwendet und neue Inhalte erschaffen und das ohne eine Zeile ABAP.
Damit sind wir am Ende der Folge, danke fürs Zuschauen und bis zum nächsten Mal.
YouTube
Video