前言
在上文工作流流程引擎 Activity 介绍与实践 中已经简单介绍过Activity工作流框架与简单的示例，那么现在开始讲解怎么在业务中使用Activity框架。
原生的不足
Activiti自己维护一套用户信息，未与业务系统的用户关联起来
表单与流程绑定，存储在Activiti自己表中，无法与业务表单进行关联
需要经过2步操作（签收与办理）才能完成一个任务
业务操作未与流程操作分离，如完成任务前需要更新业务状态
架构图
关联业务系统用户
实现方式是部署流程时写入角色信息，这样导入流程后可以读取节点的所有信息包括跟节点关联的角色（执行者）。在页面上重新选择执行者的时候系统会重新生成绑定了角色信息的xml部署。
可以查询到用户组。
业务实现一个CustomGroupEntityManager，继承GroupEntityManager这个类，重写findGroupsByUser()方法。然后根据传入的用户名返回用户所在角色的信息。
动态配置表单
流程每个节点的表单都会有点不同，所以能够动态地配置表单是很常见的需求。
结构图
配置每个表单的编码标题和访问路径
配置每个表单是否可见与是否可编辑
自动派单
上文说过任务有签收和办理两步，这在操作上有点不方便，我们日常的审批系统都是上一个节点的人办理好就自动流转到下一个节点而且办理人也是确定的。这就相当于是自动签收。
这里以一个简单的FIFO（先进先出）的轮询规则来轮询执行者角色的办理人
使用策略模式来编写派单策略
集成脚本引擎
Activiti 内部充斥着各种各样的事件，每个动作后面都全产生一个事件。所以我们需要定义全局事件监听器，截获所有事件。再分派给具体handler进行处理。我们使用流程脚本就可以做到业务与平台框架的分离，在流程流转的时候执行脚本的代码去完成业务的操作。
常见使用场景：流转到某个节点就改变订单相应的状态。
后记
以上介绍了一些业务系统上一些比较良好的Activity实践。如果有兴趣可以查看相关的书籍更深一步地学习，推荐这本Activity实践以及社区
