PeSIT

PeSIT (Protocole d'Echanges pour un Système Interbancaire de Télécompensation) est un protocole d'échange de fichiers entre systèmes informatiques reliés par une connexion réseaux.

Aperçu

Conçu par des groupes de travail d'experts dans le domaine de transfert des fichiers de grands centres d'informatique. En plus de fonctionnalités de transferts de fichiers de base, il présente les caractéristiques et les fonctionnalités qui permettent de maîtriser des flux des transferts de fichiers de masse et organiser la production industrielle de services de transferts des fichiers. La connexion PeSIT se fait entre deux partenaires nommés et identifiables. L'initiateur d’une connexion jouant le rôle de demandeur PeSIT, il négocie avec le répondeur PeSIT l’envoi ou réception d’un fichier ou l’envoi d’un message ou d’un acquittement d’un transfert. La négociation de transfert d’un fichier se fait sans jamais mentionner ni le nom de fichier ni son emplacement dans les FS respectifs des partenaires. L’objet de négociation n’est pas un fichier de FS mais un fichier virtuel identifiable par un identifiant, “filename” qui correspond à des jeux des définitions locales permettant d’accéder et lire un fichier du côté d’émetteur et de le créer et écrire du côté de récepteur. Chaque transfert a son identification unique connue de deux partenaires d’échange. Le protocole permet d’attribuer une priorité à chaque transfert qui devrait être respecté par deux parties.

Il permet: une gestion protocolaires de contrôle de flux, des interruptions et reprises de transferts, de leurs priorités et de leurs acquittements, de transferts par étapes (store and forward), d’encodages des données, de gestion d’organisation des flux de transferts par désactivation et activation des partenaires ou des fichiers virtuelles. En synthèse, il permet de créer des outils incontournables pour l’organisation de services centralisés de transferts de fichiers d’envergure industrielle.

Genèse et Historique

Les échanges des fichiers entre des ordinateurs se faisaient bien avant l’ouverture de réseau Internet aux marchés civils en 1990. D’abord chaque producteur proposait à ses clients son réseau propriétaire comme réseau SNA d’IBM ou DECNET de DEC qui permettaient de relier entre eux des ordinateurs du même constructeur. La vraie révolution est arrivée avec  les réseaux publiques X25 (X.25 — Wikipédia (wikipedia.org 1976)) agnostic de provenance des équipements informatiques interconnectés. Transpac, opérateur français de réseau X25 a commencé son activité en 1978. Pour des établissements bancaires l'arrivée d’un tel réseau public de télécommunication a ouvert des possibilités d'accélérer des échanges des fichiers client/banque (protocole ETEBAC3, très rudimentaire, défini par CFONB en 1984). La tâche d’organiser des échanges entre banques a été confiée au Groupement d'Intérêts Economiques GSIT créé en 1983. La première version du protocole PeSIT (PeSIT SIT) a permis de relier les adhérents au réseau SIT-Système Interbancaire de Télécompensation en 1992. La définition initiale sur sont utilisation sur X25, X32, PAD, ISO 8802.3 et  NETEX était étendue à TCP/IP et APPN. La dernière version E de PeSIT a été publiée en septembre 1989 avec plusieurs profils de son utilisation aussi bien sur le réseau SIT que en dehors pour des échanges Banque Client mais aussi des échanges B2B et B2C. Les grands changements de réglementation financière se sont imposés suite aux  Conseil européen de Lisbone en 2000 et au passage en euro. Le Conseil Européen des paiements (CEP, en anglais : European Payments Council, EPC) est né en juin 2002, à l’initiative des banques européennes et leurs fédérations européennes, avec l’objectif de mettre en place l’Espace unique de paiement en euros (SEPA). Le réseau SIT était remplacé par un système STET-CORE en 2008 et GSIT a cessé son activité en 2011. Mais le protocole PeSIT, grâce à ses implémentations très efficaces reste aujourd’hui largement utilisé pour des échanges B2B et B2C pas uniquement en France mais en Europe et même en dehors de l’UE.

Profiles

La dernière version E de PeSIT publiée en septembre 1989 (voir www.pesit.org) définit quatre profiles PeSIT:

PeSIT SIT

PeSIT HORS SIT

PeSIT HORS SIT Secure

ETEBAC5.

• PeSIT SIT était conçu uniquement pour le réseau SIT. Aujourd’hui n’est plus utilisé.

• PeSIT HORS SIT était retenu pour des échanges entre banques et leurs clients et devenu le profil le plus répandu pour des échanges en dehors des échanges financiers. Il est implémenté par tous les produits qui annonce le support du protocole PeSIT.

• PeSIT HORS SIT Secure inclut des fonctionnalités de sécurisation des données comme  chiffrement (DES et RSA) ou scellement des fichiers. Très rapidement il était dépassé.  

ETEBAC5 est un dérivé du profile PeSIT HORS SIT Secure avec chiffrement RSA uniquement.C’est ETEBAC5 qui était retenu par CFONB en tant que protocole PeSIT HORS SIT sécurisé pour des échanges des fichiers sensibles entre banques et grandes entreprises. Complexité d’exploitation et petit nombre d'implémentations avant l'arrivée de normes SEPA ont fait que ce profil n’a pas gagné de popularité.

Principes de fonctionnement

Le protocole PeSIT est conçu comme une machine abstraite où des messages FPDU (File transfer protocol Data Unit) sont échangés entre deux unités PeSIT homologues : l’initiateur de connexion (le demandeur) et le serveur (le répondeur). Ces messages contiennent une en-tête protocolaire et une zone variable contenant des PIs ( Parameter Identifiers) avec des paramètres du protocole ou des données du fichier.

Une session PeSIT se déroule en différentes phases qui s’imbriquent. Dans chacune de ces phases un certain nombre des services peuvent être exécutés. Chaque phase permet aux deux partenaires de coordonner l'exécution de ses services déclenchés par une FPDU de requête  (=>) et acquittées par une FPDU de réponse (<=).

Les services de coupure de connexion, d’interruption de transfert et de résynchronisation , peuvent être déclenchés aussi bien par le demandeur que par le répondeur. La FPDU.ABORT n’est jamais acquittée.  

Le processus de chaque transfert de fichier débute par sa négociation FPDU.CREATE pour l’envoi et FPDU.SELECT pour la réception. Les noms de fichiers et leurs emplacements restent à la discrétion des services PeSIT locaux. Les définitions locales de fichier virtuel de chaque côté détermine la façon d'accéder au fichier et des opérations qui doivent être faites sur des enregistrements lors de leur lecture ou écriture. Toutes les opérations nécessaires pour préparer l’envoi et la réception des fichiers sont coordonnées par appel des services de sélection et d’ouverture.

Services d’écriture et de lecture de fichier permettent de se positionner au bon endroit dans les fichiers en cas de reprise de transfert.

L’envoi des données de fichier se fait enregistrement par enregistrement avec ou sans contrôle de flux et pose de points de reprise.  

L’envoi de la FPDU.DTFEND par l’émetteur déclenche le service fin d’émission des données qui précède l'exécution de service de fin de transfert déclenché par le demandeur par l’envoi de FPDU.TRANSEND.  .

Les paramètres de FPDU.TRANSEND permettent un contrôle de nombre des enregistrements et des octets envoyés et reçus.

Fin de transfert et suivi par service de fermeture de fichier déclenché par FPDU.CRF et ensuite le service de désélection (FPDU.DESELECT).

C’est le demandeur qui termine la phase de connexion en envoyant FPDU.RELEASE.

Chaque FPDU de réponse porte le code diagnostic de résultat d'exécution du service.  

Phase CONNEXION  

• Service d’établissement de connexion
  • =>  FPDU.CONNECT,
  • <= FPDU.ACONNECT ou FPDU.RCONNECT
• Service de libération de connexion
  • => FPDU.RELEASE,
  • <= FPDU.ACK(RELEASE)
• Service de coupure de connexion
  • => FPDU.ABORT

Phase SELECTION

• Service de création de fichier
  • => FPDU.CREATE
  • <= FPDU.ACK(CREATE)
• Service de sélection de fichier
  • => FPDU.SELECT
  • <= FPDU.ACK(SELECT)
• Service de désélection de fichier
  • => FPDU.DESELECT
  • <= FPDU.ACK(DESELECT)
• Service de transfert de message
  • => FPDU.MSG (FPDU.MSGDM, FPDU.MSGMM,FPDU.MSGFM)
  • <= FPDU.ACK(MSG).

Phase OUVERTURE DE FICHIER

• Service d’ouverture de fichier
  • => FPDU.ORF
  • <= FPDU.ACK(ORF)
• Service de fermeture de fichier.
  • => FPDU.CRF
  • <= FPDU.ACK(CRF)

Phase TRANSFERT DE DONNÉES DE FICHIER

• Service d’écriture de fichier
  • => FPDU.WRITE
  • <= FPDU.ACK(WRITE)
• Service de lecture de fichier
  • => FPDU.READ
  • <= FPDU.ACK(READ)
• Service d’émission de données
  • => FPDU.DTF (FPDU.DTFDA,FPDU.DTFMA, FPDU.DTFFA),
• Service de pose de points de synchronisation
  • => FPDU.SYN
  • <= FPDU.ACK(SYN)
• Service de fin d'émission de données
  • => FPDU.DTF_END
• Service de fin de transfert
  • => FPDU.TRANS_END
  • <= FPDU.ACK(TRANS_END)
• Service d’interruption de transfert
  • => FPDU.IDT
  • <= FPDU.ACK(IDT)
• Service de resynchronisation .
  • => FPDU.RESYN
  • <= FPDU.ACK(RESYN)

Les phases d’une session de service PeSIT s'imbriquent et elles s'exécutent de façon séquentielle (deux transferts ne peuvent pas être exécutés en parallèle pendant une même session).

Capacités

Ce sont les capacités du protocole qui ont rendu des implémentations PeSIT HORS SIT si fortement ancrées dans les infrastructures de services IT de grandes entreprises.

Identification du répondeur portée par protocole (PI4)

Etablissement de connexion est initié par le demandeur par envoi de FPDU.CONNECT qui contient aussi bien son identification que l’identification de répondeur ainsi que le mot de passe ce qui permet au répondeur d’identifier le demandeur et l’authentifier et également au demander d’authentifier le répondeur. FPDU.CONNECT avec l’identification du répondeur  permet de bâtir des proxies PeSIT intelligents.

Contrôle de flux (PI7)

Lors d’établissement de connexion les deux partenaires négocient l’utilisation de service de points de synchronisation ou de resynchronisation.

Envoi des messages et des acquittements.

Le demandeur peut envoyer un message avec un texte allant jusqu’à 4095 octets. En plus du service de fin de transfert qui assure la coordination de la fermeture et de la désélection  de fichier entre deux partenaires d’échange, le receveur de fichier peut envoyer un  message spécifique appelé le message d'acquittement de la bonne réception du fichier.  

Envoi et la réception de fichiers.

Le demandeur peut envoyer ou demander de recevoir un fichier en annonçant ses caractéristiques protocolaires, comme::

Notion de fichier virtuel  (PI12)

qui est l’identification de fichier virtuel connu et défini par deux partenaires qui se caractérise par des attributs échangés entre les deux partenaires, à savoir:

• annonce de la taille de fichier à transférer (PI41 et PI42),
• organisation de fichier (PI33) peut être séquentiel, relatif ou indexé,

• format d’enregistrement (PI32) peut être fixe ou variable

• longueur d’enregistrement (PI31).

• La position de clé (PI38) et
• La longueur de clé (PI39) est notifiée en cas de fichier indexé.
• Code des données (PI16) peut être égal à ASCII, EBCDIC ou BINAIRE.
• l’utilisation de compression (PI21) est négociée entre les partenaires.

• Identification de transfert connu de bout en bout (PI13)

Chaque transfert de fichier ou de message à son identification attribué par l’émetteur et notifié au receveur ce qui permet un suivi et contrôle de chaque transfert de bout en bout.

Gestion de priorité de transfert (PI17)

Chaque transfert doit avoir le niveau de priorité attribué par le demandeur de transfert qui est notifié au répondeur.  

Coordination et contrôles de services de démarrage et fin d’un transfert

Aussi bien la négociation de transfert d’un fichier que le processus de fin d’un transfert impliquent l'exécution des services qui permettent contrôler leur résultat et notifier des échecs éventuels au même niveau d’avancement des phases respectives.

Interruption, suspension, reprise d’un transfert interrompu.

Protocole permet d’interrompre (ou de suspendre) le transfert en cours par l’envoi de la FPDU.IDT.  

Les transferts interrompus volontairement ou non peuvent être repris s'ils sont exécutés avec le contrôle de flux. Lors de ce type de transfert des points de contrôle (checkpoints) doivent être posés qui serviront à se repositionner dans les deux fichiers à l’endroit qui correspondent aux données échangés et enregistrés lors d’envoi de FPDU.ACK(SYN).

Store and Forward (PI61 et PI62)

Chaque transfert peut être fait “au nom de” et “à la destination de” grâce aux Customer Id (PI61) et Bank Id (PI62). Ces sont l’origine et la destination finale de fichier transmis entre le demandeur et répondeur de l’étape en cours de transfert. Le receveur de fichier doit connaître le partenaire adjacent connaissant le chemin menant au destinataire.  

En cas de envoi du type Store and Forward le message d’acquittement fait le chemin envers en traversant tous les points intermédiaires empruntés lors de l’envoi de fichier.      

Personnalisation de services de connexion et de transfert (PI37 et PI99)

Toutes les FPDU de services;

• établissement de connexion
• libération de connexion
• création de fichier,
• sélection de fichier
• désélection de fichier

peuvent contenir un paramètre d’utilisateur de 254 octets (PI99).

Deux FPDU de la phase de sélection ;

• FPDU.CREATE
• FPDU.ACK(SELECT)

contiennent un paramètre libre à utilisateur de 80 octets (PI37).

Ces deux paramètres donnent des capacités à passer des informations aux applications utilisatrices et même personnaliser le fonctionnement de services PeSIT.

Avantages

En comparaison avec les deux protocoles les plus connus: FTP/FTPS et SFTP, PeSIT HORS SIT offre des avantages présentés dans le tableau ci-dessous.

Capacités de PeSIT HORS SIT	FTP/FTPS	SFTP	Commentaire
Identification du répondeur	N	N
Contrôle de flux au niveau présentation	N	N
Envoi des messages	Y	Y
Envoi des acquittements	N	N
Identification de transfert connu de bout en bout	N	N
Notion de fichier virtuel	N	N	FTPS et SFTP ont des capacités à intervenir sur folders de FS du partenaire
Taille de fichier à transmettre	N	N
Priorité de transfert	N	N
Envoi de fichier indexé	N	N	A organiser avec FTPS/SFTP
Envoi de fichier relatif	N	N	A organiser avec FTPS/SFTP
Coordination et contrôle de services	Y	Y	...mais la coordination difficile en cas des différences de systèmes comme linux et z/OS
Interruption contrôlée	N	N
Reprise de transfert	Y	Y	...mais rarement implémentée.
Store and Forward	N	N	Difficile à organiser
Personnalisation de connexion	N	N

Utilisations

Le transfert de fichiers et le service IT le plus consommateur de ressources humaines et matériels. Orchestrer et maintenir la cadence de production dans des entreprises où le nombre des fichiers échangés croît toujours, nécessitent des compétences dans le domaine de stockage des données, de systèmes, de réseau et de sécurité ainsi que des produits et standards utilisés. Côté réseau, l’utilisation de la bande passante par les flux de transfert des fichiers était très pénalisante pour les échanges interactifs. L’environnement technologique des années 80 et 90 nécessitait un rigueur beaucoup plus stricte au niveau du choix d’architecture des infrastructures et des services informatiques.

Conçu par des experts ayant l'expérience d’exploitation de services de transferts de fichiers en masse au quotidien depuis des années dans les établissements bancaires, le protocole PeSIT était le plus abouti et le plus à même de répondre à tous ces besoins et contraintes.

Les premiers produits prenant en charge le protocole PeSIT, en dehors du cadre SIT (ainsi que ETEBAC5), ont fait leur apparition déjà dans les années 1980. À cette époque, on parlait davantage de moniteurs de transfert de fichiers que de MFT (Managed File Transfer). La différence entre ces deux types de produits se manifeste plus sur le mode et le niveau d’interaction avec les systèmes IT d’entreprises que sur les moyens de contrôle et de suivi des transferts. Ces dernières, offertes par PeSIT sont incontestablement toujours beaucoup plus évoluées et riches que celles offertes  par d’autres protocoles de transfert des fichiers.

Bien que le protocole PeSIT soit asymétrique, son utilisation en tant que deux applications distinctes; une, client et deuxième serveur PeSIT  n’a pas vu le jour à l’époque. Les moniteurs des transferts de fichiers PeSIt (qui souvent devenaient multi protocolaires), ont instauré la topologie d’un réseau des partenaires jouant le double rôle d’un demandeur et d’un répondeur pendant des multiples connexions simultanées ou non. Le fait d’utilisation de la notion de fichiers virtuels intimement liés aux applications business, utilisatrices de ces fichiers et des partenaires a permis de distinguer des classes managéables des flux de transferts.

Pendant l’exécution de chaînes de traitement  informatique des demandes de transferts étaient déposées dans des files d’attentes de transferts du moniteur pour être sélectionnés en fonction des règles de “scheduling” prédéfinies selon leurs priorités, leurs fichiers virtuels ou partenaires. Ils étaient exécutés de façon asynchrone par rapport aux chaînes de production.

L’interopérabilité avec des systèmes était assurée par l'exécution de procédures pré et post transfert attachées aux fichiers virtuels. Parfois un traitement online à la réception ou à la lecture de chaque enregistrement était exécuté également.

A part des moniteurs de transferts de fichiers, les solutions du type plates-formes spécialisés de services financiers, de gestion de comptabilité d’entreprise et autres, implémentaient également PeSIT HORS SIT d’abord en raison des réglementions et ensuite pour le confort de son utilisation.    

L'arrivée des technologies de traitement distribué a permis l’apparition des solutions du type MFT (Managed File Transfer)  multi-protocolaires offrant des plates-formes pour orchestrer, sécuriser et contrôler les transferts de fichiers dans le cadre de processus métier automatisés.

Dans ce contexte, les transferts de fichiers peuvent être exécutés de manière synchrone avec des chaînes de traitement bien que leurs exécution en asynchrone soit possible.

Implémentations

Produit	Editeur	Site WEB	OS	Commentaire
Moniteurs de Transfert des Fichiers
Transfer CFT	AXWAY	www.axway.com/en/products/managed-file-transfer/transfer-cft	z/OS, UNIX, Windows, iSeries, ...
Secure Transport	AXWAY	www.axway.com/en/products/managed-file-transfer/securetransport	UNIX, Windows, iSeries,
Connect:Express	IBM	www.ibm.com/support/pages/sterling-connectexpress-documentation	z/OS, UNIX, Windows
TBT400	IPLS	www.tbt400.com	iSeries
Plates-formes business
WeBank	Elcimaï	www.elcimai.com
PMFlux	CEDRICOM	www.cedricom.com
Managed File Transfer
MFT GoAnywhere	FORTRA	www.goanywhere.com	UNIX, Windows, iSeries, ...
DATA MOVER	Primeur	www.primeur.com/data-one/data-mover	UNIX, Windows,
Autres
PeSIT Server Connector	OTONET	www.otonet-lab.com		Application java
PeSIT Client Connector	OTONET	www.otonet-lab.com		Application java
Sterling Secure Proxy	IBM			Proxy/reverse-proxy

Perspectives

Les qualités intrinsèques du protocole PeSIT sont telles que, plus de deux décennies après la publication de sa dernière version (toujours accessible à www.pesit.org) il existe toujours des milliers d'utilisateurs qui n'envisagent pas d'utiliser d'autres protocoles.

Le marché du MFT est en constante augmentation, tout comme le nombre de transferts de fichiers au sein des grandes entreprises. Avec l'évolution des technologies, de nouveaux besoins ont émergé, tels que les transferts de fichiers UNICODE ou les transferts d'objets sérialisables, même stockés dans le Cloud, qui n'étaient pas pris en compte à l'époque de la définition du protocole. Certains éditeurs exploitent les capacités de personnalisation des services PeSIT en transmettant des informations supplémentaires via les paramètres utilisateur. Cependant, ce procédé judicieux est applicable uniquement aux transferts entre produits du même éditeur.

Aujourd'hui, de plus en plus de solutions MFT prennent en charge le protocole PeSIT, ce qui est facilité par l'apparition de connecteurs PeSIT en Java, comme celui d'OTONET, déjà implémentés dans plusieurs produits de ce type.

Les produits récemment développés peuvent plus facilement intégrer les nouveaux besoins, mais leur prise en compte directe par le protocole serait la meilleure solution.

Voir aussi

Article connexe

• Système interbancaire de télécompensation

Lien externe

• Site officiel de PeSIT