To describe the problem more precisely, one first has to take a closer look at the EBICS protocol. Downloads via EBICS are performed in segments, always for all of the data that is relevant to the client request. When it receives a request, an EBICS client always puts all of the data for a download in exactly one physical file.
In the EBICS download process, after a download order is received the EBICS-Server first determines the number of segments in which the file to be transferred will be transferred to the client. This number is returned to the client with the first segment. It is mandatory in EBICS. Then the client calls up every subsequent segment sequentially and creates the file in the client.
Depending on the file size and the delivery type (e.g. ZIP archive), even the operation of compiling the first segment with the total number on the EBICS-Server can take some time. First, the complete file must be created in a compressed and encrypted form so that in the first EBICS response the correct number of segments can be delivered to the EBICS client. Therefore, until the client receives feedback on the number of segments in the initialisation phase, timeout situations and thus terminations can occur in the EBICS connection when large data volumes are involved.
This is the problem. In future, therefore, it must be possible to speed up the EBICS response to the EBICS initialisation request.
It is currently seen as imperative for the number of segments, which is returned to the client with the first segment, to be correct so that the transfer can be started. However, according to EBICS specification 2.5 (see section 7.2 Implementation in the EBICS messages, page 159), if the segment number specified is incorrect the EBICS client should behave tolerantly. In such a case, the EBICS client should proceed with the ongoing transaction with the acknowledgement phase, even if the EBICS-Server delivers fewer segments than it specified in the initial EBICS response. It should be possible to determine and return an estimated number of segments so that the EBICS-Server provides feedback to the client faster and avoids a timeout in the case of large files.
Fundamentally, it would be desirable to extend the EBICS specification with the following two partial solutions.
The EBICS client initiates a download of an unspecified size to avoid timeouts due to large data volumes
In its response, the bank server returns a number of segments for the expected data along with the first segment. If the data involved enables a faster compilation procedure, the bank server can deliver the exact number of segments as it has done up to now. However, if a larger data volume is involved, and possibly a longer preparation time (e.g. ZIP), it is permissible to return an approximate number of segments.
In any case, the EBICS client must keep calling up segments until it receives the end message.
In order to avoid timeouts during downloads in the collection/preparation phase of the EBICS bank server, when calling up a subsequent segment the EBICS bank server should also be permitted to return a value that indicates that it has not yet completed the data compilation. The EBICS client can keep requesting the required segment until it receives this segment.
Optional limitation of the data volume to be downloaded by the EBICS client in order to avoid files that are too big
At the same time, downloading large data volumes can also be problematic due to conditions outside the sphere of influence of the EBICS-Server or its operators. The problems can be caused by the system design of the client or the infrastructure. In such cases, it can be helpful if the data volume to be called up on the customer side can be restricted further than the current options allow (historical call up).
For example, it would be desirable for the EBICS client to be able to specify a maximum size when initiating a download. A possible solution would be a new optional parameter for the size of the download data. During the download, the EBICS bank server then always delivers complete data blocks (e.g. an account statement), and at least one of these data blocks. The size restriction should always be interpreted as a guideline value that the bank server is also permitted to exceed. This would provide an additional possibility, aside from the historical download, to control the size of the download data on the client side.
With these two extensions, EBICS will be equipped to deal with the growing data volumes in the future as well.
Michael Lembcke
