## Warum? Wenn über FIT-Connect verschiedene Services innerhalb einer Destination akzeptiert werden, kann das empfangende Fachverfahren in einer Destination zwei (oder mehr) unterstützte Services angeben. In der API ist dies über das Feld `services` abgebildet. Hier können prinzipiell beliebig viele Services hinterlegt werden: https://docs.fitko.de/fit-connect/docs/apis/submission-api/#get-/v1/destinations/-destinationId- ## Relevante Links und Bemerkungen ## Akzeptanzkriterien 1. [x] Über das UI können mehrere Services pro Destination angegeben werden. 1. [x] Für einen Service können mehrere **Regionen** (`regions`) angegeben werden. 1. [x] Für einen Service können mehrere **Fachdatenschema-URIs** (`schemaUri`) angegeben werden. 1. [x] Das UI erkennt die in einer Destination hinterlegten Services und ermöglicht eine Bearbeitung der Services für bereits bestehende Destinations (Ist-Stand wird im Editiermodus dargestellt). 1. [x] Es ist möglich, Services, Regionen und Schemata zu entfernen, sofern jeweils mindestens ein Eintrags verbleibt 2. [x] Das SSP-Backend wird insoweit angepasst, wie es für die korrekte Funktionalität der UI nötig ist. 3. [x] Im SSP-Backend findet kein Caching der Zustellpunkt-Informationen statt (Datenquelle ist immer die Submission API). 4. [ ] Es existiert ein Integrationstest, der die korrekte Hinterlegung der Daten im Zustelldienst prüft. Es wird nur das SSP-Backend getestet (keine Frontend-Tests mit Cypress). 5. [x] (neu) Die einzelnen Services lassen sich im UI collapsen/expanden 6. [x] (neu) Die Überschrift der Services enthält die urn (in Klammern nach der bisherigen Ü.) ## Durchführungsplan (vom Entwickler bei Storyplanung auszufüllen) - [ ] Abstimmung mit @Jonas_Groeger, wie aktuell Integrationstests im Self-Service-Portal durchgeführt werden. - [ ] ... - [ ] [Definition of Done](https://wiki.fit-connect.fitko.dev/de/PM_PUBLIC/DefinitionOf#done-f%C3%BCr-api-spezifikationen) wurde geprüft