建立、實行及測試服務
物件服務是「物件」可以執行的功能。服務由混搭在 ThingWorx Platform 內部使用，其可從具有適當存取權的任何外部來源實現。您只能在下列 ThingWorx 實體上定義服務：
• 物件
• 物範本
• 物形式
• 資源
• 驗證器
服務會透過 JavaScript、SQL 或 Java 實行。
 |
Java 僅適用於延伸功能。
|
服務可透過 URL、REST 用戶端解決方案或 ThingWorx 中的另一個服務呼叫。
請在 ThingWorx 中為您的模型建立自訂服務，以符合專案的需求。
建立及實行服務的最佳作法
建立及實行服務時，請遵循下列最佳作法：
• 為您的服務定義命名慣例。請記住以下幾點：
◦ 請為服務提供有邏輯、有意義的名稱與描述。
◦ 請跨服務使用標準命名法。例如，在服務名稱前面加上動詞與服務描述。下面是一些動詞範例：
|
動詞
|
描述
|
|---|---|
|
Get
|
從資料庫擷取值。
|
|
Set
|
設定資料庫項目的值。
|
|
Query
|
從資料庫傳回一組記錄。
|
|
Add
|
將記錄新增至資料庫。
|
|
Update
|
更新資料庫中的記錄。
|
|
Delete
|
刪除資料庫中的記錄。
|
|
Validate
|
驗證資料庫中的記錄。
|
|
Purge
|
清除資料庫中的記錄。
|
|
Create
|
在資料庫中建立一組記錄。
|
|
Import
|
將資料匯入至資料庫。
|
|
Export
|
將資料從資料庫中匯出。
|
|
Parse
|
剖析資料。
|
例如：對於擷取歷史資料的服務，建議名稱為 getHistory，而非 History。
◦ 請避免使用不明確的名稱。
◦ 請盡量避免使用長服務名稱。
如需詳細資訊，請參閱 命名實體部份。
• 將常用內容與服務編組到單一實體中，最好是「物形式」。
• 請盡可能在物形式中實行服務。
|
|
建議您使用物形式來定義内容與服務。如果您在「物範本」中定義內容與服務，則很難將其定義移至「物形式」。
|
• 為諸如使用者介面、企業邏輯與資料擷取等不同層設計服務。不同層中的服務擁有不同的責任。下圖提供不同層中的責任範例：
• 編寫服務時，請嘗試重複使用 ThingWorx 程式碼片段程式庫中的可用程式碼片段。如果您對任何程式碼片段的使用方式不確定，請先進行測試，然後再用於服務中。
• 建立輸出設定為 JSON 的服務時，請注意下列事項：
◦ 如果內容的值為 null 或 undefined，則不會在結果中傳回它們。
例如：
var test = {
test1: "aaa",
test2: 123,
test3: null,
test4: undefined
};
var result = test;
test1: "aaa",
test2: 123,
test3: null,
test4: undefined
};
var result = test;
輸出：{"test1": "aaa", "test2": 123}
◦ 如果內容是 JSON 物件，並將其設定為 null，則會在結果中將其傳回。
例如：
var test = {
test1: "aaa",
test2: 123,
test3: null,
test4: undefined,
"line_categories": [ null ]
};
var result = test;
test1: "aaa",
test2: 123,
test3: null,
test4: undefined,
"line_categories": [ null ]
};
var result = test;
輸出：{"test1": "aaa", "test2": 123, "line_categories": [ null ]}
• 如果您預期服務會花費較長時間完成，請確保使用者無法同時觸發服務多次。
• 如果服務以混搭中的事件觸發器為基礎，請使用 ServiceInvokeCompleted 事件，以在解決方案中允許資料流。
• 若要重新整理混搭中的資料，建議使用「自動重新整理」小器具或 GetProperties 服務。
如果混搭使用 GetProperties 服務且瀏覽器支援 WebSocket，瀏覽器會自動從伺服器即時接收更新內容的值。在此情況下，不需要使用「自動重新整理」函數。只有在從服務內容面板中選取「可用時自動更新值」核取方塊的情況下，此功能才可用。
如果您使用「自動重新整理」函數，PTC 建議將「自動重新整理」函數設定為最低值：15 秒，以免對系統造成負擔。
| | 請勿使用伺服器端延遲服務，因為可能會導致封鎖其他服務。這可能會導致解決方案當機。 |
• 針對執行時間的簡單轉換，建議使用「運算式」小器具，而要使用服務。
例如，如果您以 °C 為單位顯示溫度並想讓使用者能夠以 °F 為單位查看該溫度，請使用「運算式」小器具。
• 請新增檢查至程式碼，以免使用者可能會收到錯誤。
例如，如果您的程式碼需要執行幾個輸入參數，請建立檢查以確保這些輸入參數在執行服務時不為空值。
• 如果您的解決方案將本地化，且 UI 元素中有文字會根據服務結果動態變更，請確保您不會對將顯示在混搭中之服務中的文字值進行硬式編碼。這是因為傳回文字的服務結果不需要本地化。如此，您在未來也能更輕鬆地維護及修改 UI 文字。
• 建立自訂服務時，決定哪些使用者或使用者群組應擁有呼叫此服務的權限。如需詳細資訊，請參閱使用可見度與權限保護在 ThingWorx Platform 上所建構解決方案的安全。
• 執行服務的一個可能結果是建立映像實體。映像實體會透過程式碼/指令編寫動態建立，而不是從 ThingWorx Composer 建立。建立映像實體是一種錯誤的作法。如需詳細資訊，請參閱建立與刪除映像實體。
• ThingWorx Platform 上的預設指令集逾時設定為 30 秒。如果指令集的執行時間比預設設定長，則 ThingWorx Platform 會終止執行。ThingWorx 管理員可以在 platform-settings.json 檔案的基本設定部份配置指令集逾時。
測試服務的最佳作法
測試服務時，請遵循下列最佳作法：
• 在建構時，以增量的方式測試您的服務。在適當請況下，請使用指令集記錄器訊息。
| | 具有無限迴圈的任何服務都可能會關閉 ThingWorx 伺服器。 |
• 在測試服務時，檢查記錄檔中是否有錯誤訊息。這對於訂閱中的服務而言特別有用。下列記錄檔很有用：
◦ ErrorLog.log - 提供詳細的錯誤堆疊追蹤
◦ ScriptErrorLog.log - 提供服務前後關聯資訊 (堆疊錯誤行號)
只有在您於「記錄子系統」子系統的「組態」標籤中選取「啟用指令集堆疊追蹤」核取方塊時，錯誤才會記錄在此檔案中。
| | 上述檔案可在 ThingworxStorage/logs 資料夾中找到。您必須擁有對 ThingWorx 伺服器的存取權，才能讀取這些檔案。 |
• 若從混搭呼叫服務，請在 Composer 中與混搭中對其進行測試。
• 若執行服務需要使用者輸入，您可以使用「驗證器」函數。
• 使用可在瀏覽器中找到的「開發者工具」檢查服務的結果。當您要偵錯在混搭中執行的服務序列時，此工具很有用。此工具會在該特定執行的前後關聯中顯示服務結果。
小秘訣
• 如果您要搜尋服務，請勿在「編輯」模式下開啟實體。請使用實體名稱左側的「預覽」連結，在「檢視」模式下開啟實體。
其他考慮事項
• 安全性 - 若要增強安全性，請使用服務取代，拒絕可在 ThingWorx Platform 上使用之重要服務的權限。
• 更新 - 使用良好的編碼實作，且不要建立較大的整合型服務。
• 並行模式 - ThingWorx 物件服務不會由應用程式引擎單獨執行。因此，在一個服務中進行的物件模型內容變更在其他所有同時執行的服務中會立即可見。如果兩個服務嘗試同時寫入相同內容，則兩次寫入都會成功。內容值會以最後執行的任何狀態結束，其可能與將寫入提交至伺服器的順序不同。事實上，在一般情況下，ThingWorx Platform 中大多數資料與資源的同步存取行為都以最後寫入者優先的方式運作。應用程式開發人員與架構設計人員應在編寫應用程式時考慮這些行為。