AntFlow系列教程之流程提交

AntFlow为笔者基于activiti深度定制的一款简单易用的开源低代码流程引擎,类似钉钉工作流.详细介绍可以查看企业级仿钉钉低代码工作流引擎开源啦.项目刚开源不久,希望喜欢的大佬们多点赞关注.后面除了会写文章介绍AntFlow的使用,还会写文章介绍activiti 8的使用.

流程的操作抽象为一个公共接口.提交、审核同意、审核不同意（拒绝）、打回修改都是同一个接口，靠operationType来区分是哪一个操作，同时靠formCode来区分是什么类型的流程，比如是一个请假流程、出差流程或者是一个加班申请流程等。formCode字段意思是表单编号，实际上是一类流程的惟一标识，并不是具体某个流程提交的表单的编号，AntFlow中流程和表单是解耦的，流程并不关心表单数据（能决定流程走向的关键字段除外）。

重申一遍，后面称formCode直接用英文名称呼，或者称作表单编号，但是其本身含义并不是流程对应的表单的编号，而是某一类流程的惟一标识。另一个重要概念流程编号，流程编号为某个运行着的或者已完结的流程的一个编号。formCode可以看作是模板，processNumber可以看作是实例。可以结合面向对象类和实例对象的关系来理解。以demo里的第三方账号申请流程为例，它的formCode为DSFZH_WMA,它下面发起的具体的流程编号为DSFZH_WMA_1,DSFZH_WMA_2,DSFZH_WMA_3 …

请求路径

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

请求参数

字段名	字段类型	描述
formCode	String	表单编号，代表着具体的要发起的是什么样的流程，比如一个请假流程
operationType	Number	操作的类型，1代表流程的提交
remark	String	流程摘要，看似无关紧要，但是实际业务中不可或缺，后面办理人已办理的流程列表里流程会越来越多，你都办公过谁提交的流程你并不能记得特别清楚 根据实践来看，一般流程摘要定义为申请人姓名-具体业务。比如张三发起的一个请假流程，摘要可以定义为张三-请假流程。首先，根据流程类型过滤掉一批流程 然后再根据摘要过滤掉一批，再根据流程的发起时间大概就能找到具体的流程了。比如张三某年某月发起了一个一万元的加班申请费用，你审批了，但是 由于可能时间很久，你也记不清楚为什么批了这么大额度的加班费用申请流程。你首先进到我的已办流程里面，根据流程类型筛选出加班申请流程，然后 再根据张三的名字搜索出张三申请的流程，找到具体的流程以后，就可以查看当时的审批意见了。（这里也给流程办理人员提个醒，虽然流程审批很繁琐 但是权利也代表着责任。尤其是一些很重要的流程审批的时候且不要只点同意就完事了，一定要填写好备注（审批备注不是这里的remark不要搞混淆了， 这里的remark是流程的摘要信息，是为了方便过滤流程用了，是流程根据一定规则生成的）。不然后面出现争议自己记不清楚了就很难办了。流程审批意见 会在流程审批章节讲

关注remark的延伸是笔者自己的经验之谈，流程备注有个前提就是重要的流程，一些不重要的流程比如办公用品申领没必要填写审批备注。（对于一些不重要的流程，还会设计批量审批功能，审批者可以批量勾选然后一键同意).至于什么样的算重要，什么样的算不重要，一般是流程管理员设定的，审批人自己也可以根据自己的情况酌情添加流程备注，酌情使用一键审批

关于请求参数。以上内容是一些公共的必填参数。实际上并不包含表单数据。前面说过流程引擎和表单是解耦的，没有表单数据也能够正常执行，但是一般情况下没有表单的流程是没有业务意义的。审批人也不知道自己审批的是什么东西。流程表单数据是根据实际流程的业务而定的，可能着随着业务的演变而不断的演变。分离的设计有一个好处就后面如果流程上没有变更只有表单数据的变更，只需要修改表单业务相关代码即可。同样，表单业务没有变动但是审批人要增加或者减少，只需要修改流程配置即可。不需要动到表单相关的代码。表单的业务数据只需要附带到请求参数的json body里即可。流程发起时会回调org.openoa.processmgr.adp.FormOperationAdaptor#submitData 方法，FormOperationAdaptor为抽象接口，具体的流程业务实现该接口，在submitData方法里将表单数据保存到数据库即可。

FormOperationAdaptor为抽象接口，不同的流程业务都需要实现这个接口然后在相应的方法里填充数据。最终FormOperationAdaptor可能会有上百个甚至上千个实现类（都必须是Spring bean），AntFlow执行引擎会根据formCode找到一个惟一的处理对应业务的实现类，在不同的节点回调不同的方法。

如何想看流程配置

如果想知道自己发起的流程配置是什么样子的，可以根据formCode(有些用户可能会有疑问，我怎么知道某个流程的formCode是什么呢，实际上你并不需要知道，流程发起的时候你只需要填写表单数据即可，流程的formCode是发起流程的时候前端自动带过来的)，然后进到 流程配置预览页 页面,点击更多-流程配置列表,根据formCode来查看具体的流程配置

流程配置列表里同一个formCode可能会有多条配置项,其中只有一条是活跃的(即激活状态,生效状态),其它的都是不生效状态.之所以会这样是因为流程审批业务可能会发生变更,需要增加审批节点/减少审批节点,增加流程分支条件等.一旦管理员编辑了流程就会生成一条新的配置.最终的结果就是有多条配置,实际上是流程的不同版本.有些流程审批人不对往往是由于流程版本发生变化引起的.比如张三上月发起了一个请3天病假的流程,上个月只需要组长审批,现在需要部门主管审批了,小张就会问到管理员这是为什么.管理员可以根据流程配置生效时间来看线三发起不同流程所处的时间当时生效的流程是什么样子的,这样才能为用户做好解释.不然就是一笔糊涂账,导致用户对流程不信任,最终影响流程的推广使用效果

目前这块设计的还比较粗糙,把所有的流程都罗列出来了,没有过滤选项,没有生效按钮,后面会逐步加上,内测专家用户委屈一下.

点击预览就可以查看流程配置了

流程通用请求参数

流程的提交、审批都是要获取系统的登陆用户（外部系统需要传入），由于AntFlow设计不与任何用户组织相关数据做绑定耦合（可以快改造接入到企业现有的系统中，不少类似竞品都是根据自己做过的业务设计了用户和组织系统，实际上不同企业的用户和组织系统千差万别，有些概念不能完全兼容。造成数据无法同步到流程引擎对应的用户组织系统里，改造公司现有系统来适应流程引擎显然不太现实。此外，即便能够将员工和组织信息同步到流程引擎表，数据同步造成的不一致性也是噩梦，对于中小企业可能影响还不大，对于大型企业处理来说处理同步数据不一致是一件极其领人暴躁抓狂的事。天天有人来找你说员工领导信息不对、部门更改了流程发起的部门负责人还是老部门负责人等等。从最佳实践上来看，后面的Activiti7也移除了_{act_id_group}，_{act_id_membership}，_{act_id_useract_id_group}，几个用户和组织相关的表，主要原因就是上面说的，企业的员工组织信息千差万别，设定的很难满足实际需求，改造有时候是一项很大的成本开支），说了这么多，就是说AntFlow设计很具有前瞻性，放弃了用户和组织设计。由于没有和任何系统融合，流程引擎没有任何与员工和组织相关的数据，需要mock

请求的时候在请求头上带上userId字段，带表用户的Id，值必须在示例表t_user表里面（生产中可以替换为自己的员工表，AntFlow只用到了员工的Id和姓名字段，姓名主要是展示用的）

通过demo页发起流程

点击更多tab,里面有一个发起测试按钮,点击发起测试,进入到流程发起页面,填写完表单通过基本验证之后,就可以点击按钮发送流程发起测试了,f12查看请求的数据

curl请求示例

curl --location 'http://localhost:7001/bpmnConf/process/buttonsOperation?formCode=DSFZH_WMA' \
--header 'userId: 21' \
--header 'Content-Type: application/json' \
--data '{
    "formCode":"DSFZH_WMA",
	"operationType": 1,
	"remark": "中通云账号申请",
    "accountType":"1"
}'