CDS - Typisierte Literale
Wie kannst du in einem Core Data Service eigentlich noch typgenauer arbeiten, wenn du ein Element im View erstellst? Dazu schauen wir uns die typisierten Literale an und wie sie dir im Alltag helfen können.
Inhaltsverzeichnis
In diesem Artikel gehen wir auf die Typisierung von Literalen ein und wie sie dir helfen typegerecht zu entwickeln.
Einleitung
Wenn du mit Core Data Service arbeitest, kommen nicht immer alle Informationen direkt aus der Datenbank. Es gibt verschiedene Wege neue Informationen und Spalten im Model zu erzeugen. Dabei solltest du allerdings immer auch an die Performance-Regel denken, dass solche Felder sehr weit oben in der Hierarchie sind, vor allem wenn es um Zugriffe auf große Datenmengen geht. In diesem Artikel schauen wir uns die Typisierung von Literalen in einem Core Data Service an. Bereits vor einer Weile hatten wir über verschiedene Literale in ABAP geschrieben und wie du sie für dich richtig einsetzen kannst.
Vorbereitung
In den folgenden Beispielen verwenden wir einen neuen Core Data Service auf Basis des Interface Views ZBS_I_DmoMaterial. Dabei benötigen wir den View nur, um später die Selektion zu machen und die zusätzlichen Felder zu erstellen. Dazu reicht uns der Schlüssel als echtes Feld im View.
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Typed Literals'
define view entity ZBS_C_DMOTypedLiterals
as select from ZBS_I_DmoMaterial
{
key MaterialNumber
}
CAST
Schauen wir uns einmal dazu ein einfaches Beispiel an, wie wir in der Vergangenheit solche Felder mit den richtigen Typen erzeugt haben. In den meisten Fällen wirst du Code Snippets mit Cast finden, um ein Element zu erzeugen und auf den richtigen Datentypen zu bringen. Dabei wird das Literal auf den Zieltypen gecastet und per Alias im View zur Verfügung gestellt.
cast( 'USD' as abap.cuky( 5 ) ) as USDCast,
Verwenden wir nun ein typisiertes Literal, dann geben wir zuerst den Basistypen an und dann ohne Leerzeichen direkt das Literal im Quelltext. Auch in diesem Fall müssen wir einen Alias angeben, um das Element im View zur Verfügung zu stellen.
abap.cuky'USD' as USDLiteral,
Die Schreibweise ist etwas kürzer und übersichtlicher. Im Data Preview sehen wir leider nicht viel vom Typen, daher machen wir einen SELECT in einer ausführbaren Klasse und schauen uns die beiden Datentypen im Debugger an. Grundsätzlich sind die beiden Typen identisch vom Inhalt und vom Typen.
Typen
Welche Typen können wir nun eigentlich alle für die Typisierung der Literale verwenden? Im Grunde sind alle eingebauten Datentypen von ABAP möglich, diese kannst du normalerweise auch in Tabellen oder Custom Entities verwenden und sie sind über "abap." abrufbar. Dabei findest du auch spezifische Typen wie:
- Mandant
- Sprache
In der Dokumentation unten findest du auch Typen, die davon ausgeschlossen sind. Meist handelt es sich hier um komplexere Typen, die über ein einfaches Literal nicht gesetzt werden können. Damit sind im Moment aber auch keine Datenelemente oder Simple Type aus CDS möglich.
Leerzeichen
Wenn du durch die Dokumentation schaust, gibt es noch einige Besonderheiten, die du bei der Verwendung von Zeichenketten beachten solltest. In diesem Beispiel definieren wir eine Zeichenkette mit Leerzeichen im Ende und definieren einen Short String und einen normalen String. Der Short String sollte sich normalerweise wie ein String verhalten, hat aber eine maximale Länge, um kurze Texte zu übernehmen.
abap.sstring'My String ' as ShortString,
abap.string'My String ' as NormalString
In diesem Fall würden wir eigentlich davon ausgehen, dass beim Verhalten die Leerzeichen hinten bestehen bleiben und wir den gleichen String erhalten. Schauen wir uns einmal den Debugger und die Typisierung an:
Hier kommt die Besonderheit zum Tragen und die Leerzeichen am Ende werden beim Short String abgeschnitten. Der Inhalt ist genau 9 Zeichen lang. Beim normalen String bleiben alle Zeichen bestehen und wir erhalten die 13 Zeichen, die wir definiert haben.
Vollständiges Beispiel
Den View und den ABAP Code aus dem heutigen Artikel findest du bei uns in GitHub im Repository für alle Core Data Beispiele. Die spezifischen Änderungen sind in diesem Commit, da sich die Objekte in Zukunft vielleicht verändern können.
Fazit
Du brauchst einen spezifischen Typen von Literal, dann kannst du die übersichtlichere Variante des typisierten Literals verwenden. Damit bleibt die Deklaration einfach und übersichtlich und du kannst das Literal direkt an verschiedenen Stellen in der Definition verwenden.
