Robust, flexibel und skalierbar: Ein praktischer Einstieg in SHOGun als Basis von WebGIS-Lösungen
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 88 | |
| Author | ||
| License | CC Attribution 4.0 International: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/56772 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
| |
| Keywords |
16
20
32
34
45
46
67
75
78
79
80
85
00:00
Direktes ProduktSpatial data infrastructureAtomic nucleusDemosceneClient (computing)Configuration spaceVersion <Informatik>Software repositoryPDF <Dateiformat>Military rankLink (knot theory)Route of administrationOpen sourceEigenvalues and eigenvectorsFocus (optics)Component-based software engineeringDemosceneFRAMEWORK <Programm>Set (mathematics)Software developerCodeClient (computing)Spatial data infrastructureMeeting/InterviewComputer animation
03:23
DIGIT <Programm>Version <Informatik>Patch (Unix)Apache <Programm>makeCodeUpdateInternetdienstACIDProviderGeoServerParticle detectorScripting languageWordSoftware developerZahlSource codeLecture/ConferenceComputer animation
04:40
PasswordLDAPWorld Wide WebMainframe computerATESClefExterior algebraDigital object identifierEmailMainframe computerSeries (mathematics)LDAPVersion <Informatik>AuthenticationCondition numberTerminal equipmentAtomic nucleusConfiguration spaceSoftware repositoryService (economics)Hausdorff spaceProviderComponent-based software engineeringSource code
10:18
Open sourceSoftware repositoryNetwork socketAPIClient (computing)Service (economics)Interface (computing)Component-based software engineeringSpatial data infrastructureSmart cardComputer animation
11:43
Component-based software engineeringAuthentication
12:13
DemosceneConfiguration spaceSoftware repositoryNetwork socketVersion <Informatik>APITypAPPELL <Programm>PositionUniform resource locatorCache (computing)UpdateCodeData modelClient (computing)Zoom lensLaufzeitRoute of administrationConfiguration spaceContent (media)Metric systemComponent-based software engineeringMobile appService (economics)Uniform resource locatorClefTypLogarithmComputer animation
18:32
Cellular automatonQuantumSoftware repositoryNetwork socketAPIClient (computing)Interface (computing)Anbindung <Informatik>LDAPComputer animation
19:46
Cache (computing)EmailLoginGame theoryUniform resource locatorHTMLDisplayLDAPProviderBLENDSample (statistics)OLEAnbindung <Informatik>Component-based software engineeringLDAPFile viewerAuthenticationMainframe computerGeoServerComputer animation
22:20
Software repositoryNetwork socketAPICodePasswordPrototypeLDAPSoftware repositoryFunctional (mathematics)Data modelActive DirectoryComponent-based software engineeringComputer animation
23:42
Version <Informatik>Software repositoryEvolutionarily stable strategyWEBGEDCOMService (economics)Data modelGeometryData modelOpen sourceMobile appDesktopFunktionalitätConfiguration spacePlug-in (computing)Computer fileSPRING <Programm>Instanz <Informatik>Social classField extensionInformationSource code
29:34
Uniform resource locatorCache (computing)Computer animation
30:07
BIND <Programm>Service (economics)GeometryCountingCache (computing)CodeServer (computing)Source codeJSONComputer animation
30:45
CodeComputer animation
31:21
Uniform resource locatorCodeServer (computing)Content (media)
32:15
XML
32:43
ProviderDemosceneComponent-based software engineeringSupremumPoint cloudData dictionaryGoogleEigenvalues and eigenvectorsDatabaseDirection (geometry)Token ringClient (computing)Meeting/Interview
36:17
MARKUS <Unternehmensspiel>
Transcript: German(auto-generated)
00:08
Ja, herzlich Willkommen zur Demo-Session Shogun. Das ist der Daniel, ich bin der Marc und wir wollen heute mal schauen, was man mit Shogun eigentlich so alles machen kann. Ja, das ist unser Logo und das ist das Logo mit dem Text. Shogun, es geht heute um Shogun.
00:24
Der Titel, den wir dieser Veranstaltung gegeben haben, ist robust, flexibel und skalierbar. Ein praktischer Einstieg in Shogun als Basis von Web-GIS-Lösungen. Wir wissen, dass das hier eine Demo-Session ist natürlich, aber ganz ohne Hintergrund glauben wir nicht, dass man sich Shogun nähern sollte und auch wirklich etwas mitnimmt aus dieser Demo-Session.
00:41
Der Fokus ganz klar liegt auf Code und Hands-On, aber ein wenig Background wollen wir geben, aber wir halten uns kurz. Was ist Shogun? Shogun ist ein Open Source Framework für die effiziente Individualentwicklung von vornehmlich GDIs. Man könnte auch andere Dinge damit machen. Dabei befindet sich Shogun auf so einer Range zwischen Individualentwicklung und Produkt von der Stange.
01:05
In der Mitte, je nach Anforderungen, die man erfüllen muss. Im Grunde besteht Shogun aus einer ganze Menge an Einzelkomponenten. Geo-Server, Key-Cloak, andere Elemente, eigenes Backend, ein Client, ein Administrations-Frontend vielleicht, die aufeinander abgestimmt sind, aber gleichzeitig auch sehr, sehr flexibel sind,
01:23
um jeweils Anforderungen, die an die entsprechende GDI gestellt werden, zu erfüllen. Wenn Sie noch mehr Interesse haben an Hintergrundinformationen zu Shogun, kann ich Ihnen nur empfehlen, unseren letztjährigen Talk von der PostGIS 2021 anzuschauen. Den Link haben wir hier angegeben.
01:41
Da geben wir noch ein bisschen mehr ein, zeigen auch Schaudiagramme und versuchen auch noch ein wenig besser zu erläutern, was denn an Theorie hinter Shogun steckt. Heute, wie gesagt, keine Theorie, sondern wir haben uns die folgende Agenda gegeben. Wir wollen eigentlich zwei Demos bauen. Die erste Demo, vielleicht der leichteste Einstieg in Shogun, ist eigentlich ein Docker Setup,
02:00
in dem verschiedene Komponenten, ein paar habe ich ja gerade eben schon genannt, aufgeführt werden. Wir schauen uns ein paar von diesen Komponenten etwas genauer an, einen einfachen WebGIS Client, ein Administrations-Frontend und legen den Schwerpunkt auch auf die Schnittstellen, die von Shogun von Haus aus mitgebracht werden. Die zweite Demo wiederum, die zeigt dann eher, wie ein Entwickler mit Shogun,
02:22
basierend auf Anforderungen, die konkret vorliegen, eine konfigurierte und auch erweiterte GDI aufbauen kann. Wir werden dazu kurz vorstellen, was für Anforderungen wir uns denn da ausgedacht haben, werden zeigen, wie wir entwickeln und werden zeigen, wie man dann auch entsprechend eigene Shogun-Applikationen erstellt.
02:45
Das erste Demo Setup führt wahrscheinlich zu einer Ausgabe, die wie folgt aussieht. Wir sind ein einfachen WebGIS Client. Die zweite Demo-Ausgabe wird sicherlich nicht zu etwa einer solch derartig konfigurierten und spezialisierten Shogun-Applikation führen, aber es zeigt, wie wir solch eine Applikation aufsetzen würden
03:03
und dass man quasi das Brüstzeug dabei hat, um auch solche Applikationen zu entwickeln. Let's a go by now. Wir wollen noch ganz kurz uns unsere Kontaktarten hier angeben, falls im Nachhinein noch Fragen sind und auch zeigen, unter welcher Lizenz dieser gesamte Vortrag, diese Demo-Session steht. Und nun aber wirklich, let's go.
03:24
Vielen Dank, Mark, für die einführenden Worte. Wir werden jetzt starten mit der Demo-Session und mit dem ersten Partedemo-Session, mit der ersten Demo, wo ich einmal zeigen möchte, wie Sie mit unserem vorgefertigten Docker-Images, mit dem vorgefertigten Docker-Compose-Setup Shogun einfach zum Laufen bekommen können. Dazu widmen wir uns als erstes dem entsprechenden GitHub-Repository.
03:43
Da gibt es zwei, die zeige ich jetzt auch beide. Einmal das Shogun-Repository, in dem der entsprechende Quellcode von Shogun selbst liegt. Da gehen wir wahrscheinlich in der zweiten Demo-Session etwas näher darauf ein, denn wir wollen jetzt im ersten Schritt die Anwendung nicht kompilieren, sondern einfach ein vorgefertiges Image benutzen. Dafür gibt es ein weiteres Repository, das Shogun-Docker-Repository.
04:05
In dem sehen Sie, wenn Sie mit Docker-Compose auch schon mal gearbeitet haben, sehen Sie wahrscheinlich auch schon ein paar bekannte Dateien, zum Beispiel die Docker-Compose-Yaml-Dateien. Davon gibt es jetzt in diesem Fall drei an der Zahl. Für das initiale Setup oder für das Demo-Setup sind davon aber auch nur zwei relevant,
04:22
wie Sie sich schon am Namen wahrscheinlich herleiten können. Die Minus-Dev-Yaml ist für den zweiten Teil, für die Entwicklung von Shogun relevant. Das heißt, wir haben jetzt hier zwei Compose-Yaml-Dateien, die Shogun und die Compose-Yaml. Ich habe jetzt schon mal in Vorbereitung die Suppository ausgecheckt. Ich switche daher zu einem Code-Editor in die entsprechende Docker-Compose.
04:43
Ich gehe jetzt nicht auf jeden einzelnen Service, den wir hier haben, im Detail ein. Also Sie kennen vermutlich auch schon einen Geo-Server. Dass jetzt das Präfix Shogun davor steht, hat nichts damit zu tun, dass wir einen eigenen Geo-Server gebaut haben oder so. Das ist einfach ein fertiges, existierendes Geo-Server-Image. Und davon also von anderen Services bzw. bestehenden Images gibt es jetzt noch ein paar.
05:02
In unserer Standard-Architektur von Shogun, also neben dem Geo-Server, gibt es noch ein Key-Clock. Key-Clock kennen Sie vielleicht nicht. Die Key-Clock nutzen wir in Shogun als zentralen Authentication Provider. Was ist das schon wieder? Das ist eine Komponente, die die User vorhält und auch die Authentifizierung vornimmt.
05:20
Das heißt, da meldet sich ein User an. Und von Key-Clock werden auch die entsprechenden Rollen, Rechte eines Nutzers ausgelesen von Shogun und auch von den anderen Komponenten. Also zum Beispiel vom Geo-Server. Da gibt es jetzt auch, wie bei anderen Services, gibt es jetzt verschiedene Einstellungen, zum Beispiel Umgebungsvariablen, die dieses Image einfach benötigt.
05:41
Da gehen wir jetzt auch nicht so super im Detail drauf an. Das sind Standard-Einstellungen, die jetzt hier vorgenommen wurden. Wir liefern noch ein eigenes LDAP mit, wo im Prinzip Nutzer dann auch gespeichert werden können. Das ist auch eher für den zweiten Part relevant. Wir haben noch ein Redes mit an Bord. Das Redes wird zum Verwalten der Sessions benötigt
06:01
und so für die Laufzeit, wenn man irgendwo Session-übergreitende, da flüchtige Daten speichern möchte. Das nehmen wir jetzt auch erst mal so hin, dass das mit dabei ist. Da gehen wir jetzt aber auch in beiden Demo-Sessions gar nicht so sehr drauf ein. Das läuft mehr oder weniger im Hintergrund für uns. Und dann haben wir natürlich noch eine Datenbank, in der die Geo-Daten gespeichert werden, wenn wir zum Beispiel bei den Geo-Server-Layer veröffentlichten
06:21
oder Daten veröffentlichen wollen. Und natürlich auch die Konfiguration von Shogun, also von Applikation und Layern zum Beispiel. Da kommen wir gleich noch deutlich mehr im Detail drauf zu sprechen. Und dann gibt es noch eine zweite Compose, in der läuft ein Engines, also ein Webserver, über den zum Beispiel ein HTTPS-Zertifikat oder SSL-Zertifikat ausgeliefert wird
06:44
und der im Prinzip auch so ein bisschen das Routing-Funds übernimmt. Und dann kommen wir jetzt tatsächlich endlich auch mal zum Kern von Shogun, nämlich der Shogun-Middleware oder wie wir es dann auch häufig bezeichnen, Shogun-Boot, Shogun-Best-Flegen, weil Shogun auf Spring bzw. konkreter Spring-Boot basiert.
07:02
Und da gehe ich dann jetzt vielleicht doch noch etwas mehr im Detail drauf ein. Also sehen wir neben dem Service-Namen, sehen Sie das entsprechende Image, also das vorinstallierte bzw. verfügbare Image. Da gehen wir jetzt hier auf die neueste Version. Jetzt kann man hier noch weitere Sachen einstellen, die so ein bisschen docker-compose-spezifisch sind.
07:20
Also Shogun, eine Kerneigenschaft von Shogun und auch anderen Komponenten, die wir verwenden, ist, dass Shogun skalierbar ist. Das heißt, ich kann nicht nur einen Stunt von Shogun hochfahren, sondern mehrere. Und das kann ich bei docker-compose relativ einfach mit diesem Deploy oder mit der Deploy-Konfiguration über Replikas steuern. In unserem Fall bestarrt mir jetzt erstmal nur ein Replika.
07:42
Das macht unser Setup einfach ein bisschen schneller hier an der Stelle. Aber für Production mag das schon viel relevanter sein. Und es gibt jetzt ein paar Umgebungsvariablen, die für Shogun notwendig sind, unabhängig davon, ob ich jetzt ein vorgefährtes Image nutze oder es selber entwickeln möchte. Zum Beispiel muss ich jetzt Shogun gewisse Konfigurationen geben über die anderen Services, die wir uns gerade schon angeschaut haben.
08:02
Also zum Beispiel, was ist denn der Datennutzer, mit dem Shogun mit der Post das Datum verbinden soll? Was ist der Host von dem Key-Clock? Was ist der Key-Clock-Admin-Nutzer? Und Shogun kann auch Mails versenden. Und dementsprechend könnten wir jetzt hier auch noch einen Mail-Host eintragen, beziehungsweise auch die entsprechenden Konditionen für diesen Mail-Server.
08:25
Das ist auch eigentlich schon fast alles. Es gibt noch eine Reihe weiterer Umgebungsvariablen. Das sind die zentralen Umgebungsvariablen. Und Sie sehen jetzt hier noch ein paar Konfigurationen, die ich von außen in dieses Image herein geben kann. Und die sehen wir uns auch später. Ich fahre das Ganze aber jetzt auch gleich mal hoch, dass man etwas sehen kann.
08:41
Dann schauen wir uns wahrscheinlich in diesem Teil gleich auch mal diese Konfigurationsdateien an. Ein paar kennen Sie oder kann man vom Namen schon herleiten, worum es da geht. Zum Beispiel mit Application Jaml. Das ist die zentrale Konfigurationsdatei. In der Dinge wie zum Beispiel sicherheitsrelevante Einstellungen vorgenommen werden können, wie Rollen, Berechtigungen etc.
09:01
Eine Log-Konfiguration kann man noch vornehmen. Und vieles weitere. Über den letzten Teil bespringe ich jetzt erst mal drüber. Das ist jetzt für den ersten Part so interessant. Vielleicht noch eine Zusatzinformation. Wir haben versucht Shogun so aufzubauen, dass es aus verschiedenen Microservices besteht.
09:20
Und wir liefern noch ein paar mit aus. Wir schauen uns aber heute nur den Kern davon an. Nämlich der Shogun Boot Image bzw. Shogun Boot Service. Das, was ich gerade gesagt habe bzw. das, was ich jetzt auch so ein bisschen zeigen werde, auf dem Terminal kann man natürlich auch nachlesen. In dem Repository gibt es auch eine README.
09:41
Da steht noch mal so ein bisschen beschrieben drin, wofür die verschiedenen Compose-Dateien sind, was sie auch benötigen würden, um das zu Hause nachzuvollziehen. Also Docker und Docker Compose, zumindest für den ersten Part. Wie sie diese Repositories empfohlenerweise auschecken. Und weiteres. Und das Allerwichtigste ist jetzt an der Stelle ein entsprechender Command,
10:02
um die Images zu starten, die Container zu starten, zu erzeugen und zu starten. Und das ist dieser Befehl, den nehme ich jetzt einfach noch mit. Und trage ihn ins Terminal ein. Und starte jetzt die entsprechenden Container. Nachdem alle Services gestartet sind,
10:21
können wir jetzt eine Browser Welt zurückwechseln und die Startseite von Shogun aufrufen. Die erreichen wir ganz einfach unter Localhost. Und wir sehen diese Startseite mit diversen Einstiegspunkten in diverse Komponenten bzw. Endpunkte von Shogun. Da sehen Sie zum Beispiel unten rechts noch mal die direkt links zu den GitHub-Repositories, wo wir gerade schon kurz draufgeschaut haben.
10:42
Oder auch in die entsprechenden Oberflächen, die wir mitliefern in diesem Demo-Setup. Das heißt, auf einer Seite ist das natürlich ein GISS-Client und ein Administrations-Client. Im GISS-Client kann man sich vorstellen, werden Karten da, also könnte der Startpunkt für eine GDI sein. Und im Admin-Client kann dieser GISS-Client
11:00
oder können GISS-Clients konfiguriert werden. Das heißt, welche Layer sollen sichtbar sein, welches Kartenzentrum soll initial geladen werden etc. Und die müssen natürlich miteinander kommunizieren, diese beiden Clients. Und das tun Sie über Schnittstellen von Shogun. Und das kann entweder über REST passieren oder über GraphQL.
11:21
Und beide Schnittstellen oder diese beiden Endpunkte haben von der Funktionalität, sind sie sehr vergleichbar, haben auch eine Selbstbeschreibung. Und die schauen wir uns auch gleich mal an. Das ist nämlich entweder die OpenAPI-Dokumentation für REST oder der GraphiQL-Editor für die GraphQL-Interfaces. Schauen wir uns als erstes mal den Admin-Client an.
11:41
Den können wir öffnen. Und werden jetzt weitergeleitet auf die Login-Seite. Diese Login-Seite kommt jetzt tatsächlich von Keyclog. Da hatten wir gerade schon kurz drüber gesprochen. Das ist also der interne Authentication Provider, bei dem wir uns jetzt anmelden können, um automatisch in allen anderen Komponenten von Shogun angemeldet zu sein.
12:01
Das heißt im GISS-Client, in dem SwaggerUI-Client oder auch im Geo-Server und weiteren. Es gibt einen mitgelieferten Admin-User. Der heißt einfach Shogun. Da können wir uns einloggen. Und wenn alles gut geht, sehen wir jetzt diese Admin-Oberfläche, das klassische Admin-Stations-Backend,
12:22
wenn man so will. Und da sieht man jetzt in diesem Dashboard auch schon die initial oder jetzt voreingestellten Konfigurationen. Das heißt, wir haben eine Applikation, wir haben einen Layer und wir haben ein paar Beispiel-Nutzer. Und da schauen wir uns jetzt mal ganz gut an, was man noch so machen kann.
12:40
Schauen wir uns das erste Mal die Themen an. Das ist jetzt in diesem Fall ein einfacher OSM-WMS. Den kann ich aus dieser Liste auswählen und habe jetzt auf der rechten Seite diverse Möglichkeiten, diesen Eintrag zu konfigurieren. Also ich kann dem Layer einen Namen geben. Ich kann sagen, von was für einem Typ dieser Layer ist. Also es könnte jetzt auch ein Teil-WMS zum Beispiel sein.
13:02
Und kann jetzt hier drunter spezifische Eigenschaften zum Beispiel für die Datenquelle eingeben. Das heißt, unter welcher URL dieser Dienst erreichbar ist und wie er natürlich auch heißt. Und ich kann jetzt hier oben drüber in der Konfiguration noch spezifische weitere Einstellungen vornehmen, die für den Client relevant sind. Zum Beispiel soll dieser Layer
13:22
Hoverable sein oder Clickable oder soll er durchsuchbar sein. Sie sehen jetzt, das ist erst einmal nur ein JSON-Editor-Fenster. Da könnten Sie jetzt fragen, ok, was kann ich denn da alles eintragen? Frage wäre vollkommen berechtigt. Als Minimalunterstützung haben wir jetzt hier auf Basis der OpenAI Spezifikation
13:41
bzw. JSON-Schemas Vorschlagslisten. Das heißt, ich kann jetzt hier ein kleines Fenster bekommen und ein kleines Tooltip bekommen, mit dem ich vorausgewählt bekomme, was für Keys ich hier entsprechend eintragen kann. Das lassen wir jetzt auch einfach so. Wechseln dann zu den Applikationen.
14:02
Sie sehen, hier gibt es auch eine Applikation. Die Oberfläche ist relativ ähnlich aufgeholt wie bei den Layern. Das heißt, diese Applikation, diese GISS-Instanz, soll einen Namen haben. Und die hat auch eine Konfiguration. In diesem Fall sieht man jetzt auch mit der Maus über die entsprechenden Eigenschaften fährt. Sieht man eine kurze Beschreibung, was das überhaupt soll.
14:20
Also in diesem Fall Zoom bedeutet, der Key Zoom steht für das initiale Zoom-Level der Karte oder eben auch das Zentrum, den Initial Center of the Map. Und da gibt es auch ein paar weitere Eigenschaften, die man jetzt auch von anderen oder die man üblicherweise in einem GISS-Client mitgeben möchte. Also die Projektion, die Zoom-Level und weitere.
14:41
Natürlich gibt es auch noch eine kurze Beschreibung. Und ich kann natürlich auch noch einen Themenbaum konfigurieren. Das heißt, den Layertree, in dem die Layer der Applikationen dann entsprechend geschachtelt zum Beispiel auftauchen sollen. In dem Admin kann ich jetzt noch ein paar weitere konfigurationsunabhängige Sachen konfigurieren oder mir anschauen.
15:01
Zum Beispiel Metriken des Systems, also wie ist mein System gerade ausgelastet, CPU-Last etc. Ich kann mir auch die Logs anschauen des Systems, wenn ich das möchte. Ist jetzt für hier wahrscheinlich ein bisschen zu detailliert. Kann aber auch, und das ist vermutlich viel interessanter, zur Laufzeit die Log-Level der jeweiligen
15:21
Einzelkomponenten einstellen. Das ist insbesondere für Debugging-Zwecke sehr, sehr hilfreich, gerade auf Produktivsystemen. Wechseln wir nun zurück zu der Startseite. Und über die Startseite können wir jetzt diesen GizClient aufrufen. Unser GizClient baut sich jetzt entsprechend der Konfiguration, die wir jetzt gerade im Admin schon vor eingestellt gesehen haben,
15:42
auf. Das heißt, wir haben einen Layer, das ist der OSM-WMS, und ein entsprechendes Kartenzentrum. Und um das Zusammenspiel nochmal zu zeigen, gehe ich nochmal zurück in den Admin, in die Themenkonfiguration, wähle diesen einzelnen Layer aus und ich ändere jetzt die URL von diesem Dienst,
16:01
nämlich von dem grauen OSM-WMS-Dienst zu dem farbigen. In dem Fall ist es jetzt ganz einfach, da kann ich die URL so ändern, indem ich das Minus-Gray rausnehme. Diese Änderung kann ich jetzt speichern und lade den Client einmal neu. Und Sie sehen
16:22
jetzt, dass im Endeffekt genau die gleiche Kartenkonfiguration zieht, mit dem Unterschied, dass jetzt hier der farbige OSM eingeladen wird. Das zeigt, glaube ich, ganz gut, wie diese zwei Komponenten miteinander agieren. Das heißt, für die Appositonsclient, für die Appositons, für die Einstellung und der Client, der Gizclient, der die entsprechenden Contents ausliefert.
16:42
Wir wollen uns jetzt natürlich noch ein bisschen genau anschauen, wie das ein bisschen in Detail funktioniert. Und dazu können wir die Swagger-Docs öffnen oder die OpenAPI-Spezifikation öffnen. Und hier sehen Sie jetzt alle Schnittstellen, die Shogun in diesem Demo, in diesem DeepFault-Standard Setup mit ausliefert.
17:01
Und wir haben jetzt im Hintergrund mit zwei sogenannten Entitäten gesprochen, nämlich einmal mit den Applications, mit den Applikationen. Das ist also die Applikations-Konfiguration und den, das sehen Sie hier oben, und mit der Layer-Konfiguration. Das heißt, die Datenquelle, die wir jetzt gerade geändert haben und um jetzt eine spezielle Konfiguration festzuschreiben,
17:22
können wir jetzt zum Beispiel bei der Applikation diverse Einstellungen vornehmen. Das heißt, wir folgen einem ganz klassischen REST-Paradigma. Das heißt, um zum Beispiel alle Applikations-Konfigurationen zu finden, gibt es eine Gatchen-Stelle, die auf Applications forcht. Das können wir jetzt auch mal ausprobieren, hier an der Stelle. Wir bekommen jetzt hier,
17:44
indem ich mir so Beispiele ausgeführt habe, die entsprechende Response auch zurück. Da sieht man also die komplette Konfiguration, die der Kleinte zum Beispiel auslesen könnte. Und genau so gut könnte ich jetzt hier über ein Postrequest eine entsprechende Applikation erstellen. Das können wir jetzt auch einfach mal machen.
18:03
Hier ist auch die Konfiguration, also die Modellierung so einer Applikation vorgegeben. Das heißt, kann ich mal ausfüllen mit dem default Setup. Und bekommen wir jetzt in diesem Fall die entsprechende Applikations-Konfiguration zurück. Das können wir uns auch mal anschauen. Im admin zum Beispiel,
18:22
da wechsle ich jetzt mal wieder hin zurück. Wenn ich also jetzt die Liste der Applikation neu lade, sehe ich jetzt auch hier das zwei Applikationen hier auftauchen. Warum zeige ich das? Das ist relativ interessant für den zweiten Teil und natürlich auch über die Arbeit hier mit Shubun hinaus. Das heißt, wir liefern Schnittstellen. Diese Schnittstellen
18:41
sind, da kommen wir gleich im zweiten Teil noch ein bisschen drauf zu sprechen, sehr generisch und dynamisch gestaltet. Und sie können einen Client entweder schon haben oder auch einen Client implementieren, der diese Schnittstellen anspricht und dann eine entsprechende UI dafür auch bereitstellt nach ihrem Gusto. So wie das der Mark zum Beispiel auch am Anfang gezeigt hat in diesem Screenshot
19:01
von diesem etwas komplexeren Projekt. Okay. Ich denke, das war jetzt schon mal ein ganz runder Einblick so in das Demo-Setup, in die Idee von Shubun. Wir werden jetzt gleich im zweiten Teil ihn einmal kurz vorstellen, wie sie, wir haben zu zwei Sachen überlegt, wie sie ein bestehendes LDAP in Shubun integrieren können,
19:22
also bestehenden Nutzer integrieren können und wie sie diese Swagger bzw. die Restschnittstellen mit eigenen Eigenschaften erweitern können. Starten wir nun mit der Anbindung der LDAP User in Shubun und dazu können wir jetzt Keyclock öffnen. Das können wir tun, indem
19:41
wir auf den Endpunkt Out gehen und uns über die entsprechende Appressionskonsole anmelden. Hierfür gibt es einen eigenen Nutzer, das ist der Admin Nutzer, mit dem wir uns anmelden können. Und innerhalb Keyclocks können wir jetzt diverse Sachen einstellen, die mit der
20:00
Absicherung von Shubun, GeoServer und anderen Komponenten zu tun haben. Uns interessiert jetzt, wie wir hier ein bestehendes LDAP und die entsprechenden Einträge aus dem LDAP in Keyclock integrieren können, sodass wir uns dann mit diesen Nutzern auch anmelden können. In Keyclock heißt die Anbindung oder wird die Anbindung über eine sogenannte User-Federation geregelt und ich habe das jetzt hier schonmal vorbereitet,
20:22
habe hier eine eigene User-Federation angelegt mit dem Namen Shubun LDAP und kann jetzt in dieser Maske die entsprechenden Verbindungsobstellungen zu dem LDAP vornehmen. In diesem Fall ist jetzt hier ein Beispiel LDAP, das wir jetzt einfach mitgeliefert haben oder mitliefern, konfiguriert.
20:42
Hier ist die entsprechende Host bzw. der entsprechende Port und die entsprechenden Verbindungs Credentials, unter dem die Nutzer zu finden sind. Das können wir mal kurz schauen, ob die Verbindung auch funktioniert. Ja, das scheint zu klappen. Auch die Authentication ist erfolgreich.
21:02
Und wir können jetzt die entsprechenden User in das System integrieren, indem wir einfach über diesen Knopf hier unten, Synchronize Change oder Synchronize All Users in Keyclock integrieren. Die entsprechenden User werden von Shubun auch verstanden bzw. ausgelesen und dann auch damit stehen sie unsere
21:20
Verfügung. So, das hat funktioniert. In dem Fall ist es tatsächlich so, dass in diesem LDAP zu Demozwecken einfach nur 4 User vorhanden sind. Und die können wir uns auch mal anschauen. Auf der linken Seite unter Users über View All Users. Und das sind jetzt im Prinzip genau diese 4 bzw. diese 3
21:42
dieser Nutzer hier unten. Und da können wir uns auch ein paar Eigenschaften zu anschauen. Also neben dem Namen auch die entsprechenden Gruppen, in denen dieser Nutzer Mitglied ist. In diesem Fall ist das ein Nutzer in der Admin-Gruppe, der entsprechend auch über entsprechende Admin über eine entsprechende Admin-Rolle verfügt
22:02
und somit auch ein Admin in unserem System ist. Das können wir jetzt auch mal ausprobieren. Also indem wir uns jetzt versuchen, mal mit dem ASTAC Nutzer anzumelden. Dazu gehen wir zurück auf die Startseite. Können es dann einmal wieder ausloggen und loggen uns wieder ein.
22:20
Nutzen dieses Mal einen der LDAP Nutzer, zum Beispiel einen ASTAC Nutzer mit dem dazugehörigen Passwort. Und loggen uns ein. Und das hat auch direkt funktioniert. Und wir sind jetzt entsprechend als dieser LDAP Nutzer im System eingeloggt. Das sollte eine kurze Demonstration sein, wie einfach Sie bestehende Nutzer aus einem bestehenden Behörden oder Firmen LDAP oder auch Active Directory
22:42
in Shogun und den dazugehörigen Komponent integrieren können. Im nächsten Part wollen wir Shogun jetzt funktional erweitern. Funktional erweitern, um ein neues Model, um eine neue Entität, die wir über Restschnittstellen lesen, manipulieren, erstellen
23:00
und entfernen können. Das kann natürlich jetzt irgendein Model sein, so wie es im Projekt halt benötigt wird. Um diese Änderung vorzunehmen, brauchen wir jetzt ein minimales Entwicklungs-Setup. Zumindest den Prototypen für das Entwicklungs-Setup haben wir schon vorbereitet. Dafür gibt es ein Repository auf
23:20
GitHub, die Shogun Example App, in der die wichtigsten Schritte schon vorangestellt, bzw. als Startpunkt vorbereitet sind. Das habe ich jetzt schon ein bisschen vorbereitet. Ich habe dieses Repository ausgecheckt und in einen Editor, in dem Fall in IntelliJ, eingeladen. Dahin switche ich auch jetzt.
23:42
Das sehen Sie jetzt hier, die Shogun Example App. Shogun ist ein Java-Maven-Projekt und für den einen oder anderen Markt jetzt auch zur Struktur auch direkt mehr oder weniger vertraut bekommen. Man erkennt meistens ein Maven-Projekt an dem Vorhandensein an der PomixML, der Manifest-Datei,
24:03
in der die zentralen Eigenschaften dieses Projektes vorhanden sind, bzw. konfiguriert werden können. Solche Konfigurationen sind dann zum Beispiel die Abhängigkeiten, die das Projekt hat, der Name, eine Kurzbeschreibung, die Konfiguration von Plugins
24:20
und vielen weiteren Sachen. Was man in dieser Pom aber auch einstellen kann, ist ein so genannter Parent. Der Parent kann jetzt verweisen auf ein existierendes Maven-Projekt. Und das ist jetzt hier auch schon eingestellt. Das heißt, der Parent, den wir verwenden wollen, ist Shogun. In dem Fall ist es auch in der aktuellsten
24:40
Version, der Version 9.2.3. Und das bedeutet, wir haben jetzt hier mehr oder weniger automatisch alle Sourcen zur Verfügung in unserem Projekt, die Shogun uns bietet. Grundsätzlich brauchen Sie für eine Projekt- erweitung, die wir uns jetzt hier gerade anschauen, nicht viel mehr implementieren als
25:00
diesen Parent und noch ein paar weitere Dependencies, bzw. eine weitere Dependency, nämlich auf Shogun Boot selbst, um dieses Projekt starten zu können. Und zwar müssten Sie da eigentlich nur eine weitere Datei erstellen, bzw. erstellen und darin eine gewisse Klasse erweitern. Und das ist in diesem Fall Shogun Example App-Konfiguration,
25:23
die gewisse Eigenschaften einerseits von Shogun erweitert. Das sehen Sie hier über das Extends Application-Konfiguration. Und an der anderen Stelle von Spring. Das sagte ich schon mal ganz kurz eingangs, dass Shogun eine Spring-Applikation ist. Durch die Erweiterung
25:42
oder durch das Nutzen der Spring-Applikation bekomme ich jetzt viele Annehmlichkeiten für mein Desktop gegeben, wie z.B. einen HTTP-Server, auf dem ich das ganze Projekt starten kann. Und auf der anderen Seite bekomme ich jetzt durch die erweiterte Application-Konfig viele Eigenschaften gegeben, die Shogun voreingestellt hat, bzw. bietet. Also angefangen
26:01
über diverse Klassen, die wir erweitern können, neben Application-Konfig selbst, hin zu Security-Konfiguration, Webstellen-Sicherheit und eben auch z.B. für die Konfiguration der Swagger-Oberfläche, die wir uns gerade schon mal kurz angeschaut haben und die wir uns auch gleich nochmal anschauen werden. Im Grunde würde das schon reichen, um jetzt eine
26:20
eigene Instanz oder eine eigene Projekt- erweitern von Shogun zu starten. Wenn Sie das jetzt so starten würden, würden Sie genau den Zustand sehen, den wir uns gerade auf Basis der vorhandenen Docker-Images angeschaut haben. Jetzt wollen wir hier noch ein bisschen Funktionalität hinzufügen. Da hat man gerade schon gesagt, wir wollen eine neue Eigenschaft, bzw.
26:42
ein neues Model hinzufügen und darauf die entsprechenden Rest- bzw. Crud-Schnittstellen. Das habe ich jetzt auch schon mal etwas vorbereitet. In dem Fall habe ich jetzt ganz kreativ ein neues Model erstellt mit dem Namen Country, in dem Länder vorgehalten bzw. gespeichert werden können.
27:02
Das kann aber jetzt natürlich auch irgendwas anderes sein. Entscheidend ist, dass eine bestehende Shogun-Klasse erweitert wird. In dem Fall ist das die BaseEntity. Wie der Name schon sagt, ist das etwas ganz Zentrales, bzw. etwas ganz Grundlegendes. Und sobald eine eigene Klasse in diesem Shogun-Kontext diese BaseEntity erweitert, gibt es allerhand
27:22
bzw. allerlei Funktionalitäten gegeben. Ich habe das jetzt in diesem Fall ganz einfach aufgebaut. Es gibt jetzt das Country, das hat ein paar Felder und das hat einen Namen, das hat einen Capital, eine Area und eine Population. Worauf ich noch ein kleines Augenmerk legen möchte, ist, dass die entsprechenden Felder jetzt hier noch um eine kleine
27:43
Dokumentation erweitert wurden. Also zum Beispiel jetzt hier um eine Description und einen Examplewert. Diese Werte, die jetzt hier angegeben sind, das sind die Informationen, die jetzt auch automatisch von der OpenAPI-Spitzifikation ausgelesen werden und dann auch später angezeigt werden können. Das werden wir also gleich in der Oberfläche von Swagger
28:02
wieder sehen können. Neben dem Model selbst brauchen wir jetzt noch die Konfiguration der WebTion-Stelle, damit dieses Model von außen zugänglich ist. Dazu brauchen wir eine neue Controller-Definition. Die habe ich jetzt hier im Controller-Paket abgelegt unter dem Namen CountryController. Da sieht man, dass die auch zusammengehören.
28:22
Und so sieht er dann aus. Er hat also einen Namen und das entscheidend auch hier an der Stelle wieder, dass eine bestehende Klasse erweitert wird. In diesem Fall ist das der Base-Controller aus Shogun. Der Base-Controller beinhaltet alle Informationen dazu, einen HTTP-Endpunkt, der nach CRUD beziehungsweise nach REST funktioniert, aufzubauen.
28:42
Das heißt, der hat die Logik, um in diesem Fall ein neues Country zu erstellen, ein bestehendes zu updaten, ein bestehendes zu entfernen und eben eins oder alle abfragen zu können. Vielmehr muss ich also auch nicht tun, außer diesen Controller zu erweitern mit ein paar weiterer generischen Typinformationen. Dazu gehört logischerweise auch das Country.
29:01
Und entscheidend ist jetzt hier auch noch so ein HTTP-Endpunkt braucht natürlich auch einen Namen. Und in diesem Fall habe ich dem Endpunkt jetzt einfach den Namen Countries gegeben. Das ist im Grunde tatsächlich jetzt auch wirklich alles, was ich brauche, um Model und Controller zu implementieren.
29:20
Und um das jetzt zu testen, muss ich die Applikation starten. Das kann ich jetzt hier in meiner IDI kann ich das hier oben über Run Configuration tun. Das habe ich jetzt im Hintergrund schon einmal gemacht. Das heißt, die Applikation läuft. Und ich kann jetzt in die Swagger Oberfläche wechseln, die wir uns gerade schon mal auf Basis
29:41
des bestehenden Images von Shogun angeschaut haben. Das sieht jetzt auch hier genauso aus. Das heißt, wir haben uns hier ein paar Controller, die wir uns auch schon angeschaut haben. Also zum Beispiel den Application Controller oder auch den Layer Controller. Was jetzt allerdings neu ist, ist der Gauntlet Controller. Das ist der Controller, den wir gerade erstellt haben.
30:01
Den kann man jetzt auch mal öffnen. Und wir erkennen jetzt direkt den Namen des Controllers, den wir zuvor in dem Controller einmal erstellt hatten oder angegeben hatten. Hier auch wieder. Wir sehen ihn aber jetzt nicht nur einmal, sondern ein paar Mal mehr, denn für die entsprechenden Funktionalitäten, die wir jetzt auf diesen Endpunkt gelegt haben. Find, add und so weiter und so fort.
30:21
Und das können wir jetzt auch mal ausprobieren, ob das funktioniert. Das heißt, wir würden jetzt gerne einmal alle Countries aus der entsprechenden Konfigurationsdatum auslesen wollen. Können wir jetzt über try it out, execute und sehen jetzt in diesem Fall die Antwort. Das ist jetzt eine leere Liste. Das ist soweit auch erstmal logisch, weil wir
30:41
noch gar kein Country angelegt haben. Machen wir das jetzt einfach mal über den entsprechenden Post-Endpunkt. Auch das wollen wir gerne ausprobieren. Und hier sehen wir jetzt auch die Example-Values, die wir gerade in den Schema Annotations definiert oder angelegt haben. Und genau die auf diesen Beispielwerten wollen wir jetzt einmal ein neues Country
31:01
anlegen. Execute. Und das hat auch geklappt. Wir bekommen jetzt hier den Status-Cost 201 zurück für erfolgreich erstellt. Und hier auch schon eine Vorschau der entsprechenden Entität, die wir angelegt haben. Jetzt können wir nochmal schauen, ob das auch wirklich klappt,
31:21
ob das angekommen ist. Jetzt fragen wir nochmal alle Countries ab. Execute. Und jetzt bekommen wir genau diese Entität mit der ID 70, die automatisch angegeben wurde. Neben noch einem created und modified Timestamp. Zurück. Das ist jetzt ein kleines Beispiel gewesen,
31:41
wie Sie Shogun auf Basis von Shogun eine eigene Applikation entwickeln können. Welche Ansatzpunkte es gibt, um HTTP-Endpunkte mit eigener Logik, mit eigenem Content zu versehen. Und in ähnlicher Weise können Sie das auch tun, für die entsprechenden Clients,
32:01
die dahinter liegen. Beziehungsweise über die dann diese Endpunkte angesprochen werden können. Also zum Beispiel einen eigenen Giz-Client oder auch einen Admin-Client. Und den genauso ausgestalten können, wie das in dem entsprechenden Projekt auch notwendig ist. Das war der letzte Punkt, den wir gerne in dieser Demo-Session präsentieren wollten. Als erstes vielen, vielen Dank für Ihr
32:21
Interesse und für Ihre Aufmerksamkeit. Und ich hoffe, wir konnten Ihnen einen kleinen Einblick in Shogun und die Möglichkeiten geben, die es zur Erweitung bietet. Beziehungsweise die es quasi von Haus aus schon mitbringt. Wenn Sie Fragen hierzu oder natürlich auch darüber hinaus haben, kontaktieren Sie uns gerne jetzt im Anschluss oder im Verlauf der Foskis. Wir sind auch noch erreichbar.
32:40
Und selbst darüber hinaus können Sie sich gerne bei uns melden. Ja, prima. Vielen Dank, Daniel und Mark, für die interessante Demo. Wir haben gleich ein paar Fragen. Die meisten beziehen sich auf die Authentifizierung, schwieriges Wort. Wenn die Nutzer,
33:02
die man da einstellen kann, sind die jetzt nur für die Admin-Oberfläche oder gilt das für die gesamte Applikation danach? Genau, die User gelten für alle Applikationsbestandte. Das ist also zum Beispiel der Admin. Das ist auch der Client und das können jetzt im Prinzip auch andere Komponenten sein. Also zum Beispiel der Geo-Server, wo
33:21
man sich dann entsprechend mit dem Nutzer angemeldet hat und dann auch die entsprechenden Berechtigungen hat. Okay. Und das Key-Cloud, was da verwendet wird, nutzt das JWT. Ich nehme an, du weißt, was JWT ist, zur Authentifizierung, dass man da was anderes reintun kann. Genau, das ist der JSON-Web-Token. Grundsätzlich funktioniert
33:41
Key-Cloud intern mit diesen Tokens. Das heißt, man könnte auch andere Provider da integrieren. Die Frage war ja auch in Richtung GitHub zum Beispiel. Auch das ist möglich. Also da gibt es auch noch viele weitere Provider, die man nutzen kann. Also Google und weitere. Grundsätzlich ist es aktuell tatsächlich so,
34:00
dass Key-Cloud noch hart verdraht ist im Chagun. Es gibt aber jetzt wirklich relativ frischen aktuellen Pull-Request, der diese harte Verdrahtung auflöst, sodass man da auch wirklich was Eigenes dann implementieren kann. Okay. Und natürlich die Frage, wie sieht es mit Replikas aus?
34:21
Ist es cloudfähig? Alles muss ja heutzutage cloudfähig sein. Genau. Jetzt können wir Buzzword- Shouting machen. Genau. Grundsätzlich ist diese komplette Architektur so aufgebaut, dass man grundsätzlich Microservices mit Chagun aufsetzen kann. Und die sind natürlich dann auch entsprechend skalierbar und dementsprechend
34:41
auch in der Cloud oder cloudfähig. Genau. Das ist so eins der zentralen Ziele wirklich von Chagun oder der entsprechenden Komponenten. Das ist für die Komponenten, die man da jetzt in Chagun drin hat, natürlich auch nicht mehr so ganz trivial. Also jetzt für diese Demo, die ich gerade gezeigt habe bzw. diese Teilkomponente von Chagun, ist das relativ gut
35:01
und auch gut möglich und auch mehr oder weniger erprobt. Für andere Komponenten, zum Beispiel für Datenbanken oder für eine Postgres-Datenbank, die da jetzt auch mit ausgeliefert wird oder auch für den Geo-Server, ist das mitunter natürlich nicht immer so ganz einfach. Da muss man halt entsprechende Konfigurationen vornehmen oder entsprechend auch diese Datenverzeichnisse
35:21
und Datenfragmentierung in Griff kriegen. Aber grundsätzlich sind die Kernkomponenten von Chagun skalierbar und cloudfähig. Na, du sagst gut, dann ist ja auch noch was übrig für euch als Consulter, dass ihr helfen könnt, Leute etwas anzurichten. Gut, dann haben wir hier noch eine Frage.
35:41
Chagun, auch für QGIS-Map-Server, ich nehme an, ob man den da irgendwie einbinden kann? Grundsätzlich kann man mehr oder weniger alle WMS oder jeden WMS-Server einbinden und dementsprechend kann man das auch mit den Diensten, die jetzt aus dem QGIS-Map-Server kommen, kann das auch funktionieren, bzw.
36:00
wird das auch funktionieren. Das heißt, die kann man auch einbinden. Super. Ja, dann sind wir durch die Fragen durch. Vielen Dank nochmal Daniel und Mark für den Vortrag, Daniel, für die Fragen, die du jetzt noch schnell beantwortet hast.