1. 背景

前段時間從前到后完整地做完了一個簡單的釘釘上的 ISV 應用 —— 猿活動。

最開始想做這么一個小工具，是想到，平時部門中經常會組織一些分享活動，但是這些分享活動卻沒有一個比較直觀的“站點”來記錄一次又一次的，很多人的努力的付出，這是很可惜的事。同時，在做這些活動的時候，也缺少一些互動的手段，比如現場簽到，打賞什么的。

好吧，剛開始的時候是這樣想的，當然，在做的過程中，也發現釘釘的基于“組織”的應用場景，在某些情況下限制挻大的（比如現場的交互，因為到現場的人并不一定是某個“企業”的成員），所以功能上也簡化了很多。（其實真相是只有 3 個周末時間，只能先搞出目前這些簡單功能了）

中間在做的過程中碰到了另一個朋友，他有一些想法，并且自己也盡力做了很多工作，就差個程序員。我見功能很簡單（就是最簡單的文章呈現功能），就幫他做出來了。之后，我也隨便把他的這塊內容管理功能，及我之前想的活動相關的功能，合在一起，變成了現在這個應用的樣子了。

http://ape.fgt.im?這個頁面中的 5 張圖就把這個小東西的功能說完了。

有興趣的，可以掃描上面的二維碼安裝試試看（需要企業管理員權限才能安裝應用），或者直接訪問?http://ape.fgt.im?。

技術方面，前后端是完全分離的。

后端用 Python 寫的，一套東西是 tornado 和 sqlalchemy 。代碼在：（附件）

前端是 AngularJS 那套，代碼在：TODO （前端代碼目前跟我工作上的業務代碼是一起的，對外就不方便了哈，以后有機會拆出來我再回來補吧）

其實還有另外一套東西，掃碼登錄的那個簡單后臺，也是一個單獨的前端項目（配合約定的后端服務的格式工作），代碼在：TODO （代碼目前跟我工作上的業務代碼是一起的，對外就不方便了哈，以后有機會拆出來我再回來補吧）

2. 做一個套件與做 N 個套件沒區別

先說第一點心得。這方面你應該已經理解 ISV 中的套件是如何工作的了，如果不清楚，可以先看看：

釘釘手機端應用獲取當前用戶信息流程?https://www.zouyesheng.com/dingding-userinfo.html
釘釘 ISV 接入流程?https://www.zouyesheng.com/dingding-isv.html

一般我們最開始來做一個套件時，會習慣性地把套件相關信息（?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?。
新建套件的回調地址中，需要標識套件。（用參數或寫在路徑中，我是寫在路徑中的，比如http://ape.fgt.im/dingding-isv-callback/SUITE）

成功創建套之后，再把?suite_key?等信息補到數據庫中就好了。

這一步開發出的，隨時隨手創建套件的能力，為之后我們的調試提供了巨大的方便。

整個流程的視頻演示：

（優酷沒有 HTTPS 的支持，視頻在http://v.youku.com/v_show/id_XMTY1MjI4ODMzMg==.html）

3. 使用 SSH 遠程轉發調試后端

這算是所有跟公網回調相關的場景的標準處理方式了吧，以前做微信的公眾號開發時就這樣干的。

簡單來說，像釘釘的推送這種，它需要訪問公網機器，并且之后的調試你也不方便在手機上作靜態的 DNS 設置，這在開發時是比較不方便的，直接登錄服務器寫代碼畢竟沒有自己本地機器舒服。

所以我們想到的一個辦法，就是通過代理把遠端服務器上的訪問導到本機。而這種遠端轉發的能力，是 SSH 自帶的。兩步就可以了：

在?sshd?的配置中（比如?/etc/ssh/sshd_config）添加：
```
    GatewayPorts clientspecified
```
這讓客戶端可以指定轉發端口。
然后本機啟：
```
    ssh -R 0.0.0.0:9000:localhost:8888 root@host
```
就是把到達遠端任意網卡的 9000 端口訪問都轉到本機的 8888 端口上來。這樣我們本機服務啟到 8888 上就可以正常響應釘釘服務器對公網機器的訪問了。

更多的細節可以參考：?http://www.ibm.com/developerworks/cn/linux/l-cn-sshforward/

4. 為各個環境創建利于前端調試的應用

因為是前后端代碼完全分離的結構，所以前端的調試上需要稍微單獨設計一下。前后完全分離，就是后端除了渲染一個頁面（里面會加載前端資源）之外，剩下的全是響應 json 的服務。

之前開發 PC 上的頁面是，我們的做法是本地啟一個靜態 Web 服務就好了，后端資源的地址前端隨意控制的。這樣我改前端代碼，直接在瀏覽器刷新就能看到效果，調試很方便。

但是換到做釘釘的移動端頁面時，情況有點不同，就是登錄流程及釘釘的 jsapi 部分。業務上的登錄流程需要在釘釘環境才能完成，單獨的瀏覽器環境無法登錄（當然你可以單獨做另一套登錄機制）。釘釘的 jsapi 部分在單獨的瀏覽器上更沒辦法。

所以，我們需要在釘釘上調試。這方面，最簡單直接的辦法就是讓釘釘掃二維碼來打開指定頁面（同網內部地址都可以）。不過在登錄上有個小問題，就是?corp_id,?app_id?這些參數，為了登錄流程正常完成，你可能總是需要自己把這些參數寫死加上之后，再生成二維碼讓釘釘來掃。（而為了找這些參數，可能你總是需要多次登錄管理后臺，相信我，這事一點也不有趣）

“開發體驗”對心情的影響是很重要的，也效率的影響也是極大的，我希望的環境是打開電腦寫完代碼就能看到結果，還要去找參數，還去拼地址，還去生成二維碼，還去掃碼，太麻煩。

我現在的作法是，直接創建一個為開發調試而用的套件，里面又為各個前端環境創建不同的應用（比如CDN測試環境，公司時的本機環境，家里時的本機環境）。這樣，我只需要本機啟一個靜態 Web 服務器（本機 IP 相對是固定的），改完前端代碼，在釘釘中直接打開相應的應用就可以了，其它事都不用管，世界清靜了。