2. ThingWorx开发环境搭建
ThingWorx Composer 是平台面向开发者的主要工作台，所有建模、服务编排、数据绑定、权限配置与协作发布都在这里完成。本节围绕“能登录、会导航、管得住项目与实体、配得清权限与协作”四个目标展开，帮助你把开发环境从“能打开”推进到“可交付”。
一、登录 Composer：地址、账号与首次进入
Composer 的访问地址通常由部署方式决定。以本地或测试环境为例，常见形式为 http://<服务器IP或域名>:8080/Thingworx/Composer；若使用 HTTPS 反向代理，则可能是 https://thingworx.example.com/Thingworx/Composer。首次登录使用管理员账号（示例：Administrator），密码由部署时设定。登录后若提示修改初始密码，应先完成修改，再进入工作区。
登录成功后，Composer 会加载当前用户的权限视图。也就是说，同一个界面在不同账号下可见的菜单、实体和操作按钮可能不同。因此，遇到“菜单找不到”或“按钮是灰的”，第一反应不应是浏览器问题，而应先确认当前账号是否具备对应权限。
二、界面导航：把常用区域和操作路径固定下来
Composer 的主界面可以按“顶部导航 + 左侧导航 + 主工作区 + 右侧信息区”来理解。顶部通常包含搜索、通知、用户菜单和帮助入口；左侧导航用于切换建模、服务、数据、监控、权限等模块；主工作区展示当前实体的编辑界面；右侧信息区常显示属性、事件、服务或日志等上下文信息。
实际开发中，建议先固定三条高频路径：
- 建模路径：Modeling → Things / Thing Templates / Thing Shapes，用于创建和管理实体。
- 服务路径：Services，用于编写、测试和调试 JavaScript 服务。
- 权限路径：Security → Users / Groups / Organizations，用于配置账号与访问控制。
导航时要注意“实体上下文”的概念：很多操作必须先选中一个实体，右侧才会出现对应的属性、服务和事件。若未选中实体，部分菜单会保持不可用状态，这是正常现象。
三、项目与实体管理：从“建一个 Thing”到“管一组实体”
ThingWorx 中的“项目”通常以 Project 或 Organization 的方式组织资源，用于把同一业务域下的 Thing、Thing Template、Thing Shape、Data Shape、Service、Mashup 等实体归拢在一起。项目管理的核心不是“建文件夹”，而是建立可复用的实体边界和权限边界。
以“设备温度监控”为例，建议按以下顺序创建实体：
- 创建
ThingShape：定义通用属性，如temperature（NUMBER）、humidity（NUMBER）、status（STRING）。 - 创建
ThingTemplate：继承上述 Shape，并加入通用服务，如GetDeviceStatus。 - 创建
Thing：基于 Template 实例化，例如Device_001、Device_002，并填写具体属性值。 - 创建
DataShape：定义服务输入输出结构，如DeviceStatusResult，字段为deviceId、temperature、timestamp。
实体命名建议遵循“业务域_对象_序号”的规则，例如 LineA_Device_001。这样在搜索、导入导出和权限分配时都能快速定位。实体创建后，务必点击 Save 保存；未保存的实体在刷新页面后会丢失。若需要批量管理，可使用 Import/Export 将实体导出为 XML 或 JSON，便于版本备份和跨环境迁移。
四、权限与协作基础配置：让不同角色看到不同内容
ThingWorx 的权限模型围绕 User（用户）、Group（用户组）、Organization（组织） 和 Visibility（可见性） 展开。基础配置的目标是：管理员能管全部，开发者能改自己负责的实体，访客只能看不能改。
一个可落地的最小权限配置如下（示例）：
| 角色 | 账号示例 | 所属组 | 权限范围 |
|---|---|---|---|
| 平台管理员 | Administrator | Administrators | 全部实体读写、用户与权限管理 |
| 开发工程师 | dev_zhang | Developers | 项目内实体读写、服务调试、不可管理用户 |
| 运维人员 | ops_li | Operators | 监控与日志查看、属性只读 |
| 访客 | guest | Guests | 仅查看已发布 Mashup，不可进入 Composer 编辑 |
配置时，先在 Security → Users 创建用户，再在 Groups 中建立角色组，最后通过 Visibility 把实体或项目授权给对应组。注意：权限是“叠加”的，用户若同时属于多个组，会获得各组权限的并集。因此，不要给临时账号随意加入高权限组。
协作方面，Composer 支持实体共享、变更记录和锁定机制。多人同时编辑同一实体时，后保存者可能覆盖前者。建议约定：修改前先确认实体未被他人锁定；修改后填写变更说明；重要版本通过导出备份。若发现实体被锁定，可在实体信息区查看锁定人，并联系对方释放。
五、常见问题与判断依据
登录后菜单缺失，通常是账号权限不足，而非浏览器缓存问题；此时应检查用户所属组和实体可见性。实体保存失败，常见原因是名称重复、必填属性为空或服务脚本语法错误；可查看右侧日志区的具体报错行。服务测试无输出，先确认输入参数是否传入，再检查 result 是否被正确赋值。若页面操作按钮灰显，先确认是否已选中实体，再确认当前账号是否具备该实体的写权限。
完成以上配置后，你的 Composer 环境应达到三个可验证状态：能用管理员账号登录并看到完整导航；能按项目创建并保存一组相互关联的实体；能为不同角色分配可区分的权限，并能在协作中识别锁定与变更。达到这三点，后续的建模、服务编排与 Mashup 开发才有稳定的工作基础。