Automation Engine intern > FileTransfer > FileTransfers – Workflow

 Ablauf von FileTransfers

Die Betriebssystem-Agenten haben die Fähigkeit Dateien zu übertragen. Dazu muss sowohl auf dem Quell- als auch auf dem Zielrechner ein Agent installiert sein. Die Dateiübertragung erfolgt selbstverständlich gesichert und verschlüsselt.

Mit Automation Engine Version 9.00A wurde der Ablauf von FileTransfers optimiert und verbessert. Dieses neue Protokoll kommt jedoch nur dann zum Einsatz, wenn die beteiligten Agenten die Version 9.00A (oder höher) aufweisen. Weist einer der Agenten eine niedrigere Version auf, so wird aus Kompatibilitätsgründen das alte Verfahren verwendet.

Altes FileTransfer-Protokoll (bis 8.00A)

Bevor die Dateiübertragung starten kann, benötigen die beiden Agenten eine Verbindung. Einer der Arbeitsprozesse wendet sich daher an den Kommunikationsprozess, der mit dem Quell-Agenten verbunden ist, und teilt ihm die Verbindungsanforderung mit. Der Kommunikationsprozess leitet die Nachricht an den Agenten weiter. Mit den darin enthaltenen Informationen versucht der Agent sich mit dem Ziel-Agenten zu verbinden.

Gelingt der Verbindungsaufbau beispielsweise auf Grund von Firewall-Einstellungen nicht, so nimmt die Automation Engine mit der gleichen Methode Kontakt zum Ziel-Agenten auf. Dieser versucht nun, ob er eine Verbindung zum Quell-Agenten aufbauen kann.

 

 

Sobald die beiden Agenten miteinander verbunden sind, kann die Dateiübertragung beginnen. Status-Nachrichten werden regelmäßig an die Automation Engine geschickt, damit der Fortschritt verfolgt werden kann. Im UserInterface sehen Sie im Detailfenster der FileTransfer-Aufgabe die bereits übertragenen Bytes der Datei.

Im Gegensatz zum neuen FT-Protokoll, werden die Dateien aller FileTransfers über eine Verbindung (FT-Verbindung) gesendet. Dabei kann es auch vorkommen, dass abwechselnd Blöcke von unterschiedlichen Dateien übertragen werden. Die Automation Engine überwacht den kompletten FileTransfer-Vorgang und weist den Quell-Agenten für jede einzelne Datei an, diese zu senden.

 

Ob die Verbindung zwischen den beiden Agenten nach der Dateiübertragung wieder abgebaut werden soll, kann der Administrator mit der Einstellung DISCONNECT_AFTER_FT in der Variable UC_HOSTCHAR_DEFAULT bestimmen. 

Neues FileTransfer-Protokoll (ab 9.00A)

Ab AE-Version 9 sendet die Automation Engine dem Quell-Agenten den kompletten FileTransfer-Auftrag (inklusive Wildcard-Angaben bei teilqualifizierten FileTransfers). Die Auflösung des Auftrages (Ermittlung der Dateien) übernimmt der Sender-Agent.

 

 

Verbindungsaufbau

Der Sender-Agent versucht eine Verbindung zum Empfänger aufzubauen. Gelingt ihm dies zum Beispiel auf Grund von Firewall-Einstellungen nicht, so benachrichtigt er die Automation Engine. Der FT-Auftrag wird daraufhin an den Empfänger gesendet, der nun einen Verbindungsaufbau zum Sender versucht. Nach erfolgreicher Verbindung überträgt der Empfänger-Agent den FT-Auftrag an den Sender.

 

 

Speicherplatz-Prüfung

Vor dem Beginn eines FileTransfers wird abhängig vom Betriebssystem eine Überprüfung durchgeführt, ob genügend Platz auf der Zielplattform verfügbar ist bzw. dieser allokiert.

Abwicklung von FileTransfers

Beim neuen Protokoll wird für jeden FileTransfer eine eigene Verbindung zwischen den Agenten aufgebaut. Die Dateien werden immer hintereinander durch eine Verbindung gesendet. Wenn der Agent dies unterstützt, wird jeder FileTransfer in einem eigenen Thread bzw. Prozess abgewickelt. Dadurch laufen mehrere FileTransfers komplett unabhängig voneinander.

Da die Verbindungen nach Abschluss der FileTransfers selbstständig wieder abgebaut werden, hat die Einstellung DISCONNECT_AFTER_FT in der Variable UC_HOSTCHAR_DEFAULT beim neuen Protokoll keine Wirkung.

Threads werden von den Agenten folgender Betriebssysteme unterstützt:

Bei NSK wird jeder FileTransfer über einen eigenen Prozess abgewickelt. Um dies zu ermöglichen besitzt der NSK-Agent einen zweiten Port speziell für FileTransfers.

Wenn es zu Verbindungsfehler zwischen Automation Engine und Agenten kommt, werden die FileTransfers trotzdem unbeeinflusst fortgesetzt. Wenn die Verbindung wieder hergestellt werden konnte, wird der tatsächliche Status des FileTransfers an die Automation Engine übermittelt.

Bei FileTransfers mit UNIX-Agenten führt die NFS-Sicherheitseinstellung "root squash" zu Problemen, wenn das alte FT-Protokoll eingesetzt wird.Der Grund dafür ist, dass FileTransfers immer unter dem UNIX-Benutzer "root" durchgeführt werden. Im neuen Protokoll tritt dieser Fehler nicht mehr auf, da FileTransfers unter UNIX immer unter dem Benutzer laufen, der im Login-Objekt angegeben wurde.

 

 

Um eine zuverlässige Übertragung von Dateien zu gewährleisten, stehen folgende Verfahren bei FileTransfers zur Verfügung:

Übertragungssicherheit

Die Richtigkeit der übertragenen Daten wird durch einer im Datenstrom enthaltenen MD5-Prüfsumme sichergestellt. Dabei werden die Daten paketweise geprüft.

Konsistenzprüfung beim FileTransfer-Wiederanlauf

Im Gegensatz zum alten Protokoll können einzelne Dateien eines FileTransfers nicht gezielt wiederholt werden. Es besteht jedoch die Möglichkeit, fehlerhafte FileTransfers ab dem letzten Wiederanlaufpunkt zu wiederholen.

Wiederanlaufpunkte werden vom Agenten während der Dateiübertragung in einem bestimmten Zeitintervall erstellt (Einstellung FT_RESTARTINFO_INTERVAL in der Variable UC_HOSTCHAR_DEFAULT).Diese Informationen speichert der Agent in sogenannte StatusStore-Dateien lokal auf seinem Rechner. Bricht der FileTransfer aus irgendeinem Grund ab, so haben Sie die Möglichkeit, diesen ab der Dateiposition des letzten Wiederanlaufpunktes zu wiederholen (Wiederanlauf - Option: "Ab letzter Restartposition"). Durch diese Funktion kann Zeit gespart werden, wenn zum Beispiel die Hälfte einer großen Datei bereits übertragen wurde.

Mit FT_RESTARTINFO_LIFETIME und FT_RESTARTINFO_CHECK (UC_HOSTCHAR_DEFAULT) stellen Sie ein, wann StatusStore-Dateien gelöscht werden sollen.

Um sicherzustellen, dass die Zieldatei nach einem erfolgreichen Wiederanlauf der Quelldatei entspricht, werden die bereits übertragenen Daten davor mit einer MD5-Prüfsumme verglichen.Bei der Erstellung eines Wiederanlauf-Punktes wird auch die MD5-Prüfsumme ermittelt und in der StatusStore-Datei abgelegt. Wurde die teilweise übertragene Datei beispielsweise am Rechner des Empfänger-Agenten verändert, würde sich die Prüfsumme unterscheiden und es zum Fehler beim Wiederanlauf kommen.

Um Übertragungszeit zu sparen, werden für Dateien, die kleiner als 1MB sind, nie MD5-Prüfsummen berechnet!

Das MD5-Verfahren kann mit der Einstellung FT_USE_MD5 in der Variable UC_HOSTCHAR_DEFAULT deaktiviert werden.

 

Die StatusStore-Dateien werden abhängig von der Agenten-Plattform in folgende Verzeichnisse abgelegt: 

Plattform Verzeichnis Dateiname Besonderheit
Windows Temp-Verzeichnis des Agenten

FTNNNNNNN.sts

Bei NNNNNNN handelt es sich um die RunID des FileTransfers, umgewandelt in eine 7-stellige Buchstabenfolge. Diese kann mit dem Sprachmittel ALPHA2RUNNR in die normale 10-stellige RunID umgewandelt werden.

StatusStore-Datei pro FileTransfer
BS2000 Temp-Verzeichnis des Agenten FTNNNNNNN.sts StatusStore-Datei pro FileTransfer
Unix/VMS Temp-Verzeichnis des Agenten FTNNNNNNN.sts StatusStore-Datei pro FileTransfer
OS/400

Abhängig vom INI-Dateiparameter store_type=

IFS: FTNNNNNNN.sts
QSYS: Objekt mit dem Namen FTNNNNNNN und dem Typ USRSPC
StatusStore-Datei pro FileTransfer
NSK

Subvolume in der Konfigurationsdatei angegeben (siehe Installation des NSK-Agenten)

INI-Datei des Agenten:

Sektion [FT-STATUS-STORE]

4 StatusStore-Dateien für alle Wiederanlauf-Informationen
z/OS  

Status-Store Dataset

Siehe: Installation des z/OS-Agenten

Ein StatusStore-Dataset für alle Wiederanlauf-Informationen

 

Siehe auch:

 


Automic Documentation - Tutorials - Automic Blog - Resources - Training & Services - Automic YouTube Channel - Download Center - Support

Copyright © 2016 Automic Software GmbH