Workflow Map 与运行流程
Workflow 用于把一项业务工作分解为可分配、可投票、可追踪的活动。 Workflow Map 是流程模板；当模板被启动后，平台为受控 Item 建立运行中的 Workflow Process。
生命周期回答“对象处于什么状态”，工作流回答“谁按什么步骤完成工作”。 二者可以集成，但不能混为同一个状态机。
适用版本与资料基线
- Map/Process、Activity、Path、Assignment、Task 与投票的核心概念跨版本相对稳定。
- 配置字段与步骤以 Aras Innovator R31、2024 年 12 月版官方培训资料为界面基线。
- R35 服务器运行在 .NET 8.0.1，R39 迁移到 .NET 10；自定义 Workflow Method 必须按目标运行时复核。
- 不同应用可能提供专用流程引擎或 Workflow UI。本文只讲 Innovator 平台经典 Workflow 的已核验配置机制。
最小心智模型
例如，文档审核可以设计为 Start → Technical Review → Release → End， 并从 Technical Review 通过 Reject Path 进入 Rework，再由 Resubmit 返回审核。
当文档 A 启动该 Map 时产生 Process A；文档 B 启动时产生独立的 Process B。 两者共享设计模板，但活动状态、分配、投票和历史彼此独立。
核心对象
Workflow Map 与 Workflow Process
| 对象 | 定义期还是运行期 | 作用 |
|---|---|---|
| Workflow Map | 定义期 | 保存 Activity、Path、Assignment、Task 和变量模板 |
| Workflow Process | 运行期 | 表示某个受控 Item 的一次流程执行 |
R31 培训基线中，Process Owner 可管理或取消运行流程，并参与升级/拒绝等责任链。 修改 Map 时不要假定运行中的 Process 会自动变成新设计；上线前要处理旧实例与兼容路径。
Activity
Activity 表示一个工作步骤或系统步骤。 R31 基线常见属性包括：
| 属性 | 作用 |
|---|---|
| Name / Label | 内部名称与显示标签 |
| Message | 给处理人的活动说明 |
| Expected Duration | 预期完成时长 |
| Timeout Duration | 超时配置基础 |
| Managed By | 允许运行期管理活动分配的 Identity |
| Role | 约束可被选择/重新分配的身份范围 |
| Start Activity | 流程入口 |
| End Activity | 流程终点 |
| Automatic Activity | 无需用户交互的自动步骤 |
| Can Refuse | 允许受让人拒绝任务 |
| Can Delegate | 允许委派 |
| Consolidate Delegated | 控制委派任务的归并行为 |
| Wait For All Votes | 达到路径阈值后是否仍等待全部投票 |
| Wait For All Inputs | 汇合节点是否等待所有入向分支 |
不是每个 Activity 都要用户处理。 Start、End 和 Automatic Activity 用于控制流程结构。
Path
Path 是 Activity 之间的有向连接，也是人工活动可选择的投票结果。
R31 基线中的关键属性包括：
- Name：内部路径名；
- Label：在投票界面显示的选择；
- Authentication：是否要求密码或电子签名认证；
- Default Path：没有其他路径达到要求时使用的默认出口；
- Override Path：一旦满足即可覆盖正常等待逻辑的出口。
旧稿中把 Path 写成任意“条件表达式”是不准确的基础模型。 经典 Workflow 的常规分支由 Assignment 的投票权重、Path 的默认/覆盖行为和活动等待选项决定。 如需 Method 驱动的复杂路由，应以目标 Release 的官方事件文档单独设计。
Assignment
Activity Assignment 决定谁收到任务。 常见配置包括：
| 字段 | 作用 |
|---|---|
| Identity / Team Role | 分配对象 |
| Required | 是否为必需分配 |
| For All Members | 是否展开 Group 的所有成员 |
| Voting Weight | 该分配贡献的投票权重 |
| Escalate To | 拒绝或升级时的接收主体 |
优先使用业务角色 Group 或 Team Role，避免把个人 Alias 固定在大量 Map 中。
Task 与 Workflow Variable
- Task 是 Activity 内可排序、可设 Required 的工作清单，不是另一个 Activity，也不能替代服务器端数据校验。
- Workflow Variable 保存 Process 运行值；R31 可配置名称、类型、来源、默认值、Required、Hidden 与 Label，并可在投票时收集。
- 需要长期查询、权限和生命周期管理的数据应建模到业务 Item，而不是只保存在流程变量中。
活动完成与投票
人工 Activity 的 Assignment 按 Voting Weight 参与 Path 选择。 设计时不要只看权重总和，还要组合下列开关：
| 配置 | 作用 | 主要风险 |
|---|---|---|
| For All Members | 为 Group 成员建立任务并分配该 Assignment 权重 | 成员数量变化会改变单人权重或法定人数效果 |
| Wait For All Votes | 即使某 Path 已达阈值，仍等待应投人员 | 停用或缺席人员可能使流程停滞 |
| Default Path | 正常投票结束且其他 Path 未满足时使用 | 错误默认出口会产生错误业务结果 |
| Override Path | 达到后立即胜出，可绕过正常等待 | 可能意外赋予单人批准或否决权 |
| Wait For All Inputs | 并行分支汇合时等待所有入向分支 | 不能替代同一 Activity 的 Wait For All Votes |
若要求“一人 Reject 立即退回、Approve 必须全员完成”，可评估 Wait For All Votes 与 Reject Override Path， 并用全部投票排列验证。投产前还要覆盖 Group 为 0、1 和多个成员的情况。
Automatic Activity 不等待用户交互；R31 基线要求明确的 Default Exit Path，且不应有人工 Required Task 或认证要求。 End Activity 会关闭 Process；并行设计中不要把局部分支的完成误接到整个流程的 End。
启动 Workflow 的受支持配置方式
ItemType 默认 Workflow
以 R31 界面为基线：
- 打开目标 ItemType。
- 在 Workflows 关系中加入 Workflow Map。
- 将需要在新 Item 创建时自动启动的 Map 标记为 Is Default。
- 保存并用新建 Item 验证只生成预期的 Workflow Process。
一个 ItemType 可以允许多个 Map，但默认标记应符合清晰的启动策略。
Lifecycle State 启动
如果流程只应在对象进入某个业务状态后启动：
- 先把 Workflow Map 加入 ItemType 的 Workflows 关系；
- 打开关联 Life Cycle Map；
- 在目标 State 的 Workflow 字段选择该 Map；
- Promote 到该 State，检查运行 Process 和首个任务。
R31 官方 Life Cycles 文档明确：State 只能选择同一 ItemType 允许的 Workflow。
两种启动方式不要重复
同一 Map 如果既设为 ItemType Default，又配置在 Start State， 可能在创建期间产生重复流程。 应选择唯一的业务启动点，并把“只生成一次”列为自动化验收条件。
不要手工新增 Workflow Item 来启动流程
旧稿使用 newItem("Workflow", "add") 并手工设置内部 ID 的示例未经目标版本官方 API 核验， 也绕开了 Map 实例化所需的运行对象和初始化规则，现已删除。 优先使用 ItemType 默认或 Lifecycle State 这两种已核验配置方式； 程序化启动必须另查目标 Release 的官方 API 文档。
Workflow 推动 Lifecycle
R31 培训基线支持在 Workflow Activity 上配置受控 Item 的生命周期促进。 这样审批活动完成或激活时可以把 Item 从指定 From State Promote 到 To State。
配置前必须满足：
- 受控 ItemType 已关联 Life Cycle Map；
- 当前 State 与 Promotion 配置的 From State 匹配；
- Life Cycle Map 中存在有效的 From → To Transition；
- Workflow 使用的系统身份在该 Transition 上具有所需 Role；
- 每一种可能的入向 State 都有明确处理。
如果 State 不匹配或 Transition 无效，流程活动可能无法正常完成并返回错误。 R31 培训练习演示了回到此前活动的失败结果； 实际事务、错误文本与恢复方式应在目标 Release 验证。
数据权限仍需单独配置
Workflow Assignment 让用户能处理任务，Activity Promotion 让流程推动状态， 但它们不自动授予用户对受控 Item 的 Get 或 Update。 审核人必须拥有查看或修改工作内容所需的 Permission。
拒绝、委派与动态分配
- Can Refuse 允许受让人拒绝 Assignment；它不同于对 Reject Path 投票。必须验证 Escalate To、管理主体和 Process Owner 的接管路径。
- Can Delegate 允许在 Role 范围内委派；Consolidate Delegated 影响归并。测试谁能看到、谁能投票、再次委派和历史责任链。
- Managed By Identity 可在运行 Process 中管理活动分配。需要动态人员时可不预置固定 Assignment，再用 Role 限定选择范围。
运行期调整属于受控例外，不应替代清晰的默认角色设计，管理操作必须可审计。
Subflow
Subflow 让某个 Activity 调用另一个 Workflow Map。 父 Activity 在子流程结束前保持等待，随后从默认出口继续。
R31 培训基线的配置要点：
- 子 Workflow Map 也必须关联到同一目标 ItemType 的 Workflows。
- 调用 Activity 选择 Subflow。
- 调用 Activity 设为 Automatic。
- 为调用 Activity 配置 Default 出向 Path。
- 测试子流程成功、拒绝、取消和异常结束。
不要把每个普通活动都拆成 Subflow。 只有可独立复用、责任边界清晰的流程片段才值得复用。
操作：建立最小审批流程
| Activity | 类型 | Assignment | 出口 | 对 Lifecycle 的动作 |
|---|---|---|---|---|
| Start | Start | 无 | Default | 无 |
| Technical Review | 人工 | Engineering Reviewers | Approve / Reject | Approve 时 Review → Released |
| Rework | 人工 | Authors | Resubmit | Released 路径之外回到 Review |
| End | End | 无 | 无 | 无 |
同时记录 Required、For All Members、Voting Weight、等待规则和超时责任人，然后：
- 打开
Administration > Workflow Maps，创建 Map，填写 Name、Description 与 Process Owner。 - 添加 Start、人工/Automatic/Subflow 活动和 End，用 Path 连接允许方向。
- 配置 Activity 的 Message、时限、Assignment、Required Task、等待选项、Managed By 与 Role。
- 配置 Path 的 Name、Label、Authentication，并审慎设置 Default/Override。
- 检查无出口、无入口、误接 End 和不可能达到阈值的活动。
- 选择唯一启动点：ItemType Workflows 的 Is Default，或 Life Cycle State 的 Workflow。
- 创建新的业务 Item 执行端到端测试，而不是只打开 Map 看图。
验证
使用独立浏览器会话和真实角色验证：
- Process 只创建一次，首个 Activity 正确激活。
- 只有预期 Identity 在 InBasket 收到任务，并有读取受控 Item 的 Permission。
- Required Task、Path Label、Authentication 与 Comment 行为正确。
- 测试全员 Approve、一人 Reject、混合投票、拒绝 Assignment、成员变化和 Override。
- 每条 Activity Promotion 匹配 From State、Transition 与 Role；成功后 State Permission 正确。
- Promote 失败时 Process/Item 状态可恢复，重试不重复产生流程或外部副作用。
- Scheduler/Service 已部署并产生日志；不要只因 Expected Duration/Timeout 有值就认定提醒和升级已工作。
版本化 Item 的注意事项
Workflow Process 与具体受控 Item/generation 的关系必须明确。 设计前确定流程控制 config_id 家族还是具体 generation、新 generation 如何处理旧 Process、 Released 后是否重启审批，以及历史版本能否误处理当前任务。 R31 培训建议谨慎处理版本化受控 Item，不能只勾选 Is Default 就假定各代次天然一致。
版本差异
| 基线 | 本文采用的事实 | 目标环境需复核 |
|---|---|---|
| R31 | Activity、Assignment、投票、默认启动、状态启动、Promotion、Subflow | 菜单标签、认证选项、通知与后台服务 |
| R35 | .NET 8.0.1 运行时 | 自定义 Workflow Method 的 API、依赖和编译目标 |
| R39 | .NET 10 运行时 | 自定义代码、应用专用 Workflow UI 与 Release Notes |
风险与最佳实践
- Map 表示定义，Process 表示一次运行；变更定义前处理运行中实例。
- 优先向 Group/Team Role 分配，避免把个人 Alias 固定在 Map 中。
- 默认启动与 Lifecycle State 启动二选一，测试不会重复实例化。
- 不手工新增内部 Workflow Item 作为通用启动 API。
- Wait For All Inputs 与 Wait For All Votes 分别测试。
- Override Path 需要业务 Owner 明确批准。
- Automatic Activity 必须有明确 Default 出口，且没有人工 Required Task。
- Assignment 不替代受控 Item 的 Get/Update Permission。
- Workflow Promotion 必须匹配 From State、Transition 与 Role。
- 外部通知或集成采用幂等、重试和补偿，不能假定随流程事务自动撤销。
- 上线前覆盖无人分配、停用账号、拒绝、委派、超时、取消和版本化场景。
相关主题
官方资料
- Aras Innovator Platform 文档库
- Aras Innovator 31 — Life Cycles
- Aras Innovator 31 — Scheduler Service
- 《Aras Innovator Configuring Solutions Student Guide》（Revision: December 2024，Unit 14–15）