Lifecycle、版本与关系行为
Life Cycle Map 描述一个业务 Item 可以处于哪些状态，以及哪些身份可以把它从一个状态 Promote 到另一个状态。 它管理的是对象状态，不是人员任务；需要审批、会签或待办时，再与 Workflow 配合。
Lifecycle 还可以在状态变化时切换 Permission、启动 Workflow、发送邮件， 并为版本化对象控制 Released 语义和关系指向行为。
适用版本与资料基线
- State、Transition、Promote、State Permission、Released 与 Item Behavior 的概念跨版本相对稳定。
- 配置步骤以 Aras Innovator R31 官方 Life Cycles 文档和 2024 年 12 月版培训资料为界面基线。
- R35 使用 .NET 8.0.1、R39 使用 .NET 10；运行时变化不改变本文的建模心智模型，但 Method 与界面必须在目标 Release 验证。
- Product Engineering 等应用可能在基础 Lifecycle 之上增加变更流程约束，不能把平台基础行为直接套用到所有应用对象。
最小心智模型
读取这张图时分别问四个问题：
- 当前 Item 在哪个 State；
- 从该 State 存在哪些 Transition；
- 当前用户是否属于 Transition 的 Role；
- 到达目标 State 后，Permission、Workflow 和版本行为如何变化。
Transition Role 只回答“谁能走这条边”。 它不自动授予 Update，也不等于 Workflow Assignment。
核心机制
State
一个 Item 在任意时刻只处于 Life Cycle Map 的一个 State。 新 Item 从 Start State 开始。
R31 基线中的重要 State 属性包括：
| 属性 | 作用 | 注意 |
|---|---|---|
| Name / Label | 内部名称与显示标签 | 稳定内部名有利于维护；Label 可本地化 |
| Image | 状态图标 | 只影响呈现 |
| Released | 标识版本化对象的发布状态 | 不是简单的“只读”开关 |
| Not Lockable | 当前状态不可锁定编辑 | 与 Permission、Released 分别控制不同机制 |
| State Permission | 进入状态时应用指定 Permission | 空值表示不改变当前 Permission |
| Workflow | 状态激活时启动允许的 Workflow Map | Workflow 必须也与同一 ItemType 关联 |
| History Template | 指定历史记录模板 | 需配合审计要求设计 |
| Configure E-Mail | 进入状态时通知 | 邮件成功不应作为状态成功的唯一证明 |
| Item Behavior | 控制与版本化相关 Item 的 Fixed/Float 行为 | 与 RelationshipType Behavior 共同决定 |
Transition
Transition 是有方向的状态连接。 R31 基线可配置：
- Role：允许执行转换的 Identity；
- Get Comment：Promote 时要求输入备注；
- Configure E-Mail：转换相关通知；
- 前置与后置服务器 Method。
只有图上存在的 Transition 才是正常可达路径。 不能把状态下拉框理解成可以任意跳到所有状态。
State Permission
Promote 到配置了 State Permission 的 State 时，Item 的当前 Permission 随之改变。 如果目标 State 未配置 State Permission，R31 官方说明是“不改变 Item Permission”， 不是自动恢复 ItemType 默认 Permission。
因此以下设计有问题：
Draft -> Draft Permission
In Review -> Review Permission
Released -> （空）如果期望 Released 使用只读权限，应显式选择 Released Permission。 该 Permission 还必须列在 ItemType 的 Permissions 关系中。
Transition Method 与事务范围
R31 官方 Life Cycles 文档给出的语义是：
- 前置 Method 在状态转换前执行；失败或抛错会阻止 Transition；
- 后置 Method 可以按配置区分 in-scope 与 out-of-scope；
- in-scope 后置 Method 失败会使状态转换回滚；
- out-of-scope 后置 Method 失败不使已完成的转换回滚。
不要把数据库回滚扩大为外部副作用回滚
即使 Method 处于转换事务范围内，也不能据此断言已发送邮件、外部 HTTP 请求、 消息队列发布或文件系统写入会被自动撤销。 涉及外部系统时仍要设计幂等、状态记录、重试和补偿。
分类与多个 Life Cycle Map
一个 ItemType 可以通过 Life Cycles 关系关联多个 Map，并按 Class Path 匹配分类。
R31 官方 Life Cycles 文档说明：
- 新 Item 根据初始 Classification 选择适用 Map；
- 如果 Item 仍在 Start State，Classification 改到使用另一 Map 的允许分类，平台可切换 Map；
- 如果 Item 已离开 Start State，这类分类变更会被拒绝，以免破坏生命周期进程。
需要允许业务用户重分类时，应把回到 Start State 的受控路径纳入设计， 并同时考虑 Permission、历史和已启动 Workflow。
Lifecycle 与 Workflow 的边界
| 问题 | Lifecycle | Workflow |
|---|---|---|
| 当前对象处于什么业务状态 | 是 | 间接反映 |
| 谁可执行状态转换 | Transition Role | 可通过活动促进进行协调 |
| 谁收到待办并投票 | 否 | Activity Assignment |
| 是否可在进入状态时启动流程 | State 可选择 Workflow | 生成运行中的 Process |
| 是否可由流程推动状态 | 被促进的目标 | Activity Promotion 可触发 |
同一个业务决策不要同时由用户手工 Promote 和 Workflow 自动 Promote， 除非已经明确并验证竞争、重复执行和回退规则。
版本控制心智模型
Lifecycle 和 Versioning 有联系，但不是同一个功能。
| 属性 | 含义 |
|---|---|
id | 当前 generation 的唯一 Item ID，各代次不同 |
config_id | 同一配置族共享的 ID，用于把各代次关联起来 |
generation | 配置族内递增的代次序号 |
major_rev | 主修订标识，按 Revision 序列变化 |
minor_rev | 平台保留的次修订字段；R31 培训基线不把它作为默认版本策略 |
is_current | 是否为当前代次 |
is_released | 是否达到 Released 语义 |
generation 增加不等于 major revision 一定增加。 非 Versionable Item 也不应被描述为“每次保存 generation 都递增”。
Versionable 与 Discipline
版本行为由 ItemType 的 Versionable 与 Discipline 配置决定。
- Automatic：平台在受支持的编辑/锁定流程中自动建立新 generation；
- Manual：需要显式执行版本动作，而不是每次编辑自动建立代次。
具体在何时创建 generation 与客户端动作组合有关， 验收时应观察目标 Release 的实际 id、config_id、generation 和 is_current， 不要用“每按一次 Save 都升版”作为规则。
Revision 序列
Revision Item 定义 major_rev 的取值序列，例如：
A B C D E F G H J K L M N P Q R S T U V W X Y Z序列以空格分隔。 常见做法跳过易与数字混淆的 I、O，但这属于组织规则，不是平台强制。
R31 培训资料明确建议不要修改系统 Default Revision。 需要不同规则时创建新的 Revision，并在测试环境验证序列耗尽、导入和升级行为。
Released 与下一次修订
Released 只对关联到 Versionable ItemType 的生命周期有版本意义。 R31 官方 Life Cycles 文档说明：标记 Released 的状态在下一次受控 Lock/Unlock/Edit 序列中会把 Item 移回 Start State，并递增 Major Rev。
这不等于“对 Released Item 每次普通保存都必然升级”。 还必须考虑：
- ItemType 是否 Versionable；
- Discipline；
- Released State 是否 Not Lockable；
- 用户走的是版本/修订动作还是其他应用层变更流程；
- Product Engineering 等应用是否接管发布与修订。
对于应用对象，应以应用用户指南定义的 Release/Revise 条件为准。
关系的版本行为
当 source 与 related Item 都可版本化时，关系需要决定“指向某个 generation”还是“跟随最新 generation”。
| Behavior | 含义 |
|---|---|
| Fixed | 指向指定 related generation |
| Float | 指向 related Item 的最新 generation |
| Hard Fixed | 固定且不能被生命周期状态改写 |
| Hard Float | 浮动且不能被生命周期状态改写 |
RelationshipType 与 State 的优先规则
旧稿把优先级简单写成“State 永远高于 RelationshipType”，这是不准确的。 R31 官方 Life Cycles 文档给出的规则是：
- RelationshipType 为普通 Fixed/Float 时，Life Cycle State Behavior 可以覆盖；
- RelationshipType 为 Hard Fixed/Hard Float 时，它不受 State Behavior 覆盖；
- State 设为 Hard Fixed/Hard Float 后，该行为延续到生命周期结束，后续 State 不能再改写；
- source Item 产生新 generation 后，旧 generation 的既有配置会保持固定。
因此要按组合测试，而不是只看某一个字段。
常见配置策略
| State | 建议起点 | 目的 |
|---|---|---|
| Draft | Float | 开发期间跟随相关对象最新代次 |
| In Review | Fixed | 评审期间稳定评审基线 |
| Released | Hard Fixed | 发布后保持受控配置 |
这只是常见模式，不是强制答案。 如果业务要求发布对象持续跟随外部主数据，可能需要不同设计和更严格风险评审。
操作：建立最小 Life Cycle
1. 写状态与转换矩阵
先定义：
| From | Transition | To | Role | Permission | 备注/校验 |
|---|---|---|---|---|---|
| Draft | Submit | In Review | Authors | Review Permission | 必填字段完整 |
| In Review | Approve | Released | Reviewers | Released Permission | 记录审批意见 |
| In Review | Reject | Rework | Reviewers | Draft Permission | 必须写退回原因 |
| Rework | Resubmit | In Review | Authors | Review Permission | 重新校验 |
矩阵必须覆盖取消、退回、重新打开和修订路径。
2. 创建 Map 与 State
以 R31 界面为基线：
- 打开
Administration > Life Cycle Maps。 - 创建 Map，填写 Name 与 Description。
- 在画布上添加 State，明确 Start State。
- 配置 Label、State Permission、Released、Not Lockable 和 Item Behavior。
- 需要状态触发 Workflow 时，选择已允许的 Workflow Map。
3. 创建 Transition
- 从来源 State 新建 Transition 并连接目标 State。
- 配置 Role。
- 需要审计备注时启用 Get Comment。
- 仅在配置不足时添加前置/后置 Method。
- 明确后置 Method 的 scope，并设计失败用例。
4. 关联 ItemType
- 在 ItemType 的 Life Cycles 关系中加入 Map。
- 如按 Classification 匹配，设置并核对 Class Path。
- 确认所有 State Permission 已列入 ItemType Permissions。
- 确认需要的 Workflow Map 已列入 ItemType Workflows。
- 如需版本行为，核对 Versionable、Discipline 与 Revision。
验证
状态与权限
使用普通角色测试：
- 新 Item 是否进入正确 Start State。
- 当前用户只看到允许的下一步 Transition。
- 非 Role 成员直接 Promote 是否被服务器拒绝。
- 到达 State 后
permission_id是否符合预期。 - 未配置 State Permission 时是否沿用此前 Permission。
- Not Lockable 与 Update 权限的组合是否符合业务预期。
版本字段
在测试副本上记录每一步的：
id
config_id
generation
major_rev
is_current
is_released
current_state分别执行：首次创建、普通编辑、手工版本动作、进入 Released、Released 后修订， 再比较字段变化。 只有这样才能验证目标 Release 与应用包的实际版本策略。
关系行为
至少覆盖四组顺序：
- source 先版本化，related 后版本化；
- related 先版本化，source 后版本化；
- RelationshipType 普通 Fixed/Float + State 覆盖；
- RelationshipType Hard Fixed/Hard Float + State 尝试覆盖。
同时打开旧 source generation 与新 generation，确认各自指向。
查看历史版本
R31 培训基线可通过 Item 的 Navigate > Versions 查看配置族中的历史版本， 并将不同版本 Dock 后对照。 菜单位置可能变化，但核对 config_id 与 generation 的方法不变。
版本差异
| 基线 | 本文采用的事实 | 需要在目标环境确认 |
|---|---|---|
| R31 | State、Transition、状态权限、Released、关系 Behavior 和配置界面 | 菜单标签、Method scope UI、应用层 Release/Revise |
| R35 | .NET 8.0.1 运行时 | 自定义 Transition Method 的 API 与依赖兼容性 |
| R39 | .NET 10 运行时 | 自定义服务器代码、Release Notes 与应用包行为 |
风险与最佳实践
- 状态名表达业务事实，Transition 名表达动作。
- 每条 Transition 只授予最小 Role，并配负向测试。
- State Permission 为空表示不改变当前 Permission，不要当成“恢复默认”。
- Released、Not Lockable、Permission 和 Versionable 分别配置、分别验证。
- 不要把每次 Save 都写成 generation 递增。
- 不要把 generation 与 major revision 混为一谈。
- 不要简单宣称 State Behavior 永远高于 RelationshipType；Hard 行为有不同规则。
- 前置 Method 用于必要校验；外部副作用采用幂等与补偿设计。
- Workflow 与手工 Promote 的责任要唯一、清晰并可审计。
- 上线前用真实角色演练全部正向、退回、取消和修订路径。
相关主题
官方资料
- Aras Innovator 31 — Life Cycles
- Aras Innovator Platform 文档库
- Manual Promotion and Revise（应用层示例）
- 《Aras Innovator Configuring Solutions Student Guide》（Revision: December 2024，Unit 13）