今天我开始根据需求设计我们的ER-图了。 然而我们项目里面有很多流程，为了简化开发，部门提出采用JBPM , 然而，我们以前还没有项目使用过它。为了在目前项目中迅速采用JPBM, 同时也想了解下它可以给我们带来的好处，我就开始上网调查它，发现JBPM看起来好庞大，显得有些复杂。但基本明白了一点：根据xml中定义的流程来动态调用不同的方法。然而，由于对JPBM的不熟悉，我却突然不知如何设计我们的ER-图、数据库表了，以前我们的流程我都会通过在表中加stepOwner(所属阶段)相关属性来控制流程流转的。 JPBM对我来说有些复杂，我需要一个简单的流程引擎。 细细想来，流程其实就是图灵机的变体，只不节点的粒度大了些，但都是根据当前状态来确定下一步动作，然后更新状态。鉴于这种考虑，我想设计一个简单的流程辅助工具(不能称为引擎，引擎所表达的功能太过强大。)。 下图就是我设计的简单工作流的执行过程： 执行过程基本就是：根据当前所处的处理阶段和状态码到工作流定义库中查询要执行的动作，然后执行相应动作， 执行完之后根据工作流定义更新流程相应的阶段和状态码。 工作流定义为：

REC	字段名称	数据类型	长度	可空	Key	说明
1	key	varchar2	50	NO	YES	规则键值
2	stepOwner	varchar2	50	NO	YES	所属阶段
3	currentState	varchar2	50	NO	YES	当前状态
4	action	300	50	YES	NO	在当前阶段、当前状态采取的动作。
5	priority	int	4	NO	NO	优先级：<stepOwner,currentState>下，优先级值小的优先选择。（用户在代码中可以优先选取。）
6	afterStepOwner	varchar2	50	NO	NO	动作执行之后的阶段所属角色。
7	afterState	varchar2	50	NO	NO	动作执行之后的状态标识。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

举例来说，有下面一个流程，

要在workFollow表中描述这个流程，我们可以在表中添加下面这些记录(省略了key和priority字段)：

REC	stepOwner	currentState	action	afterStepOwner	afterState
1	ROLE_A	EDIT_DOCUMENT	SUBMIT	ROLE_B	WAIT_AUDIT
2	ROLE_B	WAIT_AUDIT	AUDIT_ACCEPT	NONE	NONE
3	ROLE_B	WAIT_AUDIT	AUDIT_REJECT	ROLE_A	EDIT_DOCUMENT

其中， 第一条表示：在Role A 处理时，如果处于编辑文档状态(EDIT_DOCUMENT)，则执行提交动作(SUBMIT)，提交后处理阶段变为 Role B, 状态变为等待审核(WAIT_AUDIT)。 第二条和第三条：在Role B处理时，如果文档处于等待审核状态(WAIT_AUDIT)，Role B可以执行两种动作，审核通过(AUDIT_ACCEPT)和不通过(AUDIT_REJECT)。如果通过, 则结束，即将所处阶段置和状态为NONE。不通过时，将阶段置为Role A(ROLE_A), 将状态置为编辑文档(EDIT_DOCUMENT) 当然，为了记录驱动我们工作流的两个关键属性：所属阶段(stepOwner)和当前状态(currentState), 我们需要在我们的业务属性表中添加这两个字段。 有了这个基本模型后，我们就可以将流程分离到数据库中，用工作流定义来驱动程序走向。这就是我这两天设计的SimpleWorkFollow。这个简单的工作流我正在逐步完善中，但我绝不会让它变的复杂。希望这些思想对大家有所帮助。 我们项目是使用JBPM还是我这个简单的工作流有待评估。因为我们的流程很复杂，而且不同流程之间有很多关联。