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 兼容性。

相关主题

官方资料

本站内容仅供学习与参考