公司最近做的项目中使用到了审批流的业务,这种业务在现实中非常普遍。比如说老师可以对学生成绩审核,审核通过交给教务处审核。 我之前做的一个国资处管理系统也是,首先由经办人提出申请,然后部门主管审批,然后国资处审批。我采用的方式是硬编码到代码中,现在想来这种方式其实是非常不好的,比如后期加了一层审批我就需要重新修改代码了。 之前去用友面试的时候,和面试官提到我的这个项目的时候,他就问了这么一个问题,我当时就醒悟了,这种方式确实很欠妥(当时水平有限)。重新回到正题,公司是通过Activity去处理各个系统之间设计到业务流程流转这样的逻辑的。 也就是说开发人员开发系统是暂时不考虑业务流程流转,完成后再开发一套匹配的BPM(Business Process Management)系统,然后部署到Activity服务器。
之前再做.net的时候也接触过开源流程引擎,比如:
驰骋工作流引擎 ccflow
.NET开源工作流引擎 RoadFlow
他们解决的任务其实是类似的。但是本人也没有在生产环境使用过这些工具,在此不多讨论。有兴趣可以自行了解。
本质是什么 |
要回答这个问题就要从问题入手,这个在前面已经讨论了。 要解决这个流程逻辑和其他业务逻辑的高度耦合,最好的方法就是创建两个系统,两个系统互相没有关联(当然是相对的没有关系,两者之前还是存在弱耦合的,不然bpm没有任何意义)。 让我们先来看看
Activiti 的首席架构师 Tom Baeyens是怎么说的吧。
Activiti 的首个目标就是要获得开发者的青睐。首先它在使用时极为方便,只是个 jar 文件,使用时仅需要将其放在类路径中,当然,Activiti 也可以作为独立服务器的方式使用;同时 Activiti 提供了很多 BPM 高级工具,其中还包括开发了协作工具,使得开发人员、业务人员和运维人员能够更好的协同工作。
PS:就连开发人员的天敌都给考虑进去了。多么体贴
所以我认为Activiti的本质就是方便扩展流程管理, 方便应对业务人员关于流程方面需求的变更。
核心是什么 |
Activity的核心就是processEngine,更为具体一点就是BPMN 2.0 的流程引擎。BPMN 是目前被各 BPM 厂商广泛接受的 BPM 标准,全称为 Business Process Model and Notation,由 OMG 组织进行维护,2011 年 1 月份发布了其 2.0 的正式版。BPMN 2.0 对比于第一个版本,其最重要的变化在于其定义了流程的元模型和执行语义,即它自己解决了存储、交换和执行的问题。这代表着 BPMN 2.0 流程定义模型不仅仅可以在任何兼容 BPMN 2.0 的引擎中执行,而且也可以在图形编辑器间交换。作为一个标准,BPMN 2.0 统一了工作流社区。
知识体系结构是怎样的 |
下面给出了一张图,这张图包括了BPM的基本组件:
从这张图也可以看出,ProcessEnginie的核心地位。
输入:配置管理读取配置文件
输出:各种ServiceAPI,封装了各种常用服务供开发者调用。后续博客会详细介绍各种Service的功能