在上文我们已经有了发起改变的觉悟和具体的改造方案了,这次我们就开始决定撸起袖子加油干了。
开干之前,需要确定一个TODO List:
- 首先在钉钉开放平台成为一个开发者
- 创建一个应用
- 快速浏览一下API文档
- 开始编码
STEP 1. 成为钉钉开发者
首先从钉钉的官网,进入到开放平台。
在开放平台,登录到开发者后台。
登录到开发者后台后,需要把自己的账户绑定到一个组织。大家可以先在钉钉上创建一个虚拟的组织用来上手体验。
STEP 2. 创建一个应用
在我们的例子里面,我们需要创建的是“企业内部开发”
创建的时候选择“小程序”并填写好应用名称,应用描述,以及勾选开发方式为“企业自主开发”。
完成创建后,我们就能在应用列表当中看到我们刚刚创建的应用了。包括应用的APPKEY和APPSECERT等。
到这里应用创建完成,记住应用的一些相关参数,我们在之后将会用到。
STEP 3. 快速浏览一下API文档
作为第一次开发钉钉的应用,虽然不是所有的接口我们都会用到,但是快速浏览一次文档对于我们对钉钉的API接口内容会有一个大概的认识。以及整理出我们本次将会用到的一些接口。
快速浏览完文字后,我们可以了解整体的开发过程我们将会经过下面的过程。
接口名称 |
路径 |
备注 |
|
获取access_token |
服务端API->获取access_token |
获取access_token用于其他接口使用。 |
|
获取审批实例ID列表 |
服务端API->智能工作流->官方工作流->获取审批实例ID列表 |
获得审批列表 |
|
获取审批实例详情 |
服务端API->智能工作流->官方工作流->获取审批实例详情 |
获取审批详情 |
|
下载流程附件 |
https://oapi.dingtalk.com/topapi/processinstance/file/url/get |
服务端API->智能工作流->官方工作流->下载流程附件 |
获取流程附件 |
撤销申请 |
服务端API->智能工作流->官方工作流->撤销审批实例 |
判断 |
STEP 4. 开始编码
在收集好需要使用的接口后,我们就准备开始进行我们正式的编码了。我们所期望的整体流程如下。
在整个过程当中,我们一共会经理9个步骤。(由于之前考虑欠佳我们目前使用的还是用定时任务来定期执行。现在想起来我们应该用函数计算来做到间隙更小)
- 发起请求获取access_token并且存储:
服务器发起一个请求去获取access_token.这里需要用到之前我们创建的应用的app_key与app_sercet。如果获取成功,则能够获取到一个access_token,以及过期时间。
【在实际应用中我们可以把获取到的数据进行存储,每次请求之前判断一下access_token是否过期,如果过期则重新获取并更新一下,如果没有过期,则直接使用。】
- 向DingTalk Server发起请求,获取流程ID列表:
如果需要获得所有的流程详情,需要首先获得该流程的ID列表后,再通过process_instance_id去更新该流程的相信信息。
在官方接口当中,调用“获取审批实例ID列表”需要传入一个process_code。 这个process_code 的获取方式可以在编辑某个流程时看得到,如下图:
最后获取到的数据如下,
可能获取到的数据并不是我们想要看到的。我们通常在审批表单当中看到的最多的是一串年月日加占位的编号。
此刻,我们就需要调用我们下一个接口。
- 根据process_instance_id获取审批实例
在这里我们可以直接通过之前获取到的列表,循环调用获取审批实例详情接口。但是这里需要值得注意的是,该接口返回的数据特别多。主要分成以下几个大块:
- 流程主体详情,如流程编号,流程标题,创建时间,完成时间等。
- 流程任务记录,返回流程历史审批情况。(注:如果一个流程包含5个审批节点,目前正在第2个节点,接口并不会返回所有的节点数据。因为不同的流程可能会被加签或者转交,流程的审批节点并不是一直固定的)
c.流程操作记录,该数据是直接记录整支流程的具体步进或者步退的内容。
这里为了便于记忆,我们可以带入概念 oa_process(流程主体),oa_process_task(流程任务),oa_process_op_rec (流程操作记录).
4. 根据流程详情获取附件
如果流程涉及到附件,我们使用该接口把附件进行获取。并根据格式做成一个表来进行存放。
回顾一下,截止此刻。当我们的程序进行运行后,我们可以获取到所需要process_code的所有数据了。按照之前的规划,我们只需要进行一些逻辑判断即可。
我们可以尝试把所需要的流程的第一个审批人设置为一个特定的审批人(Scott)。我们的程序在每次运行的时候进行判定,当审批人出现特定人(Scott)的时候,我们直接开始调用我们的审批判断接口,并通过返回False 或者 True来决定该流程是否需要通过或者结束。
最终的效果图如下:
写在最后,当我们的第一个流程上线之后,因为机器验证直接解决了我们的三个问题。流程最终流转的效率比以往增加了很多。
当这个应用部署完成后,我们又发现了一些其他可以改进的地方,下一个章节,我们来看我们如何让机器人自动去伺候各个申请人与审批人主子。
在开发的时候,小伙伴一定需要注意以下事项:
白名单:钉钉应用在进行访问的时候有白名单限制,需要在开发者后台进行设定。
应用权限:根据不同的需求,不同的应用需要调用通信录或者其他权限,这部分也应该在开发者后台设定。
拉取时间限制:在拉取审批列表的时候,建议使用创建时间区间进行。区间范围看运行频率来设定,一般不超过10天。(主要取决流程整体的完成时间)