AntFlow系列教程二之流程同意

流程的同意即审批人点了同意按钮。没有节点上审批人的同意操作，整个流程就无法进行下去。

请求接口

POST {{serverurl}}/bpmnConf/process/buttonsOperation?formCode=DSFZH_WMA

请求参数

如果说流程发起很容易看懂，可能看到这里有不少人已经开始懵了，虽然每个字都能看懂，流程理解上可能也没问题，但是这些参数从何处获取呢，相信很多人一头雾水。其实是因为到这里跳过了关键的一步，我们要审批某个流程时，首先是要进入我的待办列表，为什么会有我的待办列表呢，因为流程引擎根据流程配置的信息生成了流程实例，其中某些节点需要我来审批，既然是需要我来审批，自然是有审批任务分配给我了。没错，流程编号，流程的taskId都是从我的待办列表进入时自动带过来的，是一个自动的过程，不需要我们自己去找。当然如果还没有页面想测试一下流程的审批功能，也是有办法获取审批任务的taskId的。下面将介绍如何获取流程的当前审批任务，以及审批任务归属的审批人，通过介绍希望能加深读者对AntFlow流程和表单关联业务的理解

演示页审批功能介绍

打开演示页,切到第二个tab待审批，就可以看到我的审批任务列表了，如下图

里面有个审批按钮，点击即可进入到审批页面了，然后点同意按钮，按下F12即可看到流程同意时的请求参数了。

由于AntFlow 引擎本身不与用户和组织系统关联。演示页面也没有登陆信息，做了一个简单的审批人Id搜索框，就可以切换不同审批人查看他的待办任务了。可能有的同学会困惑

如何获取到一些审批任务的审批人呢？请在演示页上面tab上点击更多，里面有个发起测试按钮，审批流配置下拉框选择第三方账号申请选项（目前也只有这一个流程），选择完成以后不要点击提交，点击提交就发起流程了，发起后你仍然不知道流程的审批人是谁，点击里面的流程预览tab，除了发起人节点外下个节点就是第一个节点的审批人了，流程的待办任务会进到他的待办列表里，然后查询t_user表·select * from t_user where user_name=‘xxx’ 即可查出审批人的id是什么了。然后再回到待审批页面，将查询出来的Id粘贴到搜索框里即可查询指定用户的待办任务了。虽然不是很流畅，但是也不复杂。这里主要是想让用户了解流程预览功能，也是AntFlow的一个特色功能

特色功能流程预览介绍

流程预览是AntFlow的一个特色功能，很多市面上常见的流程引擎在发起时并没有预览功能，发起完成以后会有个流程图页面，或者叫作流程预览，也有叫流程预测的，实际上流程发起后审批节点和审批人是确定的，并不需要什么预测。他们的流程预览也不是真正的预览，而是流程可能执行的路径，相当于AntFlow的流程配置页。实际上是流程的母版。对于一些复杂的流程，做为普通的审批人很难一眼看出流程真正的执行路径。AntFlow的流程预览是结合表单条件来做的，即用户填写完表单以后（预览必填字段要填写，非必填字段不用填写），根据表单条件生成的，和流程发起以后的真实执行路径是一样的。

吹了半天，这个功能有什么用呢？大有用处！！！

场景1：比如你想发起一个请假流程，根据公司的规则，员工请假天数在一天只需要组长审批即可，请假天数三天以内的需要部门负责人审批，请假天数超过三天的需要老板审批。更为复杂的场景，如果发起人是高P级别，可能与普通员工不一样。比如P7员工四天以上需要老板审批，P8员工5天以上需要老板审批。。。。一系列复杂的规则。实际工作中，普通人往往是不希望自己的流程被老板审批的（有时候可以绕过规则，比如把一个请N天假的天数拆分成多个天数更短的流程，只要跟部门主管说好就行了）。但是假如你并不清楚请假具体多少天以上流程才会到老板那里（查询公司规章制度显然很费时费力，并且一些发展中的公司可能制度不断的调整，很多规则并没有马上更新到手册中），这个流程预览功能就能帮上大忙了，由于流程的分支是根据请假天数设置的，你可以在页面上请假天数一栏先填写上一个值，比如10天，然后预览流程，发现审批人里面有老板。再返回过来修改天数，不断的尝试减少，直到老板不在审批人列表里出现。其实这个功能不但方便了审批人，同时也减少了人事行政的工作量，如果不能预览员工可能会频繁的去问人事行政请假的规则，这样就不用去问了。

场景2：我的的设想是完全的，但是现实并不是完美的。有时候我们开发的流程可能会存在bug，尤其是在上线初期，如果不能发现这些bug导致上线以后出现大规模问题在大公司将是一件非常严重的事。（说服员工撤销流程重新发起会导致员工满意度下降，甚至遭到投诉，可能很多员工根本不知道你们部门，但是由于频繁的因为流程问题麻烦他他可能就会在一些公司级的部门满意度调研中给你差评，更为严重的是可能导致公司的损失）。比如一个日常加班报销流程中，在一些自动化程度高的公司，流程通过以后会直接按照流程中的金额给员工打款，这个流程往往需要财务部门的一些专门的人员来审核票据，他的上司往往是不会真正的来细看表单内容的（大公司一天日常报销流程可能成千上万个，不可能让财务主管一个个细看，但是从流程设计上他又必须做为审批人），上司的审批往往是形式上的，他审批的前提是前面的审核票据的人员已经点同意了。如果流程设计的有问题导致票据审核人员没有出现在流程中（有时候是整体上节点丢失，有时候是特定条件下节点丢失）。他的上司根据流程的设计，自然的认为票据审核人员已经审核通过了，他也就跟着点同意了。如果最终发现有些票据有问题但是钱已经打给员工了相关的负责人肯定会追责。自然财务负责人有责任，但是根源在于流程设计上出了问题，做为流程开发人员你自己逃不了干系。这时候流程预览就起到作用了，对于能够确定某个审批节点一定要出现的，并且不出现可能会引发问题的可以设计一个流程预览功能（前面说的请假流程是会有一个页面，想主动让发起人看到，这里的流程预览功能可以是没有页面的，在发起流程时先调预览接口），在发起前强制预览，如果预览里没有指定节点即终止流程发起，这时候发起人便会找到管理员，开发人员再来排查具体问题（有些问题只有指定员工才会出现，有些是大规模性的，如何确定是大规模性的还是特定人员，或者特定部门才有的，后面再介绍）。虽然阻止用户发起流程也不是很好的体验，但是比起发起以后出现更严重的问题，算是轻的了。两害相权取其轻。

可能对第二个场景有些同学会有疑问，为什么校验不做在流程发起里而，而是弄一个流程预览呢。主要是AntFlow里流程发起是通用功能，不与具体流程绑定，也不与具体业务绑定。如果根据业务条件阻止流程发起即违背了设计初衷（流程引擎和业务分离），也违背了了责任单一原则。并且这部分是易变的，后面可能技术条件进步了，票据的审批能够完全由机器完成，不再需要人了。这个时候就要去掉校验。如果这时候改核心引擎代码来去掉业务校验显然风险较大，而做在预览里面风险小很多。

curl请求示例

curl --location 'http://localhost:7001/bpmnConf/process/buttonsOperation?formCode=DSFZH_WMA' \
--header 'userid: 1' \
--header 'Content-Type: application/json' \
--data '{
	"taskId": "137540",
	"processKey": "DSFZH_WMA_30116",
    "processNumber":"DSFZH_WMA_30116",
	"formCode": "DSFZH_WMA",
    "approvalComment":"同意!!!",
	"operationType": 3
}'

在完全没有前端页面情况进行流程同意操作

此部分功能为了方便用于更深入理解AntFlow内部的工作逻辑,可以回头再看,一开始如果看起来感觉吃力建议直接通过页面操作先体验一下,然后通过f12抓取参数来跟着做

如果想要精通AntFlow,了解内部的工作原理是必不可少的过程

1.查询流程和表单关联业务表

即bpm_business_process表,AntFlow流程和表单业务完全解耦,bpm_business_process表是把他们关联起来的桥梁.其中表里的BUSINESS_NUMBER字段为流程的编号,BUSINESS_ID为表单数据表的Id

对于一些复杂的流程,表单数据可能不止存一个表,但是这些表之间肯定有内在的联系.入库的时候一定要精心设计哪个表做为主表.因为流程和表单关联只存了一个Id,严格来说也不是主表的Id,在流程里没有任何实际意义,完全是抽象的.

2.根据流程实例Id查询当前任务

bpm_business_process表里有个PROC_INST_ID_字段,即为流程实例的Id,通过流程实例Id就可以查询到当前正在运行的流程task信息,sql如下

select art.ID_ as taskId,art.ASSIGNEE_ as userId,bbp.BUSINESS_NUMBER as processNumber,bbp.PROCESSINESS_KEY as formCode
from bpm_business_process bbp
         join act_ru_task art on bbp.PROC_INST_ID_ = art.PROC_INST_ID_
where bbp.BUSINESS_NUMBER = 'DSFZH_WMA_109';

示例数据如下

其中ASSIGNEE_列的值即为当前审批人的Id

有了这些数据就可以审批一个流程了.

审批完以后再执行以上语句,流程又行进入到下一节点,然后再mock下一节点用户即可审批下一节点,直到整个流程完成