Fiori für ABAP - Änderung archivierter Apps
Ist die Arbeit an einer Fiori App abgeschlossen, wir diese in einem Git Repository abgelegt, um sie später immer noch zugreifbar zu machen. Schauen wir uns einmal den Flow an, um das Projekt erneut zu laden und anzupassen.
Inhaltsverzeichnis
In diesem Artikel schauen wir uns an, wie wir eine gespeicherte App aus dem GitHub Repository erneut laden, diese anpassen und dann wieder ablegen können.
Einleitung
Bisher hatten wir alle Anpassungen unserer Sales App in einem lokalen Repository gemacht, welches bereits im Business Application Studio vorhanden war. Normalerweise ist es aber so, dass wir, wenn wir ein Projekt abgeschlossen haben, das Repository über Git sichern und anschließend aus dem Workspace löschen. Dies hat den Vorteil, wenn später einmal ein Kollege eine Anpassung vornimmt, arbeiten wir nicht automatisch auf einer veralteten Version weiter oder bauen Änderungen wieder zurück.
Daher starten wir hier im ersten Schritt mit einem leeren Projektverzeichnis, in den wir gleich unsere Anwendung laden, Anpassungen vornehmen, ein Deployment erzeugen und das Ganze wieder über Git sichern, um einmal den Lebenszyklus zu simulieren.
Clone
Im ersten Schritt haben wir das Projekt aus einem Git-Repository in unseren lokale Editor geklont. Dafür benötigen wir die entsprechende URL des Repository. Diese findest du im Verzeichnis über den Code-Button und kannst dort die URL kopieren. Arbeitest du mit einem Remote Git, welches über den Cloud Connector verfügbar ist, solltest du die URL noch anpassen, damit die richtige Destination zum Cloud Connector gefunden wird.
Mit CTRL + SHIFT + P suchen wir dann nach dem Kommando zum Klonen unseres Repositories und fügen die URL ein, um den Klonvorgang zu starten.
Ist der Klonvorgang abgeschlossen, solltest du ein neues Verzeichnis unter deinen Projekten finden und dort die Dateien aus dem Repository sehen, ebenso alle Änderungen, die wir bereits in der Vergangenheit durchgeführt haben. Damit kannst du im ersten Schritt sicherstellen, dass das Klonen funktioniert hat und alle nötigen Dateien für ein späteres Deployment vorhanden sind.
Wenn du klonst, wirst du meist auch gefragt, was du mit dem geklonten Repository machen willst. Du kannst es als separaten Workspace öffnen, das bedeutet, auf der linken Seite wird der Ordner als Root-Ordner definiert, oder du integrierst es in den bestehenden Workspace. Da wir bereits Projekte geladen haben, können wir auch einfach nur "Cancel" drücken und bleiben so in der gleichen Ansicht.
Prozess
Der Prozess beschreibt die Änderungen, die du vornimmst, aber auch Dinge und Tools, die dir als Möglichkeiten zur Verfügung stehen, um mit dem gesicherten Stand zu arbeiten.
Unterschied
Vielleicht sind dir bereits erste Unterschiede aufgefallen, wenn du lokal arbeitest. Zum Beispiel fehlt der "node_modules"-Ordner. Dieser wurde nicht mit Git gesichert, sondern befindet sich in der ".gitignore"-Datei. Das liegt vor allem daran, dass die verschiedenen Module aus npm automatisch installiert werden, sobald der Build-Prozess in deinem Projekt läuft, sodass du immer die aktuellen Ressourcen und Patch-Stände ziehst und zur Verfügung hast. Diese Module müssen nicht manuell gesichert werden, da sie über die npm Registry ohnehin verfügbar sind und nur zum Bauen der Anwendung benötigt werden, dann meist auch in einer aktuellen Version.
Änderung
Du kannst wie gewohnt alle Änderungen vornehmen. Hier passen wir zum Beispiel die "manifest.json"-Datei an und passen zwei Tags an. In der "i18n"-Datei passen wir jeweils eine Übersetzung an, um Änderungen an unserer Anwendung zu haben. Alle weiteren Änderungen kannst du ganz normal vornehmen, wie du es aus dem SAP Business Application Studio gewohnt bist, wenn du neue Anwendungen anlegst.
Wie du oben siehst, sind die Änderungen innerhalb des Editors auch hervorgehoben. Im Workspace siehst du dafür auch geänderte Files oder neu hinzugefügte Dateien, die vom letzten Commit abweichen.
Zurücknehmen
Gehst du in das Tool für die Source Control, findest du alle geänderten Dateien wieder, die du seit dem letzten Commit innerhalb des Repositories angepasst hast. So behältst du immer den jeweiligen Überblick, welche Dateien geändert wurden und wie die Änderungen aussehen.
Klickst du dann auf eine der geänderten Dateien, landest du in einem View, in dem du die Änderungen miteinander vergleichen kannst. Hier sehen wir zum Beispiel, welche beiden Texte wir in welcher Zeile geändert haben, und haben so noch die Möglichkeit, ein Review durchzuführen oder Änderungen zurückzunehmen, die wir vielleicht nur testhalber gemacht haben.
Möchtest du eine komplette Datei dann auf den Ausgangszustand zurückbringen, weil du zum Beispiel sehr viele Änderungen zum Test vorgenommen hast? Dann findest du dafür einen Button, wenn du mit der Maus über die jeweilige Datei hoverst. Damit kannst du den Stand komplett zurücksetzen, ohne die Änderungen manuell in der Source Control oder der Datei rückgängig machen zu müssen.
Deployment
Öffnest du die Application Info, wirst du eine Fehlermeldung erhalten, dass die "node_modules" noch nicht installiert wurden. Hierfür wird dir ein Befehl für das Terminal angeboten. Dies ist aber nur notwendig, wenn du die Anwendung direkt über die Preview starten möchtest. In diesem Fall müssen wir eigentlich nur ein Deployment durchführen, da unsere Änderungen sehr minimal sind und wir die Anwendung nicht über das Business Application Studio starten wollen.
Wurde die "ui5-deploy.yaml"-Datei noch im Projekt synchronisiert, kannst du direkt ein Deployment starten. Du solltest dafür natürlich aber auch den Transportauftrag anpassen, da sich dieser wahrscheinlich geändert hat. Wurde die Deployment-Konfiguration wie in unserem Fall nicht mitgesichert, musst du eine neue Deployment-Konfiguration anlegen. Führst du das Deployment dennoch aus, startet automatisch der Wizard, in dem du die Informationen wie Repository, Paket und Transportauftrag angeben solltest. Hier solltest du dieselben Informationen verwenden, mit denen das Artefakt bereits im System deployed wurde. Dazu schaust du am besten im System in das entsprechende Paket, um die Informationen zu finden. Am Ende sollte der Deploy der angepassten Version erfolgreich durchlaufen.
Sicherung
Hast du deine Änderungen vorgenommen und war das Deployment soweit erfolgreich, dann solltest du natürlich daran denken, auch die Ressourcen wieder zu sichern. Dazu kannst du in das Tool für die Source Control gehen, dort über den Commit-Button eine Nachricht eingeben, den Commit durchführen, um das lokale Repository zu bestätigen, und danach den Sync durchführen, um die Änderungen in das Remote Repository zu bringen. Damit ist der Sicherungsprozess wieder abgeschlossen und du kannst das Projekt aus deinem Workspace löschen.
Vollständiges Beispiel
Die gespeicherten Ressourcen zu unserer Anwendung findest du in unserem GitHub Repository. Damit kannst du in Zukunft alle Anpassungen an der Fiori App mit nachvollziehen oder die Ressourcen für ein Deployment nutzen. DIe Änderungen findest du in diesem Commit.
Fazit
Die Arbeit mit den Tools und Git ist hier besonders wichtig, vor allem wenn du Anwendungen einmal geklont hast oder an Repositories arbeitest, die ein Kollege erstellt hat. Das Laden, Ändern, Deployen und wieder Sichern ist ein wichtiger Bestandteil der Arbeit und ein Grundbestandteil wenn du mit Fiori arbeitest. Hier kannst du nicht direkt an den gleichen Ressourcen arbeiten, wie du es vielleicht in ABAP tust.
