RelationshipType 建模与验证

RelationshipType 不只是“父表与子表的一条线”。一条 Aras 关系同时涉及三个对象：Source Item、承载关系属性的 Relationship Item，以及可选的 Related Item。分清三者，才能正确设计 BOM、文档清单、人员分配和评论明细。

本章为 acme_equipment 增加文档关系。每一行可以指向一份 Document，并在关系本身保存用途说明。

适用范围

配置步骤以 R31 原厂培训的 Relationship 单元为基线。
AML 的 Relationships 结构在 11 SP9 到 R35 均有官方资料支持。
网格按钮、页签对象和客户端 DOM 会随 Release 变化，不属于本章的数据模型契约。

三个对象

text

acme_equipment             Source Item
└─ acme_equipment_document Relationship Item
   ├─ acme_usage           关系自己的 Property
   └─ related_id ─────────> Document (Related Item)

对象	回答的问题	常见属性
Source Item	这组明细属于谁？	设备编号、名称
Relationship Item	两者如何关联？	数量、顺序、用途、备注
Related Item	被关联的对象是谁？	文档编号、名称、版本

先判断是否真的需要 RelationshipType

需求	建议模型
每个设备最多引用一个制造商	Item 类型 Property
每个设备可关联多份文档	RelationshipType
关联行还要保存“用途”	RelationshipType
只需要多行备注，不指向独立 Item	Null Relationship
父子都是同一个 ItemType，例如 BOM	Circular Relationship

若目标对象只会有一个，Relationship Grid 往往比 Item Property 更复杂。先从业务基数和关系行是否需要属性出发，而不是从界面想放一个页签出发。

第 1 步：创建关系定义

在 acme_equipment 的 RelationshipTypes 配置页签中创建关系：

Related ItemType 选择 Document。
关系内部名称使用 acme_equipment_document。
页签 Label 使用“相关文档”。
保存并把新建的 RelationshipType、Relationship ItemType 及依赖加入 Package Definition。

不同版本的操作按钮可能叫 Add ItemType、Create RelationshipType 或通过选择对话框完成。以生成结果为验证标准：关系定义的 Source 为 acme_equipment，Related 为 Document。

第 2 步：给关系行增加属性

打开生成的 Relationship ItemType，新增：

Name	Type	用途
`acme_usage`	String	例如“操作手册”“校准报告”

这个值属于“设备—文档”这一连接，而不属于 Document 本身。同一份 Document 被不同设备引用时，可以有不同用途。

第 3 步：配置关系页签

确认 Source Item 的 Form 能显示关系页签，并选择适合业务的新增方式：

只允许选择已有 Related Item；
允许创建新的 Related Item；
两者都允许。

选项名称随版本可能不同。若创建 Related Item 涉及独立权限或审批，优先限制为选择已有对象，避免在父 Item 取消保存时留下没有业务归属的记录。

第 4 步：用界面验证

打开 EQ-0001 并进入编辑状态。
在“相关文档”页签选择一份测试 Document。
将 acme_usage 设为“操作手册”。
保存父 Item，关闭后重新打开。
确认关系行、用途和文档链接都仍存在。

如果关系网格可见但按钮不可用，分别检查父 Item 锁、Relationship ItemType 的 Can Add/Permission、Related Item 的 Discover/Get，而不是只改客户端按钮。

用 AML 查询关系

查询设备及其文档关系：

xml

<AML>
  <Item type="acme_equipment" action="get"
        select="id,item_number,name">
    <item_number>EQ-0001</item_number>
    <Relationships>
      <Item type="acme_equipment_document" action="get"
            select="id,acme_usage,related_id">
        <related_id>
          <Item type="Document" action="get"
                select="id,item_number,name" />
        </related_id>
      </Item>
    </Relationships>
  </Item>
</AML>

related_id 的嵌套 Item 控制返回的 Related Item 属性。不要为了方便使用无限制的 select="*"；关系树一深，响应会快速膨胀。

用 AML 新增关系

已知 Source 与 Related ID 时，可以把关系放在 Source 的 Relationships 中：

xml

<AML>
  <Item type="acme_equipment" action="edit" id="EQUIPMENT_ID">
    <Relationships>
      <Item type="acme_equipment_document" action="add">
        <related_id>DOCUMENT_ID</related_id>
        <acme_usage>操作手册</acme_usage>
      </Item>
    </Relationships>
  </Item>
</AML>

提交前必须替换两个占位 ID，并让当前用户拥有对应权限。调用端还要检查 isError()；HTTP 成功不代表 AML 业务操作成功。

IOM 构建同一关系的写法

csharp

Item equipment = inn.newItem("acme_equipment", "edit");
equipment.setID(equipmentId);

Item rel = inn.newItem("acme_equipment_document", "add");
rel.setProperty("related_id", documentId);
rel.setProperty("acme_usage", "操作手册");
equipment.addRelationship(rel);

Item result = equipment.apply();
if (result.isError())
{
    return result;
}

return result;

三类常见关系

Direct Relationship

Source 与 Related 是不同 ItemType，如设备关联文档。这是本章实验使用的模式。

Null Relationship

没有 Related Item，关系行只保存自身属性。例如设备的检查记录明细。此时仍要设计可识别的行属性、权限和排序，不要创建一张完全不可读的空网格。

Circular Relationship

Source 与 Related 是同一个 ItemType，例如 Part BOM。循环模型不代表可以无界递归查询；应设置业务层循环校验和查询深度限制。参见 AML 递归查询。

Fixed、Float 与版本行为

当 Related ItemType 使用版本控制时，关系究竟固定在某一代，还是跟随到当前代，是业务语义而不是 UI 偏好。配置字段和最终解析行为可能受 RelationshipType、ItemType 及 Release 影响，因此：

先写出业务例子，例如“已发布 BOM 必须固定到当时子件版本”。
在目标 Release 建立两代测试 Related Item。
升版后重新查询 related_id 和显示结果。
将验证结果记录到项目版本矩阵，再决定配置。

不要只凭 behavior 文本值推断所有上下文。

关系上下文不等于数据库真值

Server Event 中的 this.getRelationships() 只表示当前请求携带的 Relationship 内容。如果一次 edit 只改了表头，请求可能没有带任何关系行。需要校验数据库完整集合时，应按 Source ID 单独查询。

这也是旧代码中“明细明明存在，服务端却判断为空”的常见根因。

客户端网格代码的边界

用户样例中的 relTabbar、固定 iframe ID、grid.items_Experimental 和轮询 DOM 属于 Classic Client 或私有实现。它们最多用于有明确版本锁定的兼容层，不能代替：

Relationship ItemType 的 Permission 与 Server Event；
对 apply() 错误的处理；
父 Item 取消时的事务/孤儿数据设计；
升级后的回归测试。

参见关系页签与表单代码审查。

验证清单

[ ] Source、Relationship、Related 的职责清楚
[ ] 关系自身属性放在 Relationship ItemType
[ ] Related Item 的 Discover/Get 已用普通账号验证
[ ] 新增关系、重复关系和删除关系都有明确规则
[ ] 版本行为已用两代数据实测
[ ] AML 使用有限 select 和有限递归深度
[ ] 服务端校验没有把请求上下文误当完整数据库集合
[ ] 客户端显隐/禁用没有被当作安全控制

下一步

依据

Aras Training, Configuring Solutions Student Guide Innovator R31, Relationship 单元
Aras Innovator 35 Programmer's Guide
Aras 11 SP9《基本开发详解》，AML 与 Relationship Grid 单元（仅用于历史语义对照）

RelationshipType 建模与验证 ​

三个对象 ​

先判断是否真的需要 RelationshipType ​

第 1 步：创建关系定义 ​

第 2 步：给关系行增加属性 ​

第 3 步：配置关系页签 ​

第 4 步：用界面验证 ​

用 AML 查询关系 ​

用 AML 新增关系 ​

三类常见关系 ​

Direct Relationship ​

Null Relationship ​

Circular Relationship ​

Fixed、Float 与版本行为 ​

关系上下文不等于数据库真值 ​

客户端网格代码的边界 ​

验证清单 ​

下一步 ​

依据 ​