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 pro Ding.
Gesamtanzahl der gleichzeitigen Edge-kontrollierten Übertragungen auf der Plattform. Der Bereich liegt zwischen 1 und 1.000 Übertragungen. 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).
|
||
|
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. Der Bereich liegt zwischen 1 und 100 Übertragungen. 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.
|