第三天了,今天小J准备了用车申请的完整流程和对应的操作界面说明文档,余下的非重点流程在下个星期整理。小G重新改进了模型。
                    
                     我们三人内部讨论了流程和模型。明天项目组和需求部门进行将开发前的第一次讨论会。
                  特别的,我们再次讨论了工作流实现思路。
                    
                     考虑该系统中最简单的申请单审批流程:
                     
 
                    
                     审批流程中有 申请人、审核人两个角色,审核工作分为部门审核、分管领导审核和主管领导审核三个任务。流转的公文只有申请单一个单据。
                    
                     假设目前系统只有流程1和2两个流程:
                    
                     1.本地网用车申请流程:
                     申请人填写申请单-生成申请单据-部门审批-审批结束,转入车辆调度流程
                    
                     2.出本地网省内用车申请流程:
                     申请人填写申请单-生成申请单据-部门审批-分管领导审批-审批结束,转入车辆调度流程那么对应这两种情况的申请单审批流程实现如下:
                    
                     1.将每个环节对应的任务生成任务表
                  
                     
                      | 任务编号 
 | 任务名称 | 
                     
                      | Task1 | 部门审批 | 
                     
                      | Task2 | 分管领导审批 | 
                  
                  2.每个流程的固定模式表 按任务顺序将对应的任务编号填入
                  
                     
                      | 流程模式编号 | 第一步 | 第二步 | 
                     
                      | Flow1 | Task1 |  | 
                     
                      | Flow2 | Task1 | Task2 | 
                  
                  
                   3.申请单一经填写完毕,即生成该单据的流程实例,经过程序判断,申请单1走流程模式1,单2走流2
                   
                  
                     
                      | 申请单编号 | 流程状态 | 流程模式编号 | 
                     
                      | Sheet1 | TFFFF | Flow1 | 
                     
                      | Sheet2 | TTFFF | Flow2 | 
                  
                  
                   流程模式标示字串由5个位组成,分别对应流程模式中的步,T表示有任务,F结束虽然现在最多只有3步,设成5位是为了保证以后的流程扩充冗余。 
                   
                  4.同时,流程记录表增加单据的处理记录
                  
                     
                      | 申请单编号 | 任务编号 | 处理结果 | 
                     
                      | Sheet1 | Task1 | 0 | 
                     
                      | Sheet2 | Task1 | 0 | 
                  
                  每个任务操作都在流程记录表中产生一个记录,代表当前任务已经执行完毕,处理结果中0代表等候处理,1代表是,-1代表否
                  5.审批角色中的部门审批权限上线后,搜索流程记录表,对应的任务编号有2条未处理记录,审批结束后,流程记录表变成
                  
                     
                      | 申请单编号 | 任务编号 | 处理结果 | 
                     
                      | Sheet1 | Task1 | 1 | 
                     
                      | Sheet2 | Task1 | 1 | 
                     
                      | Sheet2 | Task2 | 0 | 
                  
                  在处理完当前的任务更新处理结果后,还要检索流程实例中该单据的流程模式字串和对应模式,发现sheet1的第一个任务下面没有要处理的环节了,停止插入记录,而sheet2的第二个任务是T,再去对应的FLow2流程模式里发现对应的第二步是Task2 
                    于是插入一条流程记录,状态是等候处理。
                  6.分管领导上线后,显示一条等待处理的申请单Sheet2,处理后流程记录表如下
                  
                     
                      | 申请单编号 | 任务编号 | 处理结果 | 
                     
                      | Sheet1 | Task1 | 1 | 
                     
                      | Sheet2 | Task1 | 1 | 
                     
                      | Sheet2 | Task2 | 1 | 
                  
                  可见流程中已经没有需要处理的单据了
                  那么工作流如何能够灵活配置呢?
                     假设我们审批流程需要增加一个流程3,里面多了任务3-主管领导审核
                     对应的任务表
                  
                  对应的流程模式表
                  
                     
                      | 流程模式编号 | 第一步 | 第二步 | 
                     
                      | Task3 | Task1 | Task3 | 
                  
                  符合流程3的申请表3对应的流程实例记录是:
                  
                     
                      | 申请单编号 | 流程状态 | 流程模式编号 | 
                     
                      | Sheet1 | TTFFF | Flow3 | 
                  
                  该单据经过部门审批后,流程记录表中的相关记录应是:
                  
                     
                      | 申请单编号 | 任务编号 | 处理结果 | 
                     
                      | Sheet3 | Task1 | 1 | 
                     
                      | Sheet3 | Task3 | 0 | 
                  
                  这样就能保证主管领导审批的界面能够调出所需要处理的单据了。
                  以上的简单流程是顺序的,单一的,而实际的流程中存在多种返回结果和多重判断以及流程之间的跳转。我们将进一步讨论和完善流程配置的实现方式。