Webapplikation zur Pflege der Metainformationen der GDI-SO (Spatial Infrastructure Metadata Interface)
Die SIMI-Images liegen auf Docker-Hub: https://hub.docker.com/r/sogis/simi
Der Grossteil der Funktionalitäten benötigt einzig einen DB-Connect auf die Meta-DB. Für diese sind die Umgebungsvariablen CUBA_DATASOURCE_* zu setzen sowie CUBA_AUTOMATICDATABASEUPDATE=true, damit das (leere) Schema mit den notwendigen Tabellen initialisiert wird.
ZU BEACHTEN Das Framework kann beim Starten nur im Schema public automatisch die Tabellen anlegen. Zu schnellen Ausprobieren also im Schema "public" arbeiten.
Siehe doc/docker-compose.yml als Beispiel einer Minimal-Konfiguration.
Variablen können im Framework an verschiedensten Stellen konfiguriert werden (ENV, *.properties, Sys-Tabellen, ...). Damit schnell erkennbar wird, welche Variable zur laufzeit wie konfiguriert ist, werden die Werte beim Startup (verschlüsselt) in Log-Output geschrieben.
...
... - SIMI Configration values
...----------------------------------------------------
... - 'CUBA_DATASOURCE_JDBCURL': [jdbc:postgresql://localhost:5432/postgres?currentSchema=public]
... - 'CUBA_DATASOURCE_PASSWORD': [Secret value with 8 digits]
... - 'CUBA_DATASOURCE_USERNAME': [postgres]
...
Die Versionierung folgt dem Pattern [major].[minor].[revision]
Auslöser für Versions-Inkrementierungen:
- major: Umfangreiche Erweiterung des Metamodells und / oder der Funktionalität
- minor: Breaking Change des Metamodells für die Trafos oder Änderung der notwendigen ENV-Variablen.
- revision: (Kleinere) funktionale Anpassung
Als Nummer der revision wird automatisch die "Build-Nummer" der github action übernommen. Major und minor werden bewusst von der Entwicklung gesetzt.
Die Konfiguration erfolgt mittels der folgenden Umgebungsvariablen:
- Konfiguration der Verbindung auf die Meta-DB:
- CUBA_DATASOURCE_USERNAME: Benutzername der DB-Connection. Bsp: "postgres"
- CUBA_DATASOURCE_PASSWORD: Passwort der DB-Connection. Bsp: "postgres"
- CUBA_DATASOURCE_JDBCURL: Jdbc Url für das Verbinden auf die DB (inklusive Info welches Schema). Bsp: jdbc:postgresql://localhost:5432/simi?currentSchema=simi.
Bemerkung: Host, Port, ... sollen nicht mehr separat angegeben werden, da in der jdbc URL enthalten.
- Konfiguration der Authentifizierung (LDAP, ...):
- CUBA_WEB_LDAP_ENABLED: LDAP Authentifizierung aktiv? Bsp: TRUE / FALSE
- CUBA_WEB_LDAP_URLS: LDAP URL. Bsp: LDAP://192_168_1_1:389
- CUBA_WEB_LDAP_BASE: Distinguished Name, auf welchen gebunden wird. Bsp: OU=EMPLOYEES,DC=MYCOMPANY,DC=COM
- CUBA_WEB_LDAP_USER: Benutzer, mit welchem verbunden wird. Bsp: CN=SYSTEM USER,OU=EMPLOYEES,DC=MYCOMPANY,DC=COM
- CUBA_WEB_LDAP_PASSWORD: Passwort, mit welchem auf das LDAP verbunden wird.
- CUBA_WEB_LDAP_USERLOGINFIELD: Name des Attributes im LDAP-Verzeichnis, welches gegen den Login-Namen verglichen wird. Bei AD häufig "sAMAccountName".
- CUBA_WEB_REQUIREPASSWORDFORNEWUSERS: Muss bei LDAP Auth auf false gesetzt sein, damit kein "Kuba Passwort" für den Benutzer verlangt wird.
- CUBA_WEB_STANDARDAUTHENTICATIONUSERS: Komma getrennte Liste der Benutzer, welche trotz aktiviertem LDAP-Login mittels Standard (cuba) Login authentifiziert werden.
- Konfiguration der URL des Schemareaders:
- SIMI_SCHEMAREADER_URL: Url, auf welcher der Schemareader erreichbar ist. Bsp: "http://localhost/schemareader"
Hinweis: Die Namen der Datenbanken in der SIMI-DB müssen mit dbs.key in der Schemareader-Konfig übereinstimmen.
- SIMI_SCHEMAREADER_URL: Url, auf welcher der Schemareader erreichbar ist. Bsp: "http://localhost/schemareader"
- Konfiguration der Suche in den GRETL-Repos (Anzeige der Abhängigkeiten):
- SIMI_GITSEARCH_URL: Url, auf welche die Git-Suchen abgesetzt werden. Bsp: "https://api.github.com/search/code"
- SIMI_GITSEARCH_REPOS: Liste aller zu durchsuchenden Git-Repos, mittels "," getrennt. Bsp: "sogis/gretljobs,oereb/jobs"
- SIMI_GITSEARCH_TOKEN: Github API Token (für die Tabellen-Suche in den GRETL-Dateien).
- Konfiguration Oauth-Tokenausgabe für die Publikations-Notifikation vom Publisher (GRETL)
- CUBA_REST_CLIENT_ID: Benutzername für die Tokenausgabe
- CUBA_REST_CLIENT_SECRET: Passwort für die Tokenausgabe mit Präfix. Vor dem Passwort muss der Präfix {noop} stehen.
- Siehe zur Service-Konfiguration auch das folgende Kapitel...
Für die Berechtigung zur Nutzung des Clients müssen zwei Konfigurationen vorgenommen werden:
- Setzen der beiden Umgebungsvariablen CUBA_REST_CLIENT_*
- Entwicklung CUBA_REST_CLIENT_ID=notifier;CUBA_REST_CLIENT_SECRET={noop}pass
- Erstellung und Berechtigung des Benutzers "gretl" via Admin-GUI
- Die Berechtigung muss beinhalten:
- Die bestehende Rolle rest-api-access
- Eine selbst erstellte Rolle für vollen Zugriff auf simiTheme_PublishedSubArea und lesenden Zugriff auf alle SIMI-Entitäten (Tabellen) im SecurityScope "REST".
- Die Berechtigung muss beinhalten:
Im Docker-Image sind drei Logger vorkonfiguriert:
- ROOT-Logger mit level "ERROR"
- Logger "com.haulmont" (= Cuba Framework) mit level "WARN"
- Logger "ch.so.agi.simi" mit level "INFO"
Bei Bedarf kann der Loglevel der vorkonfigurierten Logger verändert werden:
- Zur entsprechenden Adminmaske navigieren: CUBA-Admin -> Server Log
- In der Maske im Reiter "Options" den Logger im Dropdown wählen und den Loglevel setzen / abfragen
- Alternativ könne auch weitere Logger erstellt werden, Zum Beispiel "com.haulmont.rest" falls dieses temporär mit anderem Level geloggt werden soll.
Bitte beachten: Der ROOT-Logger sollte nicht auf Level DEBUG oder noch detaillierter gestellt werden, da dies massiv viel logging auslöst.
Zu Dokumentation und Simulation des Publisher mittels CURL siehe: doc/gretl_publisher.md
Falls eine Fragestellung vor der Verfügbarkeit der Admin-Masken analysiert werden muss, kann der Loglevel in der Datei [repo root]/webapp/docker/image/uber-jar-logback.xml angepasst werden (Bedingt neuen Build des Image).
Bitte dazu den Applikationsverantwortlichen beiziehen.
Siehe Ordner schema
Beschreibung der Inhalte der Unterordner von /webapp sowie des Custom-Codes siehe Entwicklungs-Dokumentation
Diese ist im Dok-Repo zuhause: Benutzer-Dokumentation.