Getting started
Formatter einrichten
Im Projekt verwenden wir checkstyle
und spotless
um für einen möglichst einheitlichen Codestyle zu sorgen. Dazu haben wir Regeln definiert. Diese Regeln und deren Hinterlegung in der jeweiligen IDE ist hier beschrieben.
Zusammenspiel IDE mit Docker
Services und Ports
Übersicht über die Services und auf welchen Port sie im Standard lauschen:
IMPORTANT
Diese Ports werden sowohl in der IDE als auch in Docker verwendet. Beachten Sie, dass somit nur eine Instanz eines Services gleichzeitig laufen kann.
Service | Port |
---|---|
Admin | 8209 |
Auth | 8100 |
Basisdaten | 8205 |
Briefwahl | 8202 |
Broadcast | 8200 |
EAI | 8300 |
Ergebnismeldung | 8208 |
Infomanagement | 8201 |
Monitoring | 8206 |
Vorfälle und Vorkommnisse | 8204 |
Wahlvorbereitung | 8203 |
Wahlvorstand | 8207 |
Profile
Profilname | Beschreibung |
---|---|
db-h2 | Als Datenbank wird eine embedded H2 im Service verwendet. |
db-oracle | Als Datenbank wird eine Oracle Datenbank verwendet. Im Standard wird die DB-Datenbank aus dem Stack (Docker) verwendet. |
db-dummydata | Es werden Flyway-Files mit Dummydaten für die Datenbank mit verwendet. |
no-security | Die Prüfungen der Authentifizierung und Authorisierung werden deaktiviert. |
dummy.nobezirkid.check | Deaktiviert die Prüfung, dass Anfragen für einen bestimmten Wahlbezirk (wahlbezirkID), nur von dem User des Wahlbezirkes erfolgen dürfen |
dummy.clients | Es erfolgt keine Kommunikation mit fachlichen Services weil Dummy-Implementierung anstatt von Clients verwendet werden. |
standalone | Der Service arbeitet eigenständig. Inkludiert dummy.clients, dummy.nobezirkid.check und db-h2. |
local | Der Service läuft lokal. Entsprechend wird der Port des Services definiert um nicht in Konflikt mit anderen Service zu kommen. |
plainTextLogging | Logmeldungen werden als Text ausgegeben. Ohne dieses Profil sind die Logmeldungen ein JSON-Objekt. |
Benutzer
Name | Passwort | Beschreibung |
---|---|---|
wls_test | test | Ein Benutzer ohne weitere Rechte |
wls_all | test | Ein Benutzer mit allen Rechten |
wls_all_bwb | test | Ein Benutzer mit allen Rechten mit der WahlbezirksArt BWB (Briefwahl) |
wls_all_uwb | test | Ein Benutzer mit allen Rechten mit der WahlbezirksArt UWB (Urnenwahl) |
CAUTION
Für die Anmeldung am WLS muss der User die Rolle WLS_WAHLVORSTAND
haben. Für die Anmeldung am Admintool muss der User die Rolle MONITORING_HELPDESK
haben.
Datenbank
Der Zugriff auf die Oracle-Datenbank über die IDE ist gemäß dieser Anleitung einzurichten.
Runconfigurations
Für die Spring-Boot Microservices werden für IntelliJ Runconfigurations zur Verfügung gestellt. Diese sind gruppiert nach der Art der Datenbank und ob die Security aktiviert ist oder nicht.
Eine Übersicht über die Profile gibt es hier.
TIP
Wenn es Updates an den Runconfigurations gab, die gefetcht wurden, ist es notwendig IntelliJ neu zu starten.
Starten des Frontends
Standardmäßig wird das Frontend über den Befehl "dev": "vite"
in der package.json
-Datei gestartet.
Nachdem das Frontend in der IDE und das ApiGateway über Docker gestartet wurde, kann es über http://localhost:8400/
aufgerufen werden. Allerdings befindet sich die Oberfläche dann in einer Ladeschleife und man sieht nur einen flackernden Bildschirm. Um diese Schleife während der Entwicklung zu umgehen, gibt es zwei Möglichkeiten:
1. Starten über das Gateway + Authentifizierung
Eine Möglichkeit, die Ladeschleife zu umgehen, ist es, sich lokal mit einem der User anzumelden. Nachdem das Frontend über die IDE gestartet wurde, muss die URL http://localhost:8083/
mit dem Port 8083
aufgerufen werden, um auf die Login-Seite zu kommen. Nach der Anmeldung bleibt man auf dem Port 8083
, wird aber vom Gateway zum Frontend weitergeleitet und die Ladeschleife ist weg.
NOTE
Der Anmeldevorgang muss jedes Mal wiederholt werden, sobald das ApiGateway neu gestartet wird.
2. no-security
-Profil
Die zweite Möglichkeit ist es, das ApiGateway mit dem no-security
-Profil zu starten. Dazu muss im /stack/docker-compose.yml
File beim Service refarch-gateway unter environment in der Zeile - SPRING_PROFILES_ACTIVE=hazelcast-local
das Profil no-security
hinzugefügt werden. Damit die Änderung wirksam wird, sollte der Container in Docker einmal komplett gelöscht und über das docker-compose.yml
File neu gestartet werden.
WARNING
Bei dieser Variante ist es wichtig, dass die Änderung im docker-compose.yml
File nicht gepusht wird, weil alle anderen Container mit security laufen und das no-security
-Profil nur für die Entwicklung benötigt wird.