Skip to content

[Epic] Große Attachments in Chunks übertragen

Ziel

Anhänge größer als 500 MB sollen in Chunks über den Zustelldienst übertragen werden. Zielwert bis zu 5 GB mit potential des weiteren Ausbaus ist anzustreben. Gewünscht wird eine skalierbare und sichere Lösung, die es prinzipiell ermöglicht, die Dateigröße weiter nach oben zu verschieben, sowie den Anhang vertraulich und unveränderbar zu versenden. Wichtig dabei ist jedoch, dass mindestens die SDKs imstande sind, die Dateien in ihrer tatsächlichen Größe entgegenzunehmen und nach Empfang auch zusammengesetzt wieder auszugeben. Es ist eine saubere und langfristig haltbare Lösung anzustreben, unabhängig davon, ob dies in einen Minor- oder Major-Change resultiert.

Warum

Es gibt konkrete Kunden von FIT-Connect, die sogar ganze Akten potenziell mit Multimedia-Inhalten in einer Übermittlung transportieren müssen. Dabei entstehen auch ungezippte Dateien, die allein schnell 1GB und größer werden. Langfristig wird diese Größe der Dateien, welche übermittelt werden müssen, auch immer weiter ansteigen, schon allein, da man die Zunahme der Auflösung von Bild- und Video-Material (bis hin zu Aufzeichnungsmaterial > 2D) berücksichtigen muss. Das Handling von großen und sehr großen Einzeldateien ist daher unbedingt umzusetzen und zwar so, dass die große Datenmenge (Festlegung Q4 2023: 5GB Gesamtanhang) auch in einer einzelnen FIT-Connect-Nachricht sicher (vertraulich und unveränderbar) übermittelt werden können. Gewünscht wird eine Lösungsart, die es prinzipiell ermöglicht, die Grenze weiter nach oben zu verschieben. Teil dieses Epics soll die Erstellung eines Dokuments sein, welches die theoretische Erhöhbarkeit der Datenmenge über 5GB hinaus diskutiert und die prinzipielle Machbarkeit im Ansatz beschreibt. Eine Zerteilung von sehr großen Dateien in mehrere verschlüsselbare Teile ist zwar nicht unbedingt erwünscht, wird aber aktuell als akzeptabel angesehen. Wichtig dabei ist jedoch, dass mindestens die SDKs imstande sind, die Dateien in ihrer tatsächlichen Größe entgegenzunehmen und nach Empfang auch zusammengesetzt wieder auszugeben. Wir sollten hier eine saubere und langfristig haltbare Lösung anstreben unabhängig davon ob wir ein Minor- oder Major-Change haben.

Links, Notes, Remarks

Stories

  • Konzept Partieller Upload / Download großer Dateien #72 (closed)
  • Migrationskonzept für alle Stages
  • Implementierung Anhänge in Chunks übertragen
  • Implementierung Anhänge in Chunks übertragen in SDKs
  • Migration auf allen Stages

Acceptance criteria

  1. 5GB Dateien sollen im ersten Schritt problemlos übertragbar sein
  2. Perspektivisch sollte diese Grenze kontinuierlich angehoben werden können
  3. Doku für empfohlene / maximale Größen des ZSD wurde durchgängig korrigiert (Vorgaben aus #89 (closed))

Implementation plan (to be completed by the developer)

offene Fragen

Beantwortete und eingearbeitete Fragen
  • JWE Validierung von Anhängen
    • Anhänge werden aktuell validiert - daher wird aktuell der komplette Anhang im RAM benötigt
    • bei der Konzeptionierung von Dateien >500MB wären wir offen für neue Konzepte (z.B. Streaming)
    • Herausforderungen wahrscheinlich auch in den SDKs
    • WEITERE AUSBAUSTUFFEN: aktueller Prozesse Upload -> Validierung Anhang -> OK an Client (ggf. könnte der Upload in Speicher direkt erfolgen und die Validierung über eine Queue(ggf. andere Systeme) abgearbeitet werden - Versand Submission erst sobald alle Anhänge OK) TODO: Vorteile der Lösung wären noch zu betonen
  • mögliche Alternativen für das Konzept >500MB
    • Chunks - präferierte Lösung
      • wahrscheinlich ist die Empfehlung kleinerer Chunks sinnvoller - Begrenzung der Anzahl der Attachments prüfen
      • Abwärtskompatibilität prüfen (Wording, API, ...)
      • "Verständliche" Dokumentation sicherstellen
      • hier im Epic Fokus auf Konzept und POC light für ausgewählte Fragestellungen
      • gesamtheitlich Migrationskonzept auch vorüberlegen
    • Streaming - technisch eher zu komplex, daher wird diese Variante eher nicht unterstützt (JWE Validierung ggf. problematisch - ggf. neue Bibliothek notwendig, Auswahl dafür in den unterschiedlichen Programmiersprachen eher minimal)
  • Lösung >500MB sollte so konzeptioniert sein, dass wir unsere Vorgaben sowohl im Zustelldienst als auch in SDK umsetzen
Neue Fragen
  • Es gab hier vergangenes Jahr doch schon Analysen, was aktuell technisch die maximale Größe eines Anhangs sein kann, oder? Wo sind die Ergebnisse zu finden? Welche Gegebenheiten sind für die Limits verantwortlich? ( @Christoph_Metzger)
  • "Chunks - präferierte Lösung" (#72 (closed)) → Ist das nun schon entschieden oder noch nicht? ( @Christoph_Metzger)
    • Wojtek: ja, aus meiner Sicht hatten wir in den bisherigen Diskussionen keine besseren Ansätze.
    • Falls "Chunks" schon entschieden → weiß der Zustelldienst von den Chunks oder sind das ganz normale Anhänge und das Chunking wird komplett im SDK abgehandelt? ( @Christoph_Metzger)
      • Wojtek: wahrscheinlich weiß ZSD das gar nicht und wir müssen hier vor allem den Metadatensatz anpassen (ggf. Endpunkte?)
    • Muss für das "Chunking" der Metadatensatz angepasst werden? → Informationen zum Zerlegen und zusammenbauen von Anhängen von und für das SDK? Wer aktualisiert dann den Metadatensatz → Vermutlich ist das SDK Team hier am geeignetsten, oder? ( @Christoph_Metzger)
      • Wojtek ja, eng mit SDK abgestimmt
  • "gesamtheitlich Migrationskonzept auch vorüberlegen" was genau soll migriert werden? ( @Christoph_Metzger)
    • Wojtek: Falls der Zugriff auf "alte" Anhänge ohne Chunks sich ändern müsste, sollten wir das vorüberlegen
  • "Lösung >500MB sollte so konzeptioniert sein, dass wir unsere Vorgaben sowohl im Zustelldienst als auch in SDK umsetzen" → Welche Vorgaben? 5GB als Maximalgröße? ( @Christoph_Metzger)
    • Wojtek: ja das ist aktuell der Zielwert, welchen wir unseren Nutzern gerne zusichern würden
  • "Perspektivisch sollte diese Grenze kontinuierlich angehoben werden können" → Bedeutet das, dass der Maximalwert konfigurierbar sein soll und auch schon mit Werten >5 GB gesetzt werden kann? ( @Christoph_Metzger)
    • Wojtek: Frage nicht ganz klar
  • Bitte auch daran Denken den Speicherplatz auf den VMs zu erhöhen und zu überwachen. ( @Christoph_Metzger)
    • Wojtek: das könnten wir Infrastruktur mitgeben. Die Betreiber monitoren aber aus meiner Sicht den Speicherplatz und erweitern dynamisch bei Bedarf. Durch die Lösung selbst wird erstmal ja nicht direkt der Bedarf größer.
Edited by Martin Vogel