4. 升级迁移前的资产盘点
ThingWorx 升级迁移最怕的不是版本跨度大，而是“不知道自己有什么”。平台运行几年后，往往存在大量临时创建的 Thing、被复制后遗忘的 Mashup、无人维护的订阅、指向旧设备的数据表，以及层层继承的 ThingTemplate 与 ThingShape。如果不在迁移前完成一次系统性的资产盘点，迁移过程中就会出现导入失败、依赖缺失、服务报错、界面白屏等连锁问题，而且很难定位根因。资产盘点的目标不是简单列一张清单，而是回答三个问题：有哪些资产、它们之间是什么依赖关系、哪些必须迁移、哪些可以清理或重建。
一、先明确盘点范围与分类维度
ThingWorx 平台资产大致可分为四类。第一类是模型资产，包括 Thing、ThingTemplate、ThingShape、DataShape、ThingPackage 等，它们定义了对象的结构、属性、服务与继承关系。第二类是交互资产，包括 Mashup、Widget、StyleTheme、Menu、Master 等，负责用户界面与交互逻辑。第三类是逻辑与集成资产，包括 Service、Subscription、Timer、ThingWorx Flow 工作流、Integration Connector 等，承载业务规则与外部系统对接。第四类是数据资产，包括 Stream、ValueStream、DataTable、PersistenceProvider、InfoTable 结构以及历史数据存储配置。
分类的意义在于：不同类别资产的迁移方式、依赖强度和风险等级完全不同。模型资产通常通过 ThingWorx Extension 或导入导出方式迁移，依赖关系最复杂；交互资产与模型资产强绑定，Mashup 中引用的服务一旦缺失就会直接报错；逻辑资产中的订阅和定时器往往隐含业务时序，迁移后需要重新验证触发条件；数据资产则涉及数据保留策略、数据库连接和容量规划，不能简单复制。
二、盘点执行：从导出清单到依赖分析
实际盘点通常分三步走。第一步是导出资产清单。在 ThingWorx Composer 中，可以通过“Import/Export”下的“Export”功能按实体类型批量导出，也可以使用 ThingWorx REST API 或平台内置的搜索功能获取资产列表。例如，使用 REST 接口按类型查询 Thing 列表：
GET /Thingworx/Things?type=Thing&offset=0&limit=500
Headers:
appKey: <your-app-key>
Accept: application/json返回结果中包含每个 Thing 的名称、描述、ThingTemplate、ThingShape、是否启用等字段。对 ThingTemplate、ThingShape、Mashup、DataTable 等类型重复同样操作，即可得到一份原始资产清单。建议将结果导出为 CSV 或 JSON，便于后续比对和筛选。
第二步是建立依赖关系。ThingWorx 资产之间存在明确的引用链：Thing 继承自 ThingTemplate，ThingTemplate 可实现多个 ThingShape，ThingShape 中定义的服务可能调用其他 Thing 的服务，Mashup 绑定到某个 Thing 或 ThingTemplate 的服务与属性，Subscription 订阅某个 Thing 的事件，DataTable 被服务或 Mashup 引用。盘点时必须把这些引用关系梳理出来，否则迁移时会出现“导入了 A，但 A 依赖的 B 没导入”的情况。
第三步是分类打标。建议为每个资产标注四个维度：资产类型、业务归属、迁移必要性（必须迁移 / 可选迁移 / 可废弃）、依赖数量。依赖数量越多的资产，迁移优先级越高，也越需要提前验证。对于依赖数量为零且长期未使用的资产，可以列入废弃候选，减少迁移工作量。
三、资产分类与迁移策略对照
完成清单和依赖分析后，需要为每类资产确定迁移策略。下表给出一个可参考的分类框架，实际项目中可根据平台规模和业务复杂度调整。
| 资产类别 | 典型对象 | 迁移方式 | 主要风险 |
|---|---|---|---|
| 模型资产 | Thing、ThingTemplate、ThingShape、DataShape | Extension 打包或逐项导出导入 | 继承链断裂、服务签名不兼容 |
| 交互资产 | Mashup、Widget、StyleTheme、Menu | 随模型资产一起导出，或单独迁移 | Widget 版本不匹配、绑定服务丢失 |
| 逻辑与集成资产 | Service、Subscription、Timer、Flow | 导出导入，Flow 需单独迁移 | 触发条件失效、外部连接配置丢失 |
| 数据资产 | Stream、ValueStream、DataTable | 结构迁移 + 数据迁移分开处理 | 数据量过大、数据库驱动不兼容 |
需要特别注意的是，ThingShape 和 ThingTemplate 的迁移顺序不能颠倒。ThingShape 是能力定义，ThingTemplate 依赖 ThingShape，Thing 又依赖 ThingTemplate。如果先导入 Thing，再导入它依赖的 ThingTemplate，平台会报“模板不存在”错误。正确的顺序是：DataShape → ThingShape → ThingTemplate → Thing → Mashup → Subscription → DataTable。这个顺序在批量迁移脚本中必须严格遵守。
四、盘点结果的可视化与复核
资产盘点的最终产出不应只是一张表格，而应包含依赖关系图和迁移优先级。依赖关系图可以帮助团队快速识别“关键路径资产”——那些被大量其他资产引用的 ThingTemplate 或 ThingShape。迁移优先级则决定先迁移什么、后迁移什么、哪些可以并行。
上图展示了 ThingWorx 主要资产之间的依赖方向与推荐迁移顺序。左侧的 DataShape 和 ThingShape 是基础定义层，中间的 ThingTemplate 和 Thing 是模型实例层，右侧的 Mashup、Service、DataTable 是消费层。迁移时必须从基础层向消费层推进，否则会出现引用缺失。图中橙色箭头表示迁移顺序，灰色箭头表示依赖方向，两者方向一致但含义不同：依赖关系说明“谁引用谁”，迁移顺序说明“先导入谁”。
五、盘点复核与迁移前检查
盘点完成后，建议做一次交叉复核。复核方式包括：在测试环境中按迁移顺序导入资产，观察是否有导入失败或警告；检查 Mashup 是否能在新版本中正常渲染；验证 Subscription 的触发条件是否仍然有效；确认 DataTable 的数据库连接配置是否已更新。对于依赖数量超过 10 个的关键资产，应单独建立验证用例，记录迁移前后的行为差异。
最后，资产盘点不是一次性动作，而应形成可重复执行的流程。建议将盘点脚本、依赖分析规则和迁移顺序模板固化下来，在每次升级或环境迁移前重新运行，确保清单与平台实际状态一致。这样既能降低迁移风险，也能为后续的版本治理提供准确的资产基线。