📚 课程目录第2章 Windchill工作流架构与运行机制

2. Windchill工作流架构与运行机制

Windchill 的工作流并不是“画一张流程图然后点提交”这么简单。它本质上是一套由流程模板、流程实例、活动节点、路由、队列与执行器共同构成的运行时系统。理解这套体系结构，才能在设计审批流时预判它如何被触发、在哪里排队、由谁执行、失败后如何恢复，以及流程如何与 WTDocument、WTPart、ECR、ECN 等业务对象绑定。

一、体系结构：模板、实例与执行器三层分离

Windchill 工作流在架构上分为三层。最上层是流程模板（Workflow Template），它定义节点、路由、参与者角色和变量，属于设计期产物，本身不携带业务数据。中间层是流程实例（Workflow Process Instance），当用户对某个对象发起审批时，引擎以模板为蓝本创建实例，并把对象引用、表单变量、发起人、时间戳等运行时数据写入实例。最下层是执行器与队列（Executor / Queue），负责把“该执行的活动”真正调度到某个用户或系统任务上。

这三层分离带来一个重要结论：修改模板不会自动改变已运行的实例，已启动的流程仍按创建时的定义执行。因此模板变更通常需要版本化，并通过新实例生效。

二、活动节点类型与路由逻辑

活动节点是流程的最小执行单元。Windchill 中常见的节点类型包括：开始/结束节点、用户任务节点（分配给角色或用户，需要人工完成）、系统任务节点（自动执行，如设置状态、发送通知、调用方法）、审批节点（本质是带表决语义的用户任务）、子流程节点（调用另一个流程模板）以及条件/路由节点。

路由逻辑决定流程从当前节点走向哪个后继节点。Windchill 支持顺序路由（无条件单出口）、条件路由（按变量或表达式判断）、并行分支（同时激活多条路径）和汇聚（等待所有或任一分支到达）。设计时最容易出错的是并行汇聚：如果使用“全部到达”语义，而某条分支被条件跳过，流程可能永久等待。因此并行分支应尽量保证各路径最终都会到达汇聚点，或改用“任一到达”语义。

三、队列与执行器机制

当流程实例推进到一个用户任务节点时，引擎不会直接“推”给某个人，而是生成一个工作项（Work Item）并放入对应参与者的队列。队列可以理解为待办池，用户登录后在“我的任务”中看到的就是自己队列里的工作项。执行器则负责系统任务的调度：它按轮询周期扫描到期的工作项，调用相应服务完成自动动作。

这里有两个关键参数需要关注：轮询间隔决定系统任务多久被处理一次，间隔过大导致自动动作延迟，过小则增加服务器负担；重试策略决定系统任务失败后是否重试、重试几次、间隔多久。对于调用外部系统（如 ERP 接口）的系统任务，建议配置有限次重试并记录失败日志，避免无限重试拖垮引擎。

队列是“人找任务”，执行器是“任务找人（系统）”。理解这一点，就能解释为什么用户任务会出现在待办列表，而系统任务只在后台日志中留下痕迹。

四、与业务对象的关联方式

工作流与 WTDocument、WTPart、ECR、ECN 的关联，通常通过对象初始化规则或生命周期模板建立。以文档审批为例：当 WTDocument 从“草稿”状态进入“审批中”时，生命周期模板触发关联的工作流模板，引擎创建实例并把该文档作为主对象绑定。流程中的审批节点读取文档属性作为路由条件，审批通过后由系统任务把文档状态推进到“已发布”。

ECR 与 ECN 的关联更典型：ECR 评审通过后，往往通过子流程或后续流程生成 ECN，两者通过变更对象关联。设计时要明确：流程变量中保存的是对象引用还是对象编号？如果保存编号，对象被修订后编号可能变化，导致流程找不到目标；保存引用则更稳定，但要注意版本上下文。

五、一个可参考的审批流程配置示例

下面给出一个文档审批流程的关键配置片段，用于说明模板、路由与队列如何落地。参数为教学示例，实际值需按企业环境调整。

流程模板：DOC_APPROVAL_V2
变量：
  docRef        : WTDocument 引用
  approverRole  : 角色 = DOC_APPROVER
  rejectCount   : 整数，初值 0

节点：
  N1 开始
  N2 用户任务：文档评审（队列 = DOC_APPROVER）
  N3 条件路由：
       若 approve == true  → N4
       若 approve == false → N5
  N4 系统任务：设置状态为 RELEASED → N6
  N5 系统任务：rejectCount + 1，状态回退 DRAFT → N6
  N6 结束

执行器参数（示例）：
  轮询间隔 = 60 秒
  系统任务重试 = 3 次，间隔 120 秒

判断流程是否按预期运行，可以观察三个位置：实例的当前节点与变量值、目标用户队列中是否出现工作项、系统任务日志中是否有成功或失败记录。若用户任务长期停留在同一节点，先检查参与者角色是否配置了有效用户；若系统任务反复失败，检查重试日志中的异常信息，而不是盲目重启引擎。

不要用“修改模板后重新提交”来修复已运行实例的问题。已启动实例持有创建时的模板快照，正确做法是终止旧实例、修正模板并重新发起，或使用管理工具迁移实例（需评估风险）。

掌握以上结构后，后续设计审批流时就能有意识地选择节点类型、规划路由语义、配置队列与执行器参数，并正确绑定业务对象，而不是把工作流当成一张静态流程图来对待。