手把手教你如何玩转自定义工作流（一）

小蜗牛，今天爬了多远？不急，继续爬总会到达终点。
朋友们，今天学习了多久？别慌，保持学习才会看到更好的自己。
觉得我的文章还不错的，欢迎大家还可以关注我的微信公众号：Java菜鸟进阶之路
最近会写一个系列的文章进行推出，值得期待和持续关注哦！

情景引入

小白：起床起床起床起床了。。。。
我：我就想多睡会，996的工作很累的（最近这个好像很火~！），让我多休息会把。
小白：不行，不行，你都多久没更新文章了，你的心不痛么？
我：好像是的，最近太忙，没有时间来写了。
我：怎么了？小白，你是无事不登三宝殿，是不是又遇到什么麻烦事了呢？
小白：对呀对呀。。。好愁人
我：求知欲还挺强的嘛，那行，你说说看，看我能不能帮助你。
小白：就是，比如我想出去旅游，那么就需要跟组长打报告，然后组长同意了，还需要部门领导的同意，等同意之后，我才能实现我的“旅行梦”！
我：对，这就是平常的审批处理。就和学生在学校请假的流程一样，一环扣一环。
小白：可是，这样的功能是怎么做到的呢？感觉挺有意思的。
我：不错，感觉有进步了。求知欲，越来越强了。
小白：别拍马屁了，快告诉我一下这方面的知识呗。感觉用处好大。
我：好的，那我就来跟你好好说说咱们生活中常遇到的类似这样的问题如何处理吧！
小白：我去搬小板凳，等会等会。。
我：顺便记得带一包瓜子。

简介

   通过我们上面的情景，我想大概都了解了问题的一个整体情况。简单点说，这就是我们生活中经常碰到的“审批”处理，但是，专业点说的话，其实这就是“工作流”。
（1）公司请病假
（2）学生请假
（3）经费报销
（4）报名审核
   等等。。。。。
   我们关注到，这一系列的问题，都是具有一个起点，一个终点，但是对于其中的处理却无法估计，因为里面可以包含：（1）一级一级的审核（2）同一级有多人审核（3）可以跨级，而非一层层（4）可以回退。。。
   综上所述，对于这样的问题其实是比较难以处理的，而具体的处理当然是根据需求来的，但是有一点是一样的，就是“环环相扣，非独立”。
   其实，有一个工作流的框架叫做"Activiti"，并且我也关于这个写了篇比较详细的博文Activiti工作流框架 (https://blog.csdn.net/Cs_hnu_scw/article/details/79059965)。但是，它有个不友好的地方，它自身存在很多的数据库的表，而结构过于复杂，而且对于很多的特别需求都处理得不太友好。所以，针对这个问题，我就想着自己能不能按照它的思路去构思一个属于我们自己的工作流框架（当然优化可以慢慢做，但是效果至少要能保证我们的需求）。因此，自己就慢慢的有了下面的那些思考。

需要思考的知识点

    首先，我不一下马上说如何实现，因为我觉得，对于任何一个问题，我们首先要去思考，然后再去行动，直接立刻马上的处理，我个人认为效果会比较糟糕，所以，咱们先来思考思考下面的一些内容，而且，对于这些问题，我后面的内容都会对其进行解决。

1. 首先明白工作流的基本含义。
   其实，简单点说，工作流就是审批流程。
2. 具体的需求到底是如何。
   工作流的处理其实可以分得很多种处理类型，但是万变不离其宗，都是流程，只是其中的节点处理不一样而已。
3. 现在的知识够写吗？
   只要你有Java、数据库、Web的基础，我觉得足够了。
4. 它的难点在哪？
   难点就在于，如何让流程给于对应的处理人，审批人之间的传递如何进行控制。其实，类比我们的数据细粒度的控制。
5. 一般用在哪里?
   应用非常广泛，比如很多的OA系统都会有，而且公司内部都会有这样的系统。
6. 剩下的就是跟着我，一步步来吧！

基础表的设计

我个人认为，这个主要在于数据库的表之间的联系和设计要合理，这样对我们后续的操作会比较友好。但是，对于工作流，到底怎么设计数据库呢？别急，重点就是这个，或许，我说完了基础知识，你就自己会做出成品了。

-------------------------------------------------------------------------------------
真的，好好的理解下面的这些！！！！

-------------------------------------------------------------------------------------
不过，设计表之前，必不可少的要分析，其中的关键点有哪些，要不然你怎么设计呢？所以，别急，再插播一些内容。
我先列出主要的工作角色！！！！！

1. 审批人
   很简单，就是参与审批的人是谁。。这不难理解，当然是系统中的某些人员。比如，拥有小组组长、部门领导、公司领导类似这些角色的人员咯。对于普通用户，当然只有申请的功能，没有点小权势还想审批别人么？
2. 审批节点
   这个需要一点了解。首先，审批就是处理，那么节点就是在某个审批环节上，具有同等操作功能的一些情况定义。比如，当前审批处理是有几个审批人？审批人中有多少个人通过该审批就算通过？所以，就是对每个审批扭转过程的详细内容。
3. 审批流程
   理解了审批节点，那么审批流程就好理解了，就是很多个审批节点连接起来，不就是点点之间相连，一条线就出现了。所以，审批流程就是一条完整的审批处理。比如，请假审批，这就是一个审批流程，而里面的每一步就是审批节点，现在理解了吧？还不理解，oh，no！更直白点，你要请假，那么你就是这个审批流程的起点节点，而要经过你的小组组长同意，所以，你组长就是一个审批节点，同理部位领导又是一个审批节点，当到最大的官审批完之后，那么你的请假就完成了呀，那么审批流程也就完成了。
4. 审批项目
   系统就是一个需求的集合，那么每一个需求它需要使用哪个审批流程去处理，就根据它本身的性质来决定。比如，张三由于身体不舒服，那么它就需要进行申请一个“请假流程”的审批项目；李四由于出差，那么要跟公司报账，那么它就需要进行申请一个“财务报账”的橡皮项目。
5. 审批过程
   有审批项目了，为什么还要审批过程？？？简单点说，就是我们需要记录在一个审批项目中（因为一个审批项目对应一个审批流程，而一个审批流程中间包含很多审批节点），每一个审批节点它的处理过程，比如当前是在第一个审批节点，那么什么时候进入的第二个审批节点呢？也就是说，对审批项目的一个间断的记录。（而后面的审批详情就是对这一个间断里面的每个操作进行更为细致的记录）
6. 审批详情
   简单点说，审批过程就是对一个审批流程的具体详情的一个记录。也就是说，某一条审批流程中，每一个审批节点中的操作人员他具体的处理是“同意”还是“不同意”，这些你是不是都要记录，要不然怎么显示每个人的具体操作给别人看呀。。。
   综上所述，别急，咱们别急着往下，这个部分很重要，咱们必须理解起来，要不然真的会很迷茫，所以，建议大家看到这里的时候，多花点时间回头看看上面定义的角色，再继续往下阅读，不求快，只求稳！！！
   
   OK，真正理解了的话，咱们再往下，继续！
   下面的是我自己设计的表结构，大家可以按照这样的思路去设计都可以(关键还是根据具体节点的需求修改)。
   下面的内容，包含基本表设计，其次，是能够处理的功能。

（1） 用户表

• 定义：主要是系统的用户信息（这个系统都有的，不用多解释吧）。
• 基本设计：包括ID（主键），用户基本信息（名字，账号，密码，电子邮箱，手机啥的）；
• 基本功能：在操作界面可以
  1）增删改查，不用多说吧
• 结构如下：
  
  这个我就不多说了吧。。就是用户基本信息。（关键都在于后面）

（2） 审批人表

• 定义：主要是记录审批流程中涉及到的审批人。
• 基本设计：包括审批人ID（主键），工号（与人员表中的工号相同，外键），审批人描述，审批权限描述等其他信息；
• 基本功能：在操作界面可以
  1）增加审批人。
  2）删除审批人，但在删除的时候，需要查看是否有未结束的审批节点或审批流程涉及到此审批人，如果有，则提示不能删除。
  3）修改审批人，可以对审批人的其他信息进行修改。
• 结构如下：
  
  字段含义：由上到下（后续的同理）
  第一：审批人ID，就类似表的主键，唯一
  第二：用户ID，这个就是对应我们用户表中的ID
  第三：审批人描述，用于描述当前审批人的信息，因为能够方便后续选择审批人，你如果只给了用户名字，那么有些人不认识这人，那么怎么决定是否选择不选择这个人嘛，是不是通过这个字段就可以知道是不是符合选择的情况了。
  第四：审批人权限描述，用户描述当前审批人的权限信息，这个作用类似上面的字段
  第五：用户名，其实我知道，很多人会想，这个在用户表里面不就知道了么？而且不符合第二范式设计规则？但是这样会联表，而且这个名字字段使用也比较多，所以冗余我是觉得没问题，对于后续也方便。
  其图如下所示：
  

（3） 审批节点表

• 定义：主要是记录当前审批节点的相关信息（比如，有哪些审批人，审批通过需要多少个人通过，审批节点描述）。
• 基本设计：包括如下结构的字段信息；
• 基本功能：在操作界面可以
  对于审批节点表可以进行如下操作：
  1）在显示时，需要读取审批节点包含人员表，显示此审批节点包含人员总数。
  2）增加审批节点；
  3）删除审批节点，但在删除的时候，需要查看是否有未结束的审批流程涉及到此节点，如果有，则不能删除。
  4）修改审批节点。a）如果有未结束的审批流程涉及到此节点，则不能修改。b)如果修改审批通过最小人数，则需要确定此数字大于0而小于当前包含人员数，否则不能修改。
  5)查看审批节点。
• 结构如下：
  
  第一：审批节点ID，自增，主键
  第二：审批节点的名字
  第三：当前审批最少需要多少人通过算审批通过。
  第四：审批节点的描述，用户描述当前审批节点用于干什么
  第五：当前审批节点一共有多少个审批人。
  我们发现，这时候审批节点表与审批人其实是一种1：N的关系，所以，那么就还需要一张它们之间的对应关系表。
• 结构如下：
  
  第一：审批人员表中的节点ID，自增，主键
  第二：审批节点中的审批人ID
  第三：当前审批人在当前审批节点的审批顺序，1表示第一级，以此类推。因为这个字段主要是用于可能出现：一个审批节点中有5个人，但是它们5个人的审批顺序是不一样的，所以，要满足前者审批完成后续才可以审批。（如果需求不需要这种的操作，那么这个字段是不必须的！）
  第四：对应的审批节点D的ID，也就是表明当前审批人在哪一个审批节点中。
  综上所述，我们可以知道，在创建一个审批节点的时候，要能够添加审批人员，以及对审批人员的顺序进行控制，而且要设置当前审批节点最多有多少人，最少需要多少人审批通过才算通过等相关的信息。
  所以，对应的操作界面如图所示：
  
  （4） 审批流程表
• 定义：主要是记录当前审批流程的信息（比如，有审批流程的名字、审批流程的描述等等）。
• 基本设计：包括如下结构的字段信息；
• 基本功能：在操作界面可以
  对于审批节点表可以进行如下操作：
  １）增加审批流程；
  ２）删除审批流程，但在如果有未结束的审批过程涉及到此审批流程，则不能删除。
  ３）修改审批流程。
• 结构如下：
  
  第一：审批流程ID，自增，主键
  第二：,审批流程名字
  第三：审批流程的内容
  第四：审批类型，用于标识是由于进行请假审批、还是财务报销审批等。
  我们发现，这时候审批流程与审批节点其实是一种1：N的关系，所以，那么就还需要一张它们之间的对应关系表。
• 结构如下：
  
  第一：审批流程节点表ID，自增，主键
  第二：审批节点ID
  第三：当前审批节点顺序
  第四：当前审批节点是否能够返回上一个审批节点。因为，有些需求是当前的审批节点如果拒绝，那么整个流程都结束，还有的是当前如果没有审批通过，那么撤回，让上一级再审批，等通过之后再回到该审批节点。
  第五：对应的审批流程的ID。
  综上所述，我们可以知道，在创建一个审批流程的时候，要能够添加审批节点，以及对审批节点顺序的控制，而且要设置当前审批节点具体有哪些，哪些审批节点是可以返回等待信息。
  比如，操作界面如下图所示：
  
  这里，停一下，大家对整个流程是否理解了呢？，先理解再往后面去看!

（5） 审批列表

• 定义：记录整个系统中需要审批工作的列表信息（简单的说，就是记录了哪些内容需要进行审批处理）。
• 基本设计：包括如下结构的字段信息；
• 基本功能：在操作界面可以
  1）查看所有的需要审批的内容。
  2）进行审批操作
• 结构如下：
  
  第一：项目审批ID，自增，主键。
  第二：需要审批的项目名。
  第三：对应需要审批的项目的ID。（比如一个请假流程，那么这个就是一个项目，它包含是谁发起的，需要哪个流程ID进行审批，该项目的描述，这些就是一个审批项目）
  第四：项目是否要审批。
  第五：当前审批的节点ID。
  第六：当前审批项目是否完成。
  第七：对应的审批流程ID，就是该审批项目是由哪个审批流程进行处理。
  第八：当前审批节点的名字。
  第九：当前审批节点通过的人数，默认开始是0。
  第十：需要审批项目的类型。比如是请假流程项目、报销流程项目、放假项目等等。
  其对应的界面信息如下图：
  
  通过界面再去理解上面的结构设计，我觉得就相对更好的理解了。其实上面的字段很多就是作为外键而对应其他表的主键。

其实，上面的表相互关联就已经是工作流的实现了，是不是很简单，主要就是逻辑要理清楚，而逻辑清楚的话，那么后续的代码编写就不会是问题了。然而，我们注意要一点，就是虽然功能实现了，但是需要想对每个处理流程的一些详细内容进行记录，那怎么办呢？比如我想知道“张三请假执行到第几步了？而每个审批人员的审批状态是什么呢？每一步的审批就是怎么的一个审批详细内容呢？”所以，还需要对应的一些详细表

（6）审批项目过程描述表

• 定义：记录审批项目的审批过程的内容描述。
• 基本设计：包括如下结构的字段信息；
• 基本功能：在操作界面可以
  因为这个不是在操作的，所以没有操作界面的内容
• 结构如下：
  
  第一：项目审批过程表ID。
  第二：审批项目对应的ID（即第五张表的ID）。
  第三：审批处理的时间
  第四：审批处理的具体细节。比如，当前审批同意的人+1，或者审批节点通过，进入下一个审批节点。
  比如：
  
  （7）审批项目流程细节表
• 定义：记录审批项目的审批过程的详细处理细节内容，比如某个审批项目的审批流程中当前审批节点是什么、审批人是谁、它的审批结果是什么，等等。
• 基本设计：包括如下结构的字段信息；
• 基本功能：在操作界面可以
  就是当前审批人对需要审批的项目中进行审批处理，即判断是“通过”还是“不通过”。
• 结构如下：
  
  第一：项目审批细节表ID。
  第二：审批项目对应的ID（即第五张表的ID）。
  第三：审批人给予的审批意见
  第四：审批人对应的用户ID。
  第五：审批人对应的审批时间。
  第六：审批人对应的操作操作结果，同意还是不同意。
  第器：当前审批的节点ID。
  其对应的界面如下图：
  
  点击之后，就到下面！！！！
  
  当当前的审批人员进行审批处理之后，上面的三张表（5,6,7）就会进行相应的处理了。根据表的结构，我相信大家应该可以估计到如何的一个大体处理。

实体关系图

简单绘制一下关于它们之间的关系图吧。像其中包含的属性我就不画了，这个就是数据表中的字段信息。

理一理这个整个流程

通过上面的表的结构的分析和图的解析，大家应该有一个整个的理解了，那么下面就来说说这一个过程是怎么的！！！

详细分析：

1. 系统里面有三个用户。（我就简单点哈，别搞那么多人了）
2. 由于李四就是个小员工，那么它不能作为有审批权限的用户，所以张三和王五就是审批人员了。
3. 系统假设有三个审批节点，而张三分别在节点1和节点2，而王五就在每个审批节点都存在审批处理。
4. 系统假设有两个审批流程，而审批流程1包含审批节点1、2和3，但是审批流程2就是只有审批节点2和审批节点3。
5. 假设这就是我们系统的整个关于工作流的预定义内容，而这些内容是不是就可以由我们上面的前4张表就可以实现了呢？
   那么，我们来看，假设李四要进行请假了该怎么做。
   
6. 首先，李四想要请假，那么它就需要提交一个请假的需求（等价于一个请假项目）
7. 那么李四就要在系统的审批流程选择一个，因为他是要请假，那么自然就选择“请假流程”的这个流程了。
8. 它选择好了审批流程后，那么就提交这个请假，所以就会在系统的“审批列表”中增加一条记录。剩下的，李四就等待他的审批是否完成就可以了，因为他接下来做不了任何事情，而只有等待。
9. 因为请假流程是审批节点1和审批节点2组成，假设审批节点是首先需要审批的节点，而审批节点1中张三是审批人，所以，当张三登录系统之后，就会在“审批列表”中看到一条待审批的记录，那么他就点击“审批”就可以开始审批处理啦，剩下的就是“通过”和“不通过”的处理，这里我们假设他选择了“通过”，那么由于审批节点1就一个审批人，所以，审批节点1完成，就到下一个审批节点2.
10. 同理，审批节点2就王五是审批人， 当王五登录系统之后，就会在“审批列表”中看到一条待审批的记录，那么他就点击“审批”就可以开始审批处理啦，剩下的就是“通过”和“不通过”的处理，这里我们假设他选择了“通过”，那么由于审批节点2就一个审批人，所以，审批节点2完成，就到下一个审批节点。但是，没有审批节点了，所以，这就意味着该审批流程就走完了。
11. 当李四登录系统，哇塞，他就看到他提交的审批项目的流程都走完了，那么自然他就可以请假去干其他的事情啦。。。（而之前未审批完成时，他进系统都只能看到在审批中，审批在哪一个节点）
12. 这就是一个完整的“用户”发起“工作流项目”，然后“审批人”开始审批，那么就按照一步步的审批进行处理即可。

总结

    OK，看到这里，我觉得，大家应该对整个的工作流的设计有个大概的了解。我知道，没有直接看到代码，会有点头疼，但是，代码这有思想了，就不难实现了，而且我把数据库设计都给一步步列出来了（手码的还是很辛苦的好吧，而且也算详细了吧！！！）。在这里，建议大家先好好的理解这个整个流程，当你理解完之后，先自己试着写写看，是否能写个大概。后续，我会把这个代码一步步的手把手教大家。但是，最近我需要整理整理其他的事情，所以，可能不会马上就给出，但是我是不会忘记的哈。
    内容有点多，但是，我觉得都是干货，而且用得也多，我们需要的就是把现实生活中常见的一些实例通过代码来完成，这不就是实现一种方便么？想想，如果通过人工去跑，那么有多惨，一个领导不在，你要等大半天，时间都去哪儿了？不就浪费在等待上面了嘛！
    有更好的想法，也可以在留言区给我留言哈~像之前的那些粉丝给我的，我都一一回复了，期待你的加入。。。。
其次的话，推荐大家可以看看一个开源的框架Activiti和booto，都还不错！