WordZ:Word终结者,基于Google API的文档自动化 电子合同发票流水账单线上集成方案
WordZ: Word终结者， 基于Google API开发的文档自动化产品。可用于线上合同，发票，所有有关文档的业务流程。主要功能包含，创建，复制文档，填充变量，导出word，导出pdf等一系列优秀功能
工作了那么多年，我在闲暇之余经常思考这样一个问题，作为一名软件开发人员，我的工作，我的研发价值，真的只存在于产品经理所规划出的这几个业务中吗？
开始这项研究的背景是这样的，我们公司要把签合同的流程从线下搬到线上，主要涉及到word合同模板的创建，评审，标准合同模板的拷贝，以及一些客户变量的填充。另外这些合同需要有些需要评审，打印，盖章，归档，和所有公司的签合同流程一般无二。
这其中的流程就涉及到了很多关于word文档的操作，合同是word文档创建，编辑的，打印是将word文件转化为pdf，供用户预览，打印，另外还有word文档的审阅模式。背景大概就是这样了，稍微做过销售或者签过合同的都清楚这个流程。那么问题来了，我们后端使用java的一个包，在将word转化为pdf是经常报错，另外就是打印合同和对合同进行变量填充时，经常报错，不稳定。用的是一个第三方的jar包。不仅很吃内存，而且功能不太完善。其实我要的很简单，也很复杂，就是一个可以在线编辑的word系统。包含绝大部分常用word功能。
这模块的功能我负责了一年了，真的有一年多了，因为我们公司有很多合同，而且产品规划很不清楚，经常大改，期间又重构了两次。经过一年多的摸打滚爬，现在的我已经对业务逻辑，对那些代码了如指掌。虽然对业务和代码的深入了解，我深刻地意识到，这样的功能不是业务想要的。这样不稳定，不能在线编辑合同的功能，纯粹靠下载word文件，修改后，开始审阅模块再上传文件，也根本不是技术人员的追求。 我实在不相信，签合同这样一个每个公司都有的业务场景，哪些大互联网公司就没有成熟的解决方案。我实在不想，我们不可能是第一个遇到这样的难题。于是我在几个月前，我实在想改变一下合同模块的现状，我在这个模块付出了那么多的努力，解决了那么多的难题，我不想给自己的职业生涯留下遗憾，不想在我本该更努力去寻找答案的时候，放弃去尝试，探索。于是开始独自寻找解决之道。这一开始就停不下来啦。
在一段搜索，尝试各种产品后我找到了三款比较符合我预期的产品，
- Google Docs API
- 腾讯文档
- 石墨文档
这三款产品都可以在线编辑文本，导出word，pdf，打印，以下是三款产品的 编辑器页面。大同小异。都包含协同办公的功能，而且也都有存在版本的概念。也有批注，评论。
腾讯文档：
腾讯这个产品吧，让我怎么说那，也有对外的接口文档，如官网介绍 https://docs.qq.com/doc/DUUxNYWFLeVF0TmRw
但是吧，当你去申请使用的时候，发现只能提交一些信息，等待官方回复你，我大概是7,8月份提交的。目前依然没有接到任何消息，可能是我手机号填错了吧。
石墨文档
说完了腾讯文档，再说这个石墨文档，打着协同办公的旗号，API都没有公布，想要使用，直接就要联系销售人员，也不知道有人多人用，根本不知道水有多深，反正我一般连文档都没有公布，就直接放弃了。
Google 文档
最后再说Google Docs，是因为国内他的名声真不大，csdn上只有寥寥几篇文章介绍它的使用方法，并没有介绍它的API，他的集成，他的真正强大，并且要了解他必须要坐上小飞机，去海外冲浪。真正了解它之后，你会发现，腾讯，石墨真是小家子器。首先Google Docs的文档所有文档对外，相比腾讯文档，文档详细到令人发指，可惜都是英文的。哈哈哈。。。这已经将一部分人阻挡到外部了。另外。Google Docs 的所有文档都是存储在云硬盘里，Google这个大佬，为每个用户分配了15G的免费存储空间。你也可以申请更多。此外，Google要打造的是一个协同办公的生态，Docs只是其中的一个小产品，管理，相互间调用的工具叫做AppScript。 此脚本可了不得，不仅可以将excel的数据渲染到Docs里，还可以直接使用BigQuery将数据渲染到PPT上。真是一个大平台，大生态。通过API授权的方式，使AppScript能够拿到用户所有的数据，从而创造了一个大融合，大发展，大统一的局面。这很可能是后续国内BAT后面要效仿的。不信的话 我们可以等着瞧。。。。。
扯的有点多了，在搭乘小飞机充分看了GoogleDocs的官网介绍后，和体验了他们的Demo后，我决定还是用GoogleDocs来作为第一个尝试对象。果然它也没让我失望，虽然中间很曲折，让我几度想放弃，骂娘。但最后还是完成了0.1版本的产品雏形。下面我就为一一讲解我探索Google Docs的血泪历程。
山重水复疑无路的开始
我之前对谷歌API只有一些很片面的了解，但从来没有使用过，也不知道其中的复杂。 要快速学习一个东西最好的地方是官网，Google Docs API 官网 这一个观点应该是所有技术人员的共识，但却有很多技术人员学习一个新工具的使用，总是去一些第三方，或者从乱七八糟的论坛开始。这是非常不对的。只是在学习的开始阶段是不对的。但如果遇到问题了，去这些网站去寻找答案，这无可厚非。 下面就是Google Docs API的官网截图
做的很好，有详细的文档，有快速开始的可操作Demo，也有笑容可掬的美女为你介绍该API的使用。做的可说是用心良苦。对开发者非常友好。
在简单看了官网的介绍和快速开始的Demo后，我决定立马去尝试一下，首先是创建一个文档。API支持多种编程语言调用，如官网所写支持这些
浏览器，Go ，Java ， .Net，Node.js， PHP ， Python， Ruby 在此背景下，我首选了Python版本去尝试Demo的运行，这在后来证明是错误的，不仅仅增加了自己的开发难度，而且差点让自己的新鲜想法死于摇篮。在运行了PythonDemo时总是报一个错误，链接服务器错误。后来我实在没办法了，就写了篇博客记录下来，希望以后自己能记起并且彻底解决他。也是大功一件。我相信我会解决它的，只是时间问题。在多次尝试无果之后，我又去尝试了Node.js 的Demo，然后这次还是让我很失望。依然是链接服务错误。我尝试了很多方法，修改参数，demo启动的端口，去https://stackoverflow.com/查找原因，去他们github下提Issues，就差给他们写demon的开发人员写邮件了，当然最后不得已我依然给他们写邮件，请教。为了解决我的问题，我会尽我最大的努力，去尝试一切可以尝试的办法，尽管这些办法收效甚微，或根本不会被人看到，但人总是要慢慢摸索正确的道路，而不是遇到问题，就停止不前，放弃。在尝试了三四个晚上后，我决定放弃， 放弃从Python和Node.js 的demo开始，因为相比Python和Node.js 我最擅长的在浏览器端使用JS 直接调用API，所以在一阵曲折的探索后，我确定了以Browser为基栈的产品开发，即在浏览器端直接使用JavaSript调用Google Docs API的开发方式，下图即使我运行官方Browser Demo的结果，输出结果非常完美，当然这是在搭乘小飞机的情况下。
手可摘星辰的技术方案
确定开发方式后，我简单尝试了一个官方的QuickStart demo 果然可以顺畅无比地运行，我内心稍有雀跃。既然这个开发方式没有问题，那就开始制定更为详细完善，能够集成到现有系统中的技术方案吧。
业务背景我已经说过了，以及系统现状也介绍过了。下面按照自己的思路设计一个技术方案，或者叫可执行解决方案
- 创建一个含有变量的文档A
- 复制一份文档A为B
- 更新文档B，填充变量
- 下载Word版的文档B 下载pdf版的文档B 命名可以自定义
- 打印，在线编辑（完成以上后再探讨）
- 在线评审，导出带有评审的文档，可以对文档进行，修改，删除，替换一些字段，表格内容，图片
以上的方案是在理想状态下啊，能否完成取决于API的支持。方案既定，下一步就是笔直地往前走。
步步维艰，步步为营，学富五车
在确定了技术栈和实现方案后，就开始写代码了，
OAuth2.0
首先，Google API 都是通过OAuth2.0授权的方式来调用的，关于OAuth2.0 大家可以查看一下官方资料，
这里是阮一峰的博客，大家可以用来参考
官方关于OAuth2.0在谷歌API中的使用
我翻译的中文文档
在清楚了OAuth2.0后，我就知道了为什么调用一些接口报没有权限。据说可以使用postman 调试谷歌API，但我试了几次都没成功。通过OAuth2.0 我们获取一个临时调用接口的accessToken，这个accessToken会一直跟随着API的调用，由官方库自动设置到http的headers上。我们不用管理
项目，凭据，API的开启
我们要使用Google API 首先要创建一个项目。所有的凭据，API 调用，配额，都是在项目之下
进入谷歌云控制台 点击有左上角的项目名称，在弹窗上点击新建项目，然后创建凭据。任何API的调用都需要凭据，凭据包括Client ID和 API key 还要一些其他配置项，这就像是一个密匙，是你调用API前的配置参数。
创建凭据在这里
创建完凭据后，需要此项目开启一些API，有些API是收费的，有些是免费的。
这里便是Google的API库，你可以随意挑选，
google-api-javascript-client
使用js调用接口，必须要了解一些这个库，这个是谷歌的一个开源库 地址
库里介绍了如何初始化OAuth2.0，如果配置一些变量，发起请求的两种方法，Load the API discovery document, then assemble the request. 与 Use gapi.client.request
发起请求的一些参数配置
文档链接
到这里 该了解的都已经了解了，再查阅一下文档库就可以开始真正动手写代码了。
Google Docs API
API 一共有三个 真是少的让人发指啊增删改查就只有三个， 删除不贵Docs管，归Driver管
create ：创建
get：获取详情
batchUpdate：更新
以上这些东西，我都是经过几个星期，很多个晚上，不管模块，不断试错，总结出来来的。现在写的那么轻而易举，当初真的是让我头疼。国内的资料真的少之又少。我的英文也不是很好。一半靠想象，一半靠翻译插件。算是把文档，逐渐琢磨透了。理清了思路就豁然开朗。在这个过程中，为了让我收集到的资料别人也能看得到，我就把一部分文档 复制到了我的博客里面。有中文的有英文的， 都在这个分类Google API下，大家可以随时查看。
Google Drive API
了解了Docs API ，还要去了解Google Drive API，这个API是去管理操作个人云盘上的所有文件，上传，下载，复制，修改。删除等等一系列文档操作。。。。。。
目前这个API有三个版本，最新的是V3，其次是V2
以上是我在研发WordZ是所学的大部分技术，我从没想过，做一个简单的demo需要那么多的知识，需要铺那么多的垫。如果早知道是这样，我会不会放弃？答案是不会，因为我喜欢挑战，我喜欢创新，不喜欢固步自封，闭门造车。我查看了下活动日志，从我真正开始开发，探索，到研发成果，一共用了一个月时间。整整一个月，这一个月的每天晚上，每个周末我都在想着这玩意
到底要怎么做，到底哪里出了错？最终功夫不负有心人，我终于成功地做出了一个像样的Demo级产品
为伊消得人憔悴
前文我已经说了，我在探索的过程中遇到了很多的困难和挫折，这些困难折磨这我的日日夜夜，让我难以入睡。每有闲暇时间就去想问题该怎么解决。下面我就找几个比较典型的问题来和大家分享一下
典型问题1：Google JS API 授权 失败
在调用API时，为了格式整齐，漂亮，将一部分授权代码这样写了
// 初始化OAuth2.0授权const authenticate = () => {returngapi.auth2.getAuthInstance().signIn({scope: "https://www.googleapis.com/auth/documents https://www.googleapis.com/auth/drive https://www.googleapis.com/auth/drive.file"}).then(res => {console.log(res)printLog(`签名初始化正确结果:${res}`, 'success')printLog(`Sign-in successful`, 'success')},err => {printLog(`签名初始化错误结果:${err}`, 'error')printLog(`Error signing in`)})}不知道有没有小伙伴能看出来问题所在， 这个方法也是能执行，但是无法返回一个promise，从而进行后续操作。导致授权失败
代码无法正常运行,虽然不报错。让我头疼了一会 头疼指为2，我仔细对比了demo的代码。demo代码如下
发现除了格式和换行，真的没有没有什么区别了啊。经过仔细的调试，和不断地尝试性修改，我知道了问题所在，问题就出在了换行，为了漂亮，整齐我将第一行，return 后面的语句，换了一行，这样就导致js代码执行顺序错误，此函数没有返回一个promise。将return 后的换行去掉，立马正常了。算是自己犯了一个完美主义的错误吧
典型问题2：python，Node.js 的quickStart无法正常运行
待完善。。。
典型问题3：使用V3 Drive API文件无法导出
待完善。。。
典型问题4：无法创建带有内容的文档
待完善。。。
典型问题5：无法一次填充多个变量
待完善。。。
漫卷诗书喜欲狂，我辈岂是蓬蒿人
待完善。。。
测试用例页面及日志
带有变量的基础模板，待复制
已复制出来的并填充了变量的文档
导出的word文档
导出的pdf文档
线上体验地址: mczaiyun.top/wordz（需搭载小飞机）
前无古人后无来者
待完善。。。
WordZ:Word终结者,基于Google API的文档自动化 电子合同发票流水账单线上集成方案相关推荐
- 利用python制作点读翻译软件（基于google api）
利用python制作点读翻译软件(基于google api) 摘要:实现点读功能,自动朗读翻译整段. 完整代码git地址:https://github.com/luoq ...
- 基于出库单申请电子面单的API接口文档
通过点三电商OMS系统的API开放接口,网销出库单获取电子面单更加便捷,接口文档如下: 电商API文档---点击查看!http://ds.xnxxxk.cn/apijk?source=CSDN& ...
- Swagger:搭建Swagger API接口文档
文章目录 Swagger 1.1导语: 1.2 Swagger是什么?它能干什么? 1.3Swagger简介 1.4 Swaggerr特点: SpringBoot 集成Swagger 1. 导包 2. ...
- 芋道 Spring Boot API 接口文档 Swagger 入门
点击上方"芋道源码",选择"设为星标" 做积极的人,而不是积极废人! 源码精品专栏 原创 | Java 2020 超神之路,很肝~ 中文详细注释的开源项目 RP ...
- Node.js API参考文档（目录）
Node.js v11.5.0 API参考文档 Node.js®是基于Chrome的V8 JavaScript引擎构建的JavaScript运行时. 关于文档 用法和示例 断言测试 稳定性:2 - 稳 ...
- Java API帮助文档怎么查找？
[1]打开官方帮助文档(英文):Java SE API 和文档 这里选择官方网站 打开之后,是这样婶儿的 [2]选择合适的版本:这里选择Java 8 [3]打开Java API 主页面 如何查找自己想 ...
- echarts4离线使用文档_适合写API接口文档的管理工具有哪些？
现在越来越流行前后端分离开发,使用ajax交互.所以api接口文档就变的十分有意义了,目前市场有哪些比较优秀的接口文档管理工具呢? 1.MinDoc 网址:https://www.iminho.me/ ...
- RESTful API接口文档规范小坑
希望给你3-5分钟的碎片化学习,可能是坐地铁.等公交,积少成多,水滴石穿,谢谢关注. 前后端分离的开发模式,假如使用的是基于RESTful API的七层通讯协议,在联调的时候,如何避免配合过程中出现问 ...
- 用Swashbuckle给ASP.NET Core的项目自动生成Swagger的API帮助文档
Swagger是一个描述RESTful的Web API的规范和框架.如果使用ASP.NET的话,可以用Swashbuckle来自动生成Swagger,具体参考如何使 WebAPI 自动生成漂亮又实用在 ...
最新文章
- 独家 | 10分钟带你上手TensorFlow实践（附代码）
- python django开发问题
- 带你开发类似 Pokemon Go 的 AR 游戏
- 欧几里得空间——正交矩阵
- 检索数据_11_限制返回的行数
- python注册登录系统_Python实现简单用户注册信息管理系统
- 视频回顾丨带你逛腾讯全球数字生态大会「腾讯技术工程」展区
- 【HTML/CSS】HTML元素种类的划分
- docker rabbitmq_RabbitMQ的介绍及使用进阶（Docker+.Net Core）
- mac下多个php版本切换(可操作版)
- python 菜鸟-Python 运算符
- libsvm python Linux Ubuntu下编程操作实践
- Unity3D学习1--Unity基础
- 解决MAPGIS导出数据乱码
- 万能地图下载器下载谷歌卫星地图在ArcGIS中套合
- 《软件工程（C编码实践篇）》学习总结
- import clip时Cannot re-initialize CUDA in forked subprocess
- 基于ArcGIS与高分影像进行绿地变化分析
- 一、线性回归面试题总结
- protoc did not exit cleanly. Review output for more information报错