Software ist etwas Lebendiges – mit dem Go Live ist der Lebenszyklus keineswegs abgeschlossen, sondern es beginnt dann ein ebenso wichtiger Teil: der Unterhalt. In unserem schnelllebigen Technologiezeitalter sind Applikationen auch selten als eigenständige, isolierte Einheit zu betrachten, sondern fügen sich oftmals in ein komplexes Netz von Abhängigkeiten zu anderen Systemen ein, welche wiederum selbst in einem solchen Netz bestehen. Deshalb können Anpassungen an einem Ende Auswirkungen auf unsere Applikation zur Folge haben.
In diesem Blogpost möchte ich aufzeigen, wie wir für einen unserer Kunden eine etwas in die Jahre gekommene Applikation so erweitert haben, dass sie an Veränderungen in Umsystemen angepasst wurde und gleichzeitig die zukünftige Wart- und Erweiterbarkeit sichergestellt werden konnte.
Kontext
Die betroffene Applikation dient den Nutzenden zum Bezug grosser Datenmengen durch ein karten- und tabellenbasiertes Angular-Frontend. Die Nutzer können dabei komplexe Filter erstellen, mit denen die zu beziehenden Daten eingeschränkt werden. Die möglichen Filterkonfigurationen werden dynamisch in Abhängigkeit des Datenmodells der verfügbaren Daten generiert.
Als Schnittstelle kommt ArcGIS Enterprise und dessen REST API zum Einsatz, welche die Daten aus der Postgres-Datenbank zur Verfügung stellt. Obschon zur Darstellung der Daten räumliche Komponenten verwendet werden, sind die eigentlichen Daten nicht georeferenziert, sodass ArcGIS Enterprise für die Daten als «klassische» REST API funktioniert. Die Rechtesteuerung wird über Azure AD Konten gelöst, die über ArcGIS Enterprise integriert werden. Nachstehende Grafik zeigt die grobe Architektur sowie die verschiedenen Datenströme auf.
Die Applikation wird zwar nur von einer Handvoll Powerusern verwendet. Dennoch kann es zu Nutzungsspitzen kommen.
Das Problem und Anforderungen
Für den Kunden bedeutet der Betrieb der Applikation grosse finanzielle Kosten, da die Datenmenge gross und die benötigte Postgres-Instanz entsprechend teuer ist. Mit dem Einsatz von Snowflake setzt der Kunde andernorts im Unternehmen bereits auf eine neue cloudbasierte Datenbanktechnologie. Diese ist für den vorliegenden Use Case perfekt geeignet: Es fallen nur dann Kosten an, wenn die Datenbank auch wirklich im Einsatz steht. Damit können die Nutzungsspitzen abgefangen und für die restliche Zeit Kosten gespart werden.
Allerdings hatten erste Tests gezeigt, dass ArcGIS Enterprise und Snowflake noch nicht harmonieren, weshalb der Datenbezug durch eine eigens entwickelte REST API mit Spring Boot neu entwickelt werden soll. Die Authentisierung und Autorisierung soll ferner weg von ArcGIS Enterprise hin zu der bereits firmenweit eingesetzten Azure Active Directory mit OAuth2.0 migriert werden.
Die räumlichen Informationen sollen jedoch weiterhin über ArcGIS Enterprise geliefert werden. Das Frontend soll zudem möglichst nicht tangiert werden und denselben Look-and-Feel behalten, damit sich für die User nichts ändert.
Das Problem und Anforderungen
Die Anforderungen stellten uns vor verschiedene Herausforderungen: Zum einen ist die Codebasis im Frontend gross und schon etwas in die Jahre gekommen, sodass viel implizites und verteiltes Wissen, aber keine zentralisierte Dokumentation existiert. Gleichzeitig ist das Frontend durch den intensiven Einsatz der ArcGIS Maps SDK for Javascript sowohl für die Datenbezüge als auch für die gesamte Authentisierung und Autorisierung stark an ArcGIS Enterprise gekoppelt. Die Filterfunktionalität, das Herzstück der Applikation, ist zudem wenig dokumentiert und gleichzeitig komplex.
Und zu guter Letzt – die Deadline ist sportlich!
Möglichkeiten zur Modernisierung
Für das Frontend kamen entweder ein kompletter Rewrite oder aber punktuelle Anpassungen an die neuen Gegebenheiten in Frage. Aus Zeit- und Kostengründen haben wir uns für letzteres entschieden, dies aber so zu kapseln, dass eine allfällige Neuentwicklung in Zukunft davon bereits profitieren kann. Mit vertieftem User Research könnte eine solche Neuentwicklung auch für die Endnutzerinnen und Endnutzer gewinnbringend sein, da aufgrund des historisch gewachsenen Funktionsumfang nicht mehr alles benötigt wird.
Für das eigentliche Schnittstellendesign der REST API gäbe es die Möglichkeit, die ArcGIS Enterprise REST API nachzubauen, sodass das Frontend keine Anpassungen bräuchte. Im Hinblick auf eine mögliche Weiterentwicklung wurde aber entschieden, die REST API möglichst generisch neu aufzusetzen, sodass auch hier eine Entkoppelung vom Enterprise Portal erreicht wird. Dies bedeutet zwar etwas mehr Anpassungen im Frontend, ist aber gleichzeitig in der Schnittstelle einfacher umzusetzen, da es kein zusätzliches Mapping auf das Format von Esri benötigt. Dies hat ausserdem den Vorteil, dass allfällige Anpassungen im Format von Esri keine Auswirkungen auf unsere Applikation haben – ansonsten müsste die Schnittstelle jeweils angepasst werden, sodass die Zugriffe im Frontend noch funktionieren.
Vorgehen
Zu Beginn musste die Applikation einem Reverse Engineering unterzogen werden. Dadurch konnten sowohl das Verständnis für die Datenflüsse verbessert als auch ein Überblick über viele versteckte Funktionalitäten und damit weitere Anforderungen an das Backend und die Filterfunktionalität geschaffen werden.
Mit dem so erlangten Wissen wurde eine API-Spezifikation mittels Open API entwickelt und intensiv mit den Architekten auf Kundenseite diskutiert und verbessert. Mit dieser Vorlage wurde eine erste, prototypische Version der REST API entwickelt, die bereits Daten aus Snowflake bezog. Das Herzstück hierbei war der nachgebaute Parser der von der Nutzerin oder dem Nutzer definierten Filterkonfiguration, welcher die eigentliche SQL-Query an Snowflake generiert – analog dem Verhalten der ArcGIS Enterprise Schnittstelle. Damit die Benutzerinnen und Benutzer die Filterkonfigurationen den sich verändernden Daten entsprechend konfigurieren können, wurde nebst der Java Persistence API (JPA) auch auf Hibernate-Modelle und generische Repositories gesetzt – damit können neue Daten in Zukunft effizient und mit wenig Aufwand umgesetzt werden. Parallel zu diesen Arbeiten haben wir die Oauth-Konfiguration für das Backend so vorgenommen, dass künftig auch weitere Applikationen wie etwa ein mobiler Client umsetzbar wären.
Im Frontend wurde ein neues Angular-Modul erstellt, welches alle neuen Codebestandteile beinhaltet – nebst der Integration von Azure Active Directory haben wir hier auch die Integration der neuen Spring Boot API mit entsprechenden Services realisiert. Dieses Modul hat keine Abhängigkeiten an den bestehenden Code, sondern der bestehende Code wurde punktuell so angepasst, dass er die neuen Codebestandteile integriert und z.B. die Datenbezüge neu über den neuen Service macht.
Die noch verbleibenden Geodaten können über eine API direkt via ArcGIS Enterprise bezogen werden, da diese Daten nicht spezifisch geschützt sind. In der nachfolgenden Grafik ist der neue Aufbau der Applikation sowie die Datenströme visualisiert.
Abschluss
Wir konnten die Umsetzung zielgerichtet und innerhalb der gesetzten Frist vornehmen. Nebst den finanziellen Einsparungen durch den Einsatz der neuen Datenbanktechnologie hat der Kunde nun eine Lösung im Backend, die effizient und unabhängig von Drittherstellern funktioniert. Gleichzeitig ist das Backend offen für Erweiterungen im Frontend oder für die Umsetzung zukünftiger Anforderungen wie Reporting Services oder Batchdownloads. Durch die Kapselung im Frontend als eigenes Angular-Modul kann bei einer allfälligen Neuentwicklung des Frontends ein grosser Teil der Logik übernommen und integriert werden. Durch den beschrittenen Lösungsweg mit wenigen, klar definierten Anpassungen im Frontend sowie einer von Drittsystemschnittstellen unabhängigen REST API ist der Kunde für die Zukunft also bestens gerüstet.
Haben auch Sie eine Applikation, die modernisiert werden soll? Gerne können wir uns dazu austauschen.
Entdecke mehr von digital.ebp.ch
Subscribe to get the latest posts sent to your email.