解决方案打包与可重复导入
Aras 的配置迁移不是“复制数据库差异”，而是把明确纳入 Package Definition 的元数据导出为 AML， 再由 Package Import/Export Utilities 导入目标环境。一个可靠的包必须同时解决范围、依赖、冲突和验证四个问题。
适用版本
本文以 Aras Innovator 2024 Release 的 Package Import Export Utilities 与当前 15.0.2 在线文档为依据。 R37 起，该工具由单独的 MFT 下载分发，不再假定它一定在 Innovator CD Image 内。 命令名、认证窗口和产物布局应以目标 Release 随附工具为准。
1. 三层包模型
| 层级 | 作用 | 评审问题 |
|---|---|---|
| Package Definition | 表示一个可迁移解决方案 | 这个包的业务边界是什么？ |
| Package Group | 按元数据 ItemType 组织元素 | 是否漏了 List、Permission、CUI 等类型？ |
| Package Element | 指向具体配置 Item | ID、名称和依赖是否稳定？ |
Package Definition 只会导出已纳入的元素。它不是数据库变更自动追踪器，也不会自动发现所有间接依赖。
命名建议
自定义包可使用稳定的反向域名，例如 com.example.change。 命名只是团队约定；非核心包不会因为名称带点号就一定导出成 com/example/... 目录。
2. imports.mf 才是导入清单
导入工具读取 manifest 文件。官方示例使用扩展名 .mf，常见名称是 imports.mf。 不要再额外发明一个 manifest.xml 并把它描述为必需文件。
<imports>
<package name="com.example.base"
path="base/Import" />
<package name="com.example.change"
path="change/Import">
<dependson name="com.example.base" />
</package>
</imports>name是清单内的包标识。path指向该包 AML 文件所在目录。dependson声明包级导入顺序依赖。- 路径相对于 manifest 解析；移动目录后必须重新验证。
合并多个产品包时
不要用某个应用随附的 imports.mf 覆盖仓库总清单。 官方应用安装说明通常要求复制 <package> 节点并合并到现有清单。
3. 建立 Package Definition
3.1 从业务边界开始
以一个“变更原因”定制为例，先列清单：
- 自定义 ItemType、Property、RelationshipType。
- Form、View、CUI 与客户端 Method。
- Server Method、Server Event、Action。
- List、Value、Sequence、Permission、Identity。
- Workflow、Life Cycle 与其他被引用配置。
随后在管理界面创建 Package Definition，并通过 Add to Package Definition 将配置 Item 纳入对应 Package Group。
3.2 依赖需要人工评审
常见漏项包括：
- Property 的 Data Source 指向另一个包的 List 或 ItemType。
- Form 字段引用未纳入包的 Property、Method 或控件。
- CUI Item 引用另一个包中的 Command Bar Section。
- Workflow 活动调用外部 Method 或 Identity。
- Poly Item 的 poly source 尚未导入。
官方导入的 Thorough 模式会做更多存在性检查，但这不等于一个自动、完整的“Dependency Analysis 按钮”。
4. 导出流程
- 在源环境完成配置并保存。
- 检查 Package Definition、Groups 和 Elements。
- 启动与目标 Release 匹配的 Export Tool。
- 通过工具支持的登录流程连接源服务器。
- 选择 Package Definition 或指定元素。
- 导出到一个干净目录。
- 检查生成的 AML、目录和
.mf清单。 - 将文本差异纳入代码评审。
导出后重点检查：
- 是否出现不应进入包的测试数据。
- AML 是否保留稳定 ID。
- 是否漏掉关系项、List Value 或权限。
- 是否包含密码、token、环境 URL 等秘密或环境值。
- 文件编码和换行是否被工具或编辑器无意义改写。
版本化 Item
Package Element 对版本化 Item 使用 config_id 语义。不要自行把每个 generation 当成独立包元素处理；按官方工具生成结果评审。
5. 导入的两组选项
导入界面把 Type 与 Mode 分开，它们回答不同问题。
5.1 Conflict Type
| Type | 已存在同 ID Item 时 | 使用建议 |
|---|---|---|
Ignore | 跳过已存在项 | 仅在确认目标已有正确内容时使用 |
Merge | 用新 AML 更新目标项 | 常规增量部署前先在副本环境验证 |
当 AML action 为 add 且同 ID 已存在时，Merge 会按官方规则把它改为 edit。 如果 AML 本来不是 add，工具会按原 action 使用。
5.2 Validation Mode
| Mode | 行为 | 使用建议 |
|---|---|---|
Fast | 不执行额外的导入前验证 | 仅用于已经充分验证且强调速度的受控流水线 |
Thorough | 在 apply 前检查更多依赖项是否存在 | 首次导入、开发与故障排查优先使用 |
官方推荐导入 AML 通常使用 action="add"，除非确实需要其他动作，例如明确删除某项。
没有 Recreate 模式
官方 Import Tool 的选择是 Ignore/Merge 与 Fast/Thorough。 “Recreate 会先删再建”不是这里的官方模式。删除配置可能破坏引用和数据，不应被包装成普通导入选项。
6. 可复现实验：空白基线双次导入
准备一个可恢复的测试数据库，并为发布产物计算校验和。
第一次导入
- 备份测试数据库。
- 使用
Thorough + Merge导入imports.mf。 - 保存完整日志和 Release Settings。
- 登录 Innovator，确认目标 ItemType、Form、Method 和权限存在。
- 执行一个最小业务场景。
第二次导入
- 不恢复数据库，使用同一产物再次导入。
- 验证没有重复 List Value、关系项或 CUI 按钮。
- 比较两次日志中的错误与警告。
- 确认业务场景仍然通过。
依赖失败实验
- 复制 manifest 到临时目录。
- 故意移除一个测试包的
<dependson>或依赖包。 - 使用
Thorough导入到另一份可丢弃数据库。 - 记录工具给出的依赖错误。
- 恢复清单后重试并归档结果。
实验的目标不是证明“按钮变绿”，而是证明同一产物可按明确顺序重复部署。
7. Git 与发布建议
- 提交 AML 文本、
imports.mf、变换文件和发布说明。 - 不提交登录密码、OAuth secret、数据库备份和临时日志。
- PR 中列出新增、修改、删除以及外部依赖。
- 用环境变量或秘密库提供连接信息。
- 在 SDE/UAT 先跑
Thorough，再考虑生产模式。 - 每次发布记录工具版本、Innovator Release、包校验和和导入日志。
- 数据库备份与回滚脚本必须在生产导入前验证。
Aras DevOps 的 SDE、Pipeline 和 Baseline 是订阅工具链的具体能力；普通 Git 仓库并不会自动获得这些行为。
8. 常见错误
把 manifest.xml 当必需主清单
Package Import Tool 使用 .mf manifest；本教程统一使用 imports.mf。
宣称导出目录天然符合 Git 标准
核心包与非核心包的目录规则不同。Git 是否易审查取决于仓库约定和导出结果治理。
依赖完全交给工具自动发现
工具能做检查，但包边界与跨包依赖仍需人工建模和验证。
默认使用 Fast
Fast 减少验证，不代表结果更正确。新包应先通过 Thorough。
在生产直接尝试删除再导入
配置 Item 常被业务数据引用。任何删除都应作为单独迁移设计并在数据库副本演练。
9. 官方依据
- Using Package Import Export Utilities 15.0.2
- Aras Innovator 2024 — Package Import Export Utilities
- Aras Innovator 37 Release Notes
- 官方应用安装中的 imports.mf 合并示例
文档最后核验：2026-08-13。