SAPUI5 Custom Controls – Teil 1

von Maximilian Olzinger | Jul 28, 2020 | Blog, SAPUI5 / Fiori

SAPUI5 Custom Controls Teil 1

Um SAPUI5 Custom Controls besser erklären zu können haben wir uns für eine mehrteilige Blog-Reihe entschieden. Wenn der SAPUI5 Standard nicht mehr ausreicht, müssen Custom Controls entwickelt werden. Alles zum Thema Custom Control Development erfahren Sie hier.

SAPUI5 Custom Controls Teil 1 Inhalt:

Das Konzept

Der Aufbau

Properties

Aggregations

Associations

Events

Zusätze

Coding

Render Manager

Welches Konzept steckt hinter SAPUI5 Custom Controls?

In SAP UI5 ist es möglich, dass Sie bestehende Controls erweitern. Wenn die normalen Funktionalitäten eines Controls nicht mehr ausreichen. Ebenso lassen sich ganz neue Controls erstellen, um den wachsenden Anforderungsschwierigkeiten gewachsen zu sein.

Leider weichen Sie dann jedoch vom Fiori-Standard ab und ist nicht mehr Guideline-Konform. Jedoch kann es trotzdem sein, dass man eine Aufgabenstellung zu bewältigen hat, die mit dem Standard nicht abzubilden ist.

Genau hier tritt das Custom-Control-Konzept ins Spiel.

Wie ist der Aufbau von SAPUI5 Custom Controls?

Grundsätzlich ist ein UI5 Control nichts anderes als ein Modul. Es wird zur Laufzeit dynamisch nachgeladen. Ein solches Modul können Sie mit sap.ui.define erstellen und anschließend angesprechen.

Des Weiteren wird ein UI5 Control immer als HTML-Element gerendered. Wie genau das aussieht, wird immer im Control-spezifischen render-Methode über den RenderManager definiert. Mit dieser Methode können Sie das Custom Control in die HTML-Elemente umwandeln. So möchte es der Entwickler gerne haben. Es wird zum Beispiel beim Rendern einer sap.m.Table eine HTML-table mit td- und tr-Elementen in das DOM eingetragen und mit SAP-spezifischen CSS-Klassen gestyled.

Beim Aufbau von Eigenschaften eines Controls werden Sie immer in seinen Metadaten definieren. Ein Control hat ein dementsprechendes metadata-Object. Dort können Sie Properties, Events, Aggregations und Associations definieren. Diese können dann in der View und über den Controller angesprochen werden.

Dies sieht wie folgt aus:

Sobald ich die Methode extend von dem sap.ui.core.Control aufrufe, erstelle ich ein neues Control. Wenn ich das extend von einem bestehenden Control aufrufen, z.B. dem sap.m.Button, würde ich dieses erweitern.

Nach dem ich nun ein neues Control erstellt habe, kann ich die Metadaten definieren:

Properties im SAPUI5 Custom Control

Control-Properties bekommen ein Object zugewiesen, in dem Sie den Datentyp zuweisen und gegebenenfalls einen Default-Wert hinterlegen.

Folgende Einstellungen kann ich also vornehmen:

type – Default type ist string.
defaultValue

Zulässige Datentypen für die type-Property sind:

string
int
float
string[]
…

Sie können auch eigene Konfigurationsproperties innerhalb meiner Property erstellen und diese dann zur Datenverarbeitung nutzen.

Aggregations

Aggregations können Sie mit 3 verschiedenen Konfigurationen erstellen.

type – Default type ist sap.ui.core.Control.
multiple – Default ist true.
singularName
visibility

Type gibt an, welches Control Sie gerne aggregieren möchten. Manchmal sind solche Aggregation-Controls nicht Module die von sap.ui.core.Control erben, sondern von der abstrakten Klasse sap.ui.core.Element. Sie haben daher keinen eigenen Renderer. Das Rendering von diesen Controls übernimmt das Control, das diese Elemente aggregiert. Mein Custom Control kann natürlich auch andere Custom Controls aggregieren.

Mit multiple: true kann ich sagen, ob meine Aggregation 0 bis N Controls aggregieren kann, oder ob nur ein Control in meiner Aggregation zugelassen wird.

Die Property singularName gibt einen String an, der für automatisch generierte Methoden eingefügt werden soll, um z.B. ein neues Item in die Items-Aggregation einzufügen.

Per visibility-Property lege ich fest, ob meine Aggregation in der View benutzt werden kann und ob sie für den Entwickler sichtbar sein sollte. Wenn die visibility auf Verbergen sein sollte, dann muss die Value „hidden“ vergeben werden.

Associations

Mit Associations können Controls miteinander verknüpft werden. Es kann eine Abhängigkeit erstellt werden. Das bekannteste Beispiel ist die labelFor-Property/Association vom sap.m.Label.

Associations haben den gleichen Konfigurations-Aufbau wie Aggregations. Sie haben daher auch:

type
multiple
singularName
visibility

Events

Controls können Eventhandler für bestimmte HTML-Events definieren. Für jedes selbstdefinierte Event werden automatisch folgende Funktionen erstellt:

attach<Name>
detach<Name>
fire<Name>

Somit würde ich z.B. für mein Custom Event saveForm die Funktionen attachSaveForm, detachSaveForm und fireSaveForm automatisch generiert bekommen.

Sobald ich ein Event erstellt habe, muss ich nur mehr den dementsprechenden HTML-Eventhandler definieren und dort die fire-Methode meines Events aufrufen. Für die Event-Handler-Implementierung erstelle ich innerhalb meines Controls eine neue Methode, die genau so heißt wie das dementsprechende HTML-Event.

Events können auch Parameter definieren, die ich bei einem fireEvent befülle.

myEvent: {

parameters: { wasClicked: {type: „boolean“}}

}

Zusätze

Zusätzlich zu den 4 Basis-Konfigurationen stehen noch mehr Optionen zur Verfügung.

So kann ich

dnd – Drag and Drop
designtime – Design
…

zusätzlich definieren und konfigurieren. Auch kann ich das Metadaten-Objekt um eigene Einstellungen erweitern.

Coding

Die wichtigste Methode unseres Controls ist die onInit-Methode. Diese wird beim Initialisieren unseres Controls aufgerufen und dient mir als Startmöglichkeit.

Weitere Funktionen können ganz normal als Objekt-Methoden eingefügt werden. Hier sollte aber auf das Naming der Methoden geachtet werden. Damit es keine Überschneidungen zu automatisch generierten Methoden kommt.

Mit Hilfe der automatisch generierten Set– und Get-Methoden meiner Properties kann ich jetzt auf diese zugreifen.

Render Manager im SAPUI5 Custom Controls

Nachdem ich nun die Metadaten und das Coding fertig habe, muss ich das Control auch dementsprechend anzeigen.

Hierfür dient der Render Manager in der renderer-Methode meines Controls. Mit dessen Hilfe kann ich in das DOM eingreifen und mein Control platzieren. Der Render Manager kommt in der renderer-Methode meines Controls zum Einsatz. Benutzt wird normaler HTML-Code, um unser Control in das DOM zu bringen.

Normalerweise wird die renderer-Methode in ein eigenes File ausgelagert.

Was sind wichtigsten Render Manger Funktionen?

Die wichtigsten Funktionen des RM’s sind:

openStart – Erstellt ein neues öffnendes Element <…
openEnd – Schließt das öffnende Element <…>
close – Schließt das Element </…>
write – Schreibt HTML-Code
writeControlData – Schreib die Conrol-ID in das DOM
renderControl – Ruft die renderer-Methode eines aggregierten Controls auf
class – Fügt eine CSS-Klasse dem HTML-Element hinzu
attr – Fügt dem Element ein Attribut mit Value hinzu
…

Zusammenfassung

Wir sehen, dass das Erstellen eines Custom-Controls einige Möglichkeiten beinhaltet. Wir können Properties, Aggregations, Events und Associations definieren. Zusätzlich benötigen wir noch die renderer-Methode mit dem RenderManager, um unser Control in das DOM zu bringen und anzuzeigen.

Falls Fragen auftauchen, können sie gerne unten in den Kommentaren gestellt werden. Ich freue mich auf Feedback.

Im nächsten Blog-Part 2 werden wir ein Beispiel-Control entwickeln und uns im Detail die Implementierung ansehen.

SAPUI5 Custom Controls Teil 2

Git Tutorial 2 |Git Anleitung| Git Wissen| Git erklären Teil 2

von Daniel Krancz | Jul 20, 2020 | Blog, SAPUI5 / Fiori

Git Tutorial: die wichtigsten Begriffe und Funktionen

Mit diesem Git Tutorial / Git Grundlagen wirst du zum Git Profi!

Mit dieser Git-Anleitung möchten wir dir zeigen, wie wichtig Git für Entwickler geworden ist. In dieser Blogreihe werden wir uns mit dem Thema Git beschäftigen und damit, warum das Arbeiten mit Git oder mit einem ähnlichen Tool für Entwickler fast schon unumgänglich ist.

Die folgenden Informationen werden auch, jedoch um einiges ausführlicher, in unserem – offiziell bei der SAP im Schulungskatalog gelisteten – Kurs HOUI5 behandelt.

SAP Trainings

Inhalt des Git Tutorials

Wir werden auf folgende Themen eingehen:

Einführung in die Welt von Git
Begrifflichkeiten und die wichtigsten Funktionen
SAPUI5-Entwicklung mit Hilfe von Git
- Exkurs: LDAP-Anbindung und Git-Server-Anbindung an die SAP Cloud Platform

Zielsetzung

Unser Ziel ist es, dass du nach dem Git Tutorial, die unten stehende Grafik interpretieren und mit Git die SAPUI5-Entwicklung optimieren kann.

Das Video zum Blog

Wichtig

Seitdem GitHub die Namenskonventionen umgestellt hat, heißt der Strang, der automatisch angelegt wird, nicht mehr „master“ bzw. „origin/master“, sondern „main“ und „origin/main“. Da die SAP WebIDE diese Änderung noch nicht erkennt, muss man das entweder in der WebIDE mitgeben oder in GitHub übersteuern.

zum Knowledge Base

Git Tutorial Part 2 – Inhaltsverzeichnis

Begrifflichkeiten:

Repository
Branch
Commit
Staging Area

Funktionen:

Push
Clone
Fetch
Merge
Pull
Best practice
Rebase
Reset (Hard Reset & Mixed Reset)

Über den Autor

Daniel Krancz

SAP-Consultant / Software-Developer

Ich bin SAP-Berater und -Entwickler im SAPUI5/Fiori- und OData-Umfeld. Seit 2019 bin ich offiziell als externer Trainer bei SAP gelistet und halte Kurse (UX, S4, …) über SAP-Webentwicklungen und Cloud-Implementierungen im In- und Ausland. Seit 2021 bin ich SAP Press Autor beim Rheinwerk Verlag im Bereich SAP Mobile.

Begrifflichkeiten

Zu einem guten Git Tutorial gehört natürlich auch, dass erklären der wichtigsten Begrifflichkeiten und gängigsten Funktionen im Git-Umfeld.

Repository

Ein Repository kann mit einem einfachen Verzeichnis verglichen werden, in welchem weitere Verzeichnisse und Dateien abgelegt werden können. Ein Repository beinhaltet normalerweise ein Projekt bzw. ein Programm.

Es gibt eine Unterscheidung zwischen einem Remote (am Server oder in der Cloud) und einem Local (in der IDE) Repository.

Branch

Ein Repository beinhaltet mindestens einen Entwicklungsstrang, kann aber auch in mehrere Entwicklungsstränge unterteilt werden. Diese Stränge nennt man Branches.

Branches benutzt man entweder um Systemlandschaften (z.B. DEV, QAS und PRD) oder Feature-Entwicklungen (z.B. eine neue Funktionalität für Kunden) abzubilden. Die Unterteilung in den Landschaften ist üblicherweise am Remote Repository vertreten.

Je nachdem wo die Branches liegen, redet man von Remote und Local Branches.

Wenn man ein Remote Repository erstellt, so wird automatisch auch der erste Branch mit dem Namen „origin/master“ angelegt. Bei einem Local Repository heißt der erste Branch nur „master“.

Commit

Einen Commit kann man mit einem Snapshot, sprich mit einer Momentaufnahme, vergleichen. Diese Momentaufnahme beinhaltet die gesamten Änderungen seit dem letzten Commit. Diese Commits werden mit bestimmten Daten (Description, ID, Author, Timestamp, …) versehen und abgespeichert.

Ein Commit ist somit die kleinste „Einheit“ im Git-Umfeld.

Staging Area

In der Staging Area befinden sich alle Files, die seit dem letzten Commit editiert wurden. Das heißt, die Staging Area ist ein Ort für das Zwischenspeichern der Änderungen. Zusätzlich kann man auswählen, welche Änderungen aus der Staging Area man beim nächsten Commit mitnehmen möchte.

So könnte man X Änderungen aus der Staging Area auf Y Commits aufteilen und so einen sauberen Entwicklungsstrang abbilden.

Wie funktioniert Git, und welche Vorteile hat es für die SAP-Entwicklung?- Alles darüber findet Ihr in diesem Buch: Amazon oder Rheinwerk

Git und SAP - Versionsverwaltung und Transporte

Welche Funktionen gibt es in Git?

Mit diesem Git Tutorial, gehen wir ausserdem auf die gängigsten Funktionen ein, mit der man Repositories und Branches manipulieren kann. Wir werden uns nur die wichtigsten anschauen (Push, Fetch, Merge, Pull, Clone, Rebase), aber es gibt noch um einiges mehr (Cherry-Pick, Stashing, …).

Push

Wenn man in der IDE entwickelt und irgendwann einen Stand hat, den man mit anderen Entwicklern teilen möchte, dann muss man den letzten Commit mit einem Push in das Remote Repository bringen.

Da das Remote Repository am Anfang leer ist, kann der erste Entwickler, der z.B. das Rahmenprojekt aufgesetzt hat, seine Entwicklungen ohne Rücksicht pushen:

Später sollte vor jedem Push gecheckt werden, ob sich am Remote Repository etwas geändert hat. Wie das funktioniert, erfahren Sie weiter unten.

Clone

Es kann nur einen ersten bzw. initialen Push geben. Wenn also sich am Remote Repository bereits Daten befinden, dann muss ich das Ganze in meine lokale Umgebung bekommen.

Das funktioniert mit einem Clone:

Fetch

Mit einem Fetch kann ich die Änderungen, die seit meinem letzten Fetch gemacht wurden, in die lokale Umgebung laden. Einfacher ausgedrückt: Wir schauen nach, ob andere Entwickler was Neues gemacht haben.

Merge

Nur nachschauen, ob andere Entwickler etwas gemacht haben, reicht noch nicht ganz aus. Wir müssen die Datenstände zusammenführen und diesen Vorgang nennt man Merge.

Wir haben vorhin, als wir über Branches geredet haben, etwas verschwiegen. Die Namen für Branches sind nichts anderes wie Pointer bzw. Zeiger. Ein Zeiger auf den aktuellen Commit, sprich auf den letzten Snapshot.

Was bei einem Merge technisch passiert ist ganz einfach: Der Zeiger von meinem altem Commit, wird auf den neuen Commit gesetzt, welchen wir uns mit einem Fetch geladen haben. Dabei wird geschaut, ob sich Änderungen überschneiden. Wenn sich Änderungen überschneiden, gibt es Konflikte.

Auf Konflikte wird man immer hingewiesen und der Entwickler, der die Zusammenführung macht, kann entscheiden, welche Code-Passagen die Aktuellen sind. Ein Merge wird in einem eigenen Commit protokolliert.

Pull

Man sieht jetzt schon, dass man Fetch und Merge oft brauchen wird. Das haben sich auch die Entwickler von Git gedacht und deswegen die Funktion Pull ins Leben gerufen.

Pull führt zuerst einen Fetch und dann automatisch einen Merge aus:

Git Tutorial – Best practice

Einmalig:

Clone or Initial Commit and Push
- wenn ich der erste bin = Push
- App vom Remote Repository clonen

Wiederkehrend:

Fetch: schauen ob sich was getan hat
Merge: den Zeiger auf die aktuelle Version verschieben und die Datenstände zusammenführen (auf eventuelle Konflikte reagieren)
Push: die aktuelle Version mit anderen Entwicklern teilen

Pull: schauen ob sich was getan hat, den Zeiger auf die aktuelle Version verschieben und die Datenstände zusammenführen (auf eventuelle Konflikte reagieren)
Push: die aktuelle Version mit anderen Entwicklern teilen

Wir kennen jetzt viele Begriffe und kennen auch schon die wichtigsten Funktionalitäten. Jetzt gehen wir nochmal auf die Branches ein und bringen all das Wissen mit, was wir gelernt haben.

Wir haben gesagt, dass auch am Remote Repository Branches erstellt werden können (z.B. P,Q,D), aber auch am Local Repository (z.B. Features).

Gehen wir von folgendem Beispiel aus: Es existiert bereits ein Repository und da wir jetzt auch im Entwicklerteam sind, können wir vom Remote Repository vom Entwicklungsbranch die aktuellen Stände clonen.

Wir machen sicherheitshalber einen Local Feature Branch wo wir einige Entwicklungen und auch Commits machen. Nach einigen Entwicklungstagen sind wir fertig und mergen lokal unsere Features mit dem lokalen Master.

Bevor wir unsere Änderungen mit anderen teilen können, müssen wir checken, ob andere Entwickler auch zwischenzeitlich gepusht haben und führen einen Fetch und danach Merge bzw. einen Pull aus.

Nachdem wir uns mit einigen Konflikten beschäftigen durften, können wir nun endlich unsere Änderungen pushen und mit anderen Entwicklern teilen.

Unser Administrator nimmt nach eigenem Ermessen die Datenstände und macht einen Merge zwischen D und Q und signalisiert somit dem Testteam, dass sie testen können.

Wenn die Tests abgeschlossen sind, dann kann der Administrator zwischen Q und P einen Merge durchführen. Der P-Branch wird dann entweder exportiert oder der Administrator deployed ihn direkt auf das Kundensystem und der Kunde hat nun eine neue Version der Applikation.

Rebase

Wenn wir uns die obenstehende Grafik genauer anschauen, dann werden wir erkennen, dass durch einen Merge immer ein „unnötiger“ Commit entsteht.

Durch Rebase können wir auch dieses – oft von Entwicklern empfundene – Designproblem lösen und einen sauberen Entwicklungsstrang ohne „Merge-Commits“ aufbauen.

Nehmen wir an, wir haben lokal einen Feature Branch gemacht. Dort haben wir fleißig entwickelt und möchten jetzt unsere Änderungen wieder auf den Master Branch bekommen:

Wenn wir jetzt ein Rebase von unserem Feature auf den Master Branch machen, dann schauen unsere Commits wie folgt aus:

Nichtsdestotrotz müssen wir an dieser Stelle noch einen Merge machen, da passiert aber wiederum nichts anderes, als das der Zeiger von dem alten Commit auf den neuesten Commit bewegt wird, jedoch mit dem Unterschied, dass wir an dieser Stelle keinen zusätzlichen Commit für das Mergen erzeugen:

Jetzt schaut unser Master Branch sauber aus, wir haben einen sauberen Entwicklungsstrang und ein Außenstehender würde meinen, dass wir keinen Feature Branch – sprich keinen weiteren Branch – für die Entwicklung verwendet haben.

Rebase mit Konflikten

Wenn es zu einem Konflikt kommt, so wird das nicht, wie bei einem Merge, in einem extra Commit verpackt, sondern die zwei Commits, die von den Änderungen betroffen sind, werden entweder fusioniert oder einer von den beiden Commits gewinnt. Entscheidungsträger ist hier wiederum der Entwickler, der gerade einen Rebase vornimmt.

Was ist ein Git Reset?

Viele „Git-Neulinge“ verwechseln Reset mit Rebase. Oft glaubt man, dass Rebase irgendetwas mit dem Zurücksetzen der Änderungen zu tun hat, was aber nicht stimmt.

Mit Reset hat man zwei Möglichkeiten um das Zurücksetzen der Daten bzw. den Änderungen bis zu einem, in der Vergangenheit liegenden, bestimmten Commit zu erreichen:

Welche Arten von Git Reset gibt es?

Hard Reset

Gehen wir davon aus, dass wir einen Feature Branch eröffnet haben und dem Feature, welches ein Change Request vom Kunden war, eine Absage erteilt wird. Wir wissen schon, dass wir an einem weiteren Feature arbeiten werden, welches aber nichts mit unserem bisherigen Feature Entwicklungen zu tun hat.

In diesem Fall werden wir einen Hard Reset machen. Die bisherigen Entwicklungen am Feature Branch werden verworfen und der Feature Branch wird mit dem ausgewählten Branch, in unserem Fall dem Master Branch, gemerged um wieder auf dem gleichen Datenstand zu sein:

Mixed Reset

Bei einem Mixed Reset schaut das ganze fast gleich aus, mit dem Unterschied, dass wir nicht alles verwerfen, sondern einige Änderungen, die sich in der Staging Area befinden, mitgenommen werden können.

Zusammenfassung

Nachdem wir mit dieser Git Anleitung jetzt einiges über Git wissen und auch schon die wichtigsten Begrifflichkeiten und Funktionalitäten kennengelernt haben, können wir uns im dritten Teil unserer Blogreihe ansehen, wie man Git effizient bei der Entwicklung mit der SAP WebIDE einsetzt.

Git Teil 3 entwickeln mit SAP WebIDE

Git Tutorial 1 | Git lernen | Git einfach erklärt Teil 1

von Daniel Krancz | Jul 13, 2020 | Blog, SAPUI5 / Fiori

Einführung in die Welt von Git

Herzlich Willkommen bei unserem mehrteiligen CloudDNA SAP GIT Tutorial!

Wir zeigen Ihnen, warum das Arbeiten mit Git für Ihre EntwicklerInnen fast schon unumgänglich ist. SAP und Git galt lange Zeit als Widerspruch. Doch die Zeiten ändern sich und damit auch die Anforderungen und potenzielle Lösungen. Los gehts mit dem Git Tutorial 1!

Die folgenden Informationen werden auch, jedoch um einiges ausführlicher, in unserem offiziell bei der SAP im Schulungskatalog gelisteten Kurs HOUI5 behandelt.

Unsere Trainings für die SAP

Inhalt CloudDNA SAP GIT Tutorial Serie

Wir zeigen Ihnen in unserem CloudDNA SAP GIT Tutorial folgende Inhalte:

1. Teil: Einführung in die Welt von Git
2. Teil: Begrifflichkeiten und die wichtigsten Funktionen
3. Teil: SAPUI5-Entwicklung mit Hilfe von Git
- Exkurs: LDAP-Anbindung und Git-Server-Anbindung an die SAP Cloud Platform

Zielsetzung dieses GIT Tutorials

Dieses Git Tutorial macht dich zum Git Profi

Unser Ziel ist es, dass Sie nach unseren Tutorials die unten stehende Grafik interpretieren und mit GIT Ihre SAPUI5, SAP Fiori und ABAP-Entwicklungen optimieren können.

Wichtig

zum Knowledge Base

Das CloudDNA Git Tutorial als Einführung in die Git-Welt!

Ein gutes Tutorial muss sich erst einmal mit grundlegenden Informationen beschäftigen. Stellen wir uns einige W-Fragen.

Was ist Git ?

Kurz zusammengefasst ist Git eine Software für die verteilte Verwaltung von Dateien und die damit verbunden Aktionen. Durch Versionierungen kann man Änderungen verfolgen und nachvollziehen.

Wo verwende ich Git?

Mittlerweile gibt es verschiedene Plattformen und damit auch Anbieter für Git-Software. Zu den bekanntesten zählen GitHub (Microsoft) oder GitLab und Bitbucket (Atlassian).

Abhängig von den Complianceanforderungen ihres Unternehmens ergeben sich unterschiedliche Nutzungsmodelle. Man kann sich entweder bei diesen Anbietern in der Cloud platzieren, aber es besteht auch die Möglichkeit, Git auf einem eigenen Server zu installieren. Hierbei muss man beachten, dass man alle Vorteile einer Cloud-Lösung verliert. Man ist selber für Backups, Updates usw. verantwortlich.

In unseren Beispielen werden wir uns mit GitHub und einem lokalen Git-Server auseinandersetzen.

Warum Git?

Viele Entwickler kennen das Problem, wenn man gemeinsam an einem Projekt oder gar in einem Projekt am selben File arbeiten möchte, welche sich am Server befinden. Jetzt muss man sich einerseits mit den verschiedenen Versionen und/oder mit Konflikten auseinandersetzen.

GIT nimmt Ihnen all diese Probleme ab und hilft Ihnen mit einfachen Funktionen, Änderungen mit anderen Entwicklern zu teilen. GIT verwaltet Ihre Sourcen und erkennt auch gleichzeitig Konflikte, damit Sie keine Änderungen von anderen Entwicklern überschreiben.

Womit kann ich Git kombinieren?

Mit Build Pipelines kann man sicherstellen, dass die Versionen unserer Programme am Git immer ausführbar und getestet sind. Git kann man mit verschiedensten Programmen kombinieren, um Continuous Integration und Delivery (Jenkins) zu erzielen. Man kann die Verbindung von einzelnen Programmversionen im Git mit unseren Entwicklungspaketen und User Storys im SCRUM-Umfeld (Jira) herstellen.

Das waren nur einige Beispiele von dem, was alles an Kombinationen und Möglichkeiten mit Git möglich sind.

Zusammenfassung CloudDNA SAP GIT Tutorial (Teil 1)

In diesem ersten Teil des CloudDNA Git Tutorials haben wir Ihnen die grundlegenden Informationen gezeigt. Sie wissen nun, was Git darstellt und warum Sie Git verwenden sollten. Durch einen kurzen Einblick in die Kombinationsmöglichkeiten wissen Sie auch, wie umfangreich das Thema rund um Git werden kann.

Im zweiten Teil des CloudDNA Git Tutorials erklären wir Ihnen die wichtigsten Begrifflichkeiten und Funktionen im Git-Umfeld. Damit kommen Sie dem gemeinsamen Ziel, die oben stehende Grafik interpretieren zu können und im Anschluss Git auch im SAP-Umfeld verwenden zu können, ein großes Stück näher.

Wie funktioniert Git, und welche Vorteile hat es für die SAP-Entwicklung?- Alles darüber findet Ihr in diesem Buch: Amazon oder Rheinwerk

Git Teil 2 Funktionen und Begriffe im Git-Umfeld

Unsere Empfehlung ist das Git Tutorial Teil 1 – Teil 3 chronologisch durchzuarbeiten. Falls Sie sich mit Git Funktionen und Begrifflichkeiten schon auskennen, hab wir Ihnen den dritten Teil weiter unten verlinkt. Teil 3 befasst sich mit den Themen Git Repositories anlegen und wie das Conflict Handling funktioniert. Wir wünschen viel Spaß beim Lesen und vorallem beim Ausprobieren!

Teil 3

Lernen Sie mit diesem Git Tutorial wie Git Repositories angelegt und in der SAP WebIDE verwendet werden. Wir erklären Ihnen außerdem mit dieser Git Anleitung wie Konflikte gelöst werden können.

Git Teil 3: Git Repository | Git Konflikte lösen

Sind Sie auf der Suche nach SAP Cloud Consulting oder ganz allgemein SAP Beratung in Österreich, Deutschland oder der Schweiz? Dann sind Sie bei uns genau richtig! Wir bringen Sie sicher in die Cloud und kümmern uns um ihr SAP Szenarien. Wir lassen Sie nicht hängen – we deliver !

Über den Autor

Daniel Krancz

SAP-Consultant / Software-Developer

RestModel für SAP UI5 einfach erklärt

von Maximilian Olzinger | Jun 23, 2020 | Blog, Features

RestModel für SAPUI5 kennenlernen

Herzlich willkommen bei unserem Blog zum Thema RestModel für SAPUI5.

Zuerst beantworten wir Ihnen die gängigsten W-Fragen! Wenn Sie noch weitere Fragen zum Thema RestModel für SAPUi5 haben hinterlassen einfache ein Nachricht!

Was? RestModel in SAPUI5?

Sie fragen sich vielleicht: RestModel in SAPUI5? Verwenden wir nicht normalerweise OData oder laden uns Daten in ein JSONModel?

Nun, mit dem RestModel für SAPUI5 lassen sich ganz leicht RESTful-Webservices konsumieren.

Inhaltsverzeichnis

Warum RestModel im SAPUI5?
Wie benutzen Sie das RestModel im SAPIU5?
Wie heissen die CRUD- Basics im Restmodel für SAPUI5?
Schmankler für Restmodel im SAPUI5
Ist das RestModel Open-Source?

Warum RestModel im SAPUI5?

Es gibt immer wieder die Anforderung, UI5 Apps zu bauen, die keinen OData-Service als Backend-Service benutzen. Jedoch ist das SAPUI5 Framework darauf ausgelegt, mit OData zu kommunizieren. Dies merken Sie direkt an der tollen Integration der ODataV2(OData in seiner reinsten Form) und ODataV4(es ist noch Luft nach oben)-Models.

Jetzt kann es jedoch sein, dass überhaupt kein OData-Service zur Verfügung steht, sondern nur ein RESTful-Webservice. Standartmäßig können Sie dieses Problem folgendermaßen lösen:

JSONModel.loadData(……)
- Mit der .loadData-Methode des JSONModels könnte man einen GET-Request auf eine externe Ressource abschicken.
$.ajax(….)
- Per ajax und jQuery lassen sich asynchrone Requests per Javascript losschicken. Im Grunde verwenden die bekannten UI5-Models im Hintergrund ajax-Calls.

Jedoch sind beide Lösungen nicht immer die optimalsten, vor allem da zB. das JSONModel eher als client-seitiges Model darauf ausgelegt ist, lokale Daten zu speichern.

Deshalb entwickeln wir ein RestModel auf Basis des HTTP-Clients axios.

Bei uns findet es auch Anwendung in unserem CloudDNA OData-Plugin.

Wie benutzen Sie das RestModel für SAPUI5?

Das RestModel benutzt den axios-Client, um HTTP-Calls gegen einen RESTful-Webservice abzuschicken. Axios ist ein HTTP-Client für Browser und node.js, der von Matt Zabriskie als Open-Source Projekt unter der MIT-Lizenz angeboten wird.

Das RestModel kann nun auf den bereits umfangreichen axios-Client aufbauen und schneidert die Funktionalitäten auf UI5-Ansprüche zu. So z.B. das Mapping von Destinations auf selbstdefinierbare Zugriffspunkte in der neo-app.json.

Folgende Funktionen stehen zur Verfügung:

Wie heissen die CRUD – Basics im RestModel?

create – POST um Daten wegzuschicken,
read – GET um sich Daten zu holen
update – PUT um Daten zu verändern
remove – DELETE um Daten zu löschen

Die CRUD-Funktionen des RestModels ähneln sich syntaktisch den ODataModel-CRUD-Funktionen. Dies wurde aus einem speziellen Grund so gewählt: Die Verwendung des RestModels soll sich gewohnt anfühlen.

So könnnen Sie zB. ein RestModel-Read folgendermaßen absenden:


this._oModel.read("/Customer", {

     success: function (oData) { 

         oCodeEditor.setValue(JSON.stringify(oData, null, "\t")); 

     }.bind(this) 

});

Dies sieht im 1. Moment aus wie ein Read des ODataModels.
Jedoch steht hier eine Instanz des RestModels dahinter.

this._oModel = new RestModel({

    url: "&lt;myservice.com/api&gt;",

});

Mit dieser RestModel-Instanz und dem dahinterliegenden axios können Sie jetzt in gewohnter ODataModel-Manier Rest-Calls absetzen. So werden die CRUD-Methoden plus Parameter und Header unterstützt.

Das Resultat eines Requests lässt sich entweder über Callback-Funktionen oder auch per Promise abarbeiten. Somit ist man nicht mehr auf Success- und Error-Callback gebunden, sondern kann auf das Javascript Promise-Konzept zugreifen. Die zurückgelieferten Daten können z.B. in ein JSONModel geladen werden und an die View gebunden werden.

Zusätzlich – Die ‚Schmankerl‘

bearerTokenLogin – Speichern eines Bearer-Tokens
setXCSRFTokenHandling – Cross-Site-Ressource-Forging Handling
….

Das RestModel bietet noch weitere nützliche Features an. So gibt es zB. die Unterstützung eines Bearer-Token Logins, sofern der Webservice diesen anbietet.

Ebenfalls kann das X-CSRF-Token gespeichert und als Request-Header für alle weiteren Requests gesetzt werden. Dies kennen Sie als UI5-Entwickler besonders aus dem File-Upload Gebiet.

Open-Source?

Das RestModel ist natürlich Open-Source und kann auf github geklont werden. Dort wird es immer mit neuen Updates versorgt und korrigiert.

So kommen in Zukunft neue Features hinzu, wie zB. die Speicherung der angeforderten Daten per Model, so dass ein Binding betrieben werden kann und Daten per View geladen werden können.

Ebenfalls würden wir uns über die Mitarbeit anderer Entwickler an diesem Open-Source-Projekt freuen, um das bestmögliche aus dem RestModel herauszuholen.

Alles klar

Getreu unserem Leitfaden

-Von Entwickler – Für Entwickler-

sollte das RestModel besonders Entwickler in UI5-Umfeld nützlich sein.

Wer also auf REST-Services zugreifen möchte und mit den ODataModel-Methoden vertraut ist, für den ist das RestModel interessant und sicherlich eine Erleichterung bei REST-Calls.

Einen detailierteren Einblick mit Dokumentation gibt es auf der github-Repository-Seite des RestModels.

Wir freuen uns über konstruktive Kritik und Anregungen und falls Fragen bestehen, zögern Sie nicht und kommentieren Sie unterhalb

Die UI5-Media-Entity Journey – Part 3

von Maximilian Olzinger | Mai 6, 2020 | Blog, OData-Journey

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:

HOUI5 – Hands-on Foundation zur Entwicklung von SAPUI5 Applikationen
HOFIO – Hands-on Deep Dive zur Entwicklung von SAP Fiori Oberflächen
WDECPS – SAP Cloud Platform Security Eine ganzheitliche Betrachtung

Inhalt

Im dritten Teil der Blogserie erstellen wir eine SAPUI5-App und integrieren die sap.m.UploadCollection.

Schritt 3 – File Upload

Wir erstellen nun eine SAPUI5 Applikation über die SAP WebIDE. Des weiteren binden wir den OData-Service ein, den wir in Schritt 2 erstellt haben, um Files zu speichern und anzuzeigen,

Hilfreiche Links:

Voraussetzungen

Zugang zur SAP Web IDE
Ein korrekt eingerichteter Cloud Connector mit dazugehöriger Destination in der SAP CP

App erstellen

Wir wechseln in die SAP WebIDE und legen per Create Project from Template ein neues SAPUI5 Projekt an.

Nennen wir sie ZDemoFile im Namespace at.demo.file und benutzen als Default-View eine View mit dem Namen Main.

Da wir nur eine View anzeigen und keine Navigation haben, benötigen wir nicht eine weitere View als Navigationscontainer.

Im i18n.properties-File kann noch der Titel der Page angepasst werden.

OData-Service hinzufügen

Sobald die App nun erstellt ist, kann per rechtsklick ein neuer OData-Service hinzugefügt werden. Hier bitte die Voraussetzungen oben beachten.

Wir suchen, sobald wir die richtige Destination ausgewählt haben, unseren Service und setzen diesen als Default-Model für unsere App.

UploadCollection implementieren

Als 1. Schritt implementieren wir die UploadCollection samt UploadCollectionItem.

Diese beiden Controls befinden sich im sap.m.-Standartnamensraum und können daher ohne Alias definiert werden.

Wir definieren folgende Properties für die Upload Collection:

items=“{/FileSet}“
- Zeigt auf unser EntitySet.
beforeUploadStarts=“onBeforeUploadStarts“
- Eventhandler für das Event welches aufgerufen wird, bevor der Upload beginnt.
change=“onUploadChange“
- Eventhandler, der zieht sobald ein File zum Upload ausgewählt wird.

Und für das UploadCollectionItem

documentId=“{Fileid}“
fileName=“{Filename}“
mimeType=““{Mimetype}

Sobald die App nun gestartet wird, sehen wir das in Schritt 2 hochgeladene File.

Controller bearbeiten

Wir wechseln nun in den Main-Controller.

Dort implementieren wir die beiden Eventhandler uns setzten die Upload-URL für die UploadCollection.

Zuerst speichern wir uns in der onInit-Funktion unsere UploadCollection und setzen die Upload-URL. Diese setzt sich aus der Service-URL unseres Models und dem Entity-Set FileSet zusammen.

In der onUploadChange-Funktion behandeln wir den XCSRF-Header. Dieser ist für Cross-Site-Resource-Forging zuständig und muss gesetzt werden. Das ODataModel bietet mit der Funktion getSecurityToke() die Möglichkeit, sich ein solches XCSRF-Token zu generieren lassen. Dass muss anschließend noch als HeaderParameter gesetzt werden.

In der onBeforeUploadStart-Funktion muss der Slug-Header gesetzt werden. Den Filenamen bekommen wir über das Event-Objekt heraus.

sap.ui.define([

„sap/ui/core/mvc/Controller“,

„sap/m/UploadCollectionParameter“

], function (Controller, UploadCollectionParameter) {

„use strict“;

return Controller.extend(„at.demo.file.ZDemoFile.controller.Main“, {

oFileUploader: null,

onInit: function () {

this.oFileUploader = this.getView().byId(„main_uploadcollection“);

this.oFileUploader.setUploadUrl(this.getView().getModel().sServiceUrl + „/FileSet“);

onUploadChange: function (oEvent) {

let oCSRFHeader = new UploadCollectionParameter({

name: „x-csrf-token“,

value: this.getView().getModel().getSecurityToken()

});

this.oFileUploader.removeAllHeaderParameters();

this.oFileUploader.addHeaderParameter(oCSRFHeader);

onBeforeUploadStarts: function (oEvent) {

let oHeaderSlug = new UploadCollectionParameter({

name: „slug“,

value: oEvent.getParameter(„fileName“)

});

oEvent.getParameters().addHeaderParameter(oHeaderSlug);

});

Upload testen

Sobald nun der Controller passt, kann die Upload-Funktionalität getestet werden.

Mit Hilfe des Hochladen-Buttons kann jetzt einen Daten geuploadet werden. Die UploadCollection zeigt anschließend das hochgeladene File in der Liste an. Solle es nicht angezeigt werden, kann dem mit einem Refresh auf das Model oder die Items-Aggregation abhilfe geschafft werden.

Zusammenfassung

Alles klappt

In diesem Schritt haben wir die Upload-Funktion für unsere Media-Entity implementiert. Aber nur der Upload führt noch nicht zum Ziel, denn wir möchten ja auch downloaden können.

Dies geschieht in Schritt 4, wo wir die UploadCollection um die Download-Funktion erweitern.

Falls Fragen zu diesen einzelnen Schritten auftreten, können sie gerne in den Kommentaren gestellt werden.

← Die UI5-Media-Entity Journey - Part 2 UI5 Media Entity Journey | OData- Part 4 →

« Ältere Einträge

Nächste Einträge »