记一次关于Activiti工作流引擎的业务处理个人想法

编写原因

本人一直想抽时间写写博客，但是由于在一家外包公司工作所以比较忙，一直没时间，这次写这篇博客，实在是因为某些原因才写的（具体原因后续会提到，比较心情不好的那种）

写在前面

因为工作原因，公司一个微服务系统需要使用到工作流引擎，我本人也只是比较粗浅的接触了解，之前一直使用的pbm，甲方要求使用Activiti，所以就去了解了一下官网，以及寻找一些demo，这里找的是 nanjing0415的activiti-demo 感兴趣的可以去看看 研究一下
后端地址：https://gitee.com/nanjing0412/activiti-demo
前端demo地址：https://gitee.com/nanjing0412/activiti-demo-ui

	使用的是activiti5.2.2的版本。现在都出到7了。哈哈比较落后哈

业务处理心得

	本人在这个项目中负责一个前置业务（必须使用流程处理），和流程中心。所以呢本人将流程中心作为一个单独的微服务来使用，这也是微服务架构体系下作为一个基础服务，为以后更多的业务处理做准备
然而，万万没想到。我前置业务这一部分做下来后是一波三折哇，连我的工作流引擎都改了无数次以及变更业务表快把我玩废了。
起因是这样，本来activiti在自带的editor中有个表单属性,我们在话模型图时，

只需要将vue的路由地址写进去，那么我在这个任务节点，以及历史任务节点中都会有这个地址存在，Task的属性名为formKey，在前端获取这个地址，去retouer.push过去携带者存储的业务主键，以及任务id,进行任务处理，查看历史记录等。
然而我项目经理呢不知道怎么讲。各种骚操作，说需要在业务列表中进行审核，又说待办列表中也能审核，然后又说业务列表中不知道当前用户是否能审核，又说待办列表中的任务没有显示业务信息，等等不多说了。
最后搞的这个流程中心的API接口，控制器接口是各种各样的，一直改一直加。
本人在这里就给出一点我个人的想法，感兴趣的可以看看。

activiti官网中也推荐采用taskId的方式去处理任务，那么

本人觉得，处理任务不一定要在业务列表中处理，既然我们做了待办，activiti又提供formUrl属性 为啥我们还要去业务列表中处理呢，在后端业务服务上各种fegin的内部调用？业务量下的情况下还能适应，业务量大呢？
查看审批记录，等可根据业务表中的字段流程实例id进去调用流程中心 查看，何必说我点审批记录还得显示我的业务数据，那我外面的业务列表给你提供查看？显示干哈？
既然是微服务架构体系，那么我的流程中心就一定是用来处理流程任务的，最好不要在后端频繁的调用流程中心的获取任务列表还进行区分我的业务数据是否包含任务，包含就怎样？不包含又怎样?
个人觉得既然单独做成一个流程中心了，而且activiti也提供formUrl与businessKey 那么我们何必做的那么绕？