Konzept Partieller Upload / Download großer Dateien

Um große Dateien über FIT-Connect zu versenden wäre ein möglicher Weg, die (zu) großen Dateien in kleinere Files aufzuteilen und als eigene Attachments zu versenden. Für die Kennzeichnung der Einzelteile gibt es folgende Ansätze:

Metadaten anpassen

So könnte man ein z.B. 5GB große Datei in 10 * 500MB aufteilen und diese als 10 einzelne Anlagen mit eigenen Attachment IDs zu eine Submission hinzufügen. Der Zustelldienst müsste hierfür lediglich ein neues Metadatenschema unterstützen, dass die Anlagen als Teil einer größeren Anlage kennzeichnet:

          "followedBy": {
            "type": "string",
            "description": "Falls es sich um eine aufgeteilte Anlage handelt, wird hier die Id der nachfolgenden Anlage angegeben.",
            "format": "uuid",
            "minLength": 32,
            "maxLength": 36
          }

Diese Erweiterung in der ContentStructure bei den Attachments wäre die Lösung bei diesem Ansatz.

Metadaten file

Ein weiterer Ansatz für das Problem wäre auch die Aufteilung der Datei in kleinere Häppchen aber dann eine Datei mit den Metadaten für das zerteilte File zu erstellen und anzuhängen. In diesem Beispiel würden aus dem 5GB File wieder 10 * 500MB gemacht werden und eine zusätzliche Attachment<ID>.info. Im Attachment<ID>.info steht dann nur die Reihenfolge der Teile des 5GB Files drin.

Bei diesem Ansatz ist keine Anpassung bei FIT-Connect notwendig und könnte sofort im SDK umgesetzt werden.

Anmerkung aus dem technischen Produktmanagement-Termin:

Beide Lösungen wären ein Breaking Change, da Subscriber große Attachments wieder zusammensetzen muss (war bisher nicht der Fall).

Ja, das schon aber die Attachment<ID>.info-Lösung könnte man jetzt auch schon umsetzen, ohne dass "uns" das jemand mitteilt. Also vielleicht macht das schon jemand so..?

Ich hatte gedacht, dadurch dass der Subscriber über die Destination signalisiert, ob er die neue Version unterstützt oder nicht, wäre es eine minor Version. Aber stimmt schon, nur weil der Empfänger sagen kann, ob er die neue Version unterstützt, wird es nicht automatisch von major zu minor.

Wenn es eh ein major Change wird, könnten wir überlegen, die IDs bei meiner Lösung umzubenennen. Derzeit wurde aus Gründen der Abwärtskompabilität der Name attachmentId für zwei unterschiedliche IDs beibehalten.

assigned to @Gerd_Aschemann

Wir müssen hier nochmal eine weitere Klärung mit @Jonas_Groeger und @Alexander_Hoose herbeiführen. Ich stelle dazu einen Termin ein.

added major-api-change label

Meine Notizen

Macht die API komisch
Attachmentvalidierung funktioniert nicht, wenn man die Datei erst verschlüsselt und dann splittet. Außer man deaktiviert die JWE Validierung.

FILE
ENC = encrypt(FILE) // ENC ist ein JWE
PARTS = split(ENC)

upload(P) // fail: JWE Validierung
upload(A) // fail: JWE Validierung
upload(R) // fail: JWE Validierung
upload(T) // fail: JWE Validierung
upload(S) // fail: JWE Validierung

Attachmentvalidierung funktioniert, wenn man das Attachment vorher splittet und dann verschlüsselt.

FILE
PARTS = split(FILE)

upload(encrypt(P)) // OK
upload(encrypt(A)) // OK
upload(encrypt(R)) // OK
upload(encrypt(T)) // OK
upload(encrypt(S)) // OK

Nicht erst verschlüsseln und dann zerhacken. Das ist ja auch das Problem, dass wir große Dateien nicht verschlüsseln können. Daher erst zerteilen und die Teile als einzelne Attachments hochladen.

Dann sind deine Bedenken ausgeräumt, @Jonas_Groeger (wenn wir erst splitten, dann verschlüsseln)? Ja, die API bleibt etwas weird, vielleicht können wir das auf Dauer noch irgendwie geradeziehen (in Version x.0.0 der submission-api)?

Its unfortunate to extend the API with a workaround that doesen't fix the root cause. Once we release it like this, we have to maintain it. Thats my only concern.

Hast du denn einen Vorschlag, wie der Root-Cause beseitigt werden kann? Ein einfaches Ja reicht mir, dann stelle ich einen Termin zur Diskussion ein, wo wir das klären können. Aus meiner Sicht haben wir ein systematisches Problem mit Attachments, die zu groß sind. Jedes System hat halt Grenzen und die 2GB waren wohl eher vom Marketing gesetzt, als technisch fundiert und haltbar.

mentioned in issue #1134 (closed)

Habe mit @Peter_Melichar einen Lösungvorschlag diskutiert, der auch #1134 (closed) lösen würde: https://git.fitko.de/fit-connect/arch/-/blob/ideas/andreas-huber/72-1134-transport-ids/backlog/ideas/transport-ids/transport-ids.adoc

Habe einen MR für die Diskussion angelegt: https://git.fitko.de/fit-connect/arch/-/merge_requests/15

Mir ist gerade auf dem Rad eine Lösung eingefallen, bei der ich ohne das Info-File auskomme. Gebt mir 2h und ich setze einen Lösungsvorschlag mal in Software um, wenn Ihr wollt

Mich würde deine Lösung interessieren. Wenn du sie aufschreibst, schau' ich sie mir gern an. Oder wir schnappen uns mal einen Refinement-Slot.

Ja, vielleicht kannst du das kurz skizzieren? 2h (oder ein bisschen mehr) sind nicht viel, aber ein kurze Beschreibung deines Ansatzes wäre nicht schlecht. Können wir auch gerne erst mal mdl. durchsprechen - bin ab sofort verfügbar.

Hab mal eine Submission erstellt und hoch- und runtergeladen. Das sind die Metadaten dazu. metadata.json

(Das Zusammenbauen nach dem Download fehlt mir noch aber das ist eine triviale Aufgabe)

Lösungsansätze Vor-/Nachteile:

Bei beiden Lösungen
- keine Änderung im ZSD
- eine erweiterte Semantik des Upload-/Downloads für große Dateien
Beim Ansatz von @Klaus_Fischer ist keine Änderung des Schemas nötig
Beim Ansatz von @Andreas_Huber haben wir eine Erweiterung des Metadatenschemas, die die De-/Komposition der Attachments explizit macht. Wir sollten hier auch explizit zwischen attachment ids und transport ids unterscheiden -> Neue Major Version des Schemas

Ich bin auch bei Jonas, dass ich den Ansatz komisch finde. Ich habe dabei weniger Bedenken zur grundsätzlichen Machbarkeit des Ansatzes.

Ich habe eher grundsätzliche Punkte:

Was ist denn das genaue Problem und was sind die potentiellen Lösungen?

--> Abbruch von Verbindungen während Upload/Download: Hier sehe ich Zerlegung nicht als die naheliegendste Lösung. Jonas hat schon paar alternative Ansätze aufgezeigt und ich würde noch gerne verstehen, warum alle anderen Stellschrauben nicht ziehen oder machbar sind.

--> Dateigröße: Was ist wird denn pro Attachment wirklich gebraucht? Gibt es wirklich eine einzelne Datei (PDF, JSON, JPEG), die größer als bspw. 300-400 MB ist? Nachweisbar und nicht der Anforderung, dass irgendwann in Ferner Zukunft gigantische Einzeldateien, da FIT-Connect eine Übertragungsinfrastruktur für Anträge ist und nicht universelle Fileablage. Und XML Dateien mit eingebetteten Attachments sind für mich kein Argument und diese würden auch im Data Objekt übermittelt werden. Solche Konstrukte sollte FIT-Connect mit Attachments bewusst vermeiden. Für mich wäre daher erstmal die ein offizielles Limit pro Attachment unterhalb von 500 MB die schnellste Lösung.

Aber auch bei noch größeren Dateien fehlt mir eine detaillierte Problembeschreibung (Ebene JOSE Bibliothek bzw. Zustelldienst) und die möglichen Alternativen.

Es ist ein Major Change der API:

Mir ist hier nicht genau beschrieben, wie dieser Change genau vollzogen wird. Die Submission API ist eine Public API und keine interne Enterprise Schnittstelle, wo bilaterale Absprachen getroffen werden. Wir verlangen von den Clients neue Funktion, die diese können müssen und daher ist es ein Major Change. Major Changes sind niemals trivial und immer extrem kritisch. Wenn wir den Change gegenüber allen API-Konsumenten nicht sauber darlegen und managen können, wird es knallen und dann extrem negativ auf FIT-Connect als zuverlässiger API-Provider zurückfallen. Und selbst wenn wir es sauber darstellen können, muss man als Public API Provider (erst recht in der öffentlichen Verwaltung) Vorläufe bzw. Parallelbetriebe von 6-12 Monaten für Major API Changes vorsehen.
Man könnte auch die Fähigkeit zur Verarbeitung zerlegter Attachments über die Destination an die Sender kommunizieren (analog zur Unterstützung bestimmter Rückkanäle oder Fachdatenschemata). Dann kann man es als Minor Change handhaben. Aber bin mir hier nicht sicher, ob das auf lange Sicht nicht auch Probleme nachzieht.
Sowohl beim Major als auch Minor Change sehe ich daher das Risiko erheblicher Folgeaufwände. Gerade auch weil es uns leider (meines Wissens nach) immer noch an automatisierten Testmöglichkeiten für API-Konsumenten für Schnittstellenkonformität fehlt.

Irgendwie habe ich das (vielleicht falsche) Gefühl, dass wir unseren API-Konsumenten einen Change aufdrücken, ohne alle internen Optionen als API-Provider geprüft zu haben. Alle Empfehlung für Public APIs gehen eigentlich immer dahin, API-Changes nur in zwingendend notwendigen Fällen durchzuführen und das der API-Provider grundsätzlich bei technischen Herausforderungen erstmal alle internen Optionen ausloten sollte.

Vielleicht habt ihr schon alles technischen Optionen ausgelotet, aber ich konnte es auf die Schnelle aus dem Issue nicht erkennen. Wenn dem so, dann geht es halt nicht anders.

Und dickes Sorry, dass ich die vielen Bedenken vor meinem Urlaub hier noch ausschütte, aber es ging leider organisatorisch nicht anders bei mir.

Aber auch bei noch größeren Dateien fehlt mir eine detaillierte Problembeschreibung (Ebene JOSE Bibliothek bzw. Zustelldienst) und die möglichen Alternativen.

Eine Untersuchung der Grenzen hat in #816 (closed) stattgefunden. Einzige Alternative scheint die Verkleinerung von Attachments zu sein, da die JWE implementierende JOSE-Bibliotheken intern wohl mit Strings arbeiten (max. Größe: 2 GB). Ich denke, wir haben die Option mit größeren (als ca. 700 MB) Attachments hinreichend untersucht.

Andere Alternativen:

Gibt es andere Bibliotheken für JWE?
Will FIT-Connect von JWE weg? -> das wäre eine noch viel größere API-Umstellung
Will FIT-Connect JWE selbst implementieren (z.B. Verarbeitung von Byte-Streams statt String-Objekten)?
Will FIT-Connect die JOSE-Bibliotheken auf z.B. ein Byte-Streaming vornehmen?
- Würde ein solcher Patch akzeptiert?
- Muss FIT-Connect ggf. einen Fork, bzw. zwei für Java und .NET pflegen?
Würde eine Anpassung/Ersatz von JOSE ausreichen? Müsste nicht auch z.B. die Base64-Verarbeitung angepasst werden?

Die gesamte Diskussion entzündet sich daran, dass in unserer FAQ kommuniziert ist, dass wir Attachments von 2GB (netto-Daten) verarbeiten können. Wir haben bereits festgestellt, dass das technisch nicht haltbar ist (theoretischer Max-Wert ist bei Java ca. 1.5GB, bei .NET eher ca. 700MB; praktisch vermutlich weniger). Falls @Hauke_Traulsen bereit ist, diese Aussage aus der FAQ zurückzunehmen, haben wir überhaupt keinen Handlungsbedarf. Dann könnten (und sollten) wir eine sinnvolle Maximal-Größe kommunizieren, die wir entgegennehmen und abspeichern können, würden damit aber den Nutzern überlassen, wie sie ggf. mit größeren Attachments umgehen, falls diese vorkommen.

Ich sehe folgende Optionen (nicht exklusiv) außerhalb der technischen Umsetzung des nun favorisierten Vorschlags:

Kommunikation einer (aktuell möglichen) Obergrenze in der Nutzerdoku (FAQ)
Abwarten, ob das jemals eine akute Anforderung wird (wie geht man dann damit um?)
Umfrage unter Anbindungsprojekten, ob bzw. ab wann sie mit größeren Attachments rechnen (-> Planung einer Lösung)
Vorbereitung auf größere Attachments (durch Umsetzung der bekannten Vorschläge, oder ggf. neuer Ansätze).

Der Bedarf an großen Attachments kommt von den Bauanträgen, speziell dem ELiA Verfahren. Diese Software erstellt Bauanträge und erzeugt eine AntragX-Datei, die technisch ein Zip-Archiv mit der Endung .antragx ist. Diese Zip-Datei kann bis zu 2GB groß werden, je nach Größe der dort eingebetteten Baupläne.

Das Problem großer Dateien fängt schon bei der Verschlüsselung an. Die Nimbus-Bibliothek (und vermutlich fast jede andere) verschlüsselt im RAM. D.h. die Anlage wird komplett ins RAM geladen, dann in einen String umgewandelt und danach verschlüsselt. Nach meiner Schätzung werden aufgrund des mehrfachen im RAM haltens für die Verschlüsselung einer 1GB großen Datei 5GB RAM benötigt.

Da die Anforderung nach 2GB Attachments ganz konkret angefragt wird, müssen wir uns für eine der drei Lösungen entscheiden:

FIT-Connect wird für 2GB-Attachments ertüchtigt.
Die Anbindungprojekt müssen bilateral eine Lösung abstimmen.
Wir spezifizieren eine Split-Lösung.

Zu 1.: FIT-Connect-seitig würde sich das sicherlich mit einer entsprechende RAM-Erweiterung lösen lassen. Wie oben von Gerd angemerkt, werden wir hier an Grenzen stoßen, die wir nicht mehr anheben können. Mit Blick auf die gewünschte Verschlüsselung der Anlagen noch im Browser ist diese Lösung als sehr problematisch zu bewerten.

Zu 2.: Es könnte ein Best-Practice-Konzept erarbeitet werden, wie große Anlagen zu zerteilen sind, die Teilung dokumentiert wird und die Teile wieder zusammengesetzt werden. Dieses darf nur angewendet werden, wenn die Kommunikationspartner die Verwendung vorher bilateral abgestimmt haben. Die Anwendung wäre aber für FIT-Connect völlig transparent, da einfach mehrere kleine Anlagen trasportiert werden. Diese Lösung würde ich empfehlen, wenn es sehr wenige Anbindungsprojekte mit großen Dateien sind, sodass die bilaterale Abstimmung keine große Hürde darstellt.

Zu 3.: Sofern die Lösungen 1 und 2 nicht in Betracht kommen, sollte eine Spezifikation zum Splitten von Anlagen vorgegeben werden. Ich könnte mir gut vorstellen, die Empfangsbereitschaft über ein von Alex angedeutetes Feature-Flag zu signalisieren. D.h. der Sender darf nur dann Anlagen teilen, wenn der Empfänger diese Zusatzfunktionalität über einen Eintrag im Zustellpunkt signalisiert. Das würde die Vorteile des Splittings (kleinere Teildateien) und Lösung 2 (nicht jeder Empfänger muss es unterstützen) vereinen. Es bedeutet einen kleinen zusätzlichen Aufwand beim Sender, da er aufgrund des Flags im Online-Dienst die Maximalgröße von Anlagen regeln muss (z.B. 200MB ohne Flag, 2GB mit Flag).

Bin eigentlich ab heute im Urlaub (komme am 4. September zurück), aber mache noch gerade paar letzte Sachen fertig. Daher das letzte Kommentar hierzu.

Zu der antragx Geschichte:

Sie sollen schlicht davon keinen Gebrauch machen und ihre Dateien aus der ZIP Datei in die Attachments legen. Antragx ist kein Standard, sondern nur eine Praktik in diesem Verfahrensverbund, den sie jetzt gerne weiterführen wollen. Es gibt in FIT-Connect keinen Anspruch darauf, beliebig riesige ZIP Dateien zu erstellen und diese in ein einziges Attachment zu kippen.

Mir ist klar, dass es hier Befindlichkeiten gibt und stehe gerne für Diskussionen nach meinem Urlaub bereit.

In der FAQ wird nur die Gesamtgröße eines Antrags auf 2GB beschränkt, einzelne Attachments müssten kleiner sein:

assigned to @Alexander_Hoose and unassigned @Gerd_Aschemann

mentioned in issue #1186 (closed)

marked this issue as related to #1186 (closed)

marked this issue as related to #816 (closed)

removed Epic::ZSD-Refactoring label

Konzept Partieller Upload / Download großer Dateien

User Story

Warum?

Relevante Links und Bemerkungen

Akzeptanzkriterien

Durchführungsplan (von Entwickler:in bei Umsetzungsplanung auszufüllen)

Designs

Child items ...

Activity

Metadaten anpassen

Metadaten file