Flowable使用场景的一点思考

flowable大家应该都不陌生，只要有做过工作流相关开发，一般都听说过。他是基于activiti，很多概念、用法都是相通的。

最近，客户管理系统项目需要整合flowable，整合的原因如下：客户的合同、项目信息录入后，需要进行审批，审批通过后才能算作正式数据，才能被其他模块引用。

一开始，项目经理说要整合flowable，我是比较排斥的。
1. 首先我觉得要实现这样的需求，不借助流程引擎也是可以实现的：给实体加个状态字段，配几个审批的角色，不同角色只能看到对应状态的任务，审批时候修改状态即可
2. 审批节点很简单，就两级，也不涉及会签、并行审批等复杂流程走向
3. flowable的数据库如果是在另外一个库里，还得考虑分布式事务问题，比较麻烦

综上，个人觉得没有必要去整合这么重的东西（虽然flowable自称是轻量级业务流程引擎）

还是项目经理有远见哈，上线几个月后，产品需要支持会签功能，一级审批需要至少一人同意，才能往下走

如果要增加会签功能的话，按照我之前的想法（不用流程引擎），就会比较麻烦了

流程引擎，目前主要使用场景有两种：
1.企业oa审批
2.业务系统审批

这两种场景的流程引擎在使用上是不太一样的。我也参与过企业oa流程审批开发，基本上是把流程组件整合好后，后续工作都在流程设计、部署、发布上，很少会去动流程代码。

但是对于业务系统的流程，个人感觉是流程设计比较简单，但是每个流程都需要去做个性化开发。

为什么说业务系统的流程需要个性化开发呢？

我们知道流程引擎的作用就是帮我们进行流程流转，让我们关注于业务细节，不用去管复杂的流转逻辑，所以，流程引擎的强项在于节点流转，什么会签、并线、穿行审批，他都能搞定，只要我们流程设计好，就会按照我们的逻辑进行流转。
而审批人的指定，就是一个比较麻烦的事情了，也是作为开发需要重点关注的。

对于企业oa类型的审批流，是有完整的组织架构关系，每个人的上级领导、部门经理、xx经理，其实都是可查的，可以定义一些关键字作为流程变量，在流转过程可以根据这些关键字去找到对应的审批人，并顺利流转给下个节点。

而业务系统的审批人一般比较灵活，可能是在前端让用户选择，也可能是根据一定查询口径，查询审批人再进行流转。除此之外，业务系统进行节点审批的时候，经常会处理一些流程外的事务，比如发邮件、发短信、发mq等。当然也可以使用一些任务监听器来实现，这样耦合性就小了。但是流程设计就会麻烦些，总之，各有利弊。

所以，对于业务系统的流程引擎，在实际使用中，基本上会进行个性化处理，流程流转和业务代码会耦合在一起，借助流程引擎进行流程流转，用业务代码来处理业务逻辑。

以上，是个人的一点拙见，可能不太正确和成熟，欢迎批评指正。