Skip to content

Test der Netzwerk-Umgebung durch FIT-Connect-Client / FIT-Connect-CLI

User Story

Als OD- oder FV-Hersteller möchte ich schnell prüfen ob in allen drei öffentlichen Umgebungen alle benötigten Internetpfade erreichbar sind um als Hersteller die an der Kundenumgebung notwendigen Änderungen einfach identifizieren zu können.

Why

Die Einführung einer FIT-Connect-Anbindung für ein Fachverfahren im Netzwerk einer Kommune ist fast immer mit einer aufwändigen Anpassung von Proxy und/oder Firewall-Regeln verbunden. Die Anpassungen liegen oft nicht in der Hand der Kommune, sondern müssen bei einem Dienstleister beauftragt werden.

Um diese zeitaufwändige Aufgabe erledigt zu haben, bevor das Fachverfahren an FIT-Connect angebunden wird, übermitteln wir derzeit eine TEST-config.yml mit Test-Dateien und Keys. Dies hilft aber nur bedingt, da wir damit nur die Netzwerkpfade auf das Test-System prüfen können und die Zertifikatsabrufe bei der Telesec auch nicht erfolgen (wir verwenden keine VPKI-Zertifikate in diesem Test). Zudem muss die TEST-config.yml individuelle Subscriber-Credentials enthalten, weil sonst Seiteneffekte zwischen Kundenprojekten entstehen.

Wünschenswert wäre:

  1. Eine kopierbare Auflistung aller benötigten Netzwerkpfade inkl. Beschreibung/Begründung für die Inbetriebnahme von PROD und TEST (STAGE ist ohne PVOG derzeit für uns ohne Nutzen) für die Kommune UND den Dienstleister.
  2. Eine CLI-Funktion (bestenfalls über das SDK), die ganz allgemein alle notwendigen Pfade testet, ohne eine config.yml zu benötigen
  3. Eine CLI-Funktion (bestenfalls über das SDK), die speziell eine config.yml auf ihre Funktionsweise gegenüber dem/der FIT-Connect-Server/-API testet
  4. Eine CLI-Funktion (bestenfalls über das SDK), die einen so genannten Smoke-Test (Funktionstest) über eine Zustellpunkt-LeikaID-ARS-Kombination ermöglicht (also mit Test-Fachdatei senden, abholen, vergleichen)(dazu wird vielleicht eine getrennte Sender-/Subscriber-Config gebraucht oder man filtert diese Nachrichten irgendwie elegant von den produktiven Nachrichten weg)

Mir ist klar, dass die Punkte 3 und 4 recht dicke Bretter sind, aber das automatisierte Funktionsmonitoring ist für die bundesweite Nutzung von FIT-Connect mit tausenden Zustellpunkten eine mögliche Lösung, um die notwendige Stabilität im Gesamtsystem mit akzeptablen Aufwand sicherzustellen. Diese Punkte können gern in ein Issue mit längerem Zeithorizont ausgelagert werden.

Akzeptanzkriterium

  • Doku ausbauen, dass yml nicht zwingend genutzt werden muss sondern der Code diese Möglichkeiten inne hat

Links, Notes, Remarks

Acceptance criteria

  1. Alle für die SDKs notwendigen Netzwerk / Internetpfade (notwendig und optional) sind in der öffentlichen Doku aufgelistet (siehe Wunsch 1)
  2. Java SDK bieten eine Funktion um lesend auf alle Ressourcen zuzugreifen und liefern in den Logs ein entsprechendes Ergebnis (siehe Wunsch 2)
  3. .NET SDK bieten eine Funktion um lesend auf alle Ressourcen zuzugreifen und liefern in den Logs ein entsprechendes Ergebnis (siehe Wunsch 2)

Implementation plan (to be completed by the developer)

Follow-Up

  • Erstellung der Stories um die Wünsche aus 2-4 umzusetzen (Einzuplanen im Rahmen des CLI Epics) #1300
Edited by Wojciech Gdaniec