Kunden der d.velop cloud werden Funktionen in Form von so genannten Apps bereitgestellt. Diese stellen ein oder mehrere zusammengehörige Funktionen für die Digitalisierung von Unternehmensprozessen bereit. So könnte eine App beispielsweise lediglich eine einzelne Funktion zum Signieren von Dokumenten bereitstellen oder aber mehrere zusammengehörige Funktionen anbieten, die zusammen genommen ein vollständiges Bewerbermanagement darstellen.

Im Folgenden ist beschrieben, welche Anforderungen eine d.velop cloud App erfüllen muss.

Die Inhalte stehen auch als Video zur Verfügung.

 Motivation und Prinzipien

Technologien, Frameworks und Tools ändern sich. Dies trifft insbesondere auf die Webentwicklung zu, bei der sich die Framework- und Toollandschaft gefühlt jedes Jahr ändert. Ein Framework, welches vielleicht heute noch als das Mittel der Wahl gilt, fristet mit hoher Wahrscheinlichkeit in einigen Jahren ein Nischendasein und wird dann eher als Belastung empfunden. Selbst wenn man diese Veränderungsprozesse mal außen vor lässt, wäre es wohl nicht möglich, sich zu einem bestimmten Zeitpunkt mit einer Vielzahl von Entwicklungsteams auf eine einheitliche Programmiersprache und einheitliche Frameworks zu einigen, ohne dass ein Großteil der beteiligten Personen diese Einigung als hinderlich empfinden würde.

Wie würdest du dich fühlen, wenn wir dir vorschreiben würden, dass du zwingend Java 5 und JSF verwenden musst, wenn du d.velop cloud apps entwickeln willst. Oder was würdest du sagen, wenn wir noch einen Schritt weitergehen würden und eine d.velop cloud spezifische Programmiersprache bzw. ein entsprechendes Framework vorschreiben würden, das du erst einmal erlernen musst und welches abseits der d.velop cloud völlig nutzlos ist?

Wir sind fest davon überzeugt, dass du als App Entwickler am besten entscheiden kannst, welche Programmiersprache, welches Framework und welche Tools du verwenden willst und auch in der Lage sein solltest, deine Entscheidung wieder zu revidieren, sobald sich eine bessere Alternative ergibt.

Aus diesem Grund beschränken wir uns bei den Vorgaben für d.velop cloud apps auf das absolute Minimum, mit dem Ziel, möglichst viele Freiheitsgrade zu gewähren, aber dennoch ein System zu erhalten, welches vom Endbenutzer als eine einzige Applikation wahrgenommen wird.

Bei den Vorgaben setzen wir auf etablierte, Programmiersprachen- und Framework-neutrale Standards, um eine hohe Stabilität und breite Anwendbarkeit zu erreichen.

Zusammengefasst agieren wir nach den folgenden Prinzipien:

  1. Möglichst wenige Vorgaben und hohe Freiheitsgrade für dich als App Entwickler
  2. Programmiersprachen- und Frameworkneutralität
  3. Nutzung von offenen und etablierten Standards
  4. Möglichst wenige d.velop cloud spezifischen Besonderheiten

 Vorgaben

Trotz der angestrebten Freiheitsgrade für dich als App Entwickler, gibt es einige Vorgaben, an die du dich halten musst, damit wir dem Endbenutzer letztendlich ein sicheres und verlässliches System bereitstellen können, welches für ihn so wirkt, als ob er mit einer einzigen großen Applikation und nicht mit einer Vielzahl unterschiedlicher Einzelapplikationen arbeitet.

 Zwingend zu erfüllende Vorgaben

Eigentlich gibt es mit HTML und HTTPS nur 2 unverhandelbare technische Vorgaben für eine d.velop cloud app. Die Registrierung der App im d.velop Cloudcenter ist hier eher organisatorischer Natur.

 HTML

Für die Benutzeroberflächen von d.velop cloud Apps muss HTML verwendet werden. Ganz im Sinne unserer Prinzipien, ist es uns dabei aber völlig egal, welche Programmiersprache oder welches Framework du dafür verwendest oder ob du clientseitig oder serverseitig gerendertes HTML nutzt.

Da HTML jetzt nicht gerade ein Exot ist, ist die Chance hoch, dass du die notwendigen Fähigkeiten bereits beherrscht. Wenn dem nicht so sein sollte, dann gibt es eine Fülle von kostenlosen und kostenpflichtigen Schulungsangeboten im Netz. Das Erlernen von HTML ist sicherlich keine vergeudete Zeit.

Du hast bereits eine bestehende HTML Anwendung? Prima! Dann hast du bereits einen Großteil der Voraussetzungen erfüllt und kannst deine Anwendung mit wenigen Handgriffen als d.velop cloud App bereitstellen. Lese dir hierzu bitte die weiteren Anforderungen durch.

 Mandantenfähiger HTTPS Endpunkt

Jede App muss über einen mandantenfähigen HTTPS Endpunkt erreichbar sein, der ausfallsicher ist und entsprechend skaliert, um auch in Stoßzeiten sämtliche Requests aller Mandanten beantworten zu können.

Die folgende Grafik zeigt die entsprechende Systemarchitektur.

Systemarchitektur

Innerhalb der d.velop cloud bekommt jeder Mandant eine eigene Subdomain unterhalb von d-velop.cloud. Ein Mandant ist dabei üblicherweise eine Firma mit mehreren Mitarbeitern deren Daten um jeden Preis von den Daten der anderen Mandanten getrennt werden müssen.

Sämtliche DNS Einträge verweisen auf den so genannten Approuter. Dieser ist ein Teil der d.velop cloud Plattform und fungiert als eine Art Reverse Proxy für sämtliche Apps.

Anhand des 1. Pfadsegmentes entscheidet der Approuter, an welchen Endpunkt der jeweilige Request weitergeleitet werden muss. So werden Requests, deren Pfad mit /dms/ beginnt, an den mandantenfähigen Endpunkt der DMS-App weitergeleitet. Wohingegen Requests, deren Pfad mit /home/ beginnt, an die Home-App weitergeleitet werden.

Mit welchen Mitteln du einen mandantenfähigen Endpunkt erstellst, der nicht nur ausfallsicher ist, sondern auch lastabhängig skaliert, bleibt dir überlassen. Wo dieser Endpunkt läuft und welche Domain du nutzt, spielt für uns ebenfalls keine Rolle, solange das zugrundeliegende Rechenzentrum ISO/IEC 27001 zertifiziert ist.

Hinweis

Wir selbst nutzen übrigens sowohl VM-basierte, Container-basierte und Serverless Endpunkte für unsere Apps.

 Mandantenheader

Da sämtliche Requests aller Mandanten an einen einzigen Endpunkt weitergeleitet werden, muss dieser Endpunkt entscheiden können, auf welchen Mandanten sich der jeweilige Request bezieht.

Zu diesem Zweck fügt der Approuter HTTP Header, mit entsprechenden Informationen über den Mandanten, zum Request hinzu. Diese Informationen müssen dann vom Endpunkt ausgewertet werden, um zu entscheiden, in welchen Datentopf die App schauen muss, um Daten zum Mandanten zu bekommen und über welche Basis URI die anderen Apps des Mandanten angesprochen werden können.

Mandantenheader

  1. Der Nutzer ruft die xyz-App des Mandanten acme im Browser auf.
  2. Die DNS Abfrage für die Subdomain des Mandanten löst auf den Approuter auf.
  3. Der Approuter fügt die passenden Mandantenheader zum Request hinzu und leitet diesen an den, im d.velop Cloudcenter hinterlegten, Endpunkt für die xyz-App weiter.
  4. Die xyz-App prüft die Signatur der Mandantenheader um sicherzugehen, dass die Informationen über den Mandanten auch wirklich vom Approuter kommen und kann dann anhand der tenant-id 345az3 im entsprechenden Datentopf für den Mandanten nachschauen, um den Request zu beantworten.
 x-dv-tenant-id

Die tenant-id ist eine eindeutige und lebenslang gültige Id für einen Mandanten, die nicht neu vergeben wird. Diese eignet sich also dazu, einen Mandanten dauerhaft zu identifizieren und die Daten des Mandanten von Daten der anderen Mandanten zu trennen. Wie diese Trennung implementiert wird, hängt wiederum vom genutzten Datenbankmanagementsystem ab. Bei relationalen Datenbanken liegt die Nutzung separater Schemata nahe, während die tenant-id bei Key Value Stores ein Teil des Keys (z.B. als Prefix) sein könnte.

 x-dv-baseuri

Nicht nur die Kommunikation vom Client (Browser) zu den Apps, sondern auch die Kommunikation zwischen den Apps, läuft über den Approuter. Daher muss eine App, die Requests gegen eine andere App absetzen will, neben dem Namen der anzusprechenden App, auch die baseuri des Mandanten kennen. Diese wird im x-dv-baseuri Header übertragen.

Hinweis

Da die Apps auch untereinander über den Approuter kommunizieren, müssen die Mandantenheader nicht von den Apps gesetzt werden, wenn andere Apps angesprochen werden sollen. Das erledigt der Approuter automatisch.

 x-dv-sig-1

Um sicherzustellen, dass die Mandanteninformationen auch wirklich vom Approuter kommen, ist es zwingend erforderlich, dass jede App die HMAC-SHA256 Signatur prüft, die im x-dv-sig-1 Header übertragen wird. Dazu berechnet die App die Signatur nach folgendem Verfahren:

   
Signatur = HMAC-SHA256 ("<Wert von x-dv-baseuri><Wert von x-dv-tenant-id>",App Secret)

und vergleicht das Ergebnis mit der Wert des x-dv-sig-1 Headers. Hierbei ist zu beachten, dass der Wert im x-dv-sig-1 Header Base64 kodiert ist.

Hinweis

Das o.g. App Secret ist ein exklusives Geheimnis zwischen dem Approuter und der jeweiligen App, welches bei der Registrierung der App im d.velop Cloudcenter vergeben wird. Wie es sich für richtige Geheimnisse gehört, dürfen diese unter keinen Umständen mit anderen Parteien geteilt werden. Sollte dies doch einmal versehentlich geschehen sein, dann kann im d.velop Cloudcenter ein neues App Secret für die jeweilige App erzeugt werden.

Sollte der Vergleich fehlschlagen, d.h. der berechnete Wert für die Signatur stimmt nicht mit dem im Header übertragenen Wert überein, dann muss die App den Request ablehnen. Üblicherweise wird dazu der HTTP Status Code 403 Forbidden verwendet.

 Dringend empfohlene Vorgaben

Neben den beiden Vorgaben HTML und mandantenfähiger HTTPS Endpunkt gibt es in der Tat keine weiteren Vorgaben, die du zwingend einhalten musst. Es gibt allerdings einige zusätzliche Punkte, deren Umsetzung wir dir dringend ans Herz legen. Zumindest solltest du genau wissen, welche Konsequenzen es hat, wenn du diese Punkte missachtest.

 Responsive Material Design

Wir verfolgen die Strategie, unsere HTML Oberflächen nur einmal zu entwickeln und auf verschiedenen Endgeräten wie Desktop PCs, Tablets und Mobiltelefonen anzuzeigen. Aus diesem Grund nutzen wir Responsive Webdesign für unsere HTML Oberflächen.

Des Weiteren nutzen wir Material Design von Google. Als Designsystem beinhaltet dies nicht nur eine Komponentensammlung für die Webentwicklung, sondern auch umfangreiche Guidelines und Prinzipien, die beschreiben, in welcher Situation man welches Oberflächenelement wie nutzen sollte.

Da alle unsere Oberflächen Material Design nutzen (oder gerade darauf umgestellt werden), erhält der Benutzer ein einheitliches Look & Feel und verschwimmen die für den Nutzer sichtbaren Grenzen zwischen den Oberflächen der verschiedenen Apps.

Üblicherweise ist man als Entwickler trotzt Designsystem nicht unbedingt in der Lage, visuell ansprechende Oberflächen in kurzer Zeit zu gestalten. Aus diesem Grund stellt unser Design und Usability Team einige Open Source Kopiervorlagen für ganze HTML Seiten bereit, die eine gute Ausgangsbasis für eigene Oberflächen sind.

Hinweis

Solltest du dich entscheiden, deine Oberflächen nicht responsive zu entwickeln, dann verlierst du die Kunden, die deine App auf mobilen Endgeräten oder diversen Integrationen verwenden wollen.

Solltest du eine andere Komponentensammlung oder ein anderes Designsystem als Material Design nutzen, dann wird der Wechsel von einer beliebigen App zu deiner App für den Benutzer sichtbar, wodurch sich die Usability verschlechtert und deine App möglicherweise nicht den Zuspruch bekommt, den sie verdient.

Dennoch kann es gerade bei der Integration von bestehenden Webanwendungen sinnvoll sein, die Anwendung zuerst in der d.velop cloud bereitzustellen und danach auf responsive Oberflächen mit Material Design umzustellen. Da dieser Vorgang aber Aufwand erzeugt, solltest du bei neuen Apps direkt mit auf responsive Webdesign achten und Material Design einsetzen.

 Integration in die Shell-App

Wenn du bereits die d.velop cloud genutzt hast oder On-Premises mit d.3 one gearbeitet hast, dann ist dir bestimmt aufgefallen, dass wir - je nach zur Verfügung stehendem Platz - eine bestimmte Bildschirmaufteilung haben und dass es eine Art Menüleiste gibt, über die man die Bildschirmaufteilung ändern kann. Darüber hinaus werden beim Klick auf bestimmte Links neue Webseiten (Ressourcen) reinanimiert.

Diese und weitere Funktionen werden durch die Shell-App bereitgestellt, die die Webseiten aller beteiligten Apps in separate iframes lädt. Auf diese Weise erhält man ein homogenes Bedienkonzept und gleichzeitig sind die verschiedenen Seiten der Apps voneinander isoliert, so dass innerhalb des iframes unterschiedliche Frameworks verwenden können.

Die Integration in die Shell-App ist nicht sonderlich aufwendig und unobstrusive gehalten. D.h. bei der Konzeption der Shell war und ist es das Ziel, möglichst wenig an vorhandenen Webseiten ändern zu müssen, um die Shell-App zu nutzen. Wie du dich in die Shell-App integrierst, findest du in der entsprechenden API Beschreibung.

Hinweis

Wenn du eine bestehende Webanwendung hast, dann kommst du wahrscheinlich zunächst auch ohne eine Integration in die Shell-App aus. Allerdings wird sich der Benutzer recht schnell wundern, warum bei einem Kontextwechsel keine neuen Webseiten erscheinen und sich die gesamte Navigation innerhalb eines iframes abspielt. Darüber hinaus wären die Kontrollelemente der Shell-App nicht sichtbar, wenn deine Webseiten direkt, z.b. per Link oder Bookmark aufgerufen werden, da die Shell-App in diesem Fall nicht geladen wird. Kurzum, damit der Benutzer ein gutes Benutzererlebnis hat, solltest du die Integration in die Shell-App von Anfang an verfolgen bzw. bei vorhandenen Webanwendungen zeitnah angehen.

 Browserunterstützung

Aktuell unterstützen wir in der d.velop cloud die folgenden Browser auf den genannten Betriebssystemen bzw. Geräten:

  • Internet Explorer 11, Chrome und Firefox auf Microsoft Windows
  • Chrome auf Android ab Android Version 5.0
  • Safari auf iOS (iPhone/iPad)
  • Safari auf MacOS

Bei Chrome, Firefox und Safari unterstützen wir jeweils nur die aktuellste Version.

Da der Internet Explorer seitens Microsoft nicht mehr weiterentwickelt wird, fehlen diesem wesentliche Funktionen eines modernen Browsers. Daher werden wir nicht sicherstellen können, dass auch zukünftig sämtliche Funktionen der d.velop cloud im Internet Explorer zur Verfügung stehen. Dies gilt natürlich nicht für die wesentlichen Kernfunktionen. Diese stehen selbstverständlich auch im Internet Explorer zur Verfügung. Allerdings betrifft dies möglicherweise einige optionale Zusatzfunktionen wie z.B. die Möglichkeit, das Theming zu ändern.

Hinweis

Als App Entwickler solltest du ebenfalls die genannten Browser unterstützen, damit deine App auf den selben Endgeräten und Browsern läuft, wie die restlichen Apps in der d.velop cloud. Ansonsten wirst du einige Kundengruppen nicht erreichen.

 Authentifizierung über die Identityprovider-App

Mit der Identityprovider-App gibt es in der d.velop cloud eine zentrale Anlaufstelle für die Authentifizierung, also für die Fragestellung "welcher Benutzer sitzt dort gerade vor dem Rechner".

Neben einem eigenen Identitätspool unterstützt der Identityprovider eine Reihe von externen Identitätsprovidern wie z.B. Google, Azure AD oder Facebook, so dass sich Benutzer in der d.velop cloud auch mit ihren bestehenden Credentials anmelden können, wenn sie bereits ein Konto bei den genannten Diensten haben und der jeweilige externe Identitätsprovider durch den Administrator im Mandanten konfiguriert worden ist.

Nach einer erfolgreichen Anmeldung erzeugt die Identityprovider-App eine Session für den angemeldeten Benutzer, die von sämtlichen Apps in der d.velop cloud genutzt werden kann, um den Benutzer eindeutig zu identifizieren.

Die Autorisierung, also die Fragestellung "Was darf der angemeldete Benutzer", kann dann allerdings nur von der jeweiligen App gelöst werden, da hierzu Wissen über die in der App abgebildete Fachlichkeit notwendig ist.

Die folgende Grafik zeigt den Ablauf bei der Authentifizierung.

Authentifizierungsprozess

Ablauf der Authentifizierung:

  1. Der Nutzer ruft eine beliebige App der d.velop cloud auf. Im Beispiel die Hello-App im Mandanten acme.
  2. Der Approuter fügt die Mandantenheader hinzu (hier nicht dargestellt) und leitet den Request an die Hello-App weiter. Diese stellt fest, dass keinerlei Authentifizierungsinformationen im Request enthalten sind und leitet den Client daher per Redirect (HTTP Status 302 Found) an die login-Ressource des Identityproviders weiter. Die ursprünglich aufgerufene Ressource /hello/world wird dabei URL-enkodiert als query Parameter übergeben.
  3. Der Browser folgt automatisch dem Redirect, so dass der Request über den Approuter am Identityprovider landet.
  4. Der Identityprovider findet ebenfalls keine Authentifizierungsinformationen im Request und führt daher eine Authentifizierung des Benutzers gegen den internen Identitätspool oder gegen den konfigurierten externen Identitätspool durch (hier nicht dargestellt). Wenn der Benutzer sich erfolgreich authentifiziert hat, setzt der Identityprovider ein AuthSessionId-Cookie, anhand dessen der angemeldete Benutzer identifiziert werden kann und leitet den Client dann - ebenfalls per Redirect - zur ursprünglich aufgerufenen Ressource /hello/world weiter.
  5. Der Browser folgt automatisch dem Redirect, so dass letztendlich ein entsprechender Request auf die ursprünglich (siehe Schritt 1) angeforderte Ressource bei der Hello-App landet. Allerdings enthält der Request jetzt eine Authentifizierungssession.
  6. Die Hello-App empfängt den Request mit der Authentifizierungssession (AuthSessionId), kennt aber den zur Session gehörenden Benutzer noch nicht. Um diesen zu ermitteln, ruft die Hello-App die validate-Ressource des Identityproviders auf und überträgt die Authentifizierungssession als Bearer-Token. Beachte, dass das Bearer Token nicht URL enkodiert ist.
  7. Der Identityprovider kennt den zur Authentifizierungssession gehörigen Benutzer bereits und beantwortet die Anfrage mit einem standardisierten JSON Objekt, welches Informationen über den Benutzer enthält. Unter anderem enthält dieses SCIM User Object auch eine dauerhaft gültige Id für den Benutzer, die auch über die Gültigkeit der Authentifizierungssession hinaus geeignet ist, um den Benutzer eindeutig zu identifizieren. Beachte, dass die Authentifizierungssession ihre Gültigkeit nach einer, vom Identityprovider festgelegten Zeit, verliert und daher nicht geeignet ist, um den Benutzer dauerhaft zu identifizieren.
  8. Die Hello-App hat jetzt sämtliche Informationen über den angemeldeten Benutzer, um eine Berechtigungsprüfung durchzuführen und den Request des Benutzers zu beantworten, falls dieser berechtigt ist. Damit das ganze Verfahren nicht wiederholt für jeden einzelnen Request durchlaufen werden muss, sollte sich die jeweilige App in einem mandantenspezifischen Cache merken, welches SCIM User Object zu einer AuthSessionId gehört. Der vom Identityprovider gesetzte Cache-Control-Header gibt Auskunft darüber, wie lange diese Information gecacht werden darf.

Hinweis

Der dargestellte Prozess wirkt möglicherweise auf den 1. Blick ziemlich kompliziert. Allerdings wird ein Großteil davon unter der Haube durch den Browser bzw. den Identityprovider durchgeführt. Für den Teil, der von jeder App zu implementieren ist, stellen wir Open Source SDKs in verschiedenen Programmiersprachen auf Github bereit.

Die API der Identityprovider-App ist im Developer Portal zu finden.

Solltest du dich entscheiden, die Authentifizierung über einen anderen Mechanismus als über die Identityprovider-App durchzuführen, dann muss der Benutzer sich im Laufe seines Arbeitsflusses mehrfach anmelden. Außerdem muss er Benutzerkonten bei mehreren Identitätsprovider besitzen, um das gesamte System zu benutzen.

 Registrierung der Features an der Home-App

Sobald ein Mandant deine App in der d.velop cloud gebucht hat, müssen dessen Benutzer natürlich wissen, wie die verschiedenen Funktionen deiner App aufgerufen werden können. Eine Möglichkeit wäre es, sämtlichen Benutzern die URIs zu den verschiedenen Features deiner App mitzuteilen, so dass diese passende Bookmarks setzen können.

Das ist natürlich nicht sonderlich benutzerfreundlich, so dass wir zu diesem Zweck die Home-App in der d.velop cloud bereitstellen. Diese hat - anlog zum Homescreen auf mobilen Endgeräten - die Funktion, einen zentralen Einstieg in die Features der gebuchten Apps zu ermöglichen.

In der API Beschreibung der Home-App findest du genauere Informationen dazu, wie du der Home-App die Features deiner App mitteilst. Diese stellt dann entsprechende Kacheln auf dem Startbildschirm dar.

Hinweis

Natürlich kann deine App auch genutzt werden, ohne dass du die bereitgestellten Features der Home-App meldest. Es ist allerdings recht offensichtlich, was das dann für die Auffindbarkeit deiner Features bedeutet.

 Empfehlungen

Du weißt jetzt welche zwingenden Vorgaben es gibt und welche Vorgaben zwar nicht absolut notwendig sind, aber für deren Nichteinhaltung du gute Gründe haben solltest.

Daneben gibt es noch einige Empfehlungen, die im Folgenden aufgeführt sind. Ob du diesen folgen willst, liegt bei dir. Wir haben mit der Umsetzung dieser Empfehlungen und der daraus resultierenden losen Kopplung der Apps, gute Erfahrungen gemacht, so dass wir dir diese nicht vorenthalten wollen. Selbst, wenn du hier andere Wege gehen willst - was für uns vollkommen in Ordnung ist - hilft dir die Kenntnis dieser Empfehlungen beim Umgang mit unseren d.velop cloud Apps und deren APIs.

 Self-Contained Systems

Aus der Problemstellung heraus, mit einer stetig steigenden Anzahl von Entwicklern an einer Software zu arbeiten, haben wir nach einer Lösung gesucht, die es uns ermöglicht, autarke Teams zu bilden, die jeweils nur an einem Teil dieser Software arbeiten und diese Teile für den Endkunden wieder zu einem großen Ganzen zusammenzusetzen.

Die klassische Aufteilung in Frontend, Backend und ggf. Datenhaltung stößt hier an ihre Grenzen, da diese maximal drei Teams zulassen würde. Ganz davon abgesehen, dass diese Teams alles andere als autark sind. Ganz im Gegenteil! Selbst für die kleinsten Erweiterungen in der Fachlichkeit müssen i.d.R. alle drei Teams zusammenarbeiten und passende Schnittstellen absprechen.

Statt die Teams also nach horizontalen, technischen Layern zu bilden, benutzten wir vertikale, fachlich orientierte Schnitte, um die Anwendungsdomäne in mehrere Bausteine aufzuteilen. Die Kunst bei der Erarbeitung dieser Bausteine liegt darin, Ausschnitte der Anwendungsdomäne zu finden, die möglichst wenig Abhängigkeiten zu den anderen Teilen der Domäne haben. Diese Bausteine können dann von unterschiedlichen Teams eigenständig bearbeitet werden. Intern enthalten diese Bausteine dann wieder die üblichen Schichten (Frontend, Backend, Datenhaltung), allerdings sind die Schnittstellen zwischen diesen Schichten jetzt ein internes Detail des Bausteins und für andere Bausteine unsichtbar.

Diese genannten Bausteine sind unsere Apps. Um diese für den Benutzer zu einer virtuellen Gesamtapplikation zusammenzufügen, verwenden wir vorzugsweise Links im Frontend. Dies ermöglicht uns eine wesentlich losere Kopplung als eine Interaktion auf Datenebene.

Hinweis

Nehmen wir z.B. an, dass die Task-App Aufgaben enthält, die sich auf Dokumente in der DMS-App beziehen. "Bitte führe mal ein Review des Dokumentes durch." In diesem Fall macht es Sinn, dass der Benutzer bei der Bearbeitung der Aufgabe, auch direkt das Dokument sieht.

Eine Möglichkeit, dieses Problem zu lösen, wäre es, wenn die DMS-App einen Schnittstelle bereitstellen würde, über die die Task-App sämtliche Informationen zum Dokument abrufen könnte. Die Task-App könnte diese Informationen dann an einer passenden Stelle innerhalb der eigenen Oberfläche für die Aufgabe unterbringen.

Aber was passiert jetzt, wenn sich die Schnittstelle der DMS-App ändert? Zum Beispiel könnten die JSON Properties für das Dokument einen anderen Namen bekommen. In diesem Fall käme es, je nach Implementierung, zu einem Fehler in der Task-App oder zumindest würden auf einmal Informationen zum Dokument fehlen, solange die Task-App noch nicht entsprechend angepasst worden ist. Nun könnte man argumentieren, dass man solche Änderungen an der Schnittstelle der DMS-App dann eben nicht durchführen darf. Aber je breiter eine Schnittstelle ist, desto höher ist die Gefahr, dass man in eine Situation kommt, in der sich eine Änderung der bestehenden Schnittstelle nicht vermeiden lässt. Selbst wenn es gelingt, die Schnittstelle der DMS-App stabil zu halten, stellt sich die Frage, was mit der Anzeige des Dokumentes in der Task-App passiert, wenn die DMS-App in einer neueren Fassung zusätzliche Informationen oder eine verbesserte Darstellung von Dokumenten bietet. Auch dann müsste die Task-App zuerst angepasst werden, um von diesen Zusatzinformationen zu profitieren.

Daher ist es in dieser Situation viel eleganter, von der Aufgabe der Task-App auf das zugehörige Dokument der DMS-App innerhalb der Oberfläche zu verlinken.

Die Schnittstelle ist wesentlicher schmaler. Letztendlich muss lediglich die URL zum verlinkten Dokument stabil bleiben, so dass die Gefahr einer inkompatiblen Änderung weitaus geringer ist. Darüber hinaus profitiert die Task-App unmittelbar und ohne weitere Anpassungen von zukünftigen Verbesserungen an der GUI zur Darstellung von Dokumenten.

Von dieser Art der (Ent)Kopplung profitiert sowohl das Team der Task-App als auch das Team der DMS-App.

Wir haben diese Architektur nicht erfunden und sind auch nicht die einzigen, die ihre Systeme so konstruieren. Mittlerweile hat sich mit Self-Contained Systems (SCS) auch ein Name für eine solche Architektur gefunden.

 REST

Manchmal lässt der umzusetzende Anwendungsfall keine Verlinkung im Frontend zu. Beispielsweise ist bei der serverseitigen Archivierung von E-Mails kein Benutzer und damit auch kein Frontend im Spiel.

Für solche Fälle bieten wir selbstverständlich auch klassische, RESTful HTTP APIs mit JSON Repräsentationen an. Insbesondere nutzen wir an vielen Stellen die JSON Hypertext Application Language, um auch im JSON Format zwischen verschiedenen Ressourcen zu verlinken.

Hinweis

Wenn dein eigener Anwendungsfall in diese Problemkategorie fällt, in der eine Verlinkung im Frontend keinen Sinn macht, dann gibt es höchstwahrscheinlich schon eine passende JSON API dafür. Fehlt diese, dann hast du gute Chancen, dass wir die API entsprechend erweitern werden. Solltest du aber aus der Motivation heraus handeln, eine alternative GUI für eine bereits bestehende HTML Oberfläche entwickeln zu wollen, dann wirst du - zumindest zum aktuellen Zeitpunkt - höchstwahrscheinlich nicht die passenden Schnittstellen bei uns finden. Sprich uns aber gerne an, damit wir deinen Anwendungsfall besser verstehen und gemeinsam nach einer Lösung suchen können.