50
釘釘 ISV 應用開發的一些心得
1. 背景
前段時間從前到後完整地做完了一個簡單的釘釘上的 ISV 應用 —— 猿活動。
最開始想做這麼一個小工具，是想到，平時部門中經常會組織一些分享活動，但是這些分享活動卻沒有一個比較直觀的“站點”來記錄一次又一次的，很多人的努力的付出，這是很可惜的事。同時，在做這些活動的時候，也缺少一些互動的手段，比如現場簽到，打賞什麼的。
好吧，剛開始的時候是這樣想的，當然，在做的過程中，也發現釘釘的基於“組織”的應用場景，在某些情況下限製挻大的（比如現場的交互，因為到現場的人並不一定是某個“企業”的成員），所以功能上也簡化了很多。（其實真相是隻有 3 個周末時間，隻能先搞出目前這些簡單功能了）
中間在做的過程中碰到了另一個朋友，他有一些想法，並且自己也盡力做了很多工作，就差個程序員。我見功能很簡單（就是最簡單的文章呈現功能），就幫他做出來了。之後，我也隨便把他的這塊內容管理功能，及我之前想的活動相關的功能，合在一起，變成了現在這個應用的樣子了。
https://ape.fgt.im 這個頁麵中的 5 張圖就把這個小東西的功能說完了。
有興趣的，可以掃描上麵的二維碼安裝試試看（需要企業管理員權限才能安裝應用），或者直接訪問 https://ape.fgt.im。
技術方麵，前後端是完全分離的。
後端用 Python 寫的，一套東西是 tornado 和 sqlalchemy 。代碼在：https://gitlab.alibaba-inc.com/yesheng.zys/ec
前端是 AngularJS 那套，代碼在：https://gitlab.alibaba-inc.com/rdcdata/z/tree/master/src/ec
其實還有另外一套東西，掃碼登錄的那個簡單後台，也是一個單獨的前端項目（配合約定的後端服務的格式工作），代碼在： https://gitlab.alibaba-inc.com/rdcdata/z/tree/master/src/zadmin
2. 做一個套件與做 N 個套件沒區別
先說第一點心得。這方麵你應該已經理解 ISV 中的套件是如何工作的了，如果不清楚，可以先看看：
- 釘釘手機端應用獲取當前用戶信息流程 https://www.atatech.org/articles/52162
- 釘釘 ISV 接入流程 https://www.atatech.org/articles/55208
一般我們最開始來做一個套件時，會習慣性地把套件相關信息（ suite_key, suite_secret,token 等）作為配置寫到配置文件當中。最開始我也是這樣幹的。但是在對接流程時，這樣我經常會有非常別扭的感覺。原因是，除了套件本身的信息，在 ISV 的授權流程當中，企業相關的信息，你還是得作一般化的，比較正式的持久化處理，因為會有 N 個企業用到你的套件，每個企業都有自己的一套“配置信息”。簡單來說，企業這套信息你要放到關係數據庫的表中保存。
再者釘釘的應用場景一般是基於“組織”的，也就是說你的業務數據模型中，“企業”一定是一個獨立的實體（很多業務的實體表中，都會有一個“企業”的外鍵）。
現在，“企業”已經是一個連接業務流程，跟釘釘授權流程的一個中間角色了。再細想釘釘的授權流程，企業的授權對象，是“套件”，而企業的授權狀態本身有多種，這也是一個需要在記錄的東西。到這裏，其實已經能看出來，如果在數據模型中沒有“套件”這個實體，已經會讓人不舒服了。
更進一步，套件本身還有近 10 個屬性，而且有幾個屬性還是動態的。（這跟你接一個統一的用戶係統，隻在相關表中記一個用戶 ID 完全不是一回事了）
與其在配置文件中寫死套件的幾屬性，再搞個緩存係統什麼的去維護這個套件另外幾個屬性，同時忍受數據模型中因為沒有“套件”這個實體的不完整感：
你就專門為套件建一個表，每個套件作為一條記錄來維護相關信息，是一個更直觀，更經濟，更靈活的處理方式。
而多出“套件”這個維度的代價，僅僅受限在 ISV 授權流程中，並不會蔓延到你的業務流程中去，因為你的業務流程隻關注這是哪個企業的數據，而不關心它到底是從哪個應用來的。
我用 6 張表處理 ISV 授權的流程數據：
dingding_isv_corp_relieve是企業取消授權時的一個曆史記錄。dingding_isv_corp_app_agent是app_id與agent_id的對應關係，這在獲取企業授權之後，通過服務端服務可以查詢到，並且在激活應用時需要用到相關信息，在 jsapi 簽名響應時也需要響應agent_id信息。dingding_isv_agent這個記錄企業中的agent的狀態。
把套件作為單獨是的實體在係統中處理之後，創建套件本身就是一個隨手的事了。
- 新建一條記錄，填上新建套件的
token和aes_key。 - 新建套件的回調地址中，需要標識套件。（用參數或寫在路徑中，我是寫在路徑中的，比如https://ape.fgt.im/dingding-isv-callback/SUITE）
成功創建套之後，再把 suite_key 等信息補到數據庫中就好了。
這一步開發出的，隨時隨手創建套件的能力，為之後我們的調試提供了巨大的方便。
整個流程的視頻演示：
（https://v.youku.com/v_show/id_XMTY1MjI4ODMzMg==.html）
3. 使用 SSH 遠程轉發調試後端
這算是所有跟公網回調相關的場景的標準處理方式了吧，以前做微信的公眾號開發時就這樣幹的。
簡單來說，像釘釘的推送這種，它需要訪問公網機器，並且之後的調試你也不方便在手機上作靜態的 DNS 設置，這在開發時是比較不方便的，直接登錄服務器寫代碼畢竟沒有自己本地機器舒服。
所以我們想到的一個辦法，就是通過代理把遠端服務器上的訪問導到本機。而這種遠端轉發的能力，是 SSH 自帶的。兩步就可以了：
-
在
sshd的配置中（比如/etc/ssh/sshd_config）添加：這讓客戶端可以指定轉發端口。GatewayPorts clientspecified
-
然後本機啟：
就是把到達遠端任意網卡的 9000 端口訪問都轉到本機的 8888 端口上來。這樣我們本機服務啟到 8888 上就可以正常響應釘釘服務器對公網機器的訪問了。
ssh -R 0.0.0.0:9000:localhost:8888 root@host
更多的細節可以參考： https://www.ibm.com/developerworks/cn/linux/l-cn-sshforward/
4. 為各個環境創建利於前端調試的應用
因為是前後端代碼完全分離的結構，所以前端的調試上需要稍微單獨設計一下。前後完全分離，就是後端除了渲染一個頁麵（裏麵會加載前端資源）之外，剩下的全是響應 json 的服務。
之前開發 PC 上的頁麵是，我們的做法是本地啟一個靜態 Web 服務就好了，後端資源的地址前端隨意控製的。這樣我改前端代碼，直接在瀏覽器刷新就能看到效果，調試很方便。
但是換到做釘釘的移動端頁麵時，情況有點不同，就是登錄流程及釘釘的 jsapi 部分。業務上的登錄流程需要在釘釘環境才能完成，單獨的瀏覽器環境無法登錄（當然你可以單獨做另一套登錄機製）。釘釘的 jsapi 部分在單獨的瀏覽器上更沒辦法。
所以，我們需要在釘釘上調試。這方麵，最簡單直接的辦法就是讓釘釘掃二維碼來打開指定頁麵（同網內部地址都可以）。不過在登錄上有個小問題，就是 corp_id, app_id 這些參數，為了登錄流程正常完成，你可能總是需要自己把這些參數寫死加上之後，再生成二維碼讓釘釘來掃。（而為了找這些參數，可能你總是需要多次登錄管理後台，相信我，這事一點也不有趣）
“開發體驗”對心情的影響是很重要的，也效率的影響也是極大的，我希望的環境是打開電腦寫完代碼就能看到結果，還要去找參數，還去拚地址，還去生成二維碼，還去掃碼，太麻煩。
我現在的作法是，直接創建一個為開發調試而用的套件，裏麵又為各個前端環境創建不同的應用（比如CDN測試環境，公司時的本機環境，家裏時的本機環境）。這樣，我隻需要本機啟一個靜態 Web 服務器（本機 IP 相對是固定的），改完前端代碼，在釘釘中直接打開相應的應用就可以了，其它事都不用管，世界清靜了。
最後更新：2017-06-05 11:33:50