Auch mit SEPA ändert sich das Datenverhalten im Zahlungsverkehr
weiterhin. Neue Prozesse führen dazu, dass Dateien im Austausch zwischen
Kunden und Banken sowie im bilateralen Austausch immer größer werden.
Insbesondere in der Kunde-Bank-Beziehung spielt die Downloadfunktion für
Datenabholungen (z. B. Kontoauszüge) über EBICS eine wichtige Rolle.
Und zumindest hier scheint es noch Optimierungsbedarf zu geben. Bei
besonders großen Dateien wird es mit dem erfolgreichen Download aus
verschiedenen Gründen schwierig.
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
