| Kommunikationsbeziehung | Eingabe | Ausgabe |
|---|---|---|
Durchführung der Trainings |
Lösung des Nutzers via Webapp |
Lösung richtig (ja/nein) |
Auswertung der Daten |
- |
Statistiken und Auswertungen zu Engagement, Scores, … der Teams |
Anonymisierung/Pseudonymisierung der Daten nach DSGVO |
- |
Sämtliche Daten des Nutzers nach DS-GVO löschen/pseudonymisieren |
Export der Daten nach DSGVO |
- |
Sämtliche Daten des Nutzers nach DS-GVO im JSON, bzw. CSV Format |
Das Frontend bezieht sämmtliche Daten via HTTP vom Backend.
Das Backend stellt HTTP Endpunkte bereit (REST ähnlich bzw. REST konform), in welchem es den Zustand aus der Datenbank ausliefert, bzw. eigen errechneten Zustand (z.B. Fortschrittsprozentzahlen) zur Verfügung stellt.
Die Datenbank wird zum persistieren aller Daten genutzt. Sämtlicher Zustand der Applikation ist hier gelagert.
Zum einen gibt es die User/Training API, auf welcher alle "regulären Anfragen" des Trainingfrontends im Rahmen eines Trainings behandelt werden.
Zum anderen gibt es eine API, welche die administrativen Aufgaben die im Vorfeld und während/nach dem Training anfallen behandelt (z.B. Reporting der Scores einzelner Teams/Mitarbeiter, das Anlegen von Teams/Mitarbeitern, …).
Beide APIs werden getrennt voneinander abgebildet, weil sie von unterschiedlichen Frontends angefragt werden und unterschiedliche Sicherheitsberechtigungen benötigen.
Alle API Operationen sind mindestens als REST-ähnliche Anfragen mit JSON als Serialisierungsformat und HTTP als Kommunikationsmedium umzusetzen, wenn möglich jedoch als vollständig REST konforme CRUD API. Alle API Endpunkte sind in einem Swagger zu dokumentieren (folgt).