Composer 中的 ThingWorx 模型定義 > 建模 > 物範本 > 遠端範本 > 物件存在
物件存在
為了解決連線至 ThingWorx 平台的裝置範圍過於廣泛的問題，我們將「已連線」的概念從「目前使用 websocket 繫結」變更為了「連線正常」，也稱為物件存在。「物件存在」根據裝置的預期行為指示物件連線何時為「正常」。
ThingWorx AlwaysOn 裝置 (執行以 ThingWorx Edge SDK 為基礎的應用程式或 ThingWorx Edge MicroServer) 會繫結 websocket。如果一段時間未配置為離線，會一直可從 ThingWorx 平台接收訊息。從另一方面講，Axeda eMessage Agent 裝置會定期輪詢平台 ("ping")，只有在已連線且已繫結的情況下才能從平台接收訊息。這兩種主要類型的裝置都受「物件存在」的支援。
「物件存在」可跨裝置類別進行比較，且所有 ThingWorx 介面都提供支援。例如，某服務組織可能想要建立一個儀表板，來指示可用於服務呼叫的所有裝置或意外離線的所有裝置。ThingWorx SCM 延伸功能會使用「物件存在」來確定裝置是否連線「正常」(透過檢查名為 isReporting 的內容來判定)，以便能夠選取封裝並將其部署至裝置。
瞭解「物件存在」不會嘗試診斷裝置的整體狀況，這一點很重要。「物件存在」會顯示為單一布林值內容，這可讓 ThingWorx 在多種資產之間提供一致的體驗。
運作方式
從最一般的意義上講，定義為 RemoteThing 的任何裝置都具有下列新屬性
類型
名稱
描述
內容
isReporting
識別根據套用的「報告策略」，是否將裝置判斷為可用於「正常」通訊。
內容
reportingLastChange
識別上次變更 isReporting 值的時間。
內容
reportingLastEvaluation
識別上次對 isReporting 進行評估的時間。
組態
reportingStrategy
這是一個可定義演算法的物件，該演算法可用來確定裝置是否正在報告。
服務
EvaluateReporting
評估裝置是否正在報告，並相應設定 isReporting 內容。
服務
SetReportingStrategy
設定用於評估裝置是否正在報告的策略。
服務
GetReportingStrategy
取得目前用於評估裝置是否正在報告的策略。
用來確定裝置是否正在報告的精確演算法取決於特定 ReportingStrategy 物件。不過，一般流程如下：
1. EvaluateReporting 服務由某事件觸發
2. EvaluateReporting 隨後呼叫策略物件上的 ReportingAlgorithm 服務。
3. ReportingAlgorithm 根據特定演算法傳回布林值。
4. 根據 ReportingAlgorithm 服務的結果設定 isReporting 內容。
EvaluateReporting 服務
EvaluateReporting 服務會取用下列參數：
• eventName - 已導致重新評估報告狀態之事件的名稱。
• eventTime - 事件發生時間。
• source - 產生事件之物件的名稱。
• sourceProperty - 事件的來源內容。
• eventData - 事件的資料。
EvaluateReporting() 的所有參數都會直接傳遞至 ReportingStrategy.ReportingAlgorithm()
當在物件繫結或解除繫結期間執行此服務時：
• eventName 為 BindingEvent。
• eventData 包含在 isBound 金鑰下具有單一值的單一列，指示物件是已繫結還是已解除繫結 (若是繫結，則為 true，若是已解除繫結，則為 false)。
如果在此服務期間發生問題 (包含在 ReportingAlgorithm 中)，物件會更新為「未報告」，並會在 ApplicationLog 中新增訊息。
遠端範本
物件存在報告策略物件：安全性設定
物件存在：報告策略
物件存在：使用 ThingWorx Extension SDK 在 Java 中建立的自訂報告策略
這是否有幫助?