2. ThingWorx平台架构
在ERP与PLM系统集成的语境下，ThingWorx并不是一个"替代"ERP或PLM的业务系统，而是位于两者之间、承担协议转换、数据编排与业务事件驱动的集成中间件。要理解它为什么能承担这个角色，需要先看清它的四个核心组件——Thing、ThingTemplate、Mashup、Flow——各自解决什么问题，以及它们在集成链路中的位置。
一、四个核心组件的职责边界
Thing（事物）是ThingWorx中最基础的建模单元，代表一个被数字化的实体。它可以是一台设备、一个工位、一个物料批次，也可以是一个"逻辑对象"，例如"ERP物料主数据连接器"或"PLM变更单接收器"。Thing本身不定义能力，它只是承载属性（Property）、服务（Service）、事件（Event）和订阅（Subscription）的容器。在集成场景中，我们通常为每个需要交互的外部系统建立对应的Thing，例如Thing_ERP_Connector、Thing_PLM_Connector，把连接参数、认证信息、接口地址封装在它的配置里。
ThingTemplate（事物模板）是Thing的"类型定义"，相当于面向对象中的类。它规定了某一类Thing应该具备哪些属性、服务和事件。集成的价值在于：当企业有多个工厂、多条产线需要接入同一套ERP接口时，只需定义一个ERP_Material_Sync_Template，所有具体Thing都从它继承，接口地址、字段映射、重试策略只需在模板层维护一次。这是ThingWorx能够规模化支撑集成的关键机制。
Mashup（混搭）是ThingWorx的前端可视化与交互层。它把Thing的数据、服务返回值、外部API结果组合成页面，供业务人员查看和操作。在ERP/PLM集成中，Mashup常被用作"集成监控台"：展示最近同步的物料、失败的变更单、待处理的工单，并提供"手动重推"按钮。它不承担数据转换逻辑，但承担可观测性与人工干预入口。
Flow（流程）是ThingWorx的编排引擎，负责定义"什么时候、按什么顺序、调用哪些服务、如何处理异常"。它把Thing暴露的服务串联成有向的执行链，支持条件分支、循环、并行和错误捕获。ERP与PLM之间的数据同步、状态回写、审批触发，绝大多数都落在Flow里实现。
二、为什么ERP与PLM不直接互连
ERP与PLM直接点对点集成，在系统数量少、接口稳定时尚可维持；一旦涉及多工厂、多PLM实例、多版本接口，点对点连接数会呈平方级增长，且任何一方接口变更都会引发连锁修改。ThingWorx作为中间件的核心价值，是把"N×N"的连接关系收敛为"N×1"：每个系统只与ThingWorx建立一条受控通道，转换逻辑集中在Flow和ThingTemplate中维护。
更关键的是，ERP与PLM对同一份数据的"语义"往往不同。例如物料编码，ERP可能使用MAT-000123，PLM可能使用P-2024-0123-A；计量单位上ERP用"个"，PLM用"EA"。这些差异不应侵入任何一方的业务逻辑，而应在ThingWorx的Flow中通过映射服务完成转换。ThingWorx在这里扮演的是语义翻译层，而非简单的消息转发器。
三、一个典型的物料同步链路
以"PLM新建物料 → 同步至ERP"为例，说明四个组件如何协同。假设PLM侧通过REST接口暴露物料查询能力，ERP侧通过OData接口接收物料创建请求。
第一步，在ThingWorx中定义PLM_Material_Template，包含属性plmCode、plmName、plmUnit、plmVersion，以及服务getMaterialByCode(code)。再定义ERP_Material_Template，包含属性erpCode、erpName、erpUnit，以及服务createMaterial(payload)。两个模板分别实例化为Thing_PLM_Material和Thing_ERP_Material，各自配置好接口地址与认证凭据。
第二步，在Flow中编排执行链：触发条件设为"PLM物料状态变为Released"；调用Thing_PLM_Material.getMaterialByCode获取物料详情；进入映射节点，将plmCode按规则转换为erpCode（例如去掉前缀P-、补零至6位），将plmUnit通过单位映射表转为ERP单位；调用Thing_ERP_Material.createMaterial提交；根据返回的HTTP状态码判断结果——201表示创建成功，409表示编码冲突需人工介入，500表示ERP侧异常需重试。
第三步，在Mashup中构建监控页面，绑定Flow的执行日志，展示"最近1小时同步成功数""失败清单及错误码""手动重推按钮"。业务人员无需登录ERP或PLM，即可在ThingWorx中完成异常处置。
四、组件在集成中的定位总结
| 组件 | 在ERP/PLM集成中的定位 | 典型使用方式 |
|---|---|---|
| ThingTemplate | 集成能力的类型定义与复用单元 | 定义连接器模板、数据映射模板、重试策略模板 |
| Thing | 具体系统或逻辑对象的实例载体 | 每个ERP/PLM接口对应一个Thing，封装地址与凭据 |
| Flow | 数据转换与业务编排的执行引擎 | 触发、映射、调用、异常处理、状态回写 |
| Mashup | 集成过程的可观测性与人工干预界面 | 同步监控、失败清单、手动重推、日志查询 |
五、实践中的关键判断
在动手搭建之前，需要先回答三个问题。第一，谁是数据主源？物料主数据通常以ERP或PLM之一为主源，另一侧为消费方，这决定了Flow的方向是单向推送还是双向同步。第二，同步是实时还是批量？实时同步依赖事件触发，对接口稳定性要求高；批量同步可用定时Flow，容错空间更大。第三，失败后如何处置？是自动重试、进入死信队列，还是通知人工在Mashup中处理，这需要在Flow设计阶段就明确。
这三个问题的答案会直接影响ThingTemplate的粒度、Flow的分支结构以及Mashup的页面布局。ThingWorx的组件本身并不复杂，复杂的是把ERP与PLM之间真实的业务语义差异，准确地映射到这四个组件的协作关系中。