flowable框架工作流入门教程( 三 ) _流程

我结合以前的事例谈谈我的看法，当时的业务还没整合工作流的时候，我们是有一些数据表去记录流程的流转的，但是这些表对业务的粘合性太强，举个例子，就是对账单审核流程这些表上都是对账单的业务，当初设计的数据表完全不通用。所以在建表的时候是建议考虑通用的方式去建表，而不是针对某一个业务上的流程就建立某一业务的流程表，这样可以对多个不同类型的流程归集在一起统一管理，方便想要做流程监控，日志采集什么的都很方便。
如果是在原有功能上整合加上工作流，在这种尴尬的场景下，应该也是多数人遇到的情况，那么长痛不如短痛，将数据迁移，数据表的设计上保持通用，考虑多个流程的记录。你可能需要建立两张主要的表，一张记录每个流程实例，一张记录流程流转节点。
其次，我也遇到过比较特殊的场景，就是要根据业务条件去搜索查询待办任务，既然是根据业务条件去查询待办，那么单纯去工作流服务查询获取数据那是不可能的，工作流服务里面存放的都是流程信息，很少存放一些业务信息，除非是控制流程流转条件的业务数据才存放进去。
那么怎么做到可以在业务服务上查询待办信息呢？
首先，会有人说可以把业务数据都放在工作流服务上呀，这样不就可以根据条件去查询待办信息。这样做是可以，但是成本很高，假设你的项目有几十个流程，每个流程的业务数据很多，那么流程变量的创建就很多，表与表之间的关联就非常复杂了，关键是每个流程的业务本身就不是相互通用的，所以这无疑就增加了实现的复杂度。那么，我当时的做法是，在业务服务上针对这一个业务建立一个存放该业务的流程实例的表（因为只有这个业务有这种需求去根据条件查询待办信息），这个表里面会记录当前流转到哪个节点ID,在查询待办信息的时候根据用户角色，获取对应可以审核的节点，从而过滤出需要待办的列表。
需要实现一套在产线执行错误的情况下可以回滚节点的机制
比如，产线上执行金额审批上出错了，造成这一笔资金迟迟不能运作，这是个很严重的问题，如果没有一套回滚的策略，那么你的功能在用户体验上大打折扣。结合我本身的经历，需要提供一套在节点出错的情况下可以回滚的接口进行人工操作回退，又或者第二种，当业务上发生错误的情况，流程审核也要保持一致进行回滚。
前者是人为操作，一般出现这种情况都是由于业务服务上出错了，但是继续调用执行了工作流服务，这种是分布式事务的问题。那么你可以在界面上提供一个人工修复流程节点的功能，方便用户操作。后者是自动操作，一般用户没有察觉流程上出错了，而是业务提示报错，流程操作跟着业务一起回滚，后者是完全实现了分布式事务的回滚。实现分布式事务的回滚，可以采用TCC机制，也可以通过可靠消息实现最终一致性。具体看场景应用来选择。
记录流程实例在数据量大的情况下要考虑数据备份
我说一个例子，我们有个业务订单流程，每个订单都会对应一个流程实例，每天都有很多订单，不到几个月就有几百万的订单，数据量是会很多的，如果双十一那数据会更加恐怖，那么有两种做法，如果这些单都是走完流程的，也无需进行统计，那么就不需要进行记录，直接物理删除，及时削减数据量，防止数据量过大影响数据读写。如果业务本身记录这些数据是有意义的，需要用来做统计，那么那些流程数据已经走完成为历史的需要进行迁移，可以建立一套数据仓库方便后期数据统计。后者对于设备有一定要求，需要搭建一套数据仓库来存储，然后进行数据分析。

flowable框架 工作流入门教程( 三 )

flowable框架工作流入门教程( 三 )