From 7571c02a5fdf83cbddc6029d684619b324717a9f Mon Sep 17 00:00:00 2001 From: "Alexander.Hoose@fitko.de" <Alexander.Hoose@fitko.de> Date: Mon, 3 Aug 2020 15:28:52 +0200 Subject: [PATCH] Readme und Use Case Artikel angepasst. --- docs/3_Use_Cases_der_API.md | 10 ++--- docs/README.md | 73 +++++++------------------------------ 2 files changed, 19 insertions(+), 64 deletions(-) diff --git a/docs/3_Use_Cases_der_API.md b/docs/3_Use_Cases_der_API.md index ca4e1aba..491cfb30 100644 --- a/docs/3_Use_Cases_der_API.md +++ b/docs/3_Use_Cases_der_API.md @@ -1,14 +1,14 @@ -# Anwendungsfälle +# Durch die XFall API unterstützte Anwendungsfälle -## Überblick über die Anwendungsfälle +## Gesamtüberblick der Anwendungsfälle und beteiligten Fachsysteme  -## Anwendungsfälle für den Sender +## Anwendungsfälle für antragssendende Systeme (Sender) ### Antrag bei einem Zustellpunkt abgeben -**Vorbedingung:** Es muss zuvor die `destination-id` eines gültigen Zustellpunkts ermittelt worden sein. Im Rahmen des PoC erfolgt die Übermittlung mittels bilateraler Absprachen und Kanäle zwischen dem Subscriber und Sender. +**Vorbedingung:** Es muss zuvor die `destination-id` eines gültigen Zustellpunkts ermittelt worden sein. Im Rahmen des PoC erfolgt die Übermittlung mittels bilateraler Absprachen und Kanäle zwischen dem Subscriber und Sender. Zukünftig soll diese Ermittlung über die API eines Zuständigskeitsfinders für die gewünschte Verwaltungsleistung und den Ortsbezug erfolgen, wenn die `destination-id` in den dortigen Zuständigkeitsinformation durch die zuständige Stelle hinterlegt wurde. **Ziel:** Alle Bestandteile des Antrags werden in den Abholbereich des addressierten Zustellpunkts übergeben und liegen dort zur Abholung durch den Subscriber bereit. @@ -24,7 +24,7 @@ **Beschreibung:** Der Sender fragt per GET über die `application-id` den `status` der Antrags ab. Als Antwort bekommt dieser den aktuellen Status sowie die Statushistorie übersendet. Diese Statusübergänge sind über standardisierte Codes (`incomplete`, `queued`, `forwarded`, `delivered`) definiert. -## Anwendungsfälle für den Subscriber +## Anwendungsfälle für antragsempfangende Systeme (Subscriber) ### Zustellpunkt einrichten diff --git a/docs/README.md b/docs/README.md index 77f44c56..b71d6f18 100644 --- a/docs/README.md +++ b/docs/README.md @@ -1,76 +1,31 @@ # Überblick über die XFall API -Willkomen auf der API Dokumentation für die XFall RESTful API. Zusammen mit der föderalen Integrations- und Entwicklungsplattform ermöglicht die XFall RESTful API Lösungsverantwortlichen und Entwicklern von OZG-Verfahren, ihre Anwendungen schnell und wirtschaftlich in medienbruchfreie Antragsprozesse zu integrieren. +Willkomen auf der API Dokumentation für die XFall RESTful API von FIT-Connect. Die XFall API baut auf dem bestehenden IT-Planungsrat Standard XFall auf und bietet Lösungsverantwortlichen antragssendenen und antragsempfangenden Systemen eine einfache Möglichkeit, ihre Software schnell und wirtschaftlich in länder und ebeneübergreifende Antragsprozesse zu integrieren. -Das zentrale Ziel der XFall RESTful API: -> Lösungsverantwortliche und Entwickler werden von wiederkehrenden Integrationsherausforderungen im Antragsprozess entlastet und können wertvolle Kapazitäten darauf fokussieren, Innovationen in der Verwaltung voranzutreiben und nutzerzentrierte Lösungen für Antragssteller und Sachbearbeitern schnell und kostengünstig in die Breite zu bringen! +## Was ist die XFall API und was unterscheidet diese API vom bisherigen XFall Standard? -## Was ist die XFall RESTful API und was unterscheidet diese vom bisherigen XFall Standard? +Die XFall API baut auf den bisherigen Konzepten und Erfahrungen des bestehenden IT-Planungsrats Standards XFall auf. -Die XFall RESTful API baut auf den bisherigen Konzepten und Erfahrungen des bestehenden IT-Planungsrats Standards XFall auf. Die übergreifende Zielstellung von XFall besteht darin, Anträge und Berichte, die aus vorgelagerten Systemen (bspw. Onlineantragsdienste, Fachportale oder Berichtssysteme) erstellt werden, in die unterschiedlichen Systeme der elektronische Verfahrensbearbeitung zu übergeben. +> Die übergreifende Zielstellung des Standards XFall besteht darin, Anträge und Berichte, die aus vorgelagerten Systemen (bspw. Onlineantragsdienste, Fachportale oder Berichtssysteme) erstellt werden, in die unterschiedlichen Systeme der elektronische Verfahrensbearbeitung (bspw. Fachverfahren, DMS) zu übergeben. -Ausgehend von dieser Aufgabestellung, ist die XFall RESTful API auch keine einheitliche API, sondern besteht aus zwei dedizierten APIs für Sender (`Application Sender API`) und Empfänger von Anträgen (`Application Subscriber API`). +Bei der Entwicklung der XFall API wurden viele Konzepte mit Hinblick auf die neuen Erfordernisse des Onlinezugangsgesetzes, der SDG-Verordnung sowie den Anforderungen digitaler Geschäftsmodelle. Technisch setzt die XFall API auf einen leichgewichtigen RESTful-Architekturstil und baut auf der föderalen Antragsübertragungsarchitektur von FIT-Connect auf. -Bei der Entwicklung der XFall RESTful API wurden viele Konzepte mit Hinblick auf die neuen Erfordernisse des Onlinezugangsgesetzes, dem EU-Single Digital Gateway sowie den Anforderungen moderner digitaler Geschäftsmodelle grundlegend weiterentwickelt. Im Vergleich zum bisherigen XFall-Standard, setzt die XFall RESTful API auf einen leichgewichtigen REST-Architekturstil und ergänzt die API um eine einheitliche föderale Integrations- und Entwicklungsinfrastruktur: -- Eine Integrationsplattform, welche die APIs für die Beteiligten bereitstellt und viele Integrationsherausforderungen zentral löst. Die Integrationsplattform folgt dem "Lightweight Messaging Principle", sodass keine Fachlogik im Übermittelungsprozess durch die Integrationsplattform übernommen wird, sondern die Hohheit beim Empfänger liegt und für den Sender die Zustellunglogik transparent. -- Ein Entwicklerportal, da alle Informationen und Ressourcen für Anbindung an die XFall RESTful API bereitstellt. Neben zentral erstellten Informationen und Werkzeugen ,sollen auch bisher dezentral vorliegende Informationen bedarfsgerecht gebündelt und vernetzt werden, sodass für Entwickler eine mühsame Suche kritischer Informationen entfällt. +## Was macht die XFall API? -## In welchem Stand befindet sich XFall RESTful API und wann kann man die API nutzen? +Die XFall API besteht aus zwei getrennt nutzbaren APIs für antragsempfangende Systeme (`Application Subscriber API` sowie eine `Callback` / Webhook Funktion) und antragssendenden Systeme (`Application Sender API`). Diese beiden APIs werden durch einen zentralen Intermediär (`XFall Zustelldienst`) als Angebote angeboten. -Die Entwicklung und Bereitstellung der XFall RESTful API erfolgt im Rahmen eines Proof of Concepts für die geplante föderale Integrations- und Entwicklungsplattform. Der Proof of Concept und das Gesamtvorhaben wird durch die FITKO (https://www.fitko.de) verantwortet. +Ganz grundsätzlich ermöglicht die `Application Subscriber API` den zuständigen antragsempfangenden Stellen, innnerhalb des XFall Zustelldienstes eindeutig über eine `Destination-ID` adressierbare Zustellpunkte zu eröffnen. An diese Zuständigkeitspunkte können beliebigen antragssendene Systemen, die einen Zugriff auf die `Application Sender API` haben, Anträge senden. -Im Rahmen des Proof of Concepts wird es ab dem zweiten Quartal 2020 möglich sein, dass interessierte Organisationen und Projekte einen Zugang zum API-Portal bekommen und eine prototypische Anbindung von Verfahren umsetzen können. +Für diese Zustellpunkte legen die zuständigen Stellen innerhalb alle fachlichen Vorgaben (Zulässige Fachstandards, Verschlüsselung, Datenformate etc.) fest, damit eine medienbruchfreie Weiterverarbeitung gewäl -Die langfristige produktive Nutzung der XFall RESTful API hängt jedoch vom Ausgang des Proof of Concepts und der weiteren Planung der föderalen Integrations- und Entwicklungsplattform ab. +Damit für eine konkrete Verwaltungsleistung und den jeweiligen regionalen Antragsbezug (bspw. Ort der Antragsstellung) der korrekte Zustellpunkt -### Was ist die föderale Integrations- und Entwicklungsplattform? +## Für wen ist die XFall API und warum sollte ich es nutzen? -Die föderale Integrations- und Entwicklungsplattform ist ein strategischer Ansatz, um die aktuellen Herausforderungen in der verteilten OZG Umsetzung zu adressieren. -Durch die föderale Integrations- und Entwicklungsplattform soll den OZG-Umsetzungsverantwortlichen und Lösungsentwicklern eine stabile und leistungsfähige Basis bereitgestellt werden, um schnell und wirtschaftlich bundesweit nutzbare und interopable Lösungen für Verwaltungsleistungen zu entwickeln. -Die föderale Integrations- und Entwicklungsplattform baut hierbei auf zwei zentralen Säulen auf: -- Leichtgewichtige Schnittstellen auf Basis etablierter Industriestandards sowie zentral bereitgestellte Integrationskomponenten, um wiederkehrende Integrationsherausforderungen im verteilten föderalen Vorgehen zu lösen oder zu minimieren. -- Eine gemeinsame Entwicklerplattform mit zentral bereitgestellten Entwicklungs- und Testwerkwerkzeugen, um die Entwicklung interoperabler Verfahren für die Antragsstellung und Antragsbearbeitung zu vereinfachen und zu beschleunigen. +## In welchem Stand befindet sich XFall REST API und wann kann man die API nutzen? -Die föderale Integrations- und Entwicklungsplattform folgt einem offenen Plattformgedanken und soll einen Kulturwandel in der Entwicklung digitaler Verwaltungslösungen einleuten. -- Der Staat stellt eine digitale Basis an Funktionen und Daten auf Basis offener Standards und Komponenten jedem frei zur Verfügung. -- Dies ermöglicht es allen gesellschaftlichen Akteuren (Behörden, Unternehmen, Non-Profit Organisationen, Bürger) neue digitale Lösungen und Innovationen frei zu erstellen. -- Entwickelte Lösungen können durch den Staat eingebunden, beauftragt oder eingekauft werden oder abseits des Staates im Rahmen neuer kommerzieller oder gesellschaftlicher Geschäftsmodelle eingebunden werden. +Die Entwicklung und Bereitstellung der XFall REST API erfolgt im Rahmen eines Proof of Concepts für die geplante föderale Integrations- und Entwicklungsplattform. Seit dem zweiten Quartal 2020 ist interessierten Parteien möglich, einen Zugang zur XFall API zu bekommen und eine prototypische Anbindung von Verfahren umzusetzen. -Die föderale Integrations- und Entwicklungsplattform ist dabei ganz bewusst nicht als zentralischer Ansatz zu sehen, sondern als ein föderaler Ansatz, da sowohl bei der Entwicklung von Antragsdiensten als Antragsbearbeitungssystem eine hohe Autonomie in der Umsetzung belassen wird. - - - -### Wozu dient der Proof of Concept? - -Der Proof of Concept (PoC) soll wesentliche Grundprinzipien und Lösungsansätze der föderalen Integrations- und Entwicklungsplattform am Beispiel der Antragsübermittlung praktisch erproben. Für diesen Zweck wird der bestehende XFall Standard für den PoC als offene RESTful API weiterentwickelt und die dazugehörigen Integrationskomponenten und Entwicklerressourcen prototypisch bereitgestellt. - -Mit dem PoC soll aufgezeigt werden, dass mit den zwei Säulen der föderalen Integrations- und Entwicklungsplattform und dem offenen Plattformansatz ein echter Mehrwert für die Entwicklung interoperabler und skalierbarer Lösungen geschaffen werden kann, um die föderale Verwaltungsdigitalisierung in Deutschland grundlegend voranzutreiben. - -Bei einem positiven Ergebnis des PoC wird angestrebt, die föderale Integrations- und Entwicklungsplattform als Gesamtansatz umzusetzen und die XFall RESTful API produktiv anzubieten sowie weitere APIs für das Antragsmanagement zu entwickeln. - -### Überblick PoC-Integrationsarchitektur - - - -#### Komponenten -Für den PoC werden zwei zentrale Komponenten bereitgestellt: -- **XFall-Zustelldienst:** Dieser Dienst stellt die `Application Sender API` und `Application Subscriber API` bereit. -- **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 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 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, 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 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. - - +Die langfristige produktive Nutzung der XFall REST API hängt vom Ausgang des Proof of Concepts und der weiteren Planung der föderalen Integrations- und Entwicklungsplattform ab. \ No newline at end of file -- GitLab