From 19fb503b2a02beb6731ac241024dcc3375bfad33 Mon Sep 17 00:00:00 2001 From: PublicServiceGuy <alexander.hoose@fitko.de> Date: Tue, 31 Mar 2020 00:17:00 +0200 Subject: [PATCH] =?UTF-8?q?=C3=9Cberarbeitung=20API=20=C3=9Cbersicht?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/README.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/README.md b/docs/README.md index 8199fe66..2ee56539 100644 --- a/docs/README.md +++ b/docs/README.md @@ -60,17 +60,17 @@ Für den PoC werden zwei zentrale Komponenten bereitgestellt: - **API-Gateway:** Das API-Gatway regelt den Zugriff auf die API (Authorisierung, Rate-Limiting, Sicherheitsüberprüfungen, etc.) des XFall-Zustelldienstes und stellt zusammen mit der angebundenen IdM-Komponente die Authentifizierung für den API-Zugriff bereit. Für einen API-Client ist das API-Gatway in der API-Nutzung nicht direkt sichtbar. #### Ablauf -Die Integrationsarchitektur sieht vor, dass eine empfangende Behörde oder ein Dienstleister (bspw. eine kommunales Rechenzentrum) über die `Application Subscriber API` initial eine Zustellpunkt mit einer eindeutigen `destination-id` anlegt. +Die Integrationsarchitektur sieht vor, dass eine empfangende Behörde oder ein Dienstleister (bspw. eine kommunales Rechenzentrum) über die `Application Subscriber API` initial einen Zustellpunkt mit einer eindeutigen `destination-id` anlegt. -Diese `destination-id` wird im Rahmen des PoC mit der Antragssenderseite bilateral ausgetauscht bzw. über einen vereinbaren Kanal veröffentlicht. Diese ID wird dann durch die Anwendung auf der Senderseite in der `Application Sender API` genutzt, um die korrekte Stelle zu adressieren und den Antrag beim Zustellpunkt abzugeben. Die empfangende Behörde oder der Dienstleister können dann mit beliebigen technischen Systemen diesen Antrag beim angelegten Zustellpunkt abholen. +Diese `destination-id` wird im Rahmen des PoC mit der Antragssenderseite bilateral ausgetauscht bzw. über einen vereinbaren Kanal veröffentlicht. Diese ID wird dann durch den Sender in der `Application Sender API` genutzt, um die korrekte Stelle zu adressieren und den Antrag beim entsprechenden Zustellpunkt abzugeben. Die empfangende Behörde oder der Dienstleister können dann mit ihren Systemen diesen Antrag abholen. #### Langfristige Vision -Die Integrationsarchitektur wird im Rahmen des PoC um einige zentrale Aspekte vereinfacht, die für die zukünftige Integrationsarchitektur fest eingeplant sind: -- **Nutzung von Zuständigkeitsfindern:** Langfristig ist angedacht, die `destination-id` über die bestehenden und etablierten Zuständigkeitsfindern von Bund und Ländern und deren Redaktionsprozesse zu veröffentlichen. Damit steht ein skalierbarer Ansatz bereit, bei dem Antragsdienste in Echtzeit während der Antragsstellung die `destination-id` der fachlich und örtlich zuständigen Stelle beim einem Zuständigkeitsfinder ermitteln können. Durch diesen Ansatz sind keine aufwendigen bilateralen Absprachen in der Entwicklung mehr notwendig, sondern die Antragsdienste können einen universellen zuständigkeitsbasierten Ansatz auf Basis föderaler Basisinfrastukturen nutzen! +Die Integrationsarchitektur wird im Rahmen des PoC um einige zentrale Aspekte vereinfacht, welche für die zukünftige Integrationsarchitektur fest eingeplant sind: +- **Nutzung von Zuständigkeitsfindern:** Langfristig ist angedacht, die `destination-id` über die bestehenden etablierten Zuständigkeitsfindern von Bund und Ländern zu veröffentlichen. Damit stünde ein skalierbarer Ansatz bereit, bei dem Antragsdienste während der Antragsstellung die `destination-id` der fachlich und örtlich zuständigen Stelle beim Zuständigkeitsfinder ermitteln können. Durch diesen Ansatz sind keine aufwendigen bilateralen Absprachen während der Entwicklung mehr notwendig, sondern die Antragsdienste können einen universellen zuständigkeitsbasierten Ansatz auf Basis bestehender föderaler Basisinfrastukturen nutzen!  - **Standardisierte XTA-Einbindung:** Mit XTA steht ein in vielen Teilen der Verwaltung etablierter Standard bereit, um standardisiert Transportverfahren anzubinden, welche die eigentliche Übertragung von Fachdaten über diverse Protokolle und Kommunikationsinfrastrukturen für das Fachverfahren übernehmen. Während es schon im PoC prinzipiell möglich sein sollte, technische Intermedäre für die XFall RESTful API Anbindung per XTA-SOAP Webservice anzusprechen, wird zukünftig eine vollumfängliche Unterstützung alle XTA Bestandteile (wie bspw. Reports) angestrebt. -- **Anbindung von Servicekonten und Antragsmanagementkomponenten:** Zukünftig soll der XFall-Zustelldienst alle antragsrelevenaten Daten (Kopien der Antragsdaten und Statusinformationen) bei definierten Ereignissen (Abgabe beim Zustelldienst und Abholung am Zustellpunkt) in den Hohheitsbereich des Antragsstellers übermitteln und damit Antragsdienst und Fachverfahren von dieser Querschnittsaufgabe entlasten. Hierfür ist angedacht, die zukünftig verfügbaren interoperablen Postfächer als standardisierten Übertragsweg in den Hohheitsbereich des Antragsstellers zu nutzen. +- **Anbindung von Servicekonten und Antragsmanagementkomponenten:** Zukünftig soll der XFall-Zustelldienst alle antragsrelevenaten Daten (Kopien der Antragsdaten und Statusinformationen) bei definierten Ereignissen (Abgabe beim Zustelldienst und Abholung am Zustellpunkt) in den Hohheitsbereich des Antragsstellers übermitteln und damit die Antragsdienste und Fachverfahren von dieser Querschnittsaufgabe entlasten. Hierfür ist angedacht, die zukünftig verfügbaren interoperablen Postfächer als einen standardisierten Übertragsweg in den Hohheitsbereich des Antragsstellers zu nutzen.  -- GitLab