RAP - Projektion
In diesem Artikel bauen wir unser Beispiel etwas um und ergänzen die typische Projektionsschicht, die für die Darstellung der App verwendet wird.
Inhaltsverzeichnis
Zur Vereinfachung hatten wir bisher ohne Projektionsschicht gearbeitet, sondern direkt mit dem RAP Business Objekt, damit du die Auswirkungen und die Verwendung sehen konntest. EML verwendet für die Zugriffe die Ebene der Interface Schicht, für die App spielt aber die Projektion eine wichtige Rolle.
Hintergrund
Wieso benötigen wir noch einmal eine Projektion auf unserem eigentlichen Datenmodell? Die Projektion stellt das eigentliche Business Objekt für einen speziellen Fall oder eine App nach außen zur Verfügung. Dabei besteht die Möglichkeit die Funktionen weiter einzuschränken, da vielleicht nicht der volle Funktionsumfang für die App oder API benötigt wird. Auf einem RAP Business Objekt kann man somit verschiedene Projektionen bauen und dem Anwender zur Verfügung stellen.
Consumption View
In diesem Schritt erstellen wir den Consumption View über dem Interface View. Dazu kannst du mit Rechts-Klick auf den Core Data Service "ZBS_I_RAPPartner" eine neue Daten Definition anlegen. Damit wird automatisch das Referenzobjekt vorbefüllt. Dabei verwenden wir das Muster "Define Projection View", sodass wir nur noch minimale Teile anpassen müssen:
In dem neuen View erlauben wir wieder die Erweiterung per Extension (@Metadata.allowExtensions: true) und aktivieren den Core Data Service. Dabei wird dir auffallen, dass noch eine Warnmeldung übrigbleibt, die auf einen Zusatz verweist. Wir benötigen noch einen optionalen PROVIDER CONTRACT, dieser definiert das Verhalten der Projektion und bietet verschiedene Funktionen für die unterschiedlichen Szenarien. Für unseren einfachen Fall reicht "transactional_query" aus, dies beschreibt die einfache App zum Bearbeiten. Der vollständige View sieht nun wie folgt aus:
@EndUserText.label: 'RAP consumption for partner'
@AccessControl.authorizationCheck: #NOT_REQUIRED
@Metadata.allowExtensions: true
define root view entity ZBS_C_RAPPartner
provider contract transactional_query
as projection on ZBS_I_RAPPartner
{
key PartnerNumber,
PartnerName,
Street,
City,
Country,
PaymentCurrency
}
Metadata Extension
Im nächsten Schritt verschieben wir nun die Metadata Extension vom Interface View auf die Consumption Schicht. Dazu legst du einfach per Rechts-Klick auf den Consumption View eine Metadata Extension an. Nach dem Verschieben des Inhalts, kann die alte Erweiterung gelöscht werden und der Zusatz aus dem Interface View gelöscht werden. Die neue Erweiterung ergänzen wir noch ganz am Anfang mit einer UI Annotation:
@UI: {
headerInfo: {
typeName: 'Partner',
typeNamePlural: 'Partners'
}
}
Die zusätzliche "HeaderInfo" sorgt in der Liste und auf dem Detailbild für einen entsprechenden Text, damit der User eine Information über die Daten erhält. Ob Singular oder Plural wird anhand der Daten nach der Selektion entschieden und ausgegeben.
Verhalten
Zusätzlich zur Projektionsschicht auf Core Data Service Ebene, muss nun auch eine Projektion für die Verhaltensdefinition erstellt werden. Dies geht wieder sehr einfach mit einem Rechts-Klick auf den Consumption View des Modells und Anlage einer neuen Verhaltensimplementierung.
Die Felder und Texte sind entsprechend vorbelegt und du musst keine weiteren Informationen hinterlegen. Wichtig ist vor allem, dass im unteren Teil Projection vorgewählt ist. Nach dem Abschluss der Generierung wurden bereits die wichtigsten Elemente übernommen:
projection;
strict;
define behavior for ZBS_C_RAPPartner alias Partner
{
use create;
use update;
use delete;
}
In der Projektion der Verhaltensdefinition müssen weniger Informationen als im Interface hinterlegt werden, hier geht es vor allem um die Vererbung der CRUD Operationen und Aktionen nach außen. Wenn du zum Beispiel die DELETE Operation heraus löscht, dann kann über den daraus generierten Service nicht gelöscht werden.
Service
Im Anschluss tauschen wir in der Service Definition das Interface gegen die Projektion aus und verwenden den gleichen Alias. Zusätzlich generieren wir noch einen OData v2 Service mit entsprechender UI Annotation und testen die App über den Elements Preview. Der OData v4 konnte zwar die App anzeigen, die Aktionen die Ändern oder Anlegen funktionierten darüber nicht und wir hätten einiges mehr vorzubereiten.
Legen wir nun einen neuen Datensatz an, in dem wir über den Create Button in die Detailanzeige springen:
Am Ende filtern wir das Ergebnis über die Suchfelder und sehen den neu angelegten Datensatz in der Liste:
Fazit
Die Projektionsschicht ermöglicht weitere Einschränkungen der Funktionen und Informationen, die wir mit der App nach Außen geben wollen. Benötigen wir eine App für den Sachbearbeiter (Anlegen, Ändern) und eine für den Admin (mit Löschen), können wir das über zwei Projektionen auf dem RAP Business Objekt realisieren.
