建立、實行及測試服務
物件服務是「物件」可以執行的功能。服務由「混搭」在 ThingWorx 平台內部使用，其可從具有適當存取權的任何外部來源實現。您只能在下列 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 Composer 建立。建立映像實體是一種錯誤的作法。如需詳細資訊，請參閱
ThingWorx 中映像實體的偵測、移除與預防。
如果已建立映像實體，您可以使用下列其中一種方式將其消除：
◦ 重新啟動 ThingWorx 伺服器。這會從持續性資料重新載入 JVM 記憶體，並排除映像實體。
◦ 使用「映像實體清除工具」延伸功能。您可以從
PTC Marketplace 下載該延伸功能。
• ThingWorx 平台上的預設指令集逾時設定為 30 秒。如果指令集的執行時間比預設設定長，則平台會終止執行。ThingWorx 管理員可以在 platform-settings.json 檔案的基本設定部份配置指令集逾時。
測試服務的最佳作法
測試服務時，請遵循下列最佳作法：
• 在建構時，以增量的方式測試您的服務。在適當請況下，請使用指令集記錄器訊息。
| | 具有無限迴圈的任何服務都可能會關閉 ThingWorx 伺服器。 |
• 在測試服務時，檢查記錄檔中是否有錯誤訊息。這對於訂閱中的服務而言特別有用。下列記錄檔很有用：
◦ ErrorLog.log - 提供詳細的錯誤堆疊追蹤
◦ ScriptErrorLog.log - 提供服務前後關聯資訊 (堆疊錯誤行號)
只有在您於「記錄子系統」子系統的「組態」標籤中選取「啟用指令集堆疊追蹤」核取方塊時，錯誤才會記錄在此檔案中。
| | 上述檔案可在 ThingworxStorage/logs 資料夾中找到。您必須擁有對 ThingWorx 伺服器的存取權，才能讀取這些檔案。 |
• 若從「混搭」呼叫服務，請在 Composer 中與「混搭」中對其進行測試。
• 若執行服務需要使用者輸入，您可以使用「驗證器」小器具。
• 使用可在瀏覽器中找到的「開發者工具」檢查服務的結果。當您要偵錯在「混搭」中執行的服務序列時，此工具很有用。此工具會在該特定執行的前後關聯中顯示服務結果。
小秘訣
• 如果您要搜尋服務，請勿在「編輯」模式下開啟實體。請使用實體名稱左側的「預覽」連結，在「檢視」模式下開啟實體。
其他考慮事項
• 安全性
◦ 若要增強安全性，請使用服務取代，拒絕可在平台上使用之重要服務的權限。
• 升級
◦ 使用良好的編碼實作，且不要建立較大的整合型服務。