activiti 开发环境

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

1 javadocs 的11 个package

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

  • org.activiti.engine,包含7个Service接口、异常定义、流程引擎、流程引擎配置和一些运行时异常类。
  • org.activiti.engine.delegate,处理流程的行为、监听事件的规范。流程定义中可以配置实现了监听接口的类业务处理逻辑。例如在流程结束时由系统自动归档。在流程运行过程中,引擎会遍历注册的监听并依次调用
  • org.activiti.engine.form,需要自定义表单的需求使用,表单的读取和提交可以通过使用
    FormService 接口使用
  • org.activiti.engine.history,包含了历史记录查询对象及查询结果的历史数据对象接口。可查询
    历史流程实例(HistoricProcessInstance)、历史任务(HistoricTask)、历史活动(HistoricTask)、历史详细(HistoricDetail)。流程的跟踪功能就是通过
    HistoryService 实现的
  • org.activiti.engine.identity,用来管理身份和认证
  • org.activiti.engine.management,主要实现针对流程引擎的管理功能,通过调用接口
    ManagementService 可以监控任务状态、任务调度、数据库数据读取
  • org.activiti.engine.repository,包含了针对流程资源的管理与查询,可以部署流程定义、自定义表单、规则等文件、读取流程图片、流程定义文件。
  • org.activiti.engine.runtime,可以查询运行时数据,例如当前用户的代签收任务、待处理任务及正在处理的流程实例对象、启动流程、挂起和恢复
  • org.activiti.engine.task,包含任务对象的定义,通通过 TaskService
    可以进行任务创建、删除、任务指派、批注管理、附件管理以及变量查询

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

 

   附上我的开源项目,希望可以给大家参考
https://gitee.com/agile-bpm/agile-bpm-basic

2 activiti 的默认配置文件 activiti.cfg.xml
用来定义引擎初始化参数、bean、邮件服务器及各种监听器

 

  2.1 activiti 引擎配置管理器参数说明

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

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

弊端:

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

 

正确做法:

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

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

 

图片 1

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,这个会是流程高效流程引擎的未来,而且越来越注重整合方面的事情了。

 

3 在 activiti explorer 中使用 activiti modeler

activiti流程变量获取设值

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

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

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

 

从5.11版本开始官方将 activiti modeler 整合到了 activiti explorer
,可以直接创建新模型然后部署到引擎中,也可以根据已有的流程定义创建模型,修改后可以把最新的修改部署到引擎中。

activiti驳回,activiti自由跳转

现实方式

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

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

修改流程图可以参考https://www.oschina.net/code/snippet\_39770\_36561

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

 

 

 

 

 

 

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

 

说明: activiti modeler 需要依赖 REST 服务

相关文章