Afin de pouvoir décrire le problème de manière plus précise, il convient, tout d’abord, d’examiner le protocole EBICS plus en détail. Lors d’un téléchargement de données (downloads) via EBICS en réponse à une requête client, celles-ci sont toujours segmentées. Lorsqu’il reçoit une requête, le Client EBICS dépose dans un seul fichier physique toutes les données à télécharger.
Lors du processus de téléchargement d’EBICS, le serveur EBICS, après réception d’un ordre de téléchargement, détermine d’abord le nombre de segments qui permettront de transmettre le fichier à transférer. Cette information est délivrée au Client avec le premier segment. Elle est obligatoire dans EBICS. Ensuite, le Client récupère successivement chaque segment de manière séquentielle et enregistre le fichier.
L’opération de concaténation du premier segment et avec tous les suivants sur le serveur EBICS peut, à elle seule, prendre un certain temps selon la taille et le type du fichier (ex. : archive ZIP). Le fichier complet doit d’abord être compressé et chiffré pour que la quantité exacte de segments puisse être indiquée au Client EBICS dans la première réponse EBICS. En cas de grandes quantités de données, un timeout et donc une coupure de la connexion EBICS peut se produire avant que le Client ne reçoive, dans la phase d’initialisation, une réponse indiquant le nombre de segments.
Là est le problème. À l’avenir, il faudra donc pouvoir accélérer la réponse à la requête d’initialisation EBICS.
À l’heure actuelle, la nombre de segments indiqué au Client dans le premier segment doit être exact pour permettre le démarrage du transfert. Pourtant, selon la spécification EBICS 2.5 (voir chapitre 7.2 Mise en œuvre dans les messages EBICS, page 159), le Client EBICS devrait se montrer tolérant si le nombre de segments indiqué est faux. Dans un tel cas, le Client EBICS devrait acquitter la transaction en cours, même si le serveur EBICS délivre un nombre de segments inférieur à celui indiqué dans la réponse initiale. Pour que le serveur EBICS, en cas de fichiers de grande taille, envoie plus rapidement une réponse au Client et de façon à empêcher un timeout, il devrait être possible d’estimer la quantité de segments et de délivrer cette estimation.
Fondamentalement, une extension de la spécification EBICS avec les deux solutions partielles suivantes serait souhaitable.
Le Client EBICS déclenche un téléchargement de taille indéterminée pour éviter un timeout en cas de grande quantité de données
Dans sa réponse, le serveur bancaire indique, en même temps que le premier segment, une quantité de segments des données attendues. S’il s’agit de données permettant une concaténation rapide, le serveur bancaire peut indiquer le nombre exact de segments comme c’est le cas jusqu’à maintenant. Mais s’il s’agit d’une grande quantité de données demandant éventuellement un temps de préparation plus long (ex: ZIP), il serait possible d’indiquer un nombre approximatif de segments.
Dans tous les cas, le Client EBICS devrait récupérer des segments jusqu’à ce qu’il ait reçu le message de fin.
Afin d’éviter les timeouts pendant la phase de collecte et de préparation du serveur bancaire EBICS, ce dernier devrait également, lors de la récupération d’un segment suivant, pouvoir transmettre une valeur indiquant qu’il n’a pas encore terminé la concaténation des données. Le Client EBICS pourrait redemander le segment souhaité jusqu’à ce qu’il l’ait reçu.
Limitation facultative de la quantité de données téléchargeables par le Client EBICS pour éviter les fichiers trop volumineux
Cependant, les problèmes de téléchargement de grandes quantités de données peuvent également résulter de facteurs indépendants du serveur EBICS ou de son opérateur. Les difficultés peuvent reposer dans la conception du système du Client ou dans l’infrastructure. Dans ce cas, il peut s’avérer utile de pouvoir limiter, côté client, la quantité de données téléchargeables au-delà des possibilités actuelles (téléchargement historique).
Il serait par exemple souhaitable que le client EBICS puisse déclencher un téléchargement en indiquant une taille maximale. On pourrait envisager un nouveau paramètre optionnel portant sur la taille des fichiers téléchargés. Lors du téléchargement, le serveur bancaire EBICS livrerait toujours des blocs de données complets (ex.: relevé de compte) et à minima un dans son intégralité. La limite de taille devrait toujours être considérée comme une valeur indicative que le serveur bancaire a le droit de dépasser. Il y aurait ainsi, outre le téléchargement historique, une autre possibilité de choisir soi-même la taille des fichiers de relevés.
Grâce à ces deux extensions, EBICS serait bien armé pour l’avenir et pour des volumes de données en augmentation.
Michael Lembcke
