activiti flowable 开源工作流引擎项目整合开发实施实践总结

    做工作流产品的实施有很多年了，也加了很多诸如 activiti flowable jbpm 等社区和群聊。

    发现很多人在走弯路，深陷泥潭不可自拔。

    所以写了这篇文章，旨在告诉很多走向了activiti flowable整合道路的兄弟们，切勿太过于深入整合。

    推荐下个人博文地址 doc.agilebpm.cn（这里有我多年工作流实施的经验和成果）

流程任务动态设置任务候选人 

        问题：我现在有个问题，想听听各位大佬的意见，我所有的流程节点人都是不固定的，所以流程定义文件中用的都是变量，这些人可能是流程启动的时候一次性传入进去，也可能是上一节点才临时决定下一节点审批人，目前我把这些节点变量（具体的人），全部存在流程变量中（每个流程都可能都有好多人），这样做好么？有啥其他方案

弊端：

1. 流程变量人员的设置都依靠代码，实施流程太重，性能差。
2. 流程实施对开发员对于流程引擎必须有足够的了解。整体流程实施人员学习成本太高。
3. 不利于维护，而且迭代更新的后期成本太高。

 

正确做法：

　　将流程人员配置化，当任务创建时，通过解析器解析出配置人员，设置到identityLink中。任务提交，还可以动态为下节点设置候选人。

这样不需要使用流程变量。而且配置化，策略模式的去解析各种人员配置形式。可以随时修改。而且不需要编码实现。

 

flowable，activiti  流程引擎与表单整合 

　　大多人做法： 使用url表单

弊端

1. 分支等需要业务数据的场景会很尴尬，可能又要编码设置流程变量来解决了。
2. 流程驱动url表单去加载数据，但是数据保存又要和流程引擎耦合。

　　如果url表单的数据处理器没有实现配置化，那么又要编码实施（辛苦）

 

正确的做法

url表单当然可以实现但必须注意一下几点

1. 在与其他系统整合过程中要注意事物问题
2. url表单与流程配置化，
3. url表单数据的处理器（保存数据的逻辑处理层）需要和流程进行配置化。

url表单前端提供数据，提交任务后，将业务数据交给 数据处理器，

数据处理器返回 业务id，businessKey 然后设置给流程。

 

除了url表单，还可以构建一个表单引擎服务（并非activiti那种，太弱了）

1. 将业务数据抽象成统一的业务对象，
2. 使用业务对象构建，自动生成可扩展的表单
3. 为流程配置表单，将业务对象作为流程运行时的可用参数。

        这样流程提交后，做业务数据的持久化动作，并且可以在流程中使用到流程表单数据。这样做还有一个好处，流程表单的开发标准化。可以专注的为表单构建更多的可复用的表单组件。

 

activiti5与flowable6选择

参考 https://blog.csdn.net/hj7jay/article/details/68483096

肯定选择flowable，这个会是流程高效流程引擎的未来，而且越来越注重整合方面的事情了。

 

activiti流程变量获取设值

可以通过实现了VariableScope接口的实体操作流程变量。    如：ExecutionEntity，TaskEntity在任务、流程监听事件中都可以拿到。

建议封装BpmContext 用线程变量存储一个类似 org.activiti.engine.impl.context.Context一样的线程流程变量对象。可以直接静态方法方式拿到流程的variableScope操作流程变量。

可以在流程启动接口，任务处理接口直接将流程变量提交给流程引擎

 

activiti驳回，activiti*跳转

现实方式

1. 重写activiti缓存，让流程定义缓存线程化
2. 任务提交前，克隆流程定义，放入线程中，动态修改流程图，让当前节点流程直接指向目标节点
3. 提交任务

但驳回前要做一些前置的判断，比如同步中无法驳回等等

修改流程图可以参考https://www.oschina.net/code/snippet_39770_36561

注意：缓存必须拷贝并线程化，否则存在多线程问题，比如上面那篇文章。就只能作参考驳回那部分代码。

 

 

 

 

 

 

文章会不定期更新其他人遇到的问题