SAPUI5 Custom Controls – Teil 2

SAPUI5 Custom Controls – Teil 2

Der Weg zum eigenen Control

Da wir nun im letzten Teil alles über den generellen Aufbau eines SAPUI5 Custom Controls gelernt haben, möchten wir das ganze in der Praxis anwenden.

 

Die Aufgabe

Unsere Aufgabenstellung ist folgende:

Wir möchten einen Weg finden, um eine Liste von Personen gemäß hypothetischen Firmen-Design-Guidelines darzustellen. Leider reicht das UI5 Framework für die angenommene Einschränkung nicht aus.

Daher benötigen wir ein Custom Control. Genauer gesagt, benötigen wir folgende Komponenten:

  • PersonList – Darstellung unserer Liste
  • PersonListItem – Eine einzelne Zeile 
  • style.css – Custom Styling

Optional können noch folgende Files angelegt werden:

  • PersonListRenderer – Zum ausgelagerten Rendern der Liste
  • PersonListItemRenderer – Zum ausgelagterten Rendern eines Items

PersonListItem

Wir arbeiten uns von unten nach oben. D.h. wir fangen mit unserem aggregierten Control an, welches eben das einzelne Listitem wäre.

Ausgeben möchten wir Vorname, Nachname und das Alter der Person. Um noch ein Custom-CSS reinzubekommen, werden wir Personen mit einem Alter geringer als 18 anders formattieren.

Erstellen wir zunächst ein neues UI5 Projekt und legen die Files für die Custom-Controls an.

Anschließend definieren wir ein Template für das PersonListItem:

Wir wissen, dass wir mit sap.ui.define ein neues Modul anlegen, das zur Laufzeit dynamisch von unserem UI5 Framework geladen wird. Und genau so definieren wir eben auch ein Custom Control. Dieses inkludiert das sap.ui.core.Control, welches wir per .extend erweitern und zurückliefern.

Unsere PersonListItem soll 3 verschiedene Personaleigenschaften ausgeben. Daher brauchen wir 3 Properties (Vorname, Nachname, Alter).

Aggregations soll unser PersonListItem nicht haben, denn wir möchten das PersonListItem selbst als zu aggregierendes Control verwenden.

Properties anlegen

Wir benötigen 3 Properties:

  • firstName: string
  • lastName: string
  • age: int

Auf die Properties kann per get<PropertyName>() zugegriffen werden.

 

Events anlegen

Wir möchten, dass bei einem Click auf das PersonListItem ein Event ausgeführt wird. Dieses liefert eine Hallo-Message zurück.

  • sayHello
    • parameter: message(string)

Anschließend definieren wir eine Eventhandler für das HTML-onclick-Event. Falls dieses auftritt, triggern wir das sayHello-Event und liefern eine Message bestehend aus Name und „says hello“ per message-Parameter zurück.

 

CSS Styling

Wir möchten unsere 3 Properties per HTML-ul-Element anzeigen. Da ist jedoch das Problem, dass die Liste standartmäßig untereinander ihre Items anordnet. Um das zu umgehen, sagen wir per CSS-Klasssenselektor, das alle li-Elemente unter der Klasse die CSS-Property display mit dem Wert inline bekommen.

Und zusätzlich definieren wir noch ein padding von 10 Pixel und die Schriftfarbe black;

 

Renderer

Der Renderer ist das Herzstück unseres Controls. Hier wird definiert, was wann und wie in das DOM eingtragen werden soll.

Die wichtigsten Renderer-Funktionen sind dem letzten Blog-Teil zu entnehmen.

Wir möchten unser Control als div-Element und einer ul ausgeben. Zusätzlich möchten wir noch das Alter dementsprechend farblich hervorheben, basierend auf dem Kriterium, dass das Alter > 18 ist.

1: div ausgeben

Zu aller erst erstellen wir per openStart ein öffnendes div-Tag. Dieses div-Tag wird per writeControlData die Control-Referenz geschrieben und anschließend fügen wir noch unsere CSS-Klasse hinzu. Dann wird das öffnende div-Tag mit > geschlossen.

2: Liste aufbauen

Wir erstellen eine neue unordered-list. Als erstes List-Item geben wir den Vornamen der Person aus und dann den Nachnamen.

3: Alter ausgeben

Je nach dem ob die Person ein Alter > 18 hat, erstellen wir ein List-Item mit dem Style colorred oder color: green.

4: Alles schließen

Zu letzt schließen wir die Liste und abschließend das div-Tag.

 

Somit ist unser PersonListItem komplett. Im nächsten Schritt werden wir nun die PersonList definieren und unser PersonListItem aggregieren.

PersonList

 Die PersonList soll einen Titel bekommen und unsere Personen per PersonListItem anzeigen.

Hierfür benötigen wir Properties und Aggregations.

Metadata definieren

Wir benötigen folgende Property für unseren Titel:

  • title (string) – default: Persons

Zusätzlich möchten wir noch PersonListItems aggregieren:

  • items (PersonListItem) – multiple: true

CSS Styling

per list-style: none sagen wir, dass unsere Personenliste keine Aufzählungszeichen haben sollte.

Dann selektieren wir alle Items mit einem ungeraden Index und färben diese grau ein.

Zusätzlich geben wir noch ein seitliches margin von 15 Pixel.

Renderer definieren

In unserem Renderer wollen wir den Titel der Personenliste und aggregiert die PersonListItems ausgeben.

1: div öffnen

Gleich wie beim PersonListItem öffnen wir einen div-Container und vergeben CSS-Klasse und Control-Data.

2: Titel ausgeben

Der Titel wird innerhalb eines h2-Tags ausgebeben.

3: Items-Aggregation rendern

Per getAggregation(„items“) können wir uns den Inhalt der Items-Aggregation in einem Array speichern. Dieses Array laufen wir durch und erstellen für jeden Eintrag ein neues li-Tag mit der myPersonListItemSelector-Klasse. Dieses bekommt ihren Inhalt per renderControl()-Funktion, welche die render-Methode des übergebenen Controls aufruft. In unserem Fall ist das das PersonListItem.

4: alles schließen

 Abschließend fügen wir noch die schließenden ul- und div-Tags hinzu.

Jetzt sind unsere Custom-Controls fertig und können in den Views verwendet werden.

Controls verwenden

Die beiden Custom Controls können nun in unserer View verwendet werden.

1: Namespace einbinden

Um Controls aus einem anderen Namensraum einzubinden, muss für diesen ein Alias angelegt werden. Wir verweisen hier auf unseren Folder, wo wir die Controls angelegt haben.

2: PersonList einfügen

Wir legen eine neue PersonList an. Dort vergeben wir die title-Property und legen eine items-Aggregation an.

3: PersonListItems hinzufügen

In der items-Aggregation legen wir nun mehrere PersonListItems an. Das würde natürlich auch über Aggregation-Binding in der PersonList per Model funktionieren.

Wir legen aber z.B. 3 PersonListItems an und vergeben allen Properties Werte. Zusätzlich definieren wir eine Funktion für unser sayHello-Event.

Dieses müssen wir dann noch im zugehörigen Controller ausprogrammieren.

Also definieren wir eine neue Methode namens onSayHelloHandler, wo wir den Eventparameter message auslesen und per alert anzeigen.

App ausführen

Unsere App ist nun funktionsfähig und zeig unsere Custom-Controls richtig an.

Wir sehen nun unseren Titel und 3 darunterliegende Personen, die farblich abwechselnd hinterlegt sind.

Zusammenfassung

In 2 Blogteilen haben wir nun alles Notwendige gelernt, um mit dem Entwickeln von eigenen Custom-Controls durchzustarte, falls die Anforderungen nicht durch das umfangreiche SAPUI5 Controls-Paket abgedeckt wird.

Eine weitere Vorgehensweise könnte sein, meine eigenen Custom-Controls in eine UI5-Library/Git Repo zu packen und zu deployen. Dann kann ich diese in weiteren Applikationen verwenden und kann mir meine eigene, umfangreiche Library bauen.

Nur sollte man nicht für jede Anforderung ein neues Control entwickeln oder ein bestehendes zu erweitern. Man sollte so gut und so weit wie möglich mit dem arbeiten, was einem das SAPUI5 Framework zur Verfügung stellt und sich so weit wie möglich in die Materie einarbeiten.

Wer also gerne mehr bezüglich UI5 wissen möchte, kann sich gerne unseren zahlreichen Blogs bedienen.

Die interessantesten für das Controls-Thema sind:

Vielen Dank für das Lesen dieser Blogreihe und wenn Fragen auftreten, können sie gerne in den Kommentaren gestellt werden.

Data Binding UI5

In diesem Blog werden wir uns mit den verschiedenen Arten von Bindings in SAP UI5 bzw. Open UI5 beschäftigen.

Die folgenden Informationen werden auch, jedoch um einiges ausführlicher, in unseren offiziell bei der SAP im Schulungskatalog gelisteten Kursen HOUI5 und HOFIO behandelt.

Inhalt

 

In diesem Blog werden wir uns folgenden Themen widmen: 

  • Grundlegendes zu Binding
  • Binding Modi
    • One-Time-Binding
    • One-Way-Binding
    • Two-Way-Binding
  • Binding Arten
    • Property Binding
    • Aggregation Binding
    • Element Binding
  • Binding Syntax
    • Binding Pfad
    • Composite Binding
    • Expression Binding
    • Metadata Binding 

Grundlegendes zu Binding

In SAPUI5 wird Data Binding eingesetzt, um die Daten aus den Models mithilfe von UI-Elementen darzustellen. Das ermöglicht auch das Aktualisieren und Editieren der Daten direkt aus dem UI. Dadurch wird das UI mit dem Model „verknüpft“.

 

Hierfür werden 2 Dinge benötigt:

  • Data Model (JSON, OData)
  • Binding Instanz 

Das Data Model – üblicherweise ein JSON bzw. OData-Model – stellt Daten und Methoden, um die Daten vom Server abzufragen, zur Verfügung. Zusätzlich bietet es eine Methode, um Bindings zu erstellen. Eine Binding Instanz wird erstellt, sobald diese Methode aufgerufen wird. Die Instanz beinhaltet Informationen zum Binding und ein Event, welches getriggert wird, wenn sich die gebundenen Daten ändern.

Binding Modi

Durch das enum „sap.ui.model.BindingMode“ werden 3 verschiedene Binding Modi bereitgestellt.

Diese können entweder allgemein auf ein Model mit der Methode „.setDefaultBindingMode(bindingMode)“ oder über das Property „oBindingInfo.mode“ auf einzelne Binding Instanzen angewendet werden.

 

One-Time-Binding – sap.ui.model.BindingMode.OneTime

Wird der BindingMode auf „OneTime“ gesetzt, werden die Daten nur einmalig vom Model gelesen.

 

One-Way-Binding – sap.ui.model.BindingMode.OneWay

“OneWay”-Binding bedeutet, dass der Wert nur vom Model zur View gelesen wird, jedoch nicht umgekehrt. Das bedeutet, dass Änderungen in der View keine Auswirkungen auf die Daten im Model haben.

 

Two-Way-Binding – sap.ui.model.BindingMode.TwoWay

Möchte man in der View Daten editieren und diese Änderungen auch automatisch in das Model übernehmen, ist der Binding Mode „TwoWay“ genau das Richtige. Anders als beim One-Way-Binding werden hier Daten vom Model zur View und umgekehrt übertragen.

Binding Arten

In UI5 gibt es 3 verschieden Arten von Bindings. Diese werden im Folgenden näher erläutert. Beim Binding muss immer ein Bindingpfad angegeben werden. Dieser wird durch ‚{}‘ gekennzeichnet.

Je nachdem, ob man das Default-Model oder ein Named-Model verwendet, unterscheidet sich dieser Pfad. Bei der Verwendung eines Named-Models muss dem Propertynamen noch ein ‚modelName>‘ vorangestellt werden.

Möchte man die Eigenschaft „FirstName“ auf die value-Eigenschaft eines Inputs binden (Property Binding), sieht das, bei der Verwendung eines Default-Models, so aus:

Verwendet man hingegen ein Named-Model, muss der Eigenschaft der Modelname vorangestellt werden:

Property Binding

Property Binding wird verwendet, wenn beispielsweise Daten in einem Formular gebunden werden. Hierfür muss in der entsprechenden Eigenschaft (z.B.: text, value, …) ein Binding-Pfad angegeben werden. 

Am ‚/‘ vor dem Propertynamen erkennt man, dass es sich um einen absoluten Pfad handelt. Das bedeutet, das sich die Eigenschaft „FirstName“ auf der Root-Ebene des Default-Models befindet.

Aggregation Binding

Sollen Listen auf ein Control gebunden werden, kommt Aggregation Binding zum Einsatz. Aggregation Binding wird meistens in Listen und Tabellen verwendet. Dabei muss auch ein Template angegeben werden, welches für jedes Element in der Liste einmal geklont wird. Innerhalb des Templates verwendet man relative Pfade, da der Pfad des Aggregation Bindings bereits auf die entsprechende Liste verweist. Anstelle eines Templates kann auch eine Factory-Function angegeben werden. Diese definiert, wie die Einträge dargestellt werden sollen.

Default-Model

Named-Model

Element Binding

Element Binding ermöglicht das Binden einzelner Elemente einer Liste auf Controls. Hierbei wird ein Binding-Context erzeugt. Die Binding-Pfade sind relativ.

Dies kommt vor Allem in Master-Detail Apps zum Einsatz.

Element-Binding kann auf folgende Arten umgesetzt werden:

  • bindElement im Controller aufrufen
  • binding-Property des Controls verwenden

Binding Syntax

Mit einem Binding-Pfad werden UI Elemente auf die Daten des Models gebunden. Durch das definieren eines Pfades, wird ein Binding-Context erstellt.

Composite Binding

Oftmals, wenn man einen Formatter verwendet, ist es der Fall, dass mehrere Werte an den Formatter übergeben werden müssen. Dies kann mit Composite-Binding umgesetzt werden. In der jeweiligen Eigenschaft (value, text, …) des UI-Elements kann ein parts-Array von paths definiert werden.

Expression Binding

Mithilfe von Expression-Binding können simple Prüfungen – z.B.: Vergleich von Werten – direkt in der View und das ganze zur Laufzeit gemacht werden. Dadurch erspart man sich die das Implementieren von zusätzlichen Formatter-Funktionen im Controller.

Expression-Binding kann auf 2 Arten umgesetzt werden:

  • ‚{=expression}‘: Hier wird One-Way-Binding verwendet. Sollten sich Werte im Model ändern, wird auch das Binding aktualisiert.
  • ‚{:=expression}‘: Hier wird One-Time-Binding verwendet. Der Wert wird einmal ermittelt und anschließend nicht mehr aktualisiert.

Als expression können beliebige Prüfungen implementiert werden. Dabei ist die Syntax ähnliche jener in Javascript, jedoch werden nicht alle JavaScript Expressions unterstützt. Innerhalb der Expression greift man auf Modeldaten folgendermaßen zu: ‚${binding}‘ oder ‚%{binding}‘

Eine Prüfung und entsprechende Anzeige verschiedener Werte sieht wie folgt aus:

${binding} VS %{binding}

Verwendet man ‚${binding}‘ wird der Wert automatisch in den Typ der Eigenschaft des Controls konvertiert. Im Falle des Visible-Properties eines sap.m.Input wäre dies ‚boolean‘. Nicht immer ist diese Konvertierung erwünscht, daher kann diese mit ‚%{binding}‘ umgangen werden. ‚%{binding}‘ ist eine Kurzform für ‚${path: ´binding´, targetType: ´any´}‘ Der targetType kann auch durch beliebige Typen, die sap.ui.model.odata.type bietet ersetzt werden.

 

Metadata Binding

Möchte man Metadata-Eigenschaften wie sap:label, sap:createable, sap:updatable, … in der View abfragen, erreicht man dies mit Metadata-Binding.

Auch hier gibt es 2 Ansätze.

Absolute Bindings

Absolute Bindings sehen folgendermaßen aus:

            /#EntityName/PropertyName/@Attribut

Relative Bindings

Relative Bindings sehen so aus:

            /EntitySetName/PropertyName/#@Attribut

Best-Practice Beispiel mit OData-Model und Two-Way-Binding

Abschließend noch ein kurzes Best-Practice Beispiel, in dem mithilfe eines OData-Models und Two-Way-Binding ein Update auf die Details eines Employees geschickt wird.

Hier werden folgende Methoden verwendet:

  • hasPendingChanges: Zum Abfragen, ob es Änderungen gibt
  • submitChanges: Mit ‚Save‘ werden die Änderungen ans Backend geschickt
  • resetChanges: Mit ‚Discard‘ werden die Änderungen verworfen

View:

Controller:

Git im SAP-Umfeld – Part 3

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 unseren offiziell bei der SAP im Schulungskatalog gelisteten Kursen HOUI5, HOFIO und WDECPS behandelt.

Inhalt

Auf folgende Themen werden wir in unserer Blogereihe 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 man nach unserer Blogreihe die unten stehende Grafik interpretieren und mit Git die SAPUI5-Entwicklung optimieren kann.

Part 3 – Inhaltsverzeichnis

  1. Repository anlegen (GitHub und SCP)
  2. Git Pane in der WebIDE + die wichtigsten Funktionen
  3. Conflict Handling

Einen letzten Punkt haben wir noch in unserer dreiteiligen Blogreihe, nämlich die Verwendung von Git bei SAPUI5-Entwicklungen.

SAPUI5-Entwicklung

Ein jeder SAPUI5-Entwickler wird wahrscheinlich diesen Hinweis beim Importieren von bereits bestehenden SAPUI5-Apps aus dem ABAP-Repository schon mal gesehen haben:

Auch wenn man sonst noch nie was von Git gehört hat, wird man spätestens an dieser Stelle merken, dass es fast unabdingbar mit Git die Sourcen zu verwalten.

Aber wenn es um Git geht, stellt die SAP nicht nur diesen Hinweis zur Verfügung, sondern auch einen in die WebIDE integrierten Git Pane zur Verfügung.

Repository anlegen

Für unser Beispiel werden wir zwei Git Repositories anlegen, nämlich einmal in GitHub und in der SAP Cloud Platform. Unser Beispielprojekt ist nachher nur mit dem GitHub Repository verknüpft. Im Lizenzmodell für die WebIDE sind auch die Git Repositories in der SAP Cloud Platform inkludiert.

GitHub

In GitHub können wir private Repositories anlegen, aber auch Repositories in Organisationen, in denen ich eingeladen worden bin.

Man hat zurzeit zwei Varianten an Repositories:

Public Repositories

  • für alle zugänglich, die den Link zur Repository haben
  • jeder kann clonen
  • Schreibrechte kann man einschränken (Push-Requests)

Private Repositories

  • nur für Sie oder für die Organisation sichtbar (siehe Owner)
  • Innerhalb Ihrer Org. kann man eigene Teams verwalten, die je nach Rolle Lese- und Schreibrechte haben

Zusätzlich sollte man noch einen README-File anlegen lassen, welche als Startseite für den Repository dient und dem User grundlegende Informationen vom Repo. anzeigen soll.

Es besteht auch die Möglichkeit, bestimmte Files und Filetypen ignorieren und bekannte Lizenzmodelle hinzufügen zu lassen. (.gitignore)

Nach dem Klick auf „Create repository“ wird man auch gleich in den Repository Browser geleitet:

Auf alle einzelnen Möglichkeiten möchte ich hier nicht detailliert eingehen, weil diese Informationen eh schon überall im Internet zu finden sind.

Kurz zusammengefasst:

  • man kann Lese- und Schreibrechte an bestimmte Personen und Teams vergeben
  • Commits und Pull-Requests verfolgen
  • Auswertungen ansehen
  • in den Einstellungen von Security bis Benachrichtigungen alles einstellen

Was für uns in Zukunft jetzt wichtig ist, ist der Repository URL. Bei einem Clone müssen wir diese URL angeben, denn diese ist der Zeiger zu unserem Repository:

https://github.com/clouddnagmbh/blogrepo

SAP Cloud Platform

Im Subaccount in der SCP (SAP Cloud Platform) hat man links im Menü die Möglichkeit Repositorys zu verwalten. Wenn Sie diesen Menüpunkt nicht sehen, dann fehlen Ihnen wahrscheinlich die nötigen Berechtigungen.

Mit dem „New Repository“-Button können wir gleich einen Repository anlegen. Hier ist natürlich wichtig zu wissen, dass die Authentifizierung über die SCP erfolgt.

Nachdem wir einen Namen und Beschreibung vergeben haben, können wir noch bestimmen, dass unser Repository mit einem initialen leeren Commit angelegt werden soll.

Wenn wir die Details zu unserer Repository anschauen, dann können wir ein paar Informationen ablesen und direkt auch einige Funktionen ausführen.

Es besteht die Möglichkeit, wieder den Namen zu editieren, unserem Repository nur Leserechte zu geben, den Garbage Collector zu starten, aber auch unser Repository direkt in die WebIDE clonen zu lassen.

Zwei wichtige Links sieht man auch gleich, nämlich einen mit dem Zeiger auf unseren Repository (wichtig, wenn man clonen möchte) und einen für den Repository Browser (nichts anderes als ein Explorer).

Was für uns in Zukunft jetzt wichtig ist, ist der Repository URL. Bei einem Clone müssen wir diese URL angeben, denn diese ist der Zeiger zu unserem Repository:

https://git.eu2.hana.ondemand.com/<subaccount>/blogrepo

Entwicklung

In unserer WebIDE können wir an mehreren Stellen einen Git Repository clonen. Anbei eine Möglichkeit:

Alle Varianten würden im Endeffekt zu diesem Wizard führen:

Hier müssen wir unsere Repository URL einfügen. Zusätzlich könnte man eine Konfiguration für Gerrit, ein Review-System von Google, hinzufügen.

Nach einer erfolgreichen Authentifizierung und Clone sehen wir die geclonte Applikation in unserem Workspace:

Jedoch bringt uns das in unserem Fall noch nichts, weil unser Repository leer ist. Wir haben ja im zweiten Teil unserer Blogreihe gelernt, dass ein Entwickler der Erste sein muss, der quasi eine Rahmenapplikation deployed.

Also lösche ich vorerst das geclonte Projekt, lege eine neue SAPUI5-App an und mit Rechtsklick auf das Projekt lege ich ein neues lokales Git Repository an:

In einem Popup kann man den Benutzernamen und die Mailadresse hinterlegen, welche bei den Commits als Author eingetragen wird:

Der Hinweis, dass das nicht mehr geändert werden kann, stimmt hier nicht ganz. Über Project -> Project Settings -> Git Repository kann das ganze geändert werden.

Nach dem ich das lokale Git Repository angelegt habe, bekomme ich auch gleich die Information, dass ich einen Remote Repository anbinden soll:

Das machen wir auch gleich und tragen unseren bereits erstellen Remote Repository ein:

Da das Ganze im Grunde genommen nichts anderes ist, als das Zusammenführen von Local und Remote Repository, wird zuerst noch ein Fetch gemacht.

Wir öffnen direkt den integrierten Git Pane:

Wir können hier in einer grafischen Oberfläche verschiedene Funktionen ausführen:

  1. Wie wir im zweiten Teil unserer Blogreihe kennengelernt haben, könnte man hier auf die verschiedensten Funktionen (Fetch, Merge, Pull, …) zugreifen.
  2. Man sieht auf einem Blick um welchen Local Repository es sich handelt und man könnte neue Local Branches erstellen und zwischen diesen wechseln.
  3. Eine Liste der Änderungen seit dem letzten Commit.
  4. Alle Änderungen, die sich im Staging Area befinden, werden auch beim nächsten Commit mitgenommen. Also wenn ich Änderungen habe, die ich noch nicht veröffentlichen will, dann werde ich diese aus der Staging Area rausnehmen und somit beim nächsten Commit nicht mit den anderen teilen.
  5. Jeder Commit erfordert eine Beschreibung, wie zum Beispiel eine kurze Zusammenfassung meiner Änderungen.
  6. Die Möglichkeit für Commit und Push findet man ganz unten.

Symbole in der WebIDE

Initial Commit and Push

Wir haben einen Rahmenprojekt angelegt und sind der erste, der das Projekt auf den Remote Repository pusht:

Nach einem erfolgreichen Push-Request können wir die Sourcen am Repository Browser ansehen:

Nehmen wir jetzt an, dass wir diese Applikation nicht erstellt haben. Dann müssten wir genau an dieser Stelle einen Clone in unsere WebIDE vollziehen:

Bei einem Clone erhält unser Projekt in der WebIDE den Namen vom Remote Repository. Gleich daneben steht auch, auf welchem lokalen Branch wir gerade arbeiten:

Local Branch erstellen

Im Git Pane haben wir die Möglichkeit zu unserem standardmäßig erstellen „master“ Branch weitere Local Branches zu erstellen.

Man wählt die Quelle aus (kann auch ein Remote Branch sein) und benennt den zu erstellenden lokalen Branch (in unserem Fall „featureA“):

Nach dem Erstellen befinden wir uns auch schon direkt in dem Feature Branch. Man kann mithilfe des Drop-Downs auch wieder wechseln.

In unserem Feature Branch machen wir ein paar Änderungen, legen neue Views an und fügen ein Label in die View ein. Wir beschreiben die Änderungen dementsprechend und committen sie:

Wir sind mit unseren Feature Implementierungen fertig und möchten diese mit anderen Entwicklern teilen. Wir haben in unserem Git Pane einen Indikator, dass wir seit dem letzten Merge einen Commit gemacht haben:

Wir wechseln nun in den lokalen „master“ Branch und machen einen Merge mit unserem Feature Branch. Wir verbinden die zwei Datenstände miteinander und prüfen auf eventuelle Konflikte:

Nachdem der Merge (in unserem Fall) ohne Konflikte durchgelaufen ist, checken wir die Sourcen im „master“ Branch und sehen, dass die Änderungen aus unserem Feature Branch in unserem lokalen „master“ Branch gelandet sind:

Wir hätten unseren Feature Branch natürlich auch gleich mit dem Remote Branch zusammenführen können, aber so konnten wir schonmal sichergehen, dass es mit dem letzten „origin/master“ Branch, welche ja unserem lokalen „master“ Branch entsprochen hat, keine Konflikte gibt.

Das bringt den anderen Entwicklern jetzt noch nichts. Wir müssen diese Änderungen auch auf den Remote Repository pushen. Aber wie wir schon im zweiten Teil unserer Blogreihe gelernt haben, müssen wir vorher checken, ob die anderen auch schon Änderungen gemacht und am Remote Repository gepusht haben.

Ich bevorzuge an dieser Stelle einen Fetch. In der Zusammenfassung schaue ich mir auch an, ob und was andere Entwickler gemacht haben:

Wir sehen, dass sich am Remote Repository seit unserem letzten Fetch nichts getan hat, somit können wir beruhigt pushen:

Wenn wir jetzt in den Browser Repository wechseln, dann werden wir auch sehen, dass dort unsere Änderungen bzw. unsere Feature Entwicklung sichtbar ist:

Was man hier noch gut sieht ist, dass nur die Deltas ausgetauscht worden sind. Die nicht geänderten Files haben noch immer den letzten Status und auch die letzte Commit Beschreibung, weil wir selbst die anderen Files, auch wenn wir am Projekt was geändert haben, nicht manipuliert haben.

Conflict Handling

In unserem Fall war das jetzt ganz einfach, da kein anderer Entwickler uns in die Quere kommen konnte. Aber wie ein Konflikt aussehen würde, haben wir hier für Sie simuliert.

Ich habe mich umentschieden und in meiner WebIDE im Label doch einen anderen Text eingetragen:

Diese Änderung werde ich jetzt wie gewohnt in die Staging Area bringen und mit einer entsprechenden Beschreibung einen Commit durchführen:

Wir machen einen Fetch um zu sehen, ob andere Entwickler auch was gemacht haben:

Da sehen wir jetzt, dass ein anderer Entwickler auch etwas geändert hat. Vorerst kein Problem, das ist ja eine ganz normale Situation, da unser Entwicklungsteam groß ist.

Was für uns aber neu ist, ist dieser Indikator:

Das bedeutet wir haben einen Commit seit dem letzten Merge gemacht und auch am dazugehörigen Remote Repo. hat es einen Commit seither gegeben.

Wir machen jetzt einen Merge, um die zwei Datenstände miteinander zu vereinen und da bemerken wir, dass es Konflikte gibt:

Wir klicken auf „Resolve Conflicts“ und landen in einem grafischen Editor für das Beheben der Konflikte:

Hier sieht man die zwei Versionen einander gegenübergestellt und auch die Version, die nach unserer Konfliktbehebung entstehen würde.

Mit den Buttons rechts oben könnten wir auf die Schnelle sagen, ob wir unsere Änderungen oder die Änderungen vom Remote Repo. nehmen möchten. Hinter diesem grafischen Editor steht eigentlich nichts anderes als ein Code mit bestimmten Abschnitten und Markierungen, wo Konflikte aufgetreten sind:

Also könnte man im grafischen Editor die Konflikte lösen, aber auch im Code. Man würde hier genau diesen Abschnitt rausschmeißen, welchen man als veraltet empfindet.

Wenn wir alle Konflikte behoben haben, dann bleibt uns nichts anderes mehr übrig, als einen Commit zu machen, je nachdem wie viel Zeit wir für die Konflikten aufgewendet haben, wieder einen Fetch mit Merge zu machen und anschließend unseren Code zu pushen.

Bei einem Conflict Handling haben wir während dem Beheben auch nicht alle Funktionen zur Verfügung:

Wir können lediglich einen Fetch machen und uns den aktuellen Stand holen oder die bereits gemachten Änderungen zurücksetzen.

Nach einem Commit von unserer Fehlerbehebung sehen wir am Indikator, dass wir nun nicht einen Commit vor und auch gleichzeitig nach dem origin/master sind, sondern zwei Commits voraus. Einmal haben wir ja unser Label geändert und einmal einen Merge mit Konfliktbehebung (= erneuter Commit) gemacht.

Zusammenfassung

Jetzt steht uns nichts mehr im Wege! Wir haben gelernt, wie wir unsere Entwicklungen mit Git optimieren können und in diesem Bereich vor allem das Zusammenarbeiten mit anderen Entwicklern. Der nächste und letzter Teil unserer Blogreihe, nämlich ein Exkurs von Martin Koch verfasst und präsentiert, wird nächste Woche veröffentlicht.

SAPUI5 Custom Controls – Teil 2

SAPUI5 Custom Controls – Teil 1

Das Konzept

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

Leider weicht man jedoch dann 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.

 

Der Aufbau

Grundsätzlich ist ein UI5 Control nichts anderes als ein Modul, das zur Laufzeit dynamisch nachgeladen wird. Ein solches Modul wird mit sap.ui.define erstellt und kann anschließend angesprochen werden.

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. Diese Methode wandelt das Custom Control in die HTML-Elemente um, wie es der Entwickler gerne haben möchte. So 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.

Der Aufbau von Eigenschaften eines Controls wird immer in seinen Metadaten definiert. Ein Control hat ein dementsprechendes metadata-Object, wo Properties, Events, Aggregations und Associations definiert werden. 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

Control-Properties bekommen ein Object zugewiesen, in dem ich den Datentyp zuweise und gegebenenfalls einen Default-Wert hinterlege.

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[]

Ich kann auch eigene Konfigurationsproperties innerhalb meiner Property erstellen und diese dann zur Datenverarbeitung nutzen.

Aggregations

Aggregations werden mit 3 verschiedenen Konfigurationen erstellt:

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

Type gibt an, welches Control ich gerne aggrigieren möchte. 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, bzw. 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 automasich 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

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.

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.

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

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

Git im SAP-Umfeld – Part 2

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 unseren – offiziell bei der SAP im Schulungskatalog gelisteten – Kursen HOUI5, HOFIO und WDECPS behandelt.

Inhalt

Auf folgende Themen werden wir in unserer Blogereihe 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 man nach unserer Blogreihe die unten stehende Grafik interpretieren und mit Git die SAPUI5-Entwicklung optimieren kann.

Part 2 – Inhaltsverzeichnis

Begrifflichkeiten:

  1. Repository
  2. Branch
  3. Commit
  4. Staging Area

Funktionen:

  1. Push
  2. Clone
  3. Fetch
  4. Merge
  5. Pull
  6. Best practice
  7. Rebase
  8. Reset (Hard Reset & Mixed Reset)

Begrifflichkeiten

Anbei erklären wir die 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.

Funktionen

Anbei gehen wir 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:

Best practice

Einmalig:

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

Wiederkehrend:

  1. Fetch: schauen ob sich was getan hat
  2. Merge: den Zeiger auf die aktuelle Version verschieben und die Datenstände zusammenführen (auf eventuelle Konflikte reagieren)
  3. Push: die aktuelle Version mit anderen Entwicklern teilen
  1. Pull: schauen ob sich was getan hat, den Zeiger auf die aktuelle Version verschieben und die Datenstände zusammenführen (auf eventuelle Konflikte reagieren)
  2. 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.

 

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:

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 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 anschauen, wie man Git effizient bei der Entwicklung mit der SAP WebIDE einsetzt.

Git im SAP-Umfeld – Part 1

Git im SAP-Umfeld – Part 1

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 unseren offiziell bei der SAP im Schulungskatalog gelisteten Kursen HOUI5, HOFIO und WDECPS behandelt.

Inhalt

Auf folgende Themen werden wir in unserer Blogreihe eingehen:

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

Zielsetzung

Unser Ziel ist es, dass man nach unserer Blogreihe die unten stehende Grafik interpretieren und mit Git die SAPUI5-Entwicklung optimieren kann.

Einführung in die Git-Welt

Zuerst einmal müssen wir uns die grundlegenden Informationen einholen und uns mit einigen W-Fragen beschäftigen.

Was?

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?

Mittlerweile gibt es verschiedene Plattformen und damit auch Anbieter für Git-Software. Zu den bekanntesten zählen GitHub (Microsoft) oder 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?

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 uns all diese Probleme ab und hilft uns mit einfachen Funktionen unsere Änderungen mit anderen zu teilen, es verwaltet diese Sourcen und erkennt auch gleichzeitig Konflikte, damit man keine Änderungen von anderen Entwicklern überschreibt.

Kombinationsmöglichkeiten

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

In diesem ersten Teil unserer Blogreihe haben wir uns die wichtigsten Informationen angesehen. Wir wissen bereits, was Git ist und warum man Git verwenden sollte. Durch einen kurzen Einblick in die Kombinationsmöglichkeiten wissen wir auch, wie umfangreich das Thema rund um Git werden kann.

Im zweiten Teil werden wir uns die wichtigsten Begrifflichkeiten und Funktionen im Git-Umfeld ansehen und unserem Ziel, die oben stehende Grafik interpretieren zu können und im Anschluss Git auch im SAP-Umfeld verwenden zu können, ein Stück näher kommen.