语源科技BlogJava-jbpm

jBPM开发企业流程应用之在Tomcat上部署流程引擎及控制台

jbpm — Wed, 12 Dec 2007 08:16:00 GMT

摘要: 阅读全文

jbpm 2007-12-12 16:16 发表评论

jBPM开发企业流程应用之安装流程设计器

jbpm — Wed, 12 Dec 2007 08:13:00 GMT

摘要: 阅读全文

jbpm 2007-12-12 16:13 发表评论

jbpm解析流程定义有三种方式

jbpm — Thu, 22 Nov 2007 10:02:00 GMT

作者:杨洪波
jbpm解析流程定义有三种方式:
1)par包
static ProcessDefinition auctionProcess =
ProcessArchive.parse("org/jbpm/tdd/auction.par");
注意,必须在classes的org/jbpm/tdd/目录下有一个auction.par文件

2)xml文件方式
static ProcessDefinition auctionProcess =
JpdlXmlReader.parseFromResource("org/jbpm/tdd/auction.xml");
注意,必须在classes的org/jbpm/tdd/目录下有一个auction.xml文件

3)文本方式
static ProcessDefinition auctionProcess = JpdlXmlReader.parse(
    "" +
    " " +
    "    " +
    " " +
    " " +
    "    " +
    " " +
    " " +
    "");
这种方式的本质和xml文件解析方式是一样的.

jbpm 2007-11-22 18:02 发表评论

shark和jbpm配置文件处理方式比较

jbpm — Thu, 22 Nov 2007 09:59:00 GMT

作者:杨洪波

shark和jbpm配置文件处理方式比较

1.都使用了单例模式
我想这个是最基本的,一般的程序员写解析程序都会这样使用;要说明的是,AgileFlow
除了使用单例模式,还实现了配置文件的动态装载,如果用户修改了配置文件,它能够在
运行中动态的获取这些变化.
使用jbpm时,第一句话就要使用该模式:JbpmServiceFactory.getInstance()....

2.都实现了缺省配置和定制配置
Shark中,缺省配置放在一个深层次的目录中,定制配置放在config目录,两个配置
文件的内容差不多;
jbpm中,缺省配置放在代码中实现,如下:
propertyClassNames = new HashMap();
propertyClassNames.put( "default", "org.jbpm.impl.DefaultServiceFactory" );
abbreviatedClassNames.put( "jbpm.service.factory", propertyClassNames );
定制配置放在config目录中,为jbpm.properties
比较而言,jbpm的实现方式要好,理由如下:
1)缺省配置容易找到
2)定制配置很简单,默认是没有配置的,比shark的要清爽很多

3.都实现了用一个单例实现多个单例
我在Shark学习系列的文章中讨论过这个功能,jbpm是在JbpmConfiguration.java中实现的:
private void instantiateConfiguredObjects() {
    // instantiate configured objects
    this.fileMgr = (FileMgr) instantiate( "jbpm.file.mgr", FileMgr.class );
    this.idGenerator = (IdGenerator) instantiate( "jbpm.id.generator", IdGenerator.class );
    this.serviceFactory = (ServiceFactory) instantiate( "jbpm.service.factory", ServiceFactory.class );
}

jbpm 2007-11-22 17:59 发表评论

JBPM外接任务表单简述

jbpm — Sun, 11 Nov 2007 08:24:00 GMT

摘要: 目前我看过采用JBPM的工作流有web-console (JBPM 3.2.1自带）、RUNA WFE、SMART,就这三个我做一个比较：

RUNA WFE

RUNA WFE是上面提到的三个中，唯一可以直接部署应用的，当然也有它的缺点，下面我会提到。这个框架采用的是Struts作为表示层，流程管理和组织架构管理都做的不错，良好的国际化，文档很全。如果只打算研究可以看下它的permission部分，它已经实现了对流程查看、启动、结束等的权限控制，JBPM自身在这部分基本还是TODO状态。

阅读全文

jbpm 2007-11-11 16:24 发表评论

工作流系统参考模型

jbpm — Sun, 11 Nov 2007 08:00:00 GMT

摘要: 研究工作流及其相关技术的人一定知道这个组织——工作流管理联盟（简称WfMC，Workflow Management Coalition），其成立于1993年。作为工作流技术标准化的工业组织，WfMC提出的工作流系统参考模型（Reference Model）无疑为各家工作流软件厂商的系统设计规划提供了最权威的参考，乃至标准。下面就是这个参考模型：

阅读全文

jbpm 2007-11-11 16:00 发表评论

国内外主要bpm厂商

jbpm — Sun, 28 Oct 2007 04:21:00 GMT

作者:胡长城

        目前主要列出了13家公司，这几家主要是做workflow的。当然，目前国内做OA，做Platform（包含workflow）的公司很多，但是，在workflow方面非常专注的，比较少。
        还有很多公司没有列出来，主要是个人感觉他们在workflow这一个方面并不是非常强劲（可能他们的product，platform很好），比如：BOS（金蝶），EOS（普元），GK-Workflow（北京点击科技），iOffice.net（广州红帆），KA-2（北京科诺），OW4J（Oracle中国），UAP（用友），HotOA（上海华炎），ZoTn（中唐）。还有些小型的工作流产品公司，产品并不是非常有特色，也没有列出来，比如：WiseFlow（上海维泰），aoflow（北京奥宝）

         目前我所知道的，在国内比较有名的国外workflow/BPM 厂商，主要有三家：Ultimus（较早进入中国），BusinessWare（北京麒麟，美国VITRIA）,2003年进入中国； webMethods（2003年底在北京成立办事处)
         以下的“★”表示可workflow参考度和可研究度，越多表示产品在workflow这一方面更有特点。注：BusinessWare只给了三个“★”，是表示其所定位在解决方案和项目实施，整个产品定位在Business Process Integration层次，有些超越目前国内市场需求。

编号
I00	★★★	AWF（北京炎黄盈动）	嵌入式的工作流平台，功能不是太完善，主要研发实力不足
I01	★★	DLFlo（上海东兰）	2000就开始做工作流平台，2002年推出了java版本。但整体来看，发展的不是很理想
I02	★★★★★	LiveFlow（上海东兰）	和DLFlo定位差不多，都面向二次开发平台。但是正个产品还是停留在“workflow”功能层次。—— 但是，吸收了DLFlo的很多经验，所以其工作流平台目前还是属于国内前列
I03	★★★	BusinessWare（北京麒麟远创）	主要方向是BPM和BPI（业务流程整合）。整个产品是一个“集成平台”。
I04	★★	e-cology（上海泛微）	但从workflow这个层次来说，泛微没有太多的特色。
I05	★★	eWay Platform（北京东方易维）	Eway的黄金时代已经一去不复返了，自动“马毅”那个团队离开以后。工作流的一些理念当时还是值得的，有些类似ofbiz。表单处里采用二次开发jsp页面来处理。
I06	★★★	JKCFlow（四川金科成）	JFCFlow从早期的工作流产品转移向“业务基础软件平台”，但是整个产品平台目前还只能算是，一个OA开发平台。在workflow和model方面并不是非常的强
I07	★★★★	JoinWork（上海天际星）	Joinwork刚刚推出来，其开发者丁宏比较欣赏jBPM，joinwork很多思想也是参考了jBPM。但功能上稍微弱了点。但是其基于SWT的设计思想很值得借鉴。
I08	★★★★	Koof MetaLogic（北京世纪金政）	去年推出的workflow产品，专做工作流平台，虽然主要定位于oa和电子政务平台，但工作流这一快，还是有很多克参考的功能。
I09	★★★	RiseOffice（北京有生博大）	当前版本riseoffice5.1，整个工作流产品基本上为“OA审批流程”量身定做。其表单处里和权限控制很有特色，以及审批历程的处理。整个design端时采用web的，用的 addflow控件。
I10	★★★★★	SunFlow（杭州信雅达）	sunFlow这一两年发展很迅速，大有赶超SynchroFlow 趋势。其产品最大的特色是采用基于域的联邦系统架构，对分布式管理、运行支持较好。而且也是目前国内为数不多的可以支持“仿真”的工作流系统。
I11	★★★★★	SynchroFlow（西安协同数码）	基本上非常严格遵循了wfmc的规范，完全实现了interface1、interface2、interface3、interface5。这一点上，SunFlow和SynchroFlow都有很多相像的地方，都遗留很多学院研究的特点（这两个产品的最初原型都是在大学中诞生的）。
I12	★★★★★	Utimus（国内）上海敏照（增值代理商），上海永信（增值代理商） Ultimus上海分公司	进入中国最早的国外工作流产品，整个产品采用逻辑的组织结构图，工作流系统支持的功能也很强。其比较有特色的是其“事件条件表

jbpm 2007-10-28 12:21 发表评论

工作流活动实例状态转换的两种实现模式

jbpm — Sun, 28 Oct 2007 04:12:00 GMT

作者:胡长城
今天和同事chelsea 就活动实例状态的实现思路上进行了讨论。我们两个站在了两个不同的角度来看待，这两个不同的角度也正好眼下最为常见到的两种实现思路：
helsea是从状态角度来看待，当然也完全是从state pattern的角度来思考：状态在达到某个状态的时候，会引起或必须引起活动实例执行什么操作。

而我是从活动实例的角度来考虑，活动实例的状态只是活动实例的一个属性体，是因为什么行为，造成了什么状态的结果。

这两种观点，没有谁对谁错，也没有谁优谁劣，两者是站在不同的角度来分析同一个问题。其实这两种模式在应用中都是很普遍的，也都是能够很好的解决问题的。不过在现有的workflow引擎实现中，基于活动实例的角度是占绝大多数的，比如obe，shark等等。所以我受这个的影响也是比较深的。

先说说基于活动活动实例的角度的思路吧：

让我下先来看看状态类：

public final class WMActivityInstanceState extends WMObjectState {

public static final int OPEN_NOTRUNNING_INT = 0;

public static final int OPEN_SUSPENDED_INT = 1;

}

或者也可以这么表示：

public enum WMActivityInstanceState{

NOTRUNNIN(0),

SUSPENDED(1);

private int code;

private WMActivityInstanceState(int code){this.code = code;}
public int getCode(){return this.code}

}

对于活动实例来说，状态只是其一个属性而已：

public class BasicActivityInstance extends BasicAttributedEntity{

private int _state;

public void setState(int state) {

_state = state; }

}

或者也可以是

Public void setState(WMActivityInstanceState state)

所以，从活动实例的角度来看，状态之间的关系是平行的。你可以在执行完一些初始化的操作之后，将活动实例的状态设置为Initialized：当然这个操作你必须显示的去设置活动实例（当然，你可以用一些Event去处理），比如调用活动实例的setState方法。至于为什么调用这个方法，或者此时设置的状态是对是错，活动实例并不关心。

下面再来说说基于状态角度的思路吧，这个思路大体可以说就是state pattern的应用。

     说道这儿，您可以看看这篇文档：从工作流状态机实践中总结状态模式使用心得。当然如果您对state pattern不是很了解，那么建议你先看看这篇文档：设计模式之state 。

    State模式的着眼点就是状态，以状态的变迁影响实例的行为和动作。其实这就是两个不同的抽象体：state和stateOwner，我们可以看到，活动实例对象就表现为stateOwner。

   State模式的依据是状态之间是有有向连接关系的，这有向连接关系其实就是状态的转换规则：A-B-C-D-A。

   激发状态的变迁，是由外界的事件（Event）影响的：这个事件会告知，当前的活动实例状态要从当前状态往下一个状态变迁。而活动实例并不知道下一个状态是什么，这完全是状态对象负责维护和告知的。

至此，我们可以看出来了，两种方式的不同：

第一种方式（基于活动实例），其外界事件是影响到活动实例，或者说在事件中显示的告知活动实例状态从什么变为什么。

第二种方式（基于实例状态），其外界事件是影响到活动实例状态对象，至于这个状态的下一个状态是什么，时间并不知道，完全由活动状态之间的关系来维护。

jbpm 2007-10-28 12:12 发表评论

一个简单的会签实例

jbpm — Mon, 15 Oct 2007 09:34:00 GMT

作者:tomkoo
以下例子中采用了jbpm console 的几个实例用户

项目提交人 : ernie .

主管审批 : bert

会签 : ernie , bert , grover

老板审批 : grover

正常流程: 项目金额 >= 500W RMB

提交项目 --> 主管审批 --> 会签 --> 老板审批 --> 审批通过(结束)

正常流程: 项目金额 < 500W RMB

提交项目 --> 主管审批 --> 会签 --> 审批通过(结束)

其中主管审批, 会签, 老板审批 , 不通过, 全部退回给项目提交人修改.

会签中: 所有人全通过, 则通过. 任何一人不通过, 停止其他会签任务.退回给提交人.

流程定义如下:

xml version="1.0" encoding="UTF-8"?>
<process-definition xmlns="urn:jbpm.org:jpdl-3.1"
name="tc_prj_approval">
<swimlane name="initiator" />
<swimlane name="requester">
<assignment expression="user(ernie)" />
swimlane>
<swimlane name="chief">
<assignment expression="user(bert)" />
swimlane>
<swimlane name="boss">
<assignment expression="user(grover)" />
swimlane>
<swimlane name="cosinger">
<assignment class="net.chenj.jbpm.sample.CosingerAssiHandler">
assignment>
swimlane>
<start-state name="start">
<task name="tc_prj_newprj" swimlane="initiator">task>
<transition name="to_submit" to="tc_prj_submit">transition>
start-state>
<task-node name="tc_prj_submit">
<task name="tc_prj_submit">task>
<transition name="to_chiefapprove" to="tc_prj_chiefapprove">transition>
task-node>
<task-node name="tc_prj_chiefapprove">
<task name="tc_prj_chiefapprove">task>
<transition name="approve" to="tc_prj_countersign">transition>
<transition name="disapprove" to="tc_prj_submit">transition>
task-node>
<task-node name="tc_prj_countersign" signal="last-wait"
create-tasks="false">
<task name="tc_prj_countersign">
<event type="task-end">
<action
class="net.chenj.jbpm.sample.TaskEndCountersign">
action>
event>
task>
<event type="node-enter">
<action name="createInstance"
class="net.chenj.jbpm.sample.CreateTaskInstanceCountersign">
action>
event>
<transition name="approve" to="amount_decision">transition>
<transition name="disapprove" to="tc_prj_submit">transition>
task-node>
<decision name="amount_decision">
<transition name="to_bossapprove" to="tc_prj_bossapprove">transition>
<transition name="to_end" to="end1">transition>
decision>
<task-node name="tc_prj_bossapprove">
<task name="tc_prj_bossapprove">task>
<transition name="approve" to="end1">transition>
<transition name="disapprove" to="tc_prj_submit">
<condition>#{amount >= 500}condition>
transition>
task-node>
<end-state name="end1">end-state>
process-definition>

会签swimlane class

package net.chenj.jbpm.sample;
import org.jbpm.graph.exe.*;
import org.jbpm.taskmgmt.def.*;
import org.jbpm.taskmgmt.exe.Assignable;
public class CosingerAssiHandler implements AssignmentHandler {
private static final long serialVersionUID = 1L;
public void assign(Assignable assignable, ExecutionContext executionContext) {
// 从数据库或者ldap 读取会签人设置
String[] a = { "ernie", "bert", "grover" };
assignable.setPooledActors(a);
}
}

创建会签任务实现类

package net.chenj.jbpm.sample;
import org.jbpm.graph.def.ActionHandler;
import org.jbpm.graph.exe.ExecutionContext;
import org.jbpm.graph.exe.Token;
import org.jbpm.graph.node.TaskNode;
import org.jbpm.taskmgmt.def.Task;
import org.jbpm.taskmgmt.exe.TaskMgmtInstance;
public class CreateTaskInstanceCountersign implements ActionHandler {
private static final long serialVersionUID = 1L;
public void execute(ExecutionContext executionContext) throws Exception {
Token token = executionContext.getToken();
TaskMgmtInstance tmi = executionContext.getTaskMgmtInstance();
TaskNode taskNode = (TaskNode) executionContext.getNode();
Task task = taskNode.getTask("tc_prj_countersign");
// 从数据库或者ldap 读取会签人设置创建任务实例
tmi.createTaskInstance(task, token).setActorId("ernie");
tmi.createTaskInstance(task, token).setActorId("bert");
tmi.createTaskInstance(task, token).setActorId("grover");
}
}

结束不通过时结束其他会签任务实现

package net.chenj.jbpm.sample;
import java.util.Collection;
import java.util.Iterator;
import org.jbpm.graph.def.ActionHandler;
import org.jbpm.graph.exe.ExecutionContext;
import org.jbpm.taskmgmt.exe.TaskInstance;
import org.jbpm.taskmgmt.exe.TaskMgmtInstance;
public class TaskEndCountersign implements ActionHandler {
private static final long serialVersionUID = 1L;
public void execute(ExecutionContext executionContext) throws Exception {
boolean isDisapprove = Boolean.valueOf((String) executionContext
.getVariable("isDisapprove"));
// 如果有一个任务实例拒绝通过则结束除当前任务实例外其他任务实例
if (isDisapprove) {
TaskMgmtInstance tmi = executionContext.getTaskMgmtInstance();
TaskInstance ti = executionContext.getTaskInstance();
final String actorId = ti.getActorId();
Collection c = tmi.getSignallingTasks(executionContext);
for (Iterator it = c.iterator(); it.hasNext();) {
TaskInstance task = (TaskInstance) it.next();
if (!(actorId.equals(task.getActorId())) && (!task.hasEnded())) {
task.end("disapprove");
}
}
}
}
}

jbpm 2007-10-15 17:34 发表评论

Jbpm和Shark比较的feature list

jbpm — Mon, 15 Oct 2007 07:09:00 GMT

作者：Ni Yue
前一段时间做的一个jbpm和shark的feature对比，今天整理笔记突然又看到这张记录纸了，so post here and drop the paper.作比较的时候Shark是1.0版本，而Jbpm是2.0版本（现在已经出到3.0了）

	Shark	Jbpm
持久层	Shark自己的一个ORM的方案DODS，感觉不是很好	大名鼎鼎的 Hibernate（Jbpm2中使用的是Hibernate 2.1，Jbpm3种使用的是Hibernate3）
灵活性	Shark给人的感觉就是庞大，需要独立的运行一个工作量引擎服务	相对更加灵活，和OSWorkflow有的一比，也可以作为嵌入式的工作流引擎
后台管理	其实这点和上面一点有点相对应了，灵活性差其实是由于提供的功能太多的缘故，Shark自带了一个管理程序，界面虽然差了一点，但是功能满全面的	Jbpm2中没有提供后台的管理，Jbpm3还没怎么用过，好像是有的，不知道具体功能如何
流程定义的图形设计器	Shark使用的WfMC定义的XPDL语言定义流程，有一个JaWE来图形化定义流程，不过XPDL是在是看起来很难懂	Jbpm2中没有流程图形定义器，不过Jbpm3中已经有了，是基于Eclipse的一个插件，可以使用它定义Jbpm使用的JPDL，而且不仅是插件形式，后面还会出stand alone的版本
表单定制	这个Shark可以借助XPDL来进行表单定制，没看太懂就是了	Jbpm2不支持，原来看了Jbpm的MailList里面说在考虑Jbpm3中会加入这方面的内容，现在似乎没有看到还
用户模型	好像必须采用Shark中的用户模型	灵活性的体现，任意的用户模型。Jbpm3.1的roadmap里面考虑自带一个简单的用户模型供使用
异构系统交互	Shark可以开CORBA的服务，这个方面的功能很强大	只能通过Java和异构系统的交互似乎，Java能做的Jbpm就行
学习成本	Shark使用的XPDL很难看懂…	相对简单
文档	感觉是一片空白，给的那几个pdf都不顶什么用，用两三个小时就全部看完了，组织的不是很好而且。相对其他的方面，这个是最大的缺点了	挺全面的文档，一个chapter一个chapter的，看起来也方便

jbpm 2007-10-15 15:09 发表评论