Die Betriebssystem-Agenten haben die Fähigkeit Dateien zu übertragen. Dazu muss sowohl auf dem Quell- als auch auf dem Zielrechner ein Agent"Programm, das die Ausführung von Verarbeitungen auf Zielsystemen wie z.B. Rechner oder Geschäftslösungen ermöglicht. Auch ein eigener Objekttyp in der Automation Engine. [Früher ""Executor"" genannt.] Siehe auch ""Host""." installiert sein. Die Dateiübertragung erfolgt gesichert und verschlüsselt.
Mit Version 9.00A wurde der Ablauf von FileTransfers in der Automation EngineDiese Komponente steuert ein Automation Engine-System. Besteht aus verschiedenen Serverprozessen. 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 KommunikationsprozessTeil der Komponente Automation Engine. Kommunikationsprozesse bilden die Verbindung zu den Komponenten., 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. StatusZustand einer Aufgabe (z.B. aktiv, blockiert, in Generierung, usw.).-Nachrichten werden regelmäßig an die Automation Engine geschickt, damit der Fortschritt verfolgt werden kann. Im User Interface sehen Sie im Fenster Detail der FileTransferÜberträgt Dateien zwischen zwei Rechnern. Auch ein eigener Objekttyp in der Automation Engine.-AufgabeEin gestartetes Objekt, welches gerade durchgeführt wird. Aufgaben werden auch als Aktivitäten bzw. Tasks bezeichnet. 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 Quellagenten für jede einzelne Datei an, diese zu senden.
Der Administrator kann bestimmen, ob die Verbindung zwischen den beiden Agenten nach der Dateiübertragung wieder abgebaut werden soll. Dies geschieht in der VariableSpeichert oder ermittelt Werte dynamisch zur Laufzeit. Auch ein eigener Objekttyp in der Automation Engine. UC_HOSTCHAR_DEFAULT mit der Einstellung DISCONNECT_AFTER_FT.
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.
Aufbau der Verbindung
Der Sender-Agent versucht eine Verbindung zum Empfänger aufzubauen. Gelingt ihm dies nicht (zum Beispiel auf Grund von Firewall-Einstellungen), so benachrichtigt er die Automation Engine. Der Dateiübertragungsauftrag wird daraufhin an den Empfänger gesendet, der nun einen Verbindungsaufbau zum Sender versucht. Nach erfolgreicher Verbindung überträgt der Empfänger-Agent den Dateiübertragungsauftrag 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 angefordert.
BS2000:
Zuweisung des voraussichtlich benötigten Festplattenspeichers, wenn die Option Original-Datei-Attribute beibehalten im FileTransfer-ObjektTätigkeiten und Abläufe, welche die Automation Engine steuert, werden mit Hilfe von sogenannten Objekten abgebildet (siehe auch Aufgabe). aktiviert ist. Details hierzu finden Sie unter FileTransfer-Objekte definieren.
NSK:
Keine Speicherplatzprüfung
OS/390 -
Natives Dateisystem: Zuweisung mit Hilfe des Attributes SPACE für das FileTransfer-Ziel.
OS/390 -
USS-Dateisystem: Keine Speicherplatzprüfung
OS/400 -
Natives Dateisystem: Zuweisung, wenn entweder „Original-Datei-Attribute beibehalten“ gesetzt oder das Attribut SIZE für das Ziel angegeben wurde
OS/400 -
IFS-Dateisystem: Prüfung des verfügbaren Speicherplatzes
UNIX:
Abhängig vom ini-Parameter ft_check_free_disk_space=
VMS:
Prüfung des verfügbaren Speicherplatzes
Windows:
Abhängig vom ini-Parameter ft_check_free_disk_space=
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.
FileTransfers werden durch Verbindungsfehler zwischen der Automation Engine und den Agenten nicht beeinflusst. 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-BenutzerIn einem Automation Engine-System bezieht sich ein Benutzer auf eine Instanz eines Benutzer-Objektes, aber ganz allgemein ist ein Benutzer auch die Person, die mit Automic-Produkten arbeitet. Jedes Benutzer-Objekt hat eine Benutzerkennung und bestimmte Zugriffsrechte auf unterschiedliche Bereiche eines Automation Engine-Systems und der zugehörigen Produktpalette. In der Automation Engine werden die Zugriffsrechte über Rechte und Privilegien, in Decision über Benutzerrollen und EventBase-Rechte und in der ARA-Webanwendung über Objektberechtigungen geregelt. Zentral können diese Zugriffsrechte in den Funktionen der AWI-Benutzerverwaltung geregelt werden. Weitere Informationen sind im Kapitel Unified User Management vorhanden. „root“ durchgeführt werden. Im neuen Protokoll tritt dieser Fehler nicht mehr auf, da FileTransfers unter UNIX immer unter dem Benutzer laufen, der im LoginAnmeldedaten für Zielsysteme. Auch ein eigener Objekttyp in der Automation Engine.-Objekt angegeben wurde.
Um eine zuverlässige Übertragung von Dateien zu gewährleisten, stehen folgende Verfahren bei FileTransfers zur Verfügung:
FileTransfer - Ablauf | Erklärung |
---|---|
Ü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-WiederanlaufWiederholung einer bereits gelaufenen Objekt-Durchführung, wobei einige Besonderheiten gegenüber einem erneuten Start gelten. |
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, dass 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 | Das Temp-Verzeichnis des Agenten |
FTNNNNNNN.sts wobei NNNNNNN die RunID"Kurzform für ""laufende Nummer"". Hierbei handelt es sich genauer um eine Zahl, welche die Durchführung einer Aufgabe eindeutig kennzeichnet. Die RunID kann zwischen 7 und 10 Stellen aufweisen. Sie wird von der Komponente Automation Engine vergeben." des FileTransfers ist, umgewandelt in eine 7-stellige Buchstabenfolge. Diese kann mit dem ScriptEigener Objekttyp in der Automation Engine-Sprachmittel ALPHA2RUNNR in die normale 10-stellige RunID umgewandelt werden. |
StatusStore-Datei pro FileTransfer |
BS2000 | Das Temp-Verzeichnis des Agenten | FTNNNNNNN.sts | StatusStore-Datei pro FileTransfer |
Unix/VMS | Das Temp-Verzeichnis des Agenten | FTNNNNNNN.sts | StatusStore-Datei pro FileTransfer |
OS/400 |
Abhängig vom INI-Datei parameter 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) |
Die INI-Datei des Agenten: Sektion [FT-STATUS-STORE] |
4 StatusStore-Dateien für alle Wiederanlauf-Informationen |
z/OS |
StatusStore Dataset |
Ein StatusStore-Dataset für alle Wiederanlauf-Informationen |
Siehe: