以前没怎么接触过工做流,在网上参考了一些相关的案例。任务着急,并无太看透彻就开始coding了。这套工做流引擎并不复杂,主要是应对简单的流程运转及权限控制。数据库
咱们主要用在售后等工单系统中,一张工单。主要实现了如下功能框架
1.工做流程的界面设计spa
2.流程根据设定的路线流转,设定每一个节点的权限,控制流程的编辑及访问,设定流程中每一个用户对应每一个字段的权限设计
3.流程分支的自动判断blog
4.流程的接单及驳回内存
这是工做流引擎中涉及到的全部表了。路由
B开头的为主表,L为关联表,R为引用表存储些类型之类的常量。博客
主要的流程设计只保存在两张表中。流程节点表以及路由表。
为了使工做流与业务结合,咱们用到了流程实例表,以及活动记录表。权限控制
每开启一个流程,便建立一条流程实例,每一次流程节点的变更,建立一条活动记录。工作流
在活动记录表中,设置了接单人字段belongUser,每条节点的编辑以前须要有接单人。能够在提交上一节点的时候指定下一节点的接单人或者点击接单来手动接单。这样设计来避免多人同时编辑同一个节点。
设计图使用的是gooFlow框架,功能比较简单,可是恰巧适合我这种并不复杂的工做流系统。你们有兴趣的能够下载下来玩一下,Demo和Api讲解的也比较详细
对于多个分支的状况,有用户操做的为手动选择下一流程。
无操做界面的话须要须要在路由里写上相应的条件语句,来判断接下来要走那一条路由。 以换货流程为例:
在建立退货订单的时候就会自动建立一条退货的售后工单,同时须要传入支付方式及换货单的状态给工做流。
我将每一个工做流封装为一个dto,里面包括此工做流的全部相关信息,系统启动时加载到内存中,在修改工做流程时刷新。
上图只保存了工做流的内容,关联到业务的话,还须要一个工做流上下文的类。此类中应该包括工做流当前的状态等信息,同时提供一些基本的扩展方法。
下图为工做流上下文类的结构
写下此文一来为了锻炼一下本身写博客的能力以及表达能力。同时也但愿个位前辈可以指正纰漏,提出建议!