如何利用飞书文档OpenAPI实现自动计算知识分享参会人员团队占比?

一、背景

本case是总结了日常工作流中提炼出的一个小优化,让系统帮助提效,case虽简单,但提效显著。

二、需求分析

为了深入了解每个团队知识分享的参与度,更好地运营团队知识,服务团队成员,需要统计每场知识分享参会人员的团队占比,比如属于ToB/Toc交互平台的人员占比多少?计算过程如下:

从流程图中可以看到,第1步导出参会人统计后,2~4步均属于处理数据,平均估时15min左右,属于无效工作。

秉承着“数据多跑路,释放无效人力”的原则,我们在想能不能把后面的步骤都自动化,一键生成,由流程出发,分析目前存在的痛点有:步骤2~4步,可否全部实现自动化(自动创建页签,自动更新数据,不需人工调整),借助强大的计算机算力实现“秒出”?

针对痛点,从程序员的角度出发是完全可以实现的,只需要梳理统计规则,实现自动统计即可:

针对痛点,主要涉及到是否可以借助飞书自动化的能力,在数据存储上直接存储为飞书sheet格式,并自动计算后更新飞书其他sheet页。效果如下:

总体来看,能否解决以上痛点主要依赖飞书云文档相关开放能力,于是我开始调研实现细节。

三、方案调研

飞书目前提供出来的开放能力可以在飞书开放平台官网查看,进入开发文档页面,作为后端需求直接查看服务端文档类目;

从开发文档的目录结构可以看出,文档主要是根据不同的使用场景来进行目录组织的,而我们的需求

很明显需要的是云文档的能力,Nice!飞书提供了http的API接口,让开发者可以更方便地在后端集成。

 

根据以上的调研,可初步认定此需求可实现,但由于需求的完成度与细节密切相关,则进一步调研其细节能力,避免出现一个关键的小细节需求影响了整个需求的实现。

注:在API调研阶段,需认真调研其能力,并非所有的用户界面操作(日常在飞书doc上的操作)均有

API,大家需谨慎调研(例如电子表格提供公式操作,但多维表格暂不提供等)。

为了提升调研效率,本着云文档的操作和日常的本地文档操作基本一致,在此假设上,可按照文档操

作经验初步设计导出流程需要的操作,然后一对一调研,是否有完美命中的api或者替代api。初步设想的方案如下:

可以看到:优化后的工作流的实现主要依赖的能力(API)有:

  • 获取表格元数据
  • 创建云表格
  • 批量填充数据

而后经过认真查看需要的api能力,完全满足要求,Nice!

四、开发流程

1. 新建应用

在调试接口之前,我们需要在飞书开发者后台新建一个企业自建应用。

 创建应用主要是为了拿到应用凭证,类似账号和密码,我理解的是使用开放平台,需要账号和密码,才能访问。

2. 申请权限

选择想要调用的api进行权限申请。为什么要申请权限?不同的操作需要不同权限,有些权限是敏感信息,根据权限最小原则,尽量不要申请敏感权限

3. API调试,并借助API能力进行实际的后端开发

飞书的开发文档给出了api-http的请求结构,可先行采用http走一遍全流程,但是并不需要自己去写详细的http,开放平台提供了调试工具Postman的模板库(含有所有的环境变量配置以及请求结构),导入即可,不需自己一个个去写,改改参数就行。

大家在后端完整接入之前,可以采用postman串一遍流程。

在开发过程中,不能避免会和访问凭证打交道,而不同的请求类型具有不同的凭证需求(告知飞书服务器“谁在调这个接口”),大家一般采用tenant_access_.token可满足要求。

获取token可参考👉API访问凭证概述 - 服务端文档 - 开发文档 - 飞书开放平台 (feishu.cn)

postman调用可参考👉Postman模版使用说明 - 工具与资源 - 开发文档 - 飞书开放平台 (feishu.cn)

4.进入后端开发

在调研清楚并能够采用api接口完成整个流程后,则开始coding:

Tips:以下给出的操作对飞书api的请求&回包过程进行了封装,在调研后可自行封装(仅做部分展示)

# 新建参会人统计 sheet页
spreadsheetToken = 'shtcndRY4Cu2QjfV41ychuBcBPg'
sheetId = sheets_batch_update(tat, title, spreadsheetToken)

file_path = '{}\{}'.format(path,i)
infile = load_workbook(file_path)
sheet = infile.worksheets[0]
 c = 1
# 对行进行遍历
for row in sheet.rows:
    for cell in row:
        List.append(values_list,cell.value)
    post_rows_data(values_list,sheetId[0],c,tat,spreadsheetToken)
    values_list=[]
    c = c + 1
# 总清单更新
post_data(date, name, tat, sheet)

五、更多相关开发心得

1.可能有开发者会问,调用飞书的API,为什么需要创建一个应用呢?

首先这是飞书的应用开发流程要求的。我个人理解,这主要还是和权限&安全相关,如果开发API给任何人用,任何人都可以操作其他人的数据,这不就乱套了嘛。创建一个应用,收敛权限为:只有管理员和协作者有操作权限,若不申请相关权限,是不能获取企业内他人信息的。

2.那么应用如何解决个人的权限隔离问题?

就调用API来自动创建文档需求而言,创建的文档在应用本身自己的空间中(后续若让其他人有操作权限,需通过api添加权限或转移所有权)。或者讲:自己的空间自己操作。

3.如何理解开发者调用api的行为与应用之间的关系?

应用本身有自己的空间,一种好的类比理解是:新建应用(注册一个飞书账号)-一通过API操作应用(在账号内部自己正常做自己的事情,区别只在于一个通过API,一个自己去点界面而已)。则其产出的文档肯定在自己的空间中,就好比在飞书自己的空间中创建的文档,如果没有授权,其他人是没有访问权限的。

4.企业自建应用和商店应用应该建哪一个?该需求创建商店应用可以不可以?

本需求只在小组内使用,则建立企业自建应用。可以但无必要,商店应用的创建、审核、发布、权限审核等流程比较麻烦,增加开发审核负担,不是通用能力,分享无必要。

5.关于token刷新问题:如果采用Postman进行调试,一明显的感知是token会自动过期,需要一直刷新,在这一点上,后端api获取的操作对象会自动进行刷新,比较方便。

六、收益评估

整体来看,本需求的成功实施,减少了无效人力的浪费(15min/次),因为属于长期效益,随时间的推进,团队收益越大。

开发的工作量上,本次需求研发整体花费5天(包含1天调研+设计方案1天+开发调试3天),相对于需求收益来说,可基本持平。而且在调研阶段充分认识了飞书开放后台的此种能力以及其他(包含机器人)的能力,在后续的工作中,该种能力得到复用,整体收益还是比较大的。

  • 0
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值