Der Sender auf den Inventarservern überträgt die Absuchedateien vom ZENworks 7.3 Linux Management-Inventarserver auf den ZENworks 7 Server Management- oder den ZENworks 7 Desktop Management-Inventarserver. Die folgenden Abschnitte enthalten weitere Informationen:
Bei dem Sender handelt es sich um eine Java-Komponente, die auf einem ZENworks 7.3 Linux Management-Server ausgeführt wird. Der Sender ist ein Service, der vom ZEN Loader geladen wird.
Der Informationsfluss vom Sender verläuft beim Roll-up der Inventarinformationen folgendermaßen:
Der ZEN Loader startet den Sender auf dem Inventarserver. Zum geplanten Zeitpunkt des Roll-up-Plans verschiebt der Sender die .str-Dateien mit den Absuchedaten aus dem Enterprise Merge-Verzeichnis (entmergedir) in das Enterprise Push-Verzeichnis (entpushdir).
Der Sender komprimiert diese .str-Dateien in das Verzeichnis /entpushdir auf dem Inventarserver als .zip-Datei und löscht anschließend die .str-Dateien. Diese .zip-Datei wird zusammen mit der .prp-Datei wiederum in eine .zip-Datei komprimiert. Bei der .prp-Datei handelt es sich um eine interne Datei mit Informationen zu der .zip-Datei.
Der Sender löscht anhand des bei den Empfängereigenschaften für das Inventarserviceobjekt festgelegten Relevanzdatums der Absuchedaten die komprimierten .zip-Dateien im Verzeichnis /entpushdir, die vor dem angegebenen Relevanzdatum der Absuchedaten erstellt wurden. Dadurch werden unerwünschte Absucheinformationen entfernt, die beim Roll-up gesendet werden.
Der Sender sendet die komprimierten .zip-Dateien an den Empfänger, wobei die ältesten komprimierten Dateien zuerst gesendet werden.
Nach der Übertragung der .zip-Datei löscht der Sender die komprimierten Dateien aus dem Verzeichnis /entpushdir.
Wenn der Sender keine Verbindung zum Empfänger herstellen kann, versucht der Sender nach 10 Sekunden, erneut eine Verbindung herzustellen. Das Zeitintervall erhöht sich exponentiell um den Faktor 2. Nach 14 Wiederholungen versucht der Sender nicht mehr, eine Verbindung zum Empfänger herzustellen. Der Sender wiederholt den Vorgang während eines Zeitraums von ungefähr 23 Stunden, bevor die Verbindungsversuche eingestellt werden. Der Sender verarbeitet keine anderen Informationen, während die Verbindung hergestellt wird.
Der Sender komprimiert die .str-Datei mit den Absuchedaten in eine .zip-Datei. Diese .zip-Datei wird zusammen mit der .prp-Datei wiederum in eine .zip-Datei komprimiert. Für die Benennung der .zip-Datei (mit den .zip-Dateien und der .prp-Datei) gelten folgende Konventionen:
GeplanteUhrzeit_InventarServerName_BaumName_GespeicherterStatus.zip
Wobei gilt: GeplanteUhrzeit gibt an, an welchem Datum und zu welcher Uhrzeit die .zip-Datei erstellt wurde. Inventarservername bezieht sich auf den Inventarserver, auf dem die .zip-Datei komprimiert wurde. Baumname ist der eindeutige Name des Baums, in dem sich die .zip-Datei derzeit befindet. GespeicherterStatus bezieht sich auf den Speicherstatus der .zip-Datei, und zip ist die Dateierweiterung für die komprimierten Dateien. Der Wert für GespeicherterStatus lautet 0, 1 oder 2. Der Wert 0 gibt an, dass die .zip-Datei noch nicht gespeichert wurde. Der Wert 1 gibt an, dass die .zip-Datei zum ersten Mal auf dem Inventarserver gespeichert wurde. Der Wert 2 gibt an, dass die .zip-Datei bereits einmal gespeichert wurde.
Der Name der .zip-Datei ändert sich, und zwar je nachdem, ob die Datenbank mit dem Inventarserver verbunden ist.
Die .zip-Datei enthält die .zip-Dateien und eine Eigenschaftsdatei. Für den Namen der Eigenschaftsdatei gelten folgende Konventionen:
GeplanteUhrzeit_InventarServerName.prp
Die Eigenschaftsdatei enthält die geplante Uhrzeit, den Namen des Inventarservers und die Signatur. Mithilfe der Signatur kann die .zip-Datei beglaubigt werden.
Jede .zip-Datei kann maximal 50 .str-Dateien enthalten.