Eine multi-tenant Lösung
Ab sofort erhalten alle Teilnehmer unserer Trainings ein Abzeichen im Open Badges Format. Schon seit langem gibt’s zum Abschluss des Kurses eine Teilnahmebescheinigung. Dazu haben wir eine eigene Anwendung entwickelt, die für jeden Teilnehmer ein PDF erzeugt und per Email zustellt. Diese Lösung ist genau auf unsere Belange abgestimmt und in unsere Trainingsverwaltung eingebunden. Unser Ziel war es, bei der Entwicklung eigener Anwendungen jeweils kleine eigenständige Lösungen zu erstellen, die genau eine Sache machen. In diesem Fall das Erstellen einer Teilnahmebescheinigung.
Teilnahmebescheinigung
Um eine Teilnahmebescheinigung auszustellen, müssen einige Angaben zur Verfügung stehen. Auf der Bescheinigung ist neben dem Namen und der Firma des Teilnehmers der Seminartitel angegeben, der Zeitraum sowie die Inhalte in Stichworten. Name und Email des Teilnehmers fragen wir im Self-Service ab. Dazu erhalten die Teilnehmer einen spezifischen Link für das besuchte Seminar. Die Teilnehmer gelangen über diesen Link auf ein kleines Formular, in dem sie ihren Namen und die Email eingeben. Firma, Seminartitel, etc. sind fest mit dem Link verbunden. Nach dem Ausfüllen des Formulars wird die Teilnahmebescheinigung erstellt und an den Teilnehmer gemailt. Die folgende Abbildung zeigt das Formular.
Aus der Trainingsverwaltung werden die Seminardaten über RabbitMQ an die Anwendung für die Teilnahmebescheinigungen zugestellt. Es handelt sich wie gesagt um kleine fokussierte Anwendungen. Die Trainingsverwaltung sendet die Informationen in eine Queue. Die Anwendung für die Teilnahmebescheinigungen abonniert diese Nachrichten und speichert lokal die benötigten Informationen zum Seminar. Auf diese Weise sind die beiden Anwendungen lose gekoppelt. Ferner ist es so möglich, die Anwendungen unabhängig zu entwickeln und sogar die Sprache kann frei gewählt werden. Lediglich der Kontrakt über die RabbitMQ Queue muss von beiden Seiten berücksichtigt werden.
Open Badges
Nun bestand der nächste Schritt darin, den Teilnehmern zusätzlich ein Abzeichen im Open Badges Format zur Verfügung zu stellen. Wir hätten dies in die bereits bestehende Anwendung integrieren können. Doch hier haben wir uns entschieden, eine Multi-Tenancy Anwendung zu erstellen: mybadges.io. mybadges.io ist eine Software as a Service (SaaS) Lösung. Das wäre für die Akademie, als bislang einziger Verwender, nicht erforderlich gewesen. Doch eine solche Anwendung kann im Rahmen unserer Trainings auch als Anschauungsobjekt dienen. Regelmäßig werden wir nach „Musterlösungen“ gefragt. Und spätestens im Clean Code Developer Architect Seminar müssen wir mehr zeigen, als kleine Minibeispiele. Ferner steht die Lösung nun auch anderen Mandanten offen.
Multi-Tenancy
Eine Multi-Tenancy Anwendung kann auf deutsch übersetzt als mandantenfähig bezeichnet werden. Im Fall unserer Open Badges Anwendung bedeutet das, die Akademie ist einer der Verwender der Anwendung. Daneben kann es aber andere Verwender geben, deren Daten strikt von unseren Daten getrennt abgelegt werden. Jeder Mandant der Anwendung kann seine eigenen Abzeichen definieren und an Teilnehmer herausgeben. Zur Ablage der Daten haben wir Marten verwendet. Marten ist eine Dokumentendatenbank, die auf PostgreSQL aufsetzt. Gespeichert werden beliebige JSON-serialisierte Dokumente, ähnlich wie bei MongoDB. Der große Vorteil von Marten liegt in der Tatsache, dass Marten multi-tenant fähig ist. Mit jedem Zugriff auf die Datenbank kann eine Tenant Id mitgegeben werden. Marten sorgt so für die Trennung der Daten. Letztlich liegen die Daten aller Tenants bei diesem Modell in der selben Datenbank und sind in einer hinter den Kulissen definierten Spalte einem Tenant zugeordnet. Möglich ist auch, eine Datenbank pro Tenant zu verwenden.
Authentication
Natürlich muss der Zugriff auf eine solche Anwendung über einen Mechanismus zur Authentication gesichert werden. Manche URLs stehen ohne Anmeldung zur Verfügung, aber die meisten Ressourcen sind nur zugänglich, nachdem man sich authentifiziert hat. Öffentlich zugänglich sind die Open Badges, die mit der Anwendung erstellt wurden. Anders wären diese Badges nicht für jedermann verifizierbar.
Für die Themen Authentication und Authorization verwenden wir Keycloak. Dieses Open Source Projekt stellt unter anderem OpenID Connect und OAuth 2.0 zur Verfügung. Die Benutzer werden mitsamt ihrer Passwörter in Keycloak angelegt. Anwendungen wie mybadges.io oder unsere Trainingsverwaltung verweisen jeweils auf den Keycloak Server und erhalten von diesem ein Token, über das ein erfolgreich angemeldeter Benutzer identifiziert werden kann.
Gleichzeitig erfolgt in der Anwendung eine Zuordnung des Benutzers zu einem Tenant. Das von uns gewählte Modell unterstützt die Zuordnung mehrerer Benutzer zu einem Tenant. Damit passt das Modell auch auf Anwendungen, in der mehrere Benutzer auf den selben Daten arbeiten sollen. Über die Authorization können zusätzlich die Berechtigungen gesteuert werden. So können bspw. bestimmte Operationen den Admins vorbehalten sein.
Ein weiterer Vorteil von Keycloak liegt darin, dass auch andere Identity Provider konfiguriert werden können. So ist eine Anmeldung über google, LinkedIn, Facebook, etc. möglich. Dazu muss der Provider lediglich einmal in Keycloak konfiguriert werden. In der Anmeldemaske werden die konfigurierten Provider dann automatisch angezeigt.
API
Die Anbindung der Open Badges Lösung an unsere anderen Anwendungen erfolgt hier nicht per RabbitMQ sondern per API. Dahinter steht die Überlegung, dass es den einzelnen Mandanten so einfach wie möglich gemacht werden soll, Badges zu erstellen. Dazu genügt ein simpler API Aufruf. In Arbeit ist eine Anbindung an Zapier. Damit lässt sich das Erstellen von Badges dann sehr flexibel in tausende von Anwendungen integrieren.
Fazit
Eine multi-tenant Anwendung zu schreiben erfordert einiges an Sorgfalt. Es muss sichergestellt sein, dass jeder Mandant nur seine eigenen Daten sieht. Da hilft es, bestehende Bibliotheken und Services wie Marten oder Keycloak einzusetzen. Auch die Themen Testen und Continuous Integration tauchen auf. Für die Integrationstests verwenden wir Docker plus TestContainers, wie bereits hier beschrieben.
Und natürlich müssen die Anwendungen auch betrieben werden. Auch hierbei kommen diverse Docker Container zum Einsatz. Ferner nginx, Subdomains, SSL Zertifikate und einige andere Details.
Wenn Du mehr erfahren möchtest und den Quellcode sehen möchtest, komm einfach in das nächste Clean Code Developer Architect Seminar.
Clean Code Trainings
Geschlossene Firmenkurse
Wir führen alle Seminare als geschlossene Firmenkurse für Sie durch.
Bei Interesse oder Fragen kontaktieren Sie uns gerne.
German 
English