adesso orange🍊Stellenangebote:
Software Engineer Trainee · Senior
| (Senior) Cloud Software Engineer BTP
(Senior) Consultant Technologie · Consultant ABAP
Werkstudent Softwareentwicklung · Fiori / UI5 · Consulting · Application Management
Virtuelle Felder in CDS-Views: Unterschied zwischen den Versionen
Zeile 4: | Zeile 4: | ||
Es wird zwischen drei Kategorien unterschieden: | Es wird zwischen drei Kategorien unterschieden: | ||
* virtuelle Felder mit eigener | * virtuelle Felder mit eigener Berechnungslogik | ||
* virtuelle Felder mit eigener Sortierlogik | * virtuelle Felder mit eigener Sortierlogik | ||
* virtuelle Felder mit eigener Filterlogik | * virtuelle Felder mit eigener Filterlogik |
Version vom 3. April 2024, 14:34 Uhr
Einleitung
Virtuelle Felder werden mit ABAP-Klassen implementiert und stehen seit dem SAP NetWeaver Release 7.51 zur Verfügung.
Es wird zwischen drei Kategorien unterschieden:
- virtuelle Felder mit eigener Berechnungslogik
- virtuelle Felder mit eigener Sortierlogik
- virtuelle Felder mit eigener Filterlogik
Paar Fakten:
- Virtuelle Felder werden nur innerhalb des OData-Frameworks angesprochen. Abfragen des CDS-Views über Open SQL Selects ergeben keine Ergebnisse, sprich die dahinterlegende Klasse mit Code wird nicht durchlaufen
- Virtuelle Felder kennen sich untereinander nicht
- Filterlogik auf virtuelle Felder kann nicht angewendet werden und wird explizit im weiteren SADL-Code abgefangen
- Schlüsselfelder können nicht als virtuelle Elemente definiert werden
Deklaration in CDS-View
Virtuelle Felder können dort verwendet werden, wo sie unterstützt werden z.B. in EXTEND VIEW ENTITY:
define view <CdsConsumptionView>
as select from <data_source>
{
...
@ObjectModel.readOnly: true
@ObjectModel.virtualElement
@ObjectModel.virtualElementCalculatedBy: 'ABAP:<code_exit_class>'
cast( '' as <dtype> preserving type) as <view.element>
...
}
In Projection Views ist die Notation etwas anders:
define root view entity <CdsProjectionView>
provider contract transactional_query
as projection on <data_source>
{
...
@ObjectModel. virtualElementCalculatedBy: 'ABAP:<code_exit_class>'
virtual <view.element> : abap.<type>
...
}
Exit-Klassen
Für die drei möglichen Fällen von virtuellen Elementen muss eine Klasse erstellt werden, die mit einem Marker, d.h. INTERFACE gekennzeichnet wird, sodass zwingend der Methodenkopf genutzt wird, wie sie im INTERFACE vorgegeben wird. Wie der Methodenrumpf ausprogrammiert wird, sieht man wie folgt bei allen Logiken.