工作流技术jbpm学习总结

题记：某部门领导有天突发奇想，把我们几个人叫过去，曰：最近出去开会，老有人推销自己的工作流产品，说的这好那好，你们几个给我研究研究。正好刚做完的xxx子系统里有一个申请审批的流程，你们按这个需求，把系统改成jbpm工作流试试。一定要搞清楚，引入工作流能不能减少我们开发部门的工作量。

于是，4个啥也不懂的人，忙碌的两周（实际时间大概是一周不到，因为每个人都一直有其他项目的工作）开始了。

也许是我们几个的水平不行，最后写了这么一个报告，结论是一般都会增加工作量。

 

JBPM工作流小结

 

         经过两周的学习和讨论，我们了解了工作流的概念、并逐步分析和熟悉了jbpm工作流的特点和应用，现对jbpm工作流总结如下。

 

关于JBPM工作流

1.        工作流

       工作流是一项分离业务操作和系统流程的技术。工作流由实体(Entity)、参与者(Participant)、流程定义(Flow Definition)、工作流引擎(Engine) 四部分组成。

l  实体是工作流的主体，是需要随着工作流一起流动的物件(Object)。例如，在一个采购申请批准流程中，实体就是采购申请单；在公文审批流程中，实体就是公文。

l  参与者是各个处理步骤中的责任人，可能是人，也可能是某个职能部门，还可能是某个自动化的设备；

l  流程定义是预定义的工作步骤，它规定了实体流动的路线。它可能是完全定义的，即对每种可能的情况都能完全确定下一个参与者，也可能是不完全定义的，需要参与者根据情况决定下一个参与者；

l  工作流引擎是驱动实体按流程定义从一个参与者流向下一个参与者的机制

      前三个要素是静态的，而第四个要素是动态的，它将前三者结合起来，是工作流的核心组成元素。

 

2.        JBPM

       jBPM，全称是Java Business Process Management，是一种基于J2EE的轻量级工作流管理系统。

n  jBPM的一个特色是采用了它自己定义的JBoss jBPM Process definition language (jPdl)。jPdl认为一个商务流程可以被看作是一个UML状态图。jPdl就是详细定义了这个状态图的每个部分，如起始、结束状态，状态之间的转换等。

n  jBPM的另一个特色是它使用Hibernate来管理它的数据库。Hibernate是目前Java领域最好的一种数据持久层解决方案。通过Hibernate，jBPM将数据的管理职能分离出去，自己专注于商务逻辑的处理。

 

JBPM工作流的应用分析

jbpm工作流步骤：

1、加载（发布）流程定义

这个意思是，我们通过jbpm的designer插件，或者是用其他工具，制定出processDefinition

，然后将其加载到应用中的过程。这个加载可以是写入内存中，或者是直接写入数据库等。

2、启动流程

创建流程实例的过程。具体创建实例的方法有多种，可根据自己的需要自行选择。

3、处理任务

在流程流转的过程中，JBPM引擎会为我们生成任务的实例，我们就需要针对这些任务实例来进行处理，然后结束这些任务实例，并推动流程的流转。

4、记录流程的相关状态

记录流程状态这点包括且不限于以下内容：

1）流程实例的开启

2）任务实例的创建

3）任务实例的开始执行

4）任务实例的结束

5）流程实例的结束

 

使用jBPM的优势

将业务流程复杂的系统结构清晰话，提供系统运行时的灵活性

1、  解耦系统业务流程

流程独立，可以使用工具定义和建模，利于跟踪、监控、管理、调度、优化和重整

2、  提高系统的灵活性

系统流程定义生产环境的修改和调整，用户和外部工具交互，任务的动态分派

 

使用jBPM时的问题

1、  对当前任务的条件查询

jBPM不提供灵活进行条件查询的api，如果需要，可以自定义hibernate查询，从jbpm相应的数据表中查询任务数据。但需要对jBPM机制比较了解，而且有些复杂条件难以用jBPM本身的信息查到。

2、  当前任务的分页

在上一问题的基础上，使用hibernate分页。

3、  统计各个流程实例的状态

可以通过流程实例，在jbpm系统表中查询，也可以在业务表的相应数据上加上状态列来统计。前一个比较麻烦，后一个比较直观，但不会因使用jBMP而使用工作量减少。

4、  工作流数据与业务数据结合

一般通过在流程实例中添加相应的一笔数据的标识作为变量来关联。也可以有针对性的扩展jbpm的系统表来实现与业务的关联性。

5、  修改流程后的历史数据兼容性问题

Jbpm工作流流程定义有版本的概念，修改流程后要重新发布，与旧的流程不是一个同一个版本。系统可以区别开新旧流程来。

结论

1、  工作量

初步的结论是：引入工作流技术不会明显减少系统开发工作量。相反，在一般情况下，会增加一部分工作量。

如果项目流程比较少，而且比较固定，则使用工作流技术会明显增加开发工作量。

如果项目流程多，而且比较复杂，则使用工作流技术会使项目结构层次更加清晰、更具有扩展性，根据需求有可能要修改和扩展现有开源工作流类库与数据库结构，也会增加额外的工作量。但权衡之下，利大于弊。

2、  关于业务数据与jBPM本身的数据

理论上说，如果使用jBPM，可以将所有业务数据放到jBPM的context中管理，不再维护业务数据表。但这样的结果是在流程之外的环境（比如在统计报表中）中无法容易的得到业务数据。所以一般会建立业务数据表，我不使用工作流时一样，然后让jBMP从业务数据表中得到业务数据，而不在jBPM中保留业务数据。因此，使用jBPM后，在业务数据方面基本不会减少工作

 

3、  工作流学习成本

工作流本身的概念较复杂，使用jbpm，需要学习其工作流的定义和结构，流程定义工具和语言、了解其数据结构。与其它工作流产品（如Shark）相比，jBPM对Java开发人员来说学习较低成本，在做流程复杂的项目时，学习成本可以接受。

 

4、  系统用户和角色与工作流整合

流程的流转和任务的分派完成，都是用户在控制，所以需要将用户、角色和权限整合到jbpm工作流中。

 

5、  系统业务的整合和调整

将流程抽取后，原本连续的业务处理变成一个个的任务节点。需要在每个业务相关处理处添加工作流流程控制、在每个节点处实现相关的业务和流程切入点。

 

 

6、  适用范围

Jbpm工作流适用于：

n  项目流程比较多，流程复杂的项目。

n  系统运行和维护、升级时，流程可能需要修改、调整和跟踪、控制的项目。

 

工作流使用示例

 ----------  xxxxx -----------此处省略了一些

使用JBPM，是先苦后甜。
不能看眼前的工作量。

开发部门领导关注的只有工作量。

说实话。我也不明白优势。可能是要投入到 工作流 之海 的系统开发后，才会对引擎这一东西有所依赖吧。

呵呵，写的挺好的。
主要是和业务系统的结合。
前期代码量会比较大。

写得不错，比较实在。

很多时候要从市场考虑，你说你有个工作流引擎，客户的对你的看法都不一样

jbpm这东西处理复杂的业务在我看来有点吃力，虽然怎么都可以实现，但是做出来的东西很不理想，对于的中国的国情，很多事情都是简单事情复杂化，所以这个洋玩意有时候很难胜任中国国情。

jbpm在中国需要动大手术，而且一般软件，我想最好别用jbpm，因为流程少、需求变化小，系统比较稳定，直接自己写效率比用jbpm高。当然jbpm用熟练了后，适当使用还是很爽的，毕竟人家速度快、规范。呵呵，自己考虑吧，刚入门的时候你就把jbpm当做一个类库！工具包，就ok了！

理伦太多了，