从基于db的workflow转战到jbpm

从基于db的workflow转战到jbpm

    开始接触工作流是两年前，那时刚进公司，自己也算是个新手，到公司后被分配到做IT网管的项目组，做了些东西，后来成立了个新的项目组，我被分配到这个新组成的项目组，也就是从这以后开始接触工作流的。当时对工作流是一点概念都没有，慢慢从公司开发的基于db的工作流平台开始接触工作流，并基于此工作流平台结合业务开发了几个模块。
    公司的这个基于db的工作流平台还是实现了许多功能：
        1、基于web的流程设计器，主要是基于IE的vml语言开发的，可以设计出如下图的流程模板。

    此流程模板包括开始环节，结束环节以及人工处理的两个环节（专家组处理和发起人确认），实现环节的自循环以及回朔，分别在“专家组处理”环节和“发起人确认”环节上实现。基于此流程运行中的实例图如下：

    2 、环节的扭转
    A 、串行
    像上图中介绍的就是实现了串行的功能。
    B 、并行 如图

    C、多实例（即平常所说的会签）
    实现了包括所有会签都完成后才往下个环节走和几个会签后就可往下个环节走的功能，流程的模板如图：

    其中环节模板上带“M”的环节就表示是多实例的环节。
    运行中的实例如图：

    D、子流程子流程是在一个虚拟环节中实现的，即该环节不是人工环节。如图：

    基本上一个简单的工作流平台的功能都差不多实现了，不过在使用过程中还是发现了许多的弊端，毕竟系统的逻辑大部分是基于数据库函数实现的，这使得大部分的逻辑都要依赖于数据库，而外围的一些基于java的逻辑实现就比较难实现了，举个例子：在和外系统做接口时，当某个环节竣工后要向外系统发信息，而信息是通过url的方式传递的，这个用java实现是很容易的，而用数据库函数就无法直接实现了（据目前自己掌握的技术判断，不知是否有办法实现，望知道者告知），现在变通的一个做法是在数据库里保存信息，然后通过quartz定时的扫描该表，有数据则通过httpclient给外系统发送信息。还有模型本身只有开始环节，结束环节，虚拟环节和人工执行环节，使得客户提的要按业务路由的功能就无法实现了，因为缺少个判断环节模板，就是jbpm中的decision环节模板，所以在创建下个环节的时候大部分都是人为的主观去判断到底是走上图中的“方案审核”还是“任务分配”环节。这使得运用流程整合业务逻辑时并没有完全的实现流程的自动化。
    其实还有很多的缺陷，只是我们都是通过变相的方式给予了实现，可是客户有些需求在该平台上还是无法实现的。鉴于此，就开始寻找开源的工作流引擎，在osworkflow、jbpm、shark等的开源工作流引擎中选择了jbpm。为什么会选择jbpm呢？原因还是蛮多的，具体列出几条如下几条：
    1、 基于petri net理论实现的工作流。
    2、 引擎核心以微内核的方式实现（主要逻辑都在graph包下）。
    3、 基于hibernate实现持久化。
    4、 很容易的和spring实现整合，通过spring-modules实现整合。
等。最后附上一个最复杂的流程图（像蜘蛛网更贴切^_^）