Edge 控制的檔案傳輸
Axeda Agent / Platform 啟動的檔案上載
如圖所示，
• 在步驟 2 中，執行了下列輸入驗證。
◦ 如果工作由 Edge 控制，驗證是否超過最大同步傳輸數以及每個物件的同步傳輸數。
◦ 若未超過，即會將工作排入佇列，以在稍後傳輸。否則，複製會失敗，且工作不會排入佇列。
• 在「輸出」期間，即在步驟 5 中：
◦ 確定是否有任何下載、上載、SCM 操作或遠端內容寫入操作要執行。
◦ 檔案傳輸只能在未超出傳輸限制的情況下開始。
• 在「建立」或「寫入至」二進位檔案期間，即在步驟 8 中，鎖定檔案以防寫入。如果這是最後一個內容塊，且提供了加總核對碼，則會對其進行驗證。
• 將工作標記為失敗或完成。此外，驗證加總核對碼 (若提供)。
ThingWorx Platform 啟動的檔案下載
如圖所示，
• 在檔案「複製」期間，即在步驟 1 中，執行了下列輸入驗證。
◦ 如果工作由 Edge 控制，驗證是否超過最大同步傳輸數以及每個物件的同步傳輸數。
◦ 若未超過，即會將工作排入佇列，以在稍後傳輸，否則，複製會失敗，且工作不會排入佇列。
• 在「輸出」期間，即在步驟 4 中，
◦ 確定是否有任何下載/上載/SCM 操作/遠端內容寫入操作要執行。
◦ 檔案傳輸只能在未超出傳輸限制的情況下開始。
• 在「建立」或「寫入至」二進位檔案期間，即在步驟 7 中，鎖定檔案以防讀取。
• Platform 相應將工作標記為失敗或完成。
重要的可調整參數
• 必須仔細調整「檔案傳輸子系統」中的組態設定，才能使檔案傳輸實現良好的同步性。其中一些設定如下所列。如需詳細資訊，請參閱檔案傳輸子系統
◦ 所允許的 Edge 控制的最大檔案傳輸總數 → Platform 中可用於取消將工作排入佇列及移至使用中佇列的最大同時檔案傳輸數。如果您需要更高的同時度，此值必須更高。
◦ 每個物件所允許的 Edge 控制的最大檔案傳輸總數 → Platform 中可用於取消將工作排入佇列及移至使用中佇列之每個物件的最大同時檔案傳輸數。如果您的物件較少，而每個物件的要傳輸的檔案數較大，增加此值可能會很有用。
 | 增加此值可能會導致裝置之間最大同時檔案傳輸中可用位置的不均等分佈。 |
◦ 離線佇列內所允許的最大檔案傳輸 → 如果檔案傳輸上載速率非常高，而處理速度相較而言稍慢一些，則此值必須較高，這樣才能使工作保留在離線工作中，而不是遭到拒絕。
◦ 離線佇列內每個物件所允許的最大檔案傳輸 → 如果每個物件的檔案傳輸上載速率非常高，而處理速度相較而言稍慢一些，則此值必須較高。這樣才能使工作保留在離線工作中，而不是遭到拒絕。
• Edge 控制的檔案傳輸使用 WSExecutionProcessor 執行緒集區執行。因此，必須有足夠的執行緒才能進行檔案傳輸。使用 WSExecutionProcessingSubsystem 中的「執行處理器設定」可調整此執行緒集區。如需詳細資訊，請參閱 WebSocket 執行處理子系統。
• 如需有關調整 eMessage Connector 的詳細資訊，請參閱微調 eMessage Connector。
最佳實務
• ThingWorx Platform 支援同時在「檔案存放庫」中讀取與寫入檔案。為了防止資料損毀並確保一致性，Platform 在讀取/寫入操作期間必須鎖定檔案與目錄。避免寫入相同目錄或同時寫入多個檔案可提供更高的同時處理能力並提升檔案操作的輸送量。
• 針對大量檔案傳輸，檔案輸入/輸出必須能夠處理同時讀取/寫入操作，而且必須放置在與 /ThingworxPlatform 不同的儲存區中。
• 持續監視檔案傳輸效能。請參閱指標文件集。
• 應用程式開發者應注意 ThingWorx 訂閱與檔案傳輸操作之間的關係，因為與檔案傳輸事件完成相關之輸入/輸出量較大的服務執行將會利用用於快速執行操作的有限 TWEventProcessor 執行緒。請相應調整 TWEventProcessor 執行緒集區設定，並確保基礎結構效能，以使其他訂閱執行效能不受影響。