创建、实施和测试服务
事物服务是指事物可执行的功能。服务在 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，则不会在结果中返回 JSON。
例如：
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，则会在结果中返回 JSON。
例如：
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 看到该温度，请使用“表达式”小组件。
• 将检查添加到您的代码中，以避免最终用户收到错误的可能性。
例如，如果您的代码需要几个输入参数才能运行，请创建检查以确保在执行服务时这些输入参数不为空。
• 如果您的应用程序将要进行本地化，并且用户界面元素中存在基于服务结果动态变化的文本，请确保您不会在服务中对混搭中所显示的文本值进行硬编码。这是因为返回文本的服务结果需进行本地化。这也便于日后更为轻松地维护和修改用户界面文本。
• 执行服务可能的结果就是创建幻影实体。可通过代码/脚本编写而非通过 ThingWorx Composer 来动态创建幻影实体。创建幻影实体是一种不良做法。有关详细信息，请参阅
在 ThingWorx 中检测、移除和防止幻影实体。
如果系统创建了幻影实体，则可通过下列方式之一将其消除：
◦ 重新启动 ThingWorx 服务器。这会从持久化数据中重新加载 JVM 内存，并排除幻影实体。
◦ 使用幻影实体清理程序扩展。您可以从
PTC Marketplace 下载此扩展。
• ThingWorx 平台上的默认脚本超时设置为 30 秒。如果脚本运行时间超过此默认设置，则平台会终止执行。ThingWorx 管理员可以在 platform-settings.json 文件的“基本设置”部分配置脚本超时。
测试服务的最佳做法
测试服务时，可以使用以下最佳做法：
• 在构建服务时，对其进行增量测试。如果适用，请使用脚本记录程序消息。
| | 如果服务具有无限循环，即会使 ThingWorx 服务器停止运行。 |
• 测试服务时，请检查日志以查看错误消息。这对于订阅中的服务尤其有用。以下日志文件很有用：
◦ ErrorLog.log - 提供有关错误的详细堆栈追踪
◦ ScriptErrorLog.log - 提供服务上下文信息 (堆栈错误行号)
仅当在 LoggingSubsystem 子系统的“配置”选项卡中选中“启用脚本堆栈追踪”复选框时，才会在此文件中记录错误。
| | 可在 ThingworxStorage/logs 文件夹中找到上述文件。您需要访问 ThingWorx 服务器才能读取这些文件。 |
• 如果从混搭中调用服务，请在 Composer 和混搭中对其进行测试。
• 如果需要用户输入才能执行服务，则可以使用“验证器”小组件。
• 使用浏览器中提供的开发人员工具来检查服务的结果。当想要调试在混搭中执行的服务序列时，这非常有用。此工具会在此特定执行的上下文中显示服务结果。
技巧
• 如果要搜索服务，请勿在“编辑”模式下打开实体。使用实体名称左侧的“预览”链接在“查看”模式下打开实体。
其他考虑事项
• 安全性
◦ 要增强安全性，请使用服务覆盖来拒绝针对平台上可用关键服务的权限。
• 升级
◦ 采取良好的编码做法，而无需创建大型的单一服务。