使用jBpm支持高级用户交互模式

使用jBpm支持高级用户交互模式2011-07-08 infoq 译:胡键许多通用业务流程都包含人类参与者。人类活动，从简单场景（如人工批准）到复杂场景（涉及复杂的数据输入），在流程实现中引入了新的方面，如人类交互模式。人类交互模式的一个典型集合包括：

四眼原则（The 4-eyes principle），通常又被称为“职责分离”，它是决策由多人彼此独立作出时的一个常见场景。在很多情况下，很容易就能得到另一个观点/签名。

任命（Nomination）是指上级根据团队成员的任务安排、工作负荷或经验人工地将任务分配给他的情形。

任务通常被建模来表达一种预期：它们将在确定时间段内完成。如果任务没有按预期地进展，就需要一种上报（escalation）机制。两种典型的上报实现是：重新分配任务，并常常附带一个上报已经发生的通知；或任务未按时完成的通知（通常发给经理）。

链状执行（Chained execution）是一个流程（片断），其中的一系列步骤是由同一个人来完成。

jBPM中的任务管理

jBPM的一个核心功能是为人类管理任务和任务列表。jBPM允许将任务和任务节点作为整个流程设计的一部分使用。

任务一般在jBPM中定义成任务节点。单个任务节点可以包含一个或多个任务。包含任务节点的jBPM流程的一个公共行为就是等待任务节点中的全部任务完成，然后继续执行。某个任务可被分配给个人、用户组或泳道：

假如任务被分配给某个特定用户，那么就只有这个使用者可以执行它。

假如任务被分配给某个用户组，那么这个组内的任何参与者都能执行这个任务。jBPM使用的是参与者池（pooled actors）符号（它可以包含组名、组名列表和参与者个人列表等），而不是组ID。如果用户开始执行在他们组任务列表中的任务，最终可能会引起冲突——可能有多人开始执行相同的任务。为了避免这种情况，在开始执行任务之前，用户应该将任务从组任务列表移动到他们自己的任务列表中。

泳道代表一个流程角色，它通常被分配给一个用户组。它是一种指定流程中的多个任务要由同一参与者完成的机制。因此，在第一个任务被分配给某个泳道之后，流程就会记住所有在相同泳道内的后续任务都将由同一参与者完成。

jBPM提供了两种定义任务分配的基本方法：作为流程定义的一部分或通过编程实现。如果是作为流程定义的一部分，分配可以通过指定具体用户、用户组或泳道完成。此外，可以使用表达式根据流程变量动态确定某个具体用户。完整的编程实现是基于分配处理器（assignment handler）的，它允许任务根据任意的计算规则去查找用户ID。

流程定义描述流程实例的方式类似任务描述任务实例的方式。当流程执行时，一个流程实例——流程的运行时表示——就会被创建。类似，一个任务实例—— 任务的运行时表示——就会被创建。根据任务定义，任务实例被分配给一个参与者/参与者组。

任务实例的一个作用就是支持用户交互——把数据显示给用户并从用户那里收集数据。一个jBPM任务实例拥有访问流程（令牌）变量的全部权限，而且还可以有自己的变量。任务能够拥有自己的变量对于以下场景非常有用：

在任务实例中创建流程变量的副本，这样对任务实例变量的即时更新只有在该任务完成且这些副本被提交给流程变量时才会影响流程变量。

创建更好支持用户活动的“派生（计算）”变量。

任务自己的变量在jBPM中是通过任务控制器处理器（task controller handler）支持的，它可以在任务实例创建时生成任务实例数据（从流程数据），并在任务实例完成时将任务实例数据提交给流程变量。

实现四眼原则

我们上面已经说过，实现四眼原则意味着要允许多人同时干一个活。它的实现有以下几种可能方法：

在任务外解决：需要大量时间的任务并行循环（parallel looping）。

使用动作处理器（Action handler）：附加到任务节点的进入事件（enter event），基于流程实例变量创建多个节点实例。

在任务内解决：引入“任务接受量（task take）”（类似jPDL 4）并允许某个任务实例可被接受多次。

根据jBPM最佳实践 ——“扩展jBPM API而不是去搞复杂的流程建模” ，我决定采用任务内解决的方法。这就要求修改jBPM提供的任务和任务实例类。