[Epic] Destination-API im ZSD

Why

Aktuell gibt es die Self-Service API, welche für die Verwaltung von Destinationen genutzt werden kann. Diese , als auch weitere Funktionalitäten in der direkten Frontend/Backend Kommunikation werden ebenfalls von dem Self-Service-Portal genutzt und werden auch vom Team Self-Service-Portal weiterentwickelt.

Im Hintergrund nutzen aber die Funktionalitäten sehr stark die als internal markierten Endpunkte des Zustelldienstes. Auch gibt es nur sehr wenige Zusatzdaten, die nicht in der Zustelldienst DB, sondern in der SSP-DB gespeichert werden (z.B. Owner).

Die damit verbundenen Herausforderungen sollen im Rahmen dieses Epics beseitigt werden.

Goal

Die vom Team Zustelldienst neue Destination API soll die Self-Service API, als auch die internal Endpunkte im ZSD ablösen und die komplette Backend-Kommunikation des SSP unterstützen. Ebenfalls sollen alle Funktionalitäten für die Nutzer direkt über die Destination API nutzbar gemacht werden.

Links, Notes, Remarks

Stories

1. Übernahme der Daten aus dem SSP

2. Anlage von Clients

   • aus Epic #197 (closed) Destination API darf nur Sender anlegen, wenn sowohl den AVVs als auch den Nutzungsbedingungen zugestimmt wurde
   • #1572 (closed)

3. Übernahme der Endpunkte des Self-Service API (as-is)

4. Vereinheitlichung serviceType vs. service #499

5. Anpassung bestehender Logik

   • Zuordnung User zu Client / Destination
   • Name der Destination (inkl. Änderung des Namens)
   • Anpassung Exporte für Nutzungsstatistiken

6. Bereitstellung neuer Endpunkte (auf Basis der direkten Backend/Frontend-Kommunikation)

7. Migrations- & Deploymentkonzept

   • Destination API ist als neues Doku Element verfügbar (eigene Versionierung von submission und destination)
   • deprecated (grundsätzlich ist es einem breaking change gleichzustellen - ggf. können wir in Abstimmung mit den Usern die Self-Service API aber früher abschalten, ansonsten noch parallelbetreb sicherstellen)

8. Deaktivierung / Umbau Self-Service API

   • falls wir es noch eine Zeit lang betreiben müssen, sollten wir es auf den Aufruf der neuen Endpunkte umstellen ( https://git.fitko.de/fit-connect/planning/-/issues/1565)

9. Umstellung des SSP auf reine Destination API Kommunikation (TEAM SSP) - #1279 (closed)??

10. Anpassung und Verfeinerung Testcases

• inkl. Identifikation von Arbeitspaketen, die zukünftig überarbeitet werden müssen

11. Dokumentation & Videos
12. Neue Domains: #2047 (closed)

Abgrenzung

• #1192 (closed) EPIC Keycloack inkl. Nacharbeiten beim Zugriff auf das Token [TEAM SSP]
  • wird vorab vom Team SSP umgesetzt
• #1230 (closed) EPIC Limit Destination [TEAM ZSD]
  • wird vorab vom Team ZSD umgesetzt
• #915 (closed) ELSTER + Accountverwaltung [TEAM SSP]
  • eigentlich keine Schnittmengen zu diesem EPIC (nur fachlich)
• #197 (closed) EPIC Teamfunktionalität
  • wird vorab vom Team SSP umgesetzt

Acceptance criteria

1. Alle Informationen zu Clients sind in der ZSD-DB und nicht mehr in der SSP-DB
2. Alle Informationen zu Destinations sind in der ZSD-DB und nicht mehr in der SSP-DB
3. Zuordnung Client zum Owner ist in der ZSD-DB
4. Self-Service API ist abgeschaltet / deprecated
5. Alle Funktionalitäten sind über die neue Destination API im ZSD erreichbar
   • verfeinert am 16.4: Unterschied zwischen den Versionen im Dashboard, va/info endpunkt einarbeiten
6. Dokumentation ist aktualisiert
7. Video zur Nutzung der Self-Service API ist erstellt
8. Definition of Done was checked.

Potential follow-up activities

• Umsetzung Destination API in den SDKs
• Name der Behörde und des Verfahrens in der destination angeben
• Umstellung auf multiple Zustelldienste prüfen
• Prüfen, welche Punkte aus #1278 noch relevant und offen sind
• Prüfung und Erweiterung der Testabdeckung

Open questions