activiti

Activiti 6.0源码初探 一、Github工作方式 Activiti Admin为Activiti官方管理员所维护的库。 采用从官方库fork一份到自己的库，然后再克隆，可以实现在修改完本地代码后交到自己的库中，而若是直接从官方克隆是不能实现的。若我们提交到自己的库中的代码是有价值的，可以向官方库发起一个请求，他们的运维管理员通过之后，会将代码推送到官方库，这样就为开源软件做贡献。并且一个项目的fork数体现了该项目的受欢迎程度。若要实时更新Activiti的代码，可以从Activiti库中pull一份，然后提交到自己的库中。 二、克隆源码并编译 1.克隆源码 git clone git@github.com :shaoyucao/Activiti.git 2.进入到Activiti中并进行checkout创建分支操作cd cd Activiti git checkout -b study6 activiti-6.0.0 #以activiti-6.0.0为分支分化一个新分支study6，并切换到study6 3.编译 mvn clean test-compile #mvn clean清除编译生成的文件，mvn test-compile ，对源码进行编译，包括test/java，main/java下面的源码 发现编译前后两者的文件内容是不一样的 编译前： 编译后： 编译完成后

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> ##需求 serviceTask失败之后，期望能够自动重试。 ##配置 <serviceTask activiti:async="true" activiti:exclusive="false" activiti:expression="${demoService.getSentence(execution)}" id="demoServiceTask" name="demoServiceTask"> <extensionElements> <activiti:failedJobRetryTimeCycle>R5/PT1M</activiti:failedJobRetryTimeCycle> </extensionElements> </serviceTask> 配置async为true 配置重试次数为每个1分钟重试一次，总共重试5次 ##docs Custom Fail Retry configuration activiti:failedJobRetryTimeCycle R5/PT7M</activiti:failedJobRetryTimeCycle> service-task-async及retry配置 Re: Handling erros in Process Instances. How to

http://www.360doc.com/content/13/1106/11/203871_327110236.shtml 1.简单介工作流引擎与Activiti 对于工作流引擎的解释请参考百度百科： 工作流引擎 1.1 我与工作流引擎 在第一家公司工作的时候主要任务就是开发OA系统，当然基本都是有工作流的支持，不过当时使用的工作流引擎是公司一些牛人开发的（据说是用一个开源的引擎修改的），名称叫CoreFlow；功能相对Activiti来说比较弱，但是能满足日常的使用，当然也有不少的问题所以后来我们只能修改引擎的代码打补丁。 现在是我工作的第二家公司，因为要开发ERP、OA等系统需要使用工作流，在项目调研阶段我先搜索资料选择使用哪个 开源 工作流引擎，最终确定了Activiti5并基于公司的架构做了一些DEMO。 1.2 Activiti与JBPM5？ 对于Activiti、jBPM4、jBPM5我们应该如何选择，在InfoQ上有一篇文章写的很好，从大的层面比较各个引擎之间的差异，请参考文章： 纵观jBPM：从jBPM3到jBPM5以及Activiti5 1.3 Activiti资料 官网： http://www.activiti.org/ 下载： http://www.activiti.org/download.html 版本：Activiti的版本是从 5 开始的

在上篇文章中，我们介绍了在Linux中部署Activiti，在windows下也可以通过相同的方式，将Activiti的模块拷贝到tomcat下，通过浏览器访问。本篇文章介绍使用Activiti默认的两个模块Activiti-app和Activiti-admin，通过浏览器访问的方式体验Activiti的流程过程。 我们使用admin/test登录Activiti-app模块（浏览器本地访问地址： http://localhost:8080/activiti-app/ ） 1.创建流程参与者 2.创建流程 选择Kickstart App 画流程图 并配置用户状态： 同理，配置HR的用户状态，保存并关闭编辑器 创建APP 选中并关闭（选中一个模块） 保存并发布 可以见到主页上多了一个审批模块 退出后用用户登录 点击审批模块： 开始一个流程，可以在comments处添加一个描述 在show diagram中可以看到流程进行到了TL审批 然后退出当前登录，使用TL登录，选择审批模块之后可以看到有一个待办任务，点击Cliam即为获取待办任务，然后可以写备注，再点击Complete完成。 然后点击流程，用Show diagram查看，可以看到节点进行到了HR审批。 然后退出当前tl用户，用hr登录，进行同样的操作，最后流程结束。而在HR审批完成后，Process中是无法查看到的

工作流在我们日常的工作中用得可谓相当普及，尤其在企业内部管理系统，如考勤、财务、合同等系统中更是离不开它。在我们金融科技领域，工作流主要用于贷款审批、风控审核等环节。早期工作流在企业信息化发挥着很重要的作用，随着信息化的初步完成，工作流核心技术也为国内很多大一点的系统集成的公司所掌握。比如我们合作过的宇信、神码、浪潮、企源等传统IT公司都拥有自主产权的的工作流框架。由于工作流具有一定的门槛，国内尚没有能满足企业级应用的工作流开源框架，一些国内CMS开源项目号称支持的工作流也只是对Activiti的简单引入或者是较简单的工作流实现，还不能完整的满足一般企业应用。 Activiti是目前最热门的开源工作流框架，但是由于中西方文化差异及组织架构上的不同，拿Activiti来做中国式的企业级应用难度很高，需要做大量的改造。这里记录下常见的思考点及解决思路，实际碰到的问题会更多且更复杂。 1 、待办已办在Activiti相关API中是面向任务的，需求是面向流程的 比如，如下图的需求 在Activit中一个流程是有多个Task组成，而我们中国式的审批需求是一个流程只允许出现一次，哪怕这个流程你在审批过程中参与过两次以上的审批任务，也仅需要显示一次。 这里就需要将TaskService查询出来的任务再按流程实例ID进行去重，去重后任务查询api的分页会变得不可用，对待办和已办未完结来说还好

之前在选择工作流引擎时曾经在activiti和jbpm之间有过比较，当时做出的决定是使用jbpm，但实际开发过程中发现这个选择是不合适的。目前我们改为选择Activiti作为工作流模块的引擎，理由如下： 1，Activiti拥有更简洁健壮的接口 JBPM自从版本五后，便重启炉灶，完全抛弃了JBMP4的代码基础，重新基于drools进行了实现。JBPM5，JBPM6似乎缺少一个合格的系统架构师，其接口设计匪夷所思，基本上是按照drools的接口再提供了一套JBPM接口，同名的接口，实现类不断重复出现，代码体系十分混乱。 一个典型的例子，同样是查询待办事项，在JBPM中接口如下： List<TaskSummary> getTasksAssignedAsBusinessAdministrator(String userId, String language); List<TaskSummary> getTasksAssignedAsExcludedOwner(String userId, String language); List<TaskSummary> getTasksAssignedAsPotentialOwner(String userId, String language); @Deprecated List<TaskSummary>