Transfert de Fichier

Transfert de Fichier

Fonctionnement multi-serveur

---

Procédure de Transfert de Fichier

Le déroulement des Transferts de fichiers est optimisé et amélioré dans la version 9.00A de l'Automation Engine. Ce nouveau protocole n'est cependant utilisé que lorsque les Agents impliqués présentent la version 9.00A (ou supérieure). Si un des Agents présente une version précédente, l'ancienne méthode est utilisée pour des raisons de compatibilité.

Ancien protocole de Transfert de Fichier (jusqu'à la version 8.00A)

Pour commencer le transfert de fichiers, les deux Agents doivent d'abord être connectés. Un des deux processus de travail s'adresse au processus de communication qui est relié à l'Agent source et lui transmet une demande de connexion. Le processus de communication transfère le message à l'Agent. L'Agent tente de se connecter à l'Agent cible avec les informations contenues.

 Si la connexion échoue, par exemple à cause d'un pare-feu, l'Automation Engine entre en contact avec l'Agent cible avec la même méthode. Celui-ci essaie à présent d'établir une connexion avec l'Agent source.

Dès que les deux Agents sont connectés, le transfert de fichiers peut commencer. Des messages de statut sont régulièrement envoyés à l'Automation Engine pour que l'avancement puisse être suivi. Dans l'Interface Utilisateur, une fenêtre de détails de la Tâche de Transfert de Fichier affiche les octets déjà transférés.

Contrairement au nouveau protocole de Transfert de Fichier, les fichiers de tous les Transferts de Fichiers sont envoyés au moyen d'une connexion (connexion TF). Il peut également arriver que des blocs de fichiers différents soient tour à tour transférés. L'Automation Engine surveille l'intégralité du processus de Transfert de Fichier et indique l'Agent cible pour chaque fichier à envoyer.

 L'administrateur peut définir dans le paramètre DISCONNECT_AFTER_FT de la Variable UC_HOSTCHAR_DEFAULT si la connexion entre les deux Agents doit être interrompue après le transfert de fichiers. 

Nouveau protocole de Transfert de Fichier (à partir de la version 9.00A)

A partir de la version 9, l'Automation Engine envoie l'intégralité de l'ordre du Transfert de Fichier à l'Agent source (y compris les saisies avec caractères génériques pour les Transferts de Fichiers avec des caractères génériques). L'Agent expéditeur reprend la résolution de l'ordre (détermination des fichiers).

Etablissement de la connexion

L'Agent expéditeur essaie de mettre en place une connexion vers le destinataire. Si cela ne peut avoir lieu en raison, par exemple, du pare-feu, il en informe l'Automation Engine. L'ordre TF est envoyé au destinataire qui peut alors tenter d'établir une connexion vers l'expéditeur. Suite à une connexion réussie, l'Agent destinataire transfère l'ordre TF à l'expéditeur.

Vérification de l'espace mémoire

Avant le début d'un Transfert de Fichier, une vérification est effectuée en fonction du système d'exploitation si suffisamment de place est disponible ou est allouée pour cela sur la plateforme cible.

• BS2000 : Allocation de l'espace disque probablement alloué lorsque l'option "Conserver les attributs originaux de fichier" est activée dans l'objet Transfert Fichiers.
• NSK : aucune vérification de l'espace mémoire
• Système de fichier natif OS/390 : Allocation à l'aide de l'attribut SPACE pour la cible du Transfert de Fichier.
• Système de fichier natif USS OS/390 : aucune vérification de l'espace mémoire
• Système de fichier natif OS/400 : Allocation lorsque soit l'option "Conserver les attributs originaux de fichier" est définie, soit l'attribut SIZE est défini comme cible
• Système de fichier natif IFS OS/400 : Vérification de l'espace mémoire disponible
• UNIX : Vérification de l'espace mémoire disponible (interruptible avec le paramètre ft_alloc_disk_space)
• VMS : Vérification de l'espace mémoire disponible
• Windows : Vérification de l'espace mémoire disponible

Déroulement de Transferts de Fichier

Pour un nouveau protocole, une connexion propre est créée pour chaque Transfert de Fichier entre les Agents. Les fichiers sont toujours envoyés les uns après les autres au moyen de la connexion. Si l'Agent prend cela en charge, chaque Transfert de Fichier est traité dans un Thread ou un processus propre. De cette façon, plusieurs Transferts de Fichiers sont exécutés complètement indépendamment les uns des autres.

Les connexions étant recréées de manière autonome à la fin du Transfert de Fichier, le paramètre DISCONNECT_AFTER_FT n'a aucun effet dans la Variable UC_HOSTCHAR_DEFAULT pour un nouveau protocole.

Les Threads sont pris en charge par les Agents des systèmes d'exploitation suivants :

• OS/400
• Unix
• Windows
• z/OS

Pour NSK , chaque Transfert de Fichier est traité dans un processus propre. Pour permettre cela, l'Agent NSK possède un deuxième port spécialement pour les Transferts de Fichiers.

Si une erreur de connexion survient entre l'Automation Engine et l'Agent, les Transferts de Fichiers ne sont malgré tout pas affectés. Si la connexion peut être rétablie, le statut réel du Transfert de Fichier est transmis à l'Automation Engine.

Pour les Transferts de Fichiers avec l'Agent UNIX, le paramètre de sécurité NFS "root squash" pose un problème lorsque l'ancien protocole TF est utilisé. La raison est que les Transferts de Fichiers sont toujours exécutés sous l'Utilisateur UNIX "root". Cette erreur ne survient plus dans le nouveau protocole. Les Transferts de Fichiers sont toujours exécutés sous l'Utilisateur qui est indiqué dans l'objet Login.

Afin de garantir un transfert fiable des fichiers, différentes procédures sont disponibles pour le Transfert de Fichier :

Sécurité du transfert

L'exactitude des données transférées est assurée par une somme de contrôle MD5 contenue dans le train de données. Les données sont alors vérifiées par paquet.

Vérification de la consistance lors de Transferts de Fichier - Reprise

Contrairement à l'ancien protocole, chaque fichier d'un Transfert de Fichier ne peut être répété séparément. Toutefois, vous avez la possibilité de répéter un Transfert de Fichier incorrect à partir du dernier point de reprise.

Les points de reprise sont établis par les Agents lors d'un Transfert de Fichier dans un intervalle de temps défini (Paramètre FT_RESTARTINFO_INTERVAL dans la Variable UC_HOSTCHAR_DEFAULT). L'Agent enregistre localement ces informations dans les fichiers StatusStore dans l'ordinateur. Si le Transfert de Fichier est interrompu pour quelque raison, vous avez alors la possibilité de relancer le processus à partir de la position de fichier du dernier point de reprise (Reprise - Option : "depuis la position de dernier démarrage"). Grâce à cette fonction, il est possible d'économiser du temps lorsque, par exemple, la moitié d'un gros fichier a déjà été transféré.

Avec FT_RESTARTINFO_LIFETIME et FT_RESTARTINFO_CHECK (UC_HOSTCHAR_DEFAULT) configurez le moment auquel les fichiers StatusStore doivent être supprimés.

Afin de s'assure que le fichier cible correspond à une reprise réussie du fichier source, les données déjà transmises sont différenciées avec une somme de contrôle MD5. Lors de la création d'un point de reprise, la somme de contrôle MD5 est également déterminée et stockée dans le fichier StatusStore. Si le fichier partiellement transmis est, par exemple, modifié sur l'ordinateur de l'Agent destinataire, la somme contrôle serait alors différente et cela produirait une erreur lors de la reprise du processus de transfert.

Afin d'économiser du temps de transfert, aucune somme de contrôle MD5 n'est calculée pour les fichiers inférieurs à 1 Mo !

La méthode MD5 peut être désactivée avec le paramètre FT_USE_MD5 dans la Variable UC_HOSTCHAR_DEFAULT.

Les fichiers StatusStore sont stockés dans les répertoires suivants en fonction de la plateforme Agent :

Rubriques connexes :

Transfert de Fichier
Transfert de Fichier - Exécution
Fonctionnement multi-serveur
Connexion