Routing API Testsystem ermöglichen

Warum machen wir das?

Als Entwickler:in,

möchte ich, dass mir die Sandbox- / Testumgebung auch eine Testung der Routing API für meine Testfälle ermöglicht,

weil ich bspw. als Entwickler eines empfangenden Systems für eine bestimmte Fachlichkeit mit dem sendenden System den vollständigen Ablauf einschließlich Routing durchtesten will. Dafür möchte mittels eigener Zustellpunkte oder generischer Testzustellpunkte testen können.

Relevante Links

Funktionale Anforderungen

1. Für die Routing API wird eine Testumgebung bereitgestellt, in die Adressierungsinformationen und Destinationinformationen aus den Testumgebungen des Zustelldienstes und des SSP bereitgestellt werden.
   • Diese Routing API stellt sicher, dass es zu keinen Doppelantworten kommt, weil im SSP identische Leika/Region Einträge erstellt werden. Dies ist als wahrscheinlich anzunehmen, da keine redaktionelle Kontrolle über eine FIM Leistungssystem vorliegt.
     • Dies kann bspw. darüber sichergestellt werden, dass vor dem API Pfad in der Testumgebung eine Destination-ID als dynamischer Parameter vorgesehen wird: https://testing.routing-api/{destinationId}/routes oder https://testing.routing-api/{destinationId}/areas ---> Dieser Parameter ist nicht Teil der Spec und sollte von einem externen Entwickler als Teil der Hostadresse verstanden werden. Siehe Akzeptanzkriterium 4
2. Der Routingdienst in der Testumgebung kann die Destinationinformationen statt von einem DVDV Testsystem auch vom Zustelldiensttestsystem über die Submission API abrufen.
3. Die Testumgebung des Self-Service-Portal stellt über eine einfache Schnittstelle dem Routing Dienst die signierten Adressierungsinformationen einer Destination (Siehe #175 (closed)) bereit.
   • Diese kann ggf. auch offiziell als API-Spec dokumentiert werden
4. (Irgendwas zum Thema generische Zustellpunkte. Ggf. auch nicht Teil der Story.)

Nicht-funktionale Anforderungen

• Dokumentation:
  • Prozessänderungen sind für Nutzer der Anwendung dokumentiert
• Code:
  • Code Qualität & Formatierung eingehalten
  • Commits orientieren sich an Conventional Commits
  • Bei neuen Dateien sind Lizenz- und Urheberrechtshinweise gemäs der REUSE-Spezifikation vorhanden
• Leistung:
  • Code ist in einer Testinstanz deployt
  • Es gibt keine bekannten Bugs
• Testen:
  • Alle funktionale Anforderungen sind durch Testfälle abgedeckt

Durchführungsplan

• ...
• ...
• ...