当今常见的BPM趋势是集中化整个公司或公司内大部门的BPM执行。这意味着，单个BPM服务器（集群）运行着整个公司的许多流程定义。这种方式的挑战在于，虽然BPM引擎（包括jBPM）提供了对于任务访问的授权[1]，但它们一般都不支持这些功能的授权：流程定义的查看和删除，流程实例的启动、结束、查看和删除等。在这篇文章中，我们将描述如何对jBPM引擎进行扩展（基于jBPM 4.3）来实现这一功能。

　　整体实现方法

　　整个实现方式相当直接了当——对于每个流程定义引入一组可以授权的用户/用户组（类似任务定义），作用于定义、实例和给定流程的历史。此外，我们还想对给定的用户/用户组支持多重授权级别——目前我们打算引入2个角色：“starter”和“user”。这里的“starter”是允许对流程定义/实例/历史进行任何操作的角色，而“user”角色的权限仅限于查询流程/历史。

　　这种方式的实现需要对jBPM进行以下改造：

• 流程定义
  • 给流程定义增加流程访问权限
• 流程部署
  • 扩展当前的流程部署器，增加流程授权定义的解析和流程访问列表的生成
  • 引入额外的类/数据库表，存放每个流程定义的访问权限
• 流程执行（Execution）
  • 引入已授权命令（authorized command）——要求用户经过授权才能执行的命令
  • 修改现有的jBPM中我们期望基于当前用户证书进行授权的部分。这包括启动、结束和删除流程实例，以及删除部署定义。
  • 修改现有的jBPM查询，考虑现有用户的证书。这包括部署和流程定义查询、流程实例查询，以及历史流程实例、活动和细节的查询。

　　除了以上更改，我们还想扩展流程实例查询，好让用户可以通过指定某些流程变量的值来缩小查询结果。这种搜索的一个常见情况就是查询“由我启动的”流程。为了确保这种查询总是可用，我们更改了启动流程实例命令的实现，显式地把当前用户ID加到了流程变量值的集合中。

　　最后，为了支持多种用户认证方法，我们实现了一个自定义的身份会话，它支持用程序来设置和访问当前用户的证书。其目的在于，把用户证书（ID和参与的组）的获得和jBPM运行时对这种信息的使用分离开来。

我们的实现利用了非常强大和灵活的jBPM 4的配置机制，它让我们可以：

• 通过扩展现有jBPM类，最小化了自定义代码的数量，只实现我们扩展所需的额外功能
• 将我们的扩展实现成可以与jBPM 4类库一起使用的单独jar包，无需对现有库进行任何改变。

　　在深入我们的实现细节之前，我们首先要讨论一下我们大量使用的jBPM 4的配置。

　　jBPM 4的配置机制

　　jBPM的基础是流程虚拟机（PVM），它建立在自定义的依赖注入实现之上。依赖注入由非常强大的、基于XML的配置机制控制，这种机制用于创建标签和预定义接口相关的特定实现之间的绑定（binding）。

这种机制的核心是jbpm.wire.bindings.xml文件，它描述了jBPM PVM的主要组件，包括：

• 基本类型
• 对象及引用
• 环境引用
• Hibernate绑定
• 会话
• 服务
• 部署器
• 拦截器
• 等

　　该文件是jBPM分发包的一部分。如果用户想增加自己的绑定（binding），他可以创建jbpm.user.wire.bindings.xml描述它们，而不用修改jbpm.wire.bindings.xml文件。

　　这两个文件会被jBPM PVM在启动时读入并解析，为定义在jbpm.cfg.xml中的基础PVM执行（execution）配置而服务。jbpm.cfg.xml一般会包含多个部分，描述了PVM执行的特定组件的配置。

　　jBPM PVM由一组提供PVM功能的服务组成，主要的PVM服务包括：

• 仓储服务，提供一组查看和管理部署仓储的方法
• 执行服务，提供一组查看和管理运行中流程执行（execution）的方法。
• 管理服务，提供一组查看和管理工作（job）的方法
• 任务服务，提供一组查看和管理用户任务（task）的方法。
• 历史服务，提供一组访问运行中和已完成流程执行的历史信息的方法。

　　这组可用服务和实现这些服务的类（使用前面说的绑定）被配置成流程引擎的上下文。

　　服务执行被实现成一组命令（command），它们作为服务方法执行的一部分被调用。命令的实际执行由命令服务控制。

命令服务在命令服务上下文中被配置成一组拦截器，实现横切关注点，环绕（around）命令调用（命令执行管线）。缺省的jBPM分发包在命令执行管线中携带了以下拦截器：

• 重试（Retry）拦截器负责重试命令执行
• 环境（Environment）拦截器负责在必要时把jBPM上下文注入命令执行中
• 事务（Transaction）拦截器负责介入命令调用的事务边界划分。

　　拦截器是将jBPM移植到不同环境以及引入其他横切关注点的核心机制。

　　命令执行一般会利用环境，它也是可配置的。典型的环境组件有：

• 仓储会话
• DB会话
• 消息会话
• 定时器会话
• 历史会话
• 邮件会话

　　可以添加其他会话来扩展PVM的功能。

　　最后，部署管理器配置允许指定一组部署器，它们依次执行，把业务流程部署到PVM。这种方法使得扩展流程定义可以通过实现额外的部署步骤完成，无需覆盖 jBPM分发包自带的部署器。

整个PVM的架构图1示：

图 1 PVM架构

　　在流程定义中引入授权

　　我们在图2中看到，可以给流程定义添加任意属性。利用这种扩展选项，我们现在定义以下流程属性，描述授权策略：

• starter-users，具有“starter”角色的用户列表
• starter-groups，具有“starter”角色的组列表
• user-users，具有“user”角色的用户列表
• user-groups，具有“user”角色的组列表

　　每个属性的值是逗号分隔的组/用户id列表。

图 2 流程定义模式

　　此外，我们还定义了一个特殊的用户类型——“any”和两个用户组——“all”和“admin”。任何用户，不论其真实ID是什么，都是“any”用户。任何组，不论其ID是什么，也都是“all”。最后，“admin”组的成员被认为是任意组的成员。

流程授权定义由以下规则驱动：

• 如果user-users和user-groups都未被指定，则user-users=”all”
• 如果 starter-users和starte-groups都未被指定，则流程用户被额外地分配“starter”角色。

　　按照这个规则，清单1中的流程可以被任何人启动和使用。

<process package="com.navteq.jbpm" 	    key="NO_AUTHORIZATION" 	    name="Test Authorization not required"   version="1" 	    xmlns="http://jbpm.org/4.0/jpdl">	<start g="68,14,48,48" name="start"  >	<transition to="end"/></start><end g="78,383,48,48" name="end"/></process>

it知识库：使用JBoss jBPM实现流程访问和执行的授权，转载需保留来源！

郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。