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 = () => { return gapi.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（需搭載小飛機）

前無古人后無來者

待完善。。。

API

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。