Skip to content

平台架构与请求边界 ​

Aras Innovator 是一个以元数据为核心的企业应用平台。 ItemType、Property、RelationshipType、Form、Permission、Life Cycle Map 与 Workflow Map 共同描述数据结构、界面、访问控制和业务过程;平台运行时解释这些定义并提供统一服务。

本文先建立足够用于开发、部署和排错的架构心智模型, 不把某一版本的物理部署方式误写成永久不变的平台规则。

适用版本与资料基线

  • Item/ItemType、元数据驱动、权限、生命周期、工作流和 Vault 的概念在多个版本间相对稳定。
  • 配置界面名称与导航路径以 Aras Innovator R31、2024 年 12 月版官方培训资料为基线;R31 官方 Programmer's Guide 说明服务器组件运行在 .NET 6.0。
  • 服务器运行时以官方 R35《Programmer's Guide》和 R39 Release Notes 为准:R35 服务器组件运行在 .NET 8.0.1;R39 已迁移到 .NET 10。
  • 本文不据此推断所有操作系统、数据库和浏览器组合。部署时必须查目标 Release 的 Installation Guide 与 Platform Specifications。

最小心智模型 ​

把 Innovator 理解成四个相互协作、但边界不同的部分:

一次常见操作可以概括为:

  1. 用户在浏览器中提交新增、查询、更新或 Promote 请求。
  2. 服务器识别当前用户及其有效 Identity。
  3. 服务器根据 ItemType、Permission、生命周期和事件配置执行业务规则。
  4. 结构化数据写入 SQL Server;文件内容由 Vault 管理。
  5. 服务器把成功结果或错误返回客户端,客户端再刷新界面。

这个模型有两个重要边界:

  • 浏览器不是权限边界。隐藏按钮或只读字段不能替代服务器授权。
  • 数据库写入与外部系统、邮件、文件系统等副作用不能想当然地视为同一个分布式事务。

核心组成 ​

客户端 ​

标准客户端运行在受支持的浏览器中,负责:

  • 呈现搜索网格、Item 表单、关系页签和流程任务;
  • 收集用户操作并向服务器发送请求;
  • 根据返回的元数据和数据渲染界面;
  • 执行获准运行的客户端 Method。

客户端可以改善交互体验,却不能自行授予 Get、Update、Delete 或 Promote 权限。 任何安全要求都必须在服务器可执行的权限或业务规则中落实。

Web 入口与服务器运行时 ​

Innovator Server 承担以下职责:

  • 解释 AML 或受支持 API 所表达的 Item 操作;
  • 执行认证后的授权检查;
  • 解析 ItemType、Property、RelationshipType 等元数据;
  • 执行生命周期、工作流和 Method 事件;
  • 协调数据库、Vault、认证服务和可选平台组件。

运行时不能再统一描述为“.NET Framework 应用直接运行在 IIS 中”。 官方 R35 文档明确说明:

  • 服务器组件运行在 .NET 8.0.1;
  • ASP.NET Core 使用 Kestrel 作为主要 Web 服务器;
  • MSI 安装场景下,IIS 作为反向代理,仍可能通过 web.config 参与托管配置。

R39 Release Notes 又明确记录平台由 .NET 8 迁移到 .NET 10。 因此,诊断托管问题前应先确认 Release,而不是套用旧版 .NET Framework 经验。

SQL Server ​

SQL Server 保存两类内容:

  • 平台配置元数据,例如 ItemType、Property、Form、Permission 与流程定义;
  • Item 实例及其关系、历史、生命周期和工作流运行数据。

从开发角度看,一个 ItemType 通常对应持久化结构,Property 对应数据字段, Relationship 本身也是 Item。 这有助于理解模型,但不等于允许业务代码绕过平台直接更新表。

不要把数据库表当成公共 API

直接 SQL 写入可能绕过权限、事件、版本、历史和缓存一致性。 除官方维护流程或经验证的迁移方案外,业务写操作应经过 Innovator Server。

Vault Server ​

Vault 保存 CAD、PDF、Office 文档等文件内容。 数据库保存 File、Vault 及业务对象之间的引用和元数据, 文件字节则位于配置的 Vault 存储中。

这一区分会影响备份和故障恢复:

  • 只备份数据库不能恢复全部文件内容;
  • 只复制 Vault 目录也不能恢复文件与业务 Item 的关联;
  • 数据库与 Vault 的恢复点必须协调验证。

OAuth 与身份认证 ​

现代版本的安装包含 OAuth Server 等认证相关组件。 认证用于确认“请求者是谁”,Permission、Identity、Team 和状态规则用于判断“可以做什么”。

外部身份提供程序、Windows Authentication 或本地认证的配置会随版本和部署模式变化。 不要把密码散列格式写进业务集成,也不要依赖数据库中的密码表示。

可选服务 ​

根据产品组合和业务需求,环境还可能包括:

  • Agent Service;
  • Conversion Server;
  • Scheduler Service;
  • Reporting、消息或其他平台组件;
  • ERP、MES、CAD 等外部系统。

这些组件并非每个环境都必需,也不应在逻辑架构图中假定与主服务器同机。

元数据驱动机制 ​

ItemType 与 Item ​

ItemType 是类型定义,Item 是该类型的一条实例。 最小对应关系如下:

配置对象回答的问题
ItemType这类业务对象是什么
Property它保存哪些值
RelationshipType它与哪些对象关联,关系自身保存什么
Form用户如何查看和编辑
Permission哪些 Identity 可以访问已有 Item
Life Cycle MapItem 可以处于哪些状态,如何 Promote
Workflow Map哪些人按什么步骤完成任务

“一切都是 Item”是有用的学习近似: 大量配置和运行对象都通过 Item 模型表达,因而可以由统一的查询、权限和事件机制处理。 但具体系统对象仍可能受到平台保护,不能据此假定任何 Item 都可任意增删改。

AML、IOM 与 REST ​

平台常见交互方式包括:

  • AML:表达 Item、Relationships 与 action 的 XML 语言;
  • IOM:在 AML 之上提供 Item 对象模型;
  • REST/OData:供受支持版本和外部技术栈使用的 HTTP 接口。

三者不是三套互不相关的数据模型。 它们最终都必须遵守服务器端身份、权限和业务规则。

选择接口的原则

先按目标 Release 的官方文档确认接口是否受支持,再根据调用方技术栈、认证方式、 批处理需求和错误处理要求选择。不要仅因为某段旧代码“能够运行”就把内部端点当成稳定 API。

请求处理与事务边界 ​

一个写请求的逻辑顺序 ​

下图只表达职责顺序,不承诺每个动作都对应独立数据库语句:

不能把 OnBeforeAdd 理解为“先插入数据库,再执行前置校验”。 前置事件的用途正是让服务器在完成目标操作前进行校验或调整。 具体事件次序和事务语义应以 Method 事件文档及目标 Release 行为为准。

不要扩大事务承诺 ​

服务器端一次 apply 失败,通常应按该请求返回错误处理; 但以下副作用不能仅凭“同一段 Method”就断言会与数据库自动原子回滚:

  • 调用外部 HTTP 服务;
  • 向消息系统发布事件;
  • 发送邮件;
  • 直接读写文件系统;
  • 调用另一数据库或长时间后台任务。

需要跨系统一致性时,应设计幂等、重试、补偿、状态记录与可观测性, 而不是依赖未核验的分布式事务假设。

部署拓扑 ​

单机拓扑 ​

官方安装指南通常用同机部署讲解入门:Innovator Server、Web 入口、Vault 和数据库 位于同一台机器或同一环境中。 它适合学习、评估和受控开发,但不自动满足生产可用性与安全要求。

分离拓扑 ​

生产环境可按网络可达性和支持矩阵拆分组件:

  • Web 入口与 Innovator Server;
  • SQL Server;
  • Vault Server;
  • Conversion Server 与 Agent Service;
  • 身份认证、监控和备份设施。

拆分后必须显式处理 DNS、证书、端口、防火墙、服务账户、共享路径、延迟和恢复顺序。

操作与验证 ​

建模前检查 ​

  1. 确认目标环境的 Innovator Release 和已安装应用版本。
  2. 确认开发、测试、生产使用相同的包基线与依赖。
  3. 先用 ItemType、Permission、Lifecycle、Workflow 等配置实现需求。
  4. 只有配置不足时再引入 Method 或外部集成。
  5. 为所有服务器端写操作设计正向和越权测试。

部署后冒烟检查 ​

检查项通过标准
登录普通测试用户能够通过预期认证方式登录
元数据可打开已授权 ItemType 的搜索与表单
权限无 Get 的用户无法通过直接 URL 或 API 越权读取
写入新建、编辑、保存遵守 Can Add 与 Update
生命周期仅允许的 Identity 能执行配置的 Transition
工作流默认或状态触发方式只生成预期的 Process
文件上传、下载、权限和 Vault 容量均正常
日志Web、服务器、数据库及相关服务无持续错误

排错顺序 ​

遇到“界面没有反应”时,按边界定位:

  1. 浏览器网络请求是否发出,返回状态和响应体是什么;
  2. 认证令牌、数据库选择和用户身份是否正确;
  3. Permission、Can Add、TOC Access 或 Transition Role 是否阻止操作;
  4. 服务器日志是否记录 Method、配置或运行时错误;
  5. 数据库、Vault 或外部服务是否可达;
  6. 问题是否只出现在某一 Release 或定制包中。

版本差异 ​

基线已核验事实文档使用方式
R31Programmer's Guide 说明服务器组件运行在 .NET 6.0;培训资料给出配置界面本站 UI 与旧环境迁移基线
R35服务器组件运行在 .NET 8.0.1;Kestrel 为主 Web 服务器;MSI 下 IIS 为反向代理现代运行时与安装架构基线
R39官方 Release Notes 明确迁移到 .NET 10升级与运行时差异提醒

版本号不是兼容性保证。 尤其是自定义 DLL、旧 .NET API、程序集加载、操作系统相关代码和认证配置, 必须在目标 Release 上重新编译或验证。

风险与最佳实践 ​

  • 不要在客户端脚本中实现唯一的安全校验。
  • 不要直接修改 Innovator 数据表来替代受支持的 Item 操作。
  • 不要把 IIS、.NET Framework 或某个 SQL Server 版本写成跨 Release 永久要求。
  • 不要承诺数据库、Vault、邮件和外部 API 自动组成一个原子事务。
  • 为集成调用设置超时、幂等键、重试上限和可追踪的错误状态。
  • 为数据库、Vault、配置、证书和密钥建立成套备份与恢复演练。
  • 使用组/角色 Identity 授权,避免把个人 Alias 散落在大量配置中。
  • 升级前扫描自定义服务器代码的运行时与 SQL 兼容性。

相关主题 ​

官方资料 ​

本站内容仅供学习与参考