Untersystem für Dateiübertragung
Das Untersystem für Dateiübertragung stellt die erforderlichen Methoden bereit, um Dateiübertragungen zwischen Remote-Dingen, Datei-Repositorys und Verbundservern zu verwalten.
Wenn nicht anders angegeben, erfordern Dateiübertragungen zwischen einem Edge-Client und ThingWorx Platform, dass der Client von Anfang bis Ende der Übertragung verbunden ist. ThingWorx Platform Dateiübertragungen können initiiert werden, während der Edge-Client getrennt ist, indem Sie ThingWorx Platform anweisen, die Kopie mit der warteschlangenfähigen Funktionalität auszuführen. Warteschlangenfähige Dateiübertragungen werden in einer Offline-Warteschlange platziert und ausgeführt, wenn der Agent verbunden ist.
 |
Wenn Sie PostgreSQL als Persistenzanbieter verwenden, wird die Offline-Warteschlange persistent gemacht, um Failover für ThingWorx Hochverfügbarkeit zu unterstützen.
|
Nachdem die Übertragung initiiert wurde, kann der Edge-Client nicht getrennt werden, oder die Übertragung schlägt fehl. Dateiübertragungen, die in die Warteschlange gestellt werden, laufen ab, wenn sie nicht vor dem Konfigurationseinstellungswert Time to live (in Sek.) der Dateiübertragung in der Warteschlange beginnen.
Im Allgemeinen werden Dateiübertragungen durch ThingWorx Platform kontrolliert. Sie können jedoch Edge-kontrollierte Dateiübertragungen durchführen, die durch das Hinzufügen der Dingform EdgeControlled zum Remote-Ding aktiviert werden, das Teil der Dateiübertragung ist. Für Edge-kontrollierte Dateiübertragungen muss entweder die Quelle oder das Ziel als FileRepository-Ding in ThingWorx Platform festgelegt sein. In einer Edge-kontrollierten Dateiübertragung wird die Übertragung vom Edge-Client kontrolliert. Der Edge ruft den Dienst Touch auf, um den Zeitstempel der Dateiübertragung fortlaufend zu aktualisieren. Wenn der Edge dies nicht tut, erfolgt ein Timeout der Dateiübertragung in ThingWorx Platform. Der Edge gibt an, ob die Übertragung erfolgreich war oder mit einem Fehler abgeschlossen wurde.
Sie können Kontext einbetten, indem Sie den Parameter metadata beim Initiieren der Dateiübertragung angeben. Dieses Feld ist ein JSON-Objekt, das jede beliebige JSON enthalten kann. Bestimmte grundlegende Funktionen führen dazu, dass ThingWorx Platform dieses Feld verwendet, um zusätzliche Anweisungen für den Edge-Client bereitzustellen. Für diese Übertragungen sollten die Informationen im Feld metadata nur von ThingWorx Platform geändert werden.
Dateiübertragung zwischen Verbundservern
Gehen Sie wie folgt vor, um Dateien zwischen Verbundservern zu übertragen:
|
|
Ein Schrägstrich (/) ist das empfohlene Pfadtrennzeichen für Datei-Repositories.
|
1. Konfigurieren Sie einen Verbund zwischen ThingWorx ServerA und ThingWorx ServerB. Weitere Informationen finden Sie unter Verbund konfigurieren.
2. Fügen Sie ThingA zu ServerA unter Verwendung der Dingvorlage FileRepository hinzu.
a. Aktivieren Sie das Kontrollkästchen Veröffentlicht für ThingA, damit es für andere ThingWorx Server zugänglich ist.
3. Fügen Sie RemoteThingA zu ServerB unter Verwendung der Dingvorlage RemoteThingWithFileTransfer hinzu.
a. Geben Sie im Feld ID ThingA@ServerA ein.
4. Kopieren Sie Ihre Datei (beispielsweise test.txt) in den Stammordner SystemRepository von ServerB.
5. Öffnen Sie FileTransferSubsystem auf ServerB, und führen Sie den Dienst copy mit den folgenden Parameterwerten aus:
◦ sourceRepo: SystemRepository
◦ sourcePath: /
◦ sourceFile: test.txt
◦ targetRepo: RemoteThingA
◦ targetPath: /
◦ targetFile: test.txt
◦ Ändern Sie die Standardwerte der anderen Parameter nicht.
6. Rufen Sie den Ordner /ThingworxStorage/repository/ThingA auf ServerA auf, und prüfen Sie, ob die Datei test.txt erfolgreich dorthin kopiert wurde.
Konfiguration
|
Dateiübertragungseinstellungen
|
Datentyp
|
Standard
|
Hinweise
|
||
|---|---|---|---|---|---|
|
Mindest-Anzahl der dem Dateiübertragungspool zugeordneten Threads
|
NUMBER
|
10
|
Definiert die Kern-Poolgröße für ThreadPoolExecutor. Dieser Thread-Pool wird verwendet, um die plattformgesteuerte Dateiübertragungslogik zu koordinieren.
|
||
|
Maximale Anzahl der dem Dateiübertragungspool zugeordneten Threads
|
NUMBER
|
10
|
Definiert die maximale Thread-Poolgröße für ThreadPoolExecutor.
Asynchrone Dateiübertragungen könnten verloren gehen, wenn ThingWorx ausfällt. Nehmen Sie beispielsweise an, diese Einstellung hat den Standardwert 10, und 50 Dateiübertragungen mit längerer Ausführungsdauer werden gesendet. Wenn ThingWorx ausfällt, gehen 40 Dateien verloren.
|
||
|
Maximale Anzahl an Warteschlangeneinträgen bevor ein neuer Arbeitsthread hinzugefügt werden kann
|
NUMBER
|
100
|
Definiert den oberen Grenzwert für die Anzahl der Einträge in der Warteschlange, die in ThreadPoolExecutor verwendet wird.
Dadurch wird die Anzahl aktiver Übertragungen beschränkt, die gleichzeitig zulässig sind.
|
||
|
Leerlauf-Thread-Timeout (Sek.)
|
NUMBER
|
600000
|
Definiert, wie lange Leerlauf-Threads in ThreadPoolExecutor beibehalten werden sollen. Der Pool beendet Threads und kehrt nach der angegebenen Zeit zur Kern-Poolgröße zurück.
|
||
|
Dateiübertragungs-Leerlauf-Timeout (Sek.)
|
NUMBER
|
30
|
Während des Dateiübertragungsprozesses wird zwischen jedem Schritt (checksum, ReadFromBinaryFile, WriteToBinaryFile, validation) das Leerlauf-Timeout geprüft. Dauert der Schritt länger als die definierte Timeout-Zeit, so wird die Übertragung abgebrochen.
|
||
|
Maximale Dateiübertragungs-Blockgröße (Bytes)
|
NUMBER
|
128000
|
Definiert die Anzahl der angeforderten Bytes für Operationen vom Typ ReadFromBinaryFile und WriteToBinaryFile. Dabei handelt es sich um die Blockgröße für jeden Schreibvorgang.
Diese Variable legt eine maximale Blockgröße während der Dateiübertragung auf Systemebene fest.
Die EMS-Konfiguration hat weiterhin Vorrang. Wenn buffer_size in der EMS-Konfiguration jedoch größer als der in dieser Variable angegebene Wert ist, kappt diese Variable diese Blockgröße. Wenn größere Blockgrößen (128 KB) über EMS konfiguriert werden, muss dieser Wert erhöht werden. Die maximale Kompilierungsebene ist 1 MB.
|
||
|
Maximale Dateiübertragungsgröße (Bytes)
|
NUMBER
|
100000000
|
Definiert die maximale Anzahl von Bytes, die die Operation "Kopieren" unterstützt.
Wenn die Quelldatei größer als dieser Wert ist, schlägt die Übertragung fehl, und es wird eine Fehlermeldung angezeigt.
|
||
|
Maximal zulässige Dateiübertragungen in der Offline-Warteschlange
|
NUMBER
|
50000
|
Definiert die maximale Anzahl von Dateiübertragungen in der Offline-Warteschlange, die im System zulässig sind.
|
||
|
Maximal zulässige Dateiübertragungen pro Ding in der Offline-Warteschlange
|
NUMBER
|
10
|
Definiert die maximal zulässige Anzahl von Dateiübertragungen in der Offline-Warteschlange, die pro Ding zulässig sind.
|
||
|
Time to live (in Sek.) der Dateiübertragung in der Warteschlange
|
NUMBER
|
86400
|
Definiert die maximale Zeit, die eine Dateiübertragung in der Warteschlange in der Offline-Warteschlange vorhanden sein kann.
Nach dieser angegebenen Zeit wird eine Dateiübertragung aus der Offline-Warteschlange entfernt.
|
||
|
Gesamtzahl der maximal zulässigen Edge-kontrollierten Dateiübertragungen
|
NUMBER
|
500
|
Definiert die im System maximal zulässigen aktiven Edge-kontrollierten Dateiübertragungen.
Gesamtanzahl der gleichzeitigen Edge-kontrollierten Übertragungen auf der Plattform. Dies ist ein anderer Wert als die maximal zulässigen Always-On-Übertragungen (die durch die Einstellung Maximale Anzahl an Warteschlangeneinträgen bevor ein neuer Arbeitsthread hinzugefügt werden kann kontrolliert werden).
Die Obergrenze dieser Eigenschaft wird über die Einstellung MaxConcurrentFileTransfersEdgeCtrl in der Datei platform-settings.json gesteuert. Der Standardwert ist 1000.
|
||
|
Gesamtzahl der maximal zulässigen Edge-kontrollierten Dateiübertragungen pro Ding
|
NUMBER
|
2
|
Definiert die maximale Anzahl gleichzeitiger Übertragungen, die zu oder von einem Edge-kontrollierten Ding zulässig sind. Beispielsweise bedeutet der Wert 2, dass ein Edge-kontrolliertes Ding nur zwei aktive Übertragungen gleichzeitig haben kann (Hochladen oder Herunterladen). Nachfolgende Anforderungen zum Entfernen des Dateiübertragungsausgangs aus der Warteschlange werden zurückgewiesen, bis ausreichende Kapazität vorhanden ist.
|
||
|
Leerlauf-Timeout für Edge-kontrollierte Dateiübertragungen (Sek.)
|
NUMBER
|
600
|
Definiert die maximale Zeit, die ein aktiver Job aktiv bleiben kann, ohne bearbeitet zu werden (z.B. durch Datenübertragung oder Jobstatusaktualisierung). Der Bereich liegt zwischen 1 und 3.600 Sekunden. Dies ähnelt dem Leerlauf-Timeout für Always-On-Übertragungsjobs, dauert in der Regel aber länger, um den Ping-Zyklus der Abrufgeräte zu berücksichtigen.
|
||
|
File Transfer Cleanup Frequency (sec)
|
NUMBER
|
10
|
Definiert die Häufigkeit der Ausführung der Bereinigungsaufgabe zum Auswerten der Dateiübertragungsvorgänge.
Die Bereinigungsaufgabe entfernt veraltete und abgelaufene Jobs aus der Tabelle der aktiven Aufträge. Diese Aktion gibt die Dateiübertragungs-Slots frei, was anderen Operationen in der Warteschlange hilft. Die empfohlenen Mindest- und Höchstwerte müssen zwischen 1 Sekunde und 60 Sekunden betragen.
Der Wert für diese Einstellung muss nach eigener Beurteilung festgelegt werden. Der Standardwert, 10 Sekunden, soll für die meisten Anwendungsfälle funktionieren.
• Bei einem sehr kleinen Wert wird die Hintergrundaufgabe zu häufig gestartet. Dabei werden alle derzeit aktiven Dateiübertragungsjobs aus dem Cache abgerufen und im Hinblick auf ein Auslaufen ausgewertet. Dies führt zu unnötigen Berechnungen und Belastungen der Caches.
• Bei einem sehr hohen Wert wird diese Aufgabe weniger häufig gestartet, und Dateiübertragungen, die die gültige Reservierung haben, könnten feststecken und die Reservierung möglicherweise nicht rechtzeitig wieder freigeben. Dies könnte sich möglicherweise auf die gesamten Dateiübertragungsvorgänge auswirken, wenn viele Operationen feststecken, wie instabiles Netzwerk, Gerät wird nicht verbunden usw.
|