浅析PM工作流引擎

标签: pm 工作流 引擎 | 发表时间:2014-02-07 23:55 | 作者:a1314517love
出处:http://blog.csdn.net

1.      JBPM工作流引擎是用来做什么的

首先要说明的一点是工作流引擎指的并不只是JBPM,JBPM只是工作流引擎的一种。JBPM利用JPDL流程定义语言将现实生活中处理事务的业务流程进行抽象,形成一套业务流程规则,只要处理该项业务就必须按照这个流程规则进行。举一个很简单的例子,就拿看医生来讲,看医生的整个流程必须是先挂号,再看病,再抓药,只要你进行看医生这个业务就必须按照这套流程进行。说白了,工作流引擎只是将我们人工的处理过程进行了信息化而已,也并不是多么高深的思想。但是JBPM也并不是想我所说的这样简单,毕竟是一套相对来讲比较成熟的技术,它的功能还是十分强大的,它可以用来定义顺序流程结构,选择流程结构(也就是根据条件判断来决定下一步执行哪项任务),以及多任务必须全部完成才能进行到下一步的流程结构。总之,JBPM是将生活中的各种业务处理情况进行抽象所制定出的一套业务处理规则。

2.      JBPM如何应用

使用JBPM工作流引擎一般来讲分为五部分,他们分别是部署流程,创建流程实例,获取当前活动,获取特定用户的任务,以及完成任务。其中,每一部分都是通过一项JBPM服务完成的。下面通过上面的看医生这个流程来讲解如何使用JBPM。

首先来看我们的jpdl文件:

<?xml version="1.0" encoding="UTF-8"?>
<process key="test" name="test" xmlns="http://jbpm.org/4.4/jpdl">
   <start g="275,16,48,48" name="start1">
      <transition g="-60,-15" name="挂号" to="进行挂号"/>
   </start>
   <task assignee="nurse" g="255,101,92,52" name="进行挂号">
      <transition g="-69,-20" name="提交到医师" to="医师看病"/>
   </task>
   <task assignee="doctor" g="259,186,92,52" name="医师看病">
      <transition g="-50,-20" name="抓药" to="end1"/>
   </task>
   <end g="283,283,48,48" name="end1"/>	
</process>

上面的jpdl文件定义好了整个看医生的流程,它由四个节点组成,开始节点,进行挂号节点,医师看病节点以及结束节点组成。下面我们来看上面提到的具体的五部分都是怎样进行的:

public class seeDoctor extends TestCase {

	/**
	 * 部署流程
	 */
	public void deploy(){
		//创建流程引擎
		ProcessEngine processEngine = Configuration.getProcessEngine();
		
		//创建服务
		RepositoryService repositoryService = processEngine.getRepositoryService();
		
		//部署流程
		repositoryService.createDeployment().addResourceFromClasspath("seeDoctor.jpdl.xml").deploy();
		
		
	}
	
	/**
	 * 创建流程实例
	 */
	public void createInstance(){
		//创建流程引擎
		ProcessEngine processEngine = Configuration.getProcessEngine();
		
		ExecutionService executionService = processEngine.getExecutionService();
		
		ProcessInstance processInstance = executionService.startProcessInstanceByKey("seeDoctor");
		
		System.out.println("流程实例ID===============" + processInstance.getId());
	}
	
	//查询流程实例当前所在节点
		public void getCurrentActivity(){
			ProcessEngine processEngine = Configuration.getProcessEngine();
			ExecutionService executionService = processEngine.getExecutionService();
			String activityName = executionService.createProcessInstanceQuery().processInstanceId("seeDoctor.10001").uniqueResult().findActiveActivityNames().toString();
			System.out.println("当前任务所在节点======" + activityName);
		}
	
	/**
	 * 获取对应人员的任务
	 */
	public void getTask(){
		ProcessEngine processEngine = Configuration.getProcessEngine();
		TaskService taskService = processEngine.getTaskService();
		List<Task> tasks = taskService.findPersonalTasks("nurse");
		Task task = tasks.get(0);
		System.out.println("任务数量===" + tasks.size() );
		System.out.println("任务名词===" + task.getActivityName());
		System.out.println("任务人员===" + task.getAssignee() + "任务ID===" + task.getId());
	}
	
	
	
	//完成任务
	public void completeTask(){
		ProcessEngine processEngine = Configuration.getProcessEngine();
		TaskService taskService = processEngine.getTaskService();
		taskService.completeTask("20001");
	}
}

下面我们来一次讲解每个部分所完成的主要功能。

Deploy()部署流程的作用顾名思义,就是部署一个已经制定好的jpdl文件,它的作用类似一个具有版本号的类,流程实例就是这个流程的实例化。在jpdl文件中我们通常通过指定key值来区分所部署的各个流程,如果key相同则规定创建流程实例时按最高版本进行实例化。

 

createInstance()创建流程实例就是根据key值来确定实例化哪个流程,如果有多个流程的key相同则取最高版本。

 

getCurrentActivity()查询流程实例当前所在节点。该函数的作用在于根据流程实例ID,来获取该流程实例当前执行到了哪个节点,如本例中的流程实例有进行挂号和医师看病两个节点,该函数就是用来确定当前流程实例执行到了进行挂号还是医师看病环节。

 

getTask()函数中,之所以用Task task = tasks.get(0)语句来取得第一个任务是因为可能有多个完全不同的流程实例中都有一个为nurse的角色名字,假如恰好出现了这种情况则该函数会取出所有流程实例中角色名称为nurse的任务。

 

completeTask()完成任务,该函数的作用比较清晰就是根据任务ID,将该任务结束,然后进入到下一节点中,比如当前所在任务节点是进行挂号,该任务ID是10001,则完成该任务后,则会自动进入到医师看病这个节点,当完成医师看病这个任务后则会自动进入到end节点,也就是完成了整个流程。

 

3.      JBPM中每个服务所对应的数据库表。

在上面的代码中我们可以很明显的看出在每一部分中都对应着一个Service,也就是一个服务,而所有的服务都是由JBPM引擎来创建的。

在部署流程环节,它所对应的是RepositoryService服务,当部署完流程后,在jbpm4_deployment中会插入一条部署流程记录,同时在jbpm4_deployprop表中会记录该流程的详细信息。

 

在创建流程实例环节,所对应的的是ExecutionService服务,该服务可以根据流程的key值用来启动一个具体的流程实例。启动一个具体的流程实例后会在jbpm4_execution表中插入一条流程实例记录。

 

getCurrentActivity()获取当前流程实例环节对应的也是ExecutionService,它操作的表同样是jbpm4_execution,但是该服务对该表进行的查询操作而并非插入操作,根据流程实例ID来查询出该流程实例当前所在的节点。

 

getTask()获取对应人员的任务环节对应的是TaskService服务,该服务的作用是获取特定角色名的人员的所有任务,它所操作的表示jbpm4_task表,该表所存储的是各个实例的当前任务,所以根据角色名所查询出的很可能是不同实例的相同角色名对应的所有任务。

 

最后一个是completeTask()环节,该环节对应的同样是TaskService服务,它的作用也十分的单一,就是根据任务ID来结束任务,使得流程实例进入到下一个节点。


作者:a1314517love 发表于2014-2-7 15:55:32 原文链接
阅读:14 评论:0 查看评论

相关 [pm 工作流 引擎] 推荐:

浅析PM工作流引擎

- - CSDN博客推荐文章
1.      JBPM工作流引擎是用来做什么的. 首先要说明的一点是工作流引擎指的并不只是JBPM,JBPM只是工作流引擎的一种. JBPM利用JPDL流程定义语言将现实生活中处理事务的业务流程进行抽象,形成一套业务流程规则,只要处理该项业务就必须按照这个流程规则进行. 举一个很简单的例子,就拿看医生来讲,看医生的整个流程必须是先挂号,再看病,再抓药,只要你进行看医生这个业务就必须按照这套流程进行.

activiti工作流引擎思想探究

- - 开源软件 - ITeye博客
       研究activiti有一阵了,逐渐了解了开源activiti的相关api,但对期中的processinstanceId,executeId,taskId相关应用还是有些模糊,得益于activiti开源技术推广者临远同志的启发,明白了很多工作流引擎的核心思想源自佩特里网(英语:Petri net),采用token机制来执行流程.

Jbpm工作流引擎学习日志

- - 行业应用 - ITeye博客
     jBPM是JBOSS下的一个开源java工作流项目,该项目提供eclipse插件,基于Hibernate实现数据持久化存储. 下载地址:http://pan.baidu.com/s/1ntr8t6L.     安装gpd、配置runtime环境、导入jbpm所需的jar包、创建配置文件jbpm.cfg.xml和jbpm.hibernate.cfg.xml.

从编辑到PM

- 小鱼 - 所有文章 - UCD大社区
春节前收到一封陌生人的来信,一位网站频道编辑,向我咨询转型PM的可行性. 他问道:“你觉得做媒体和做产品,以前一样么. 话题很有趣,我也乐意就此写点什么. 遗憾的是,编辑转产品的成功概率却是不高的,就我的经验来看,存在四个障碍. 媒体工作需要捕捉阅读的共性,即“大家都爱看的内容”,相对来说比较忽视用户的个性化特征.

关于PHP的工作流引擎EZER简介

- - ITeye博客
        关于PHP的工作流引擎,除了三大主流开源:PorcessMaker(排名第一,因其有拖放式图形定义界面),RadiCore(基于PETRI NET)和CuteFlow以外,另外还有一个不为人知的,但却也是非常强大的开源,叫做EzerPhp..         EzerPhp的主页: http://code.google.com/p/ezerphp/.

如何与PM沟通

- - 曉生
1.要学会听取别人意见,也许PM提出的问题你并没有考虑到,集思广益,可以得出有更好的方案. 值得肯定的是,你设计时已经能学会从产品角度考虑,引导用户操作,而不是单纯的好看. 只要不是单纯审美上的PK,都可以讨论,不是吗. 2.让产品阐述自己的需求点,明确重点. PM们七嘴八舌肯定不对的,要引导他们梳理出统一的意见.

PM札记:产品设计这两年

- - 所有文章 - UCD大社区
做产品差不多也两年左右了,基本上这条路是磕磕绊绊,迷迷糊糊,但好歹大方向是正确的,有空回想总结起来,唏嘘不已,看看以前对产品的看法,再看看今天对产品的认识,不仅感叹自己当初的幼稚,如今,更多的是了解了自己的无知与渺小,怀着一颗谦卑的心,继续学习,在产品这条路上寻找自己的价值. 产品职责包含很多东西,产品设计只是其中的一种职责,只是简单的描述一下我在产品设计上的弯路,回想起我的产品设计生涯,目前走过了三个阶段:.

PM培训的答疑课小结

- - 阿里巴巴(中国站)用户体验设计部博客
这期PM培训的最后一次课安排的是答疑,回答了一些同学们普遍关心的问题. 对学员们和讲师的讨论,我做了些小结如下:. 产生这种情况说明项目管理已经存在大的问题了. 要做到的是提前预知,避免这种情况的出现. 万一出现了,首先要深入了解原因. 两个方向,项目内搞定或者项目外搞定. 回答这个问题的关键是找关键路径.

您的团队需要什么样的PM?

- - 所有文章 - UCD大社区
     在腾讯,多数部门的实际采用了职能化或弱矩阵的组织结构形式. 中心和小组等组织层级实质属于职能线条,产品、开发、测试、运营、运维等职能角色是产品运营的主要角色,而各部门都会或多或少有一些全职或兼职的PM组织管理着各类跨职能活动.       基于各自情况的不同和各自对PM职位理解的差异,对PM职位的定位也千姿百态.