In dieser 4-Teiligen Blogreihe erfahren Sie alles nötige, um Media-Entity-Handling in SAP UI5 laut gängigen Best-Practice-Erfahrungen zu implementieren.
Einen tieferen Einblick in verschiedenste Themen gibt es in unseren Kursen bei Die Entdecker, die offiziell über training.sap.com angeboten werden.
Für diesen Blog interessante Trainings:
Inhalt
Die Reihe befasst sich mit folgenden 4 Schritten zur kompletten UI5-App mit Media-Handling inklusive OData-Service per SEGW.
- onPremise-Vorarbeit
- OData-Service
- File Upload
- File Download
In Schritt 1 legen wir den Grundstein unseres File-Handlings. Wir legen eine Tabelle zur Speicherung unserer Files und die dazugehörige Struktur und CDS-View an.
In Schritt 2 implementieren wir über ein SEGW-Projekt einen OData-Service, der uns unser File an unsere UI5-App liefert. Hier werden die nötigen Methoden der Data-Provider-Class (DPC) redefiniert und korrekt implementiert.
In Schritt 3 legen wir ein neues UI5-Projekt an und verbinden uns mit dem erstellten Service. Außerdem implementieren wir eine UploadCollection, um Files von unserer App per OData-Service ins Backend zu uploaden.
In Schritt 4 erweitern wir die UploadCollection um eine Download-Funktion. Der Schritt 4 ist der abschließende Part der UI5-Media-Entity-Journey.
Schritt 1 – onPremise-Vorarbeit
Damit der Dokumentenupload in unserer UI5-App funktioniert, müssen wir auf unserem onPremise-System Vorarbeit leisten, sofern noch nicht geeignete Tabellen als Media-Entity über eine OData-Service freigegeben wurden.
Tabelle anlegen
Zu aller Erst begeben wir uns in die SE80 unseres onPrem-Systems.
In diesem Beispiel arbeiten wir mit lokalen Objekten. Diese befinden sich in der $TMP-Entwicklungsklasse und werden nicht weitertransportiert.
Nun legen wir eine neue Datenbanktabelle an. Diese wird bei unseren Lokalen Objekten in dem Dictionary-Folder gespeichert.
Als Name der Tabelle vergeben wir ZDEMO_FILE. Nach dem Names-Dialog fügen wir eine Beschreibung hinzu und konfigurieren Auslieferungsklasse und die Pflegeerlaubnis. Anschließend speichern wir die Tabelle als lokales Objekt.
Jetzt müssen wir Tabellenfelder vergeben. Die von uns in diesem Beispiel verwendeten können selbstverständlich anders benannt werden, die letzten 3 Felder sind sogar optional, da sie nicht so trivial für die Funktionalität sind, jedoch nützliche Informationen beinhalten.
- MANDT
- FILEID – Zur eindeutigen Identifikation unseres Files verwenden wir hier eineUUID.
- FILENAME – Speichert unseren Dokumentennamen, diesen bekommen wir später als Request-Header.
- MIMETYPE – Hier wird der Datentyp unseres Files gespeichert.
- CONTENT – Der Inhalt unseres Files.
- CREATION_DATE – Erstelldatum – Optional
- CREATION_TIME – Erstellzeit – Optional
- CREATED_BY – Ersteller – Optional
Anschließend speichern wir die Tabelle, aktivieren sie und ergänzen die Erweiterungskategorie und konfigurieren die Technischen Einstellungen.
Struktur anlegen
Sobald die Tabelle fertig konfiguriert ist, legen wir eine dazugeörige Struktur namens ZDEMO_FILE_S an. Diese wird gespeichert, aktiviert und zusätzlich wird noch die Erweiterungskategorie definiert.
View anlegen
Um den Inhalt der File-Tabelle über OData anzuzeigen, könne wir eine CDS-View erstellen. Diese wird mit unserer OData-Entity gemapped, somit bekommen wir die Get-Entity und die Get-Entity-Set Funktionen zusätzliche mit Filter und Sorter geschenkt.
Erforderlich sind hier:
Nüzliche Links:
- ABAP Projekt in Eclipse
- CDS-View anlegen
- CDS Best-Practice – Credits to inui.io
Wir erstellen eine CDS-View namens ZDEMO_FILE_V. Laut Best-Practice-Regeln sollte man für jede Tabelle, die man jedenfalls freigeben möchte, eine Basic-View erstellen. Diese gibt alle Felder der Tabelle frei. Und für jede Anwendung die nun die Daten der Tabelle/Basic-View benutzen möchte, sollte nun eine eigene Consumption-View erstellt werden, die genau auf den Anwendungsfall zugeschnitten wird. Für unser Beispiel reicht jedoch nur eine Consumption-View ohne Basic-View.
Sobald unsere View angelegt ist, können wir sie konfigurieren.
Wir benötigen den SQL-View-Namen, den View-Type und die zu selektierende Tabelle.
Der SQL-View-Name muss sich von dem DDL-Name unterscheiden. Als View-Type verwenden wir eine Consumption-View und wir möchten die Werte unserer zuvor angelegten ZDEMO_FILE-Tabelle selektieren.
Anschließend speichern wir unsere View und aktivieren sie. Falls Fehler auftreten, könnte es sein, dass der SQL- oder der DDL-Name schon vergeben ist, oder dass die ZDEMO_FILE-Tabelle nicht richtig aktiviert worden ist.
Zusammenfassung
In Teil 1 haben wir die Vorarbeit für unseren OData-Service gelegt, den wir im nächsten Schritt anlegen werden. Dazu haben wir eine Tabelle angelegt, die dazugehörige Struktur definiert und eine CDS-View erstellt.
Falls Fragen zu diesen einzelnen Schritten auftreten, können sie gerne in den Kommentaren gestellt werden.
Recent Comments