[Epic] Verbesserung des Routings in der Test-Umgebung

Warum

Das Zusammenspiel von Routingdienst, PVOG und DVDV-MS ist kompliziert und vor dem Hintergrund der Art und Weise, wie das für die FIT-Connect-Testumgebung genutzte Demo-PVOG gepflegt wird, fehleranfällig. Es kommt immer wieder vor, dass ein zukünftiger FIT-Connect-Nutzer bei einem Aufruf des Routingdienstes nicht den erwarteten Zustellpunkt erhält. Im Zustelldienst liegen jedoch in jedem Fall durch die vom jeweiligen Zustellpunkt unterstützten Verwaltungsleistungen mit deren Leistungs-URN und den dieser zugeordneten Regionen Informationen vor, die ein Routing ermöglichen sollten.

Ziel

Dadurch, dass der Routingdienst in der Testumgebung zusätzlich auch die Informationen aus dem Zustelldienst verwendet, kommt es nur noch in Ausnahmefällen vor, dass die Suche nach einer Route zu keinem Ergebniss führt.

Links, Hinweise, Bemerkungen

Der Zustelldienst bietet dem Routingdienst eine Such-API an, über die der Routingdienst aktive Zustellpunkte anhand von Leistungskennung (LeiKa-ID) und ARS ermitteln kann. Der Routingdienst greift zusätzlich zu PVOG und DVDV auch auf die aus dem Zustelldienst stammenden Informationen zu und führt die über PVOG und FIT-Connect-Zustelldienst gefundenen Routen zusammen, wobei die aus dem PVOG stammenden Routen Vorrang haben. Um kenntlich zu machen, dass die Route nicht im PVOG gefunden wurde, wird ein zusätzliches optionales Feld eingeführt, dass über den Ursprung der Daten Auskunft gibt: origin (pvog, infodienste, fit-connect)

Suche (folgende Bedingungen müssen zutreffen):

• LeiKa-ID der Verwaltungsleistung des Zustellpunktes entspricht gesuchter LeiKa-ID. UND
• Gesuchter ARS beginnt mit einem der betreffenden Verwaltungsleistung des Zustellpunktes zugeordnetem ARS

Der Zustelldienst könnte die Daten liefern, die zu einem Zustellpunkt auch über die Destination-API verfügbar sind. Ein vom Routingdienst zurückgegebenes Route-Objekt umfasst minimal destinationId und destinationSignature (vgl. Routing API. Die DestinationSignature wird derzeit noch vom SSP generiert. In Zukunft soll das der Zustelldienst übernehmen (vgl. #2379). Daher wird für die für die Verbesserung des Routings in der Test-Umgebung benötigte DestinationSignature vom ZSD generiert, was als Basis für das später umgesetzte Epic #2379 dienen kann.

⚠ Die Umsetzung darf aus Sicherheitsgründen nur auf der Testumgebung erfolgen. HIntergrund ist: Die Hinterlegung der Zuständigkeiten in den FIM-Leistungs-Redaktionsystemen der Länder stellt sicher, dass nur die von den Ländern berechtigten Personen entsprechende Zuständigkeiten im jeweiligen Redaktionssytstem pflegen können (die Infos aus den FIM-Leistungs-Redaktionsystemen werden anschließend im PVOG agreggiert). Im Zustelldienst hingegen können ohne vorherige fachliche Berechtigungsprüfung beliebige Zuständigkeiten hinterlegt werden.

Stories

Akzeptanzkriterien

1. ZSD bietet eine API für den RTD mit OAuth an, über die DestinationID, DestinationSignature, DestinationParameter und DestinationParameterSignature von zu LeiKa-ID und ARS passenden aktiven Zustellpunkten zurückgegeben werden. Die dafür benötigte DestinationSignature wird in Vorgriff zu #2379 vom ZSD generiert.
2. RTD sucht ggf. als Fallback über die ZSD-Daten und gibt den so gefundenen Zustellpunkt als origin "fit-connect" an.[ #2830 (closed)]
3. Es ist sichergestellt, dass die Nutzung des ZSD als Fallback ausschließlich in der Testumgebung stattfindet. [ #2830 (closed)]
4. ...
5. Definition of Done wurde überprüft.

Mögliche Folgeaktivitäten

Offene Fragen