java工作流代码_(2)java程序走一遍工作流activiti

工作流从流程定义到创建一个流程实例完成执行步骤

使用activi-designer创建一个流程定义(.bpmn结尾的文件)

将定义好的流程定义和生成的png图片通过RepositoryService(前面章节说过主要是用来处理流程定义的service)的api上传到数据库

通过RuntimeService(这个service主要是处理当前正在运行的流程实例的)启动一个流程实例

这个时候通过TaskService(主要处理当前运行的任务,一个流程实例下有多个任务)获取到上面的实例所对应的当前人任务

结束上面的任务task,流程实例会走向下一个task任务

重复4,5,完成一个流程实例的启动到结束

上面就是一个最简单从上往下执行的流程的执行步骤,本章节都是以代码做示例,代码不多,但是都执行一遍,你会对整个activiti的流程有个大概的了解

1,首先第一步要做的就是通过eclipse插件activiti-designer绘制一张最简单的流程图出来(在这里我们只用到了startEvent,endEvent,UserTask三个组件所以是比较简单的)

5043516d5cca6e7d35d9486f256399fd.png

绘制的流程图如下

dc1634f9f0bffd283c66907e9a70739e.png

当我们点击创建采购单的时候,为这个节点定义一个id和名称(下面几个节点也是同样的道理)

4c64ab1b9ec6b507dd0c58cbcb7cdb9b.png

点击左侧的mainConfig在Assingee输入一个名字,设置该流程这个步骤的处理人(当然在实际程序中会采用另外的动态获取的方式,这样只是方便理解一个整体过程)

接下来同样的道理依次为每个节点设置处理人

最后点击空白处,设置整个流程的id和名称

ebef4be2909f494b462e8fdcb1485061.png

到这里点击保存后,会在相同的目录下生成purchasingflow.png,到这里简单的流程就绘制完成了

2,利用activiti的api将上面定义好的工作流bpmn文件和png文件上传到activiti的数据库

1 /*

2 * 获取流程引擎对象,下面的方法会默认查找classpath目录下的名称为activi.cfg.xml3 * 里面bean的id为processEngineConfiguration的ProcessEngineConfiguration引擎配置对象来获取ProcessEngine对象4 */

5 private ProcessEngine engine =ProcessEngines.getDefaultProcessEngine();6

7 //部署一个流程

8 @Test9 public voiddeployProcessDefinition(){10 //根据引擎获取资源service

11 RepositoryService repositoryService =engine.getRepositoryService();12 //部署bpmn文件

13 String bpmnName="purchasingflow.bpmn";14 InputStream bpmnIn = this.getClass().getClassLoader().getResourceAsStream("diagram/purchasingflow.bpmn");15 //部署bpmn生成的图片

16 String pngName="purchasingflow.png";17 InputStream pngIn = this.getClass().getClassLoader().getResourceAsStream("diagram/purchasingflow.png");18 //添加这两个文件进行部署

19 Deployment deployment =repositoryService.createDeployment()20 .addInputStream(bpmnName, bpmnIn)21 .addInputStream(pngName, pngIn)22 .deploy();23

24 System.out.println("部署id:"+deployment.getId());25 System.out.println("部署的name:"+deployment.getDeploymentTime());26

27 }

上面的简单的api就将采购流程的流程定义部署到我们的activiti的数据库,打开数据库act_re_procdef可以查询到我们刚才上传的流程定义

3,在启动一个流程实例之前我们再重复上传上面的流程定义,接着我们根据流程定义的id(purchasingflow)来查询这个流程定义看看会发生什么情况

1 //查询流程定义

2 @Test3 public voidqueryProcessDefinition(){4

5 RepositoryService repositoryService =engine.getRepositoryService();6 //创建流程定义查询对象

7 ProcessDefinitionQuery definitionQuery =repositoryService.createProcessDefinitionQuery();8

9 String processDefinitionKey = "purchasingflow";10 //设置流程定义的key的查询条件

11 definitionQuery.processDefinitionKey(processDefinitionKey);12 //查询所有的流程定义

13 List processDefinitionList =definitionQuery.list();14 for(ProcessDefinition definition:processDefinitionList){15 System.out.println("-------------------------");16 System.out.println("流程定义id:"+definition.getId());17 System.out.println("流程资源名:"+definition.getResourceName());18 System.out.println("流程部署id:"+definition.getDeploymentId());19 }20

21

22 }

上面的结果输出了三条流程定义,并且部署的id不同和流程定义的id都不相同,带着这个疑问,我们在下面启动一个流程实例并详细讲解下

4,启动一个流程实例

1 //启动一个流程实例

2 @Test3 public voidstartProcessInstance(){4

5 RuntimeService runtimeService =engine.getRuntimeService();6

7 String processDefinitionKey = "purchasingflow";8 //根据流程定义的key启动一个流程实例

9 ProcessInstance processInstance =runtimeService.startProcessInstanceByKey(processDefinitionKey);10 System.out.println("流程实例id:"+processInstance.getId());11 System.out.println("流程定义id:"+processInstance.getProcessDefinitionId());12

13

14 }

我们发现上面打印的流程定义的id是我们最后一次上传的流程定义,所以我们得出结论,多次上传相同id的流程定义,根据流程定义启动流程实例,会取版本最新的流程定义

5,查询当前处理人的任务,我们之前在流程定义的时候写死第一个节点(也就是创建采购单这一步的处理人是zhangsan)

1 //查询当前用户的代办任务

2 @Test3 public voidqueryProcessInstance(){4

5 //查询任务使用的service

6 TaskService taskService =engine.getTaskService();7 //获取任务查询对象

8 TaskQuery taskQuery =taskService.createTaskQuery();9 taskQuery.taskAssignee("zhangsan");10 //查询该条件下的所有的任务

11 List tasks =taskQuery.list();12 for(Task task:tasks){13 System.out.println("当前任务id:"+task.getId());14 System.out.println("当前任务所属流程定义id:"+task.getProcessDefinitionId());15 System.out.println("当前任务的key:"+task.getTaskDefinitionKey());16 }17

18 }

我们通过zhangsan查询到当前任务的id和所属流程定义id,大家会发现如果填写的不是zhangsan而是别的就会查询不到,因为我们指定的任务处理人是zhangsan

6,处理一个任务,到这里我们的zhangsan获取到这个任务后,需要处理完它

1 //完成一个流程

2 @Test3 public voidcompleteProcessInstance(){4

5 //任务的id,后期整合后会通过当前登录人身份查询到该用户的任务,然后获取到该id

6 String taskId="402";7 TaskService taskService =engine.getTaskService();8 //根据任务id完成该任务

9 taskService.complete(taskId);10

11 }

7,我们在通过lisi,也就是下一节点的处理人查询当前任务会发现查询到了一个任务,然后重复5,6,直到任务结束

前 言 1 1 概 述 2 1.1 选题背景 2 1.2 组织结构 2 2 所用相关技术和方法 3 2.1 工作流 3 2.1.1 什么叫工作流 3 2.1.2 工作流发展 3 2.1.3 工作流的优点 3 2.2 MVC工作模式 4 2.2.1 MVC设计思想 4 2.2.2 MVC的具体实现 5 2.2.3 MVC的不足 6 2.3 JSP技术介绍 6 2.3.1 JSP的运行原理 7 2.3.2 JSP的生命周期 8 2.3.3 Servlet和JavaBean技术介绍 8 2.3.4 Java 虚拟机 9 2.3.5 JSP访问SQL Server 2000数据库 9 2.4 数据库后台环境配置 10 2.5 系统开发工具简介 10 2.5.1 Dr eamweaver 10 2.5.2 MyEclipse 10 2.5.3 Tomcat 11 2.5.4 SQL Server2000 11 2.5.5 chs_sql2ksp3 12 3 系统需求分析 13 3.1 系统功能分析 13 3.2 系统性能分析 13 3.3 系统方案的确定和评价 13 4 系统总体设计 15 4.1 系统层次模块图 15 4.1.1 营业厅模块 15 4.1.2 收费管理模块 16 4.2 系统数据流程图 16 4.3 数据表设计 18 5 详细设计及编码 21 5.1 编写JAVABEAN 21 5.2 营业厅实现函数 21 5.3 收费厅主要的实现函数 22 5.4 JAVABEAN主要实现模块 22 5.4.1 中文字符格式的转换模块(Stringto.java) 22 5.4.2 自动生成验证码(Ran.java) 22 5.4.3 数据库的连接(ConnectionFactory.java) 23 5.4.4 数据库连接的关闭(DatabaseUtils.java)--只提供接口 23 5.4.5 密码修改模块(Common_fuction.java) 24 5.4.6 时间格式转换(timeBean.java) 24 5.4.7 数据统计(counthander.java) 25 5.4.8 营业厅的接口(luruaction.java) 27 5.4.9 营业厅的主要函数实现(luruhander.java) 28 5.4.10 收费厅的主要函数接口 32 5.5 管理员登陆模块 33 5.5.1 管理员登录 33 5.6 营业厅管理模块 36 5.6.1 Left.jsp页面 36 5.6.2 Work.jsp 40 5.6.3 customerlistinfo.jsp 41 5.6.4 allinfo.jsp 41 5.7 收费厅管理模块 42 5.7.1 Left.jsp 42 5.7.2 Work.jsp 43 5.7.3 Customerlistinfo.jsp 43 5.7.4 gongdan.jsp 43 6 系统测试与维护 45 6.1 测试目的 45 6.2 测试环境 45 6.3 系统测试 45 6.4 系统维护 45 7 开发难点与技术 46 7.1 主要程序实现的代码描述 46 7.1.1 验证码的自动生成 46 7.1.2 生成WORD工单 46 7.1.3 以一定的时间刷新页面 47 7.1.4 JSP中文问题的解决 47 7.2 在程序编码过程遇到的主要问题: 48 7.3 代码编写风格 49 7.4 我的不足: 49 结束语 50 致 谢 50
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值