Um das Problem genauer zu beschreiben, muss man zunächst etwas tiefer in das EBICS-Protokoll einsteigen. Datenabholungen (Downloads) über EBICS erfolgen segmentweise immer für alle zur Clientanfrage passenden Daten. Ein EBICS-Client legt beim Empfang einer Anfrage alle Daten für eine Abholung immer in genau einer physischen Datei ab.
Im Downloadprozess von EBICS ermittelt der EBICS-Server nach Empfang eines Abholauftrages zunächst die Anzahl der Segmente, in denen die zu übertragende Datei an den Client übergeben wird. Diese Angabe wird mit dem ersten Segment an den Client zurückgegeben. Sie ist in EBICS verpflichtend. Anschließend ruft der Client jedes Folgesegment sequentiell nacheinander ab und legt die Datei bei sich an.
Bereits der Vorgang zum Zusammenstellen des ersten Segments mit der Gesamtanzahl auf dem EBICS-Server kann je nach Dateigröße und Auslieferungsart (z. B. ZIP-Archiv) längere Zeit beanspruchen. Es muss erst die vollständige Datei komprimiert und verschlüsselt erzeugt werden, damit in der ersten EBICS-Response die korrekte Anzahl an Segmenten an den EBICS-Client mitgeliefert werden kann. Bis der Client in der Initialisierungsphase eine Rückmeldung über die Segmentanzahl bekommt, kann es somit bei großen Datenmengen in der EBICS-Verbindung zu Timeout-Situationen und damit zu Abbrüchen kommen.
Hier liegt das Problem. Daher muss es zukünftig möglich sein, die EBICS-Response auf die EBICS-Initialisierungsanfrage zu beschleunigen.
Die Anzahl der Segmente, die mit dem ersten Segment an den Client zurückgegeben wird, muss heute für den Start der Übertragung nach Möglichkeit korrekt sein. Laut EBICS-Spezifikation 2.5 (siehe Abschnitt 7.2 Umsetzung in den EBICS-Nachrichten, Seite 159) sollte sich der EBICS-Client bei falscher Angabe der Segmentanzahl jedoch tolerant verhalten. In einem solchen Fall müsste der EBICS-Client die laufende Transaktion ordnungsgemäß mit der Quittungsphase fortsetzen, auch wenn der EBICS-Server weniger Segmente liefert, als er in der initialen EBICS-Response angegeben hat. Damit der EBICS-Server bei großen Dateien schneller zu einer Rückmeldung an den Client kommt und ein Timeout vermieden wird, sollte es möglich sein, eine geschätzte Segmentanzahl zu ermitteln und zurückzugeben.
Grundsätzlich wäre eine Erweiterung der EBICS-Spezifikation mit folgenden zwei Teillösungen wünschenswert.
Der EBICS-Client initiiert einen Download mit unbestimmter Größe zur Vermeidung von Timeouts bei großen Datenmengen
Der Bankrechner liefert in seiner Response zusammen mit dem ersten Segment eine Segmentanzahl der zu erwartenden Daten zurück. Wenn es sich um Daten mit der Möglichkeit einer schnellen Zusammenstellung handelt, kann der Bankrechner die Segmentanzahl wie bisher genau liefern. Handelt es sich jedoch um eine größere Datenmenge mit ggf. längerer Aufbereitungszeit (z. B. ZIP), darf auch eine ungefähre Segmentanzahl zurückgeliefert werden.
In jedem Fall muss sich der EBICS-Client so verhalten, dass er so lange Segmente abruft, bis er die Ende-Nachricht bekommt.
Um nun bei Abholungen Timeouts während der Sammel-/Aufbereitungsphase des EBICS-Bankrechners zu vermeiden, sollte der Bankrechner beim Abruf eines Folgesegments auch einen Wert zurückgeben dürfen, der aussagt, dass er mit der Datenzusammenstellung noch nicht fertig ist. Der EBICS-Client kann das gewünschte Segment wiederholt anfragen, bis er es bekommt.
Optionale Begrenzung der abzuholenden Datenmenge durch den EBICS-Client, um zu große Dateien zu vermeiden
Der Download von großen Datenmengen kann aber auch durch Bedingungen problematisch sein, die nicht im Einflussbereich des EBICS-Servers bzw. dessen Betreibers liegen. Ursachen können in der Systemauslegung des Clients oder in der Infrastruktur liegen. In solchen Fällen kann es u. U. helfen, wenn die abzurufende Datenmenge kundenseitig über die heutigen Möglichkeiten hinausgehend (historischer Abruf) weiter eingeschränkt werden kann.
Zum Beispiel wäre es wünschenswert, wenn der EBICS-Client einen Download unter Angabe einer maximalen Größe initiieren kann. Denkbar ist ein neuer optionaler Parameter für die Größe der Abholdaten. Beim Download liefert der EBICS-Bankrechner dann immer vollständige Datenblöcke (z. B. Kontoauszug) und davon mindestens einen. Die Größenbegrenzung sollte stets als Richtwert interpretiert werden, den der Bankrechner auch überschreiten darf. Damit gäbe es auch clientseitig neben der historischen Abholung eine weitere Möglichkeit, die Größe der Abholdaten selbst zu steuern.
Mit diesen beiden Erweiterungen ist EBICS auch zukünftig für die wachsenden Datenmengen gerüstet.
Michael Lembcke
