关于activit6工作流与业务嵌合的设计思路

        现在所在的公司的一个项目原先使用的工作流节点全部写死，要做技术更新，框架选用了activiti。版本是6.0.0。

        其实在接触activit之前，完全不明白它是怎么和业务发生关系的，我需要做什么，它需要做什么，才能完成一个业务需求？摸不到头脑。

        在买了三本书《activiti权威指南》《activiti实战》《疯狂讲义之activiti6.0》并翻阅、查询了网上大量资料、实例之后，才对activiti6.0有了一个初步了解。原来，要使工作流和我们的自身业务发生关系，那是需要程序员去撮合的（噢大哥这tm的叫惊喜啊）。所谓撮合，不是把业务代码入侵到activiti中---解耦还是有必要的---而是说，把自己业务中可能会用到的工作流的应用场景做一个总结和抽离，再在这一层的基础上，写作调用的具体业务代码。也就是说，activiti好比骨架，纯业务层好比皮肤，那么联结和铺垫在他们之间的这一层就是肌肉。

        举个例子，我们的项目需求中有一条是：流转中要使用完全自定义的按钮名称、按钮数量，比如可以叫做“确认”，同样表示肯定意味的还有“同意”、“通过”、“确定”等等。这种东西不可能交给前端来实现，一个是因为前端一般不做业务逻辑处理，第二则是前端也根本没有办法控制这种逻辑，这种东西一定是需要和后端进行交互的，分离控制的话会非常复杂。

        如果是后端处理，我是这么设计的，如下图：

{
"buttonDefs":[
						{
						"businessType":"yes",
						"buttonName":"同意"
						},
						{
						"businessType":"no",
						"buttonName":"拒绝"
						},
						{
						"businessType":"bt1",
						"buttonName":"退货"
						},
						{
						"businessType":"bt2",
						"buttonName":"试用"
						}						
]
}

是的，这是一段json，可以还原为具体有层次的javabean，可以被读取。我管它叫做“按钮定义数组buttonDefs”，里面的每一个元素都是一个按钮定义，包括了按钮的名称，还有被按钮名称代表的参数名。这段json代表了我的设计，要和工作流发生关系，我把它放在了流程图定义的某个节点中。如下：

 这样，在查看用户任务的接口中，我可以通过某些方法将“按钮定义数组”从activiti中读取到，并与用户任务一起，返回给前端，形成一种准动态控制的用户按钮机制。如果我想，我还可以实现：改变按钮的颜色、按钮的条件式隐藏、特殊按钮的特殊业务代码触发等等，完全取决于后端流程图的定义与后端代码的写作。而用户点选了哪个按钮，则决定了按钮参数名称的取值，即流程接下来的走向。

        以上，就是一个小小的“肌肉”的例子，它不会被业务代码入侵，但是又能满足现有业务场景的调用，并且结合了activiti框架本身。

        其实这种结合，能做的还有很多，比如对用户评论comment的利用，可以实现每一个用户任务的上传附件、下载附件的管理；对业务要求指定节点的跳转；数据的一次性流程生成与先生成数据、再进行数据流程生成的分离式操作等等。

        总之，不要觉得使activiti与业务发生密切关系是不现实的，同样不要认为它能代替你实现任何业务场景。它只是一个满足了基本工作流转的框架而已，具体怎么使用，需要程序员去丰满，去实现。

        在这里，我再列举一下，个人认为在写作业务代码和使用activiti的过程中一定需要的基本“肌肉”：

1.自定义按钮的实现。上文有简述，不再赘述。

2.根据用户点选的条件找到下一个任务节点

3.找到上一个节点并驳回该节点

4.撤回已发出的流程节点

5.各种对业务流程的校验并提示用户

6.对回环业务中可能有的业务要求的实现，比如隐藏按钮

7.与启动业务流程的业务实体发生的各种可能的关系

8.切面化的业务代码，与“肌肉”解耦

以上，抛砖引玉尔。如果有任何工作流相关的问题，欢迎与我进行交流探讨，互通有无，谢谢。