Zum Hauptinhalt springen
Version: FIT-Connect_v1

Roadmap

Stand 26.07.2021

Die FIT-Connect Submission API, die Routing API und die dazugeh├Ârige Infrastruktur wird in einem Projekt des IT-Planungsrats im Jahr 2021 zu einer Produktreife entwickelt. Die Umsetzung der Projektliefergegenst├Ąnde erfolgt iterativ, um eine schnelle Erprobung und Feedback zu erm├Âglichen.

Die Roadmap soll daher einen ├ťberblick verschaffen, wann das FIT-Connect Team f├╝r die folgenden Projektliefergegenst├Ąnde neue Features anstrebt:

  • API-Spezifikation: In der OpenAPI geschriebene Spezifikation der FIT-Connect Submission API.
  • Entwicklerdokumentation- und tools: Weiterf├╝hrende Dokumentationsartikel zur technischen Anbindung an der API f├╝r sendende und empfangende Systeme udn Bereitstellung von Tools f├╝r technische Querschnittsaufgaben wie Tokenhandling, Signaturpr├╝fung oder Verschl├╝sselung.
  • Infrastruktur: Bereitstellung von Infrastrukturkomponenten f├╝r die Durchf├╝hrung von Anbindungstests oder Validierungsaufgaben sowie die produktive Bereitstellung der API f├╝r Daten├╝bermittlungen.

Die Roadmap wird laufend aktualisiert und erweitert. Unser Team versucht weitestgehend verbindliche Termine zu benennen, jedoch passen wir die Umsetzungen den aktuellen Bedarfen des Projekts an, wodurch es zu Verz├Âgerungen bei manchen Liefergegenst├Ąnden kommen kann. Umgekehrt kann es auch sein, das Features fr├╝her fertiggestellt werden, falls die Priorit├Ąten ├Ąndern oder freie Kapazit├Ąten zur Verf├╝gung stehen.

Wir nehmen gerne neue W├╝nsche & Anregungen f├╝r die FIT-Connect APIs als Issue auf unserem Projekt (https://git.fitko.de/fit-connect/api) entgegen und versuche diese Issues nach einer Umsetzungspr├╝fung in unsere Roadmap aufzunehmen.

W├╝nsche & Anregungen oder Fehler k├Ânnen ├╝ber den hier beschriebenen Prozess abgegeben werden k├Ânnen.

├ťberblick ├╝ber die Zeitplanung#

  • Seit 24.06.2021: Preview der API-Spezifikation und der Entwicklerdokumentaion f├╝r die Version 1.0 der Submission API ist online und ist f├╝r alle interessierten Entwickler zug├Ąnglich.
  • Anfang August 2021: Bis zu diesem Zeitpunkt werden alle Kernfeatures der Submission API spezifiziert und als stabile API Spezifikation ver├Âffentlicht. F├╝r die Evaluierung und Entwicklung durch interessierte Entwickler wird ein ├Âffentlicher Testserver bereitgestellt.
  • Bis September 2021: Die Submission API wird als Produktivinfrastruktur f├╝r erste Pilotantragsverfahren und deren Systeme bereitstellt. Zudem werden noch neue abw├Ąrtskompatible Features und zus├Ątzliche Entwicklerangebote bereitgestellt.
  • Bis Q2 2022: Alle Beschl├╝sse zur weiteren Pflege der API und dem Betrieb der Infrastruktur liegen vor.

Detailplanung bis Mitte August 2021#

API-Spezifikation#

Die Submission API wird mit folgenden Änderungen und Erweiterung in der Form einer V1 finalisiert:

  • Bereitstellung und ├ťbermittlung des Security Event Logs: Der bisherige ├ťbermittlungsstatus wird durch einen Security Event Log ersetzt, der aus signierten Security Event Tokens besteht und die einzelnen ├ťbermittlungsschritte beweissicher dokumentiert. Die jeweiligen Security Event Tokens sind durch die jeweils verantwortlichen Systeme ( Zustelldienst bzw. das empfangende System) zu erstellen und zu signieren. Dieser Security Event Log kann ├╝ber die API von beiden Parteien abgerufen werden und dient sp├Ąteren Nachweisen ├╝ber die korrekte Zustellung.
  • Callbacks zur Benachrichtigung sendender Systeme: Sendende Systeme bekommen die M├Âglichkeit f├╝r Submissions einen Callback einzurichten. ├ťber diesen Callback informiert der Zustelldienst sendende Systeme, sobald es ├änderungen im Zustellstatus. Durch den Callback soll ein regelm├Ą├čiges Polling des Security Event Log zur Pr├╝fung des Zustellstatus unn├Âtig gemacht werden.
  • Neuumsetzung von Features: Einige Features aus der Beta7 Version der API wie die Abfrage von Destination Informationen und die Abfrage von abholbereiten Antr├Ągen werden neu konzipiert und sind in der aktuellen Preview noch nicht enthalten.
  • Neues Client Autorisierungskonzept auf Basis des bestehen Client Credentials Flows: Ein neues OAuth Konzept soll umgesetzt werden, da detailierte Berechtigung f├╝r den API-Zugriff erm├Âglicht und h├Âhere Sicherheit f├╝r die Nutzung von Access Token gew├Ąhrleistet.
  • Anlegen neuer Zustellpunkte nur ├╝ber das Self-Service-Portal: Aufgrund des neuen Autorisierungskonzepts werden neue Zustellpunkte aktuell nur noch ├╝ber das Self-Service-Portal angelegt. ├änderungen an Zustellpunkten (bspw. Hinterlegung von Zertifikaten oder Fachschemareferenzen) werden weiterhin ├╝ber die API m├Âglich sein.

Entwicklerdokumentation- und tools#

Infrastruktur#

  • Testinfrastruktur: Es wird eine Testinfrastruktur bereitgestellt, ├╝ber die alle Funktionen der API angesprochen und getestet werden k├Ânnen.
  • Self-Service-Portal: Es wird ein Self-Service-Portal eingerichtet, ├╝ber das Entwickler ihre API-Clients am OAuth Server selbst anlegen k├Ânnen. Als weiteres Feature wird es f├╝r Betreiber von empfangenden Systemen m├Âglich sein, ├╝ber das Self-Service-Portal Destinations anzulegen und zu konfigurieren. Das Self-Service-Portal wird mit dem Start des Testserver bereitgestellt.

Detailplanung bis September 2021#

API-Spezifikation#

  • Im Rahmen der Produktivstellungen werden Erweiterungen an der API zur├╝ckgestellt und nur bei dringenden Bedarf bzw. kritischen Fehlern Fixes an der API durchgef├╝hrt.

Entwicklerdokumentation- und tools#

  • Bereitstellung von SDKs f├╝r erste Querschnittsfunktionen: Es ist geplant, erste Unterst├╝tzungsfunktionen f├╝r Querschnittsaufgaben bereitzustellen.

Infrastruktur#

  • Sandbox Systeme: ├ťber eine Portaloberfl├Ąche werden generische API-Clients angeboten, um bei Versand oder Empfang von Submissions die jeweilige Gegenseite zu simulieren.

Detailplanung bis Ende 2021#

API-Spezifikation#

  • Routing API: ├ťber die Routing API wird zuk├╝nftig m├Âglich sein, Destinations und deren technische Parameter ├╝ber eine API Anfrage anhand technische Zust├Ąndigkeitskriterien zu ermitteln.
  • Hinterlegung einer OSCI-Weiterleitung: Um bestehende OSCI Intermedi├Ąrsinfrastrukturen einzubinden, wird eine Hinterlegung von OSCI-Kommunikationsparametern m├Âglich sein. Hierdurch werden abgebeben Submissions durch den Zustelldienst automatisch an den vorgesehen OSCI Intermedi├Ąr weitergeleitet.
  • Erweiterung um einen R├╝ckkanal f├╝r Prozessstandards: Als abw├Ąrtskompatible Erweiterung wird ├╝ber die API erm├Âglich, eine bilaterale Antragskommunikation auf Basis von Fachstandards wie XBau umzusetzen. API-Nutzer, die FIT-Connect nur f├╝r Einreichungen nutzen, sind von diesen ├änderungen nicht betroffen.
  • Weiterentwicklung von FIM/XFall Schemata: Um die Nutzung von FIM f├╝r die Antrags├╝bermittlung zu vereinfachen, werden in Zusammenarbeit mit FIM neue technologische Ans├Ątze und Verbesserung in der Schema Nutzung angestrebt.

Entwicklerdokumentation- und tools#

  • Vollumf├Ąngliche Bereitstellung von SDKs: In der zweiten Jahresh├Ąlfte werden SDKs in verschiedenen Programmiersprachen f├╝r alle zentralen FIT-Connect Anforderungen angeboten.
  • FIM Entwicklungstools: Um die Nutzung von FIM f├╝r Antragsschemata sollen diverse Entwicklungstools f├╝r die Generierung und Validierung von FIM/XFall Nachrichten angeboten werden.

Infrastruktur#

  • Validierungsumgebung: Um gegen├╝ber Auftraggebern oder anderen Stellen nachzuweisen, dass die eigene Software FIT-Connect nutzen kann, soll eine Validierungsumgebung geschaffen werden, die die API-Umsetzung gegen├╝ber festgelegten Testf├Ąllen pr├╝fen und hierf├╝r einen signierten Nachweis an den Verfahrenbetreiber ausstellt.

Bis Q2 2022#

... TBD ...