我是3y，一年CRUD經驗用十年的markdown程式員???????常年被譽為職業八股文選手

在前陣子我就已經接入了釘釘的群機器人和作業訊息推送，一直沒寫文章同步到給大家，

像這種接入渠道的作業，雖然我沒接入過，但可預見性地就是看看官方檔案，然后對著檔案一頓學習，復制下接入的代碼，然后除錯，最后就完事了，老實說，有點枯燥，

基于原有的架構上，感覺沒啥技術性可言，對于新增發送渠道這種需求也不會有代碼的創新，所以，我一直不太積極干這事，但是，沒人愿意干啊，

為了系統的完整性，我還是花時間去接入了，比如渠道可發送不同的訊息型別（圖片/markown/音頻等等），基于不同的訊息型別可能我們要有素材管理相關的功能，

目前這種多型別的發送渠道，由于我前端用的是低代碼平臺，在前端組裝引數的時候不太靈活，但都一一克服了

所以，一個比較完整的訊息推送平臺要干、要解決的事情還是蠻多的，不要小看它，

可以到Git倉庫看看源代碼，配合文章食用更加喲：

訊息推送平臺??推送下發【郵件】【短信】【微信服務號】【微信小程式】【企業微信】【釘釘】等訊息型別，

https://gitee.com/zhongfucheng/austin
https://github.com/ZhongFuCheng3y/austin

01、群機器人

1、閱讀官方檔案：https://open.dingtalk.com/document/group/custom-robot-access

2、創建智能群助手，得到Webhook地址和加密的值

3、HTTP呼叫嘗試是否發送成功

02、釘釘作業訊息

1、在官網檔案了解基礎概念：https://open.dingtalk.com/document/org/basic-concepts

2、進入企業管理后臺： https://open-dev.dingtalk.com/fe/app#/corp/app ，隨后創建應用

3、查看訊息通知發送的檔案：https://open.dingtalk.com/document/orgapp-server/asynchronous-sending-of-enterprise-session-messages

4、直接引入釘釘的SDK開發（主要是方便后續其他的操作，SDK會比HTTP方便不少）

5、對于拼裝引數呼叫作業訊息介面，沒什么好值得說的，大家把代碼拉下來就看得一清二楚了，

6、從檔案發現呼叫介面需要access_token這個引數，還發現這個引數是會過期的（2個小時）

有了這個access_token引數之后，我們就需要考慮怎么去“維護”它，畢竟它會過期的，不能當做一個靜態引數寫死在代碼或者組態檔上，

我當時是發這個問題到小群里，看看大伙們都是怎么“維護”的，畢竟，我們不可能每次在呼叫介面的時候都去遠程拿到最新的（一般外部的API都會有限制呼叫頻率的，沒過期的前提下也沒必要去呼叫外界的介面取）

分析后，依我看來，就兩種思路：

定時任務重繪，每隔一段時間去獲取最新的access_token，將最新的token開放介面給有需要的人使用，
呼叫介面的時候拿到上一次的access_token，如果發現access_token失效了再重新獲取并重試介面，

我一想，肯定是定時任務重繪比較合適啊，反正我已經接入了xxl-job了，新增一個定時任務不就完事了？

不過也有小伙伴說他們是第二種思路，如果發現access_token失效了，再重新獲取并重試介面，我讓他們來聊下為什么要這么干的時候，他們也說不出個所以然，（懂的老哥可以在評論區交流交流）

03、支持撤回和多種型別訊息

在這個程序中，有的同學會給我留言，會問我是不是訊息型別設計得有問題，只支持文本型別的：

其實并不是，在之前的文章提到了，接入渠道其實是個很枯燥的程序，很苦逼的程序，既然都被說到了，沒辦法，卷了幾天把釘釘渠道的群機器人和作業訊息官方所支持的所有訊息型別都給寫了，

又因為作業訊息可能會發圖片/語音/檔案這種訊息型別，而這些的訊息型別需要把素材先發到釘釘，才能進行訊息下發，所以我這邊也已經寫了素材上傳的模塊

在后端實作上，這塊代碼量并不大，因為整個架構都基本寫好了，只要適配下引數呼叫介面下發就完事了，花了一周左右時間都在前端上了（：

前端要做聯動，要根據不同的渠道不同的訊息型別提交不同的引數格式到Java介面，真的寫死我了，不過，逐漸把訊息推送平臺的功能完善，看到stars也在不斷的提升，感徑訓是不錯的，

代碼寫得比較多的其實是在釘釘應用作業訊息撤回這個功能上，在最開始設計接入層代碼的時候，我用的是責任鏈設計模式，那時候我已經預留了可能會有某些請求走不同的責任鏈，所以會有code這個引數

/**
 * 發送/撤回介面的引數
 * @author 3y
 */
@Data
@Accessors(chain = true)
@AllArgsConstructor
@NoArgsConstructor
@Builder
public class SendRequest {
?
    /**
     * 執行業務型別
     * send:發送訊息
     * recall:撤回訊息
     */
    private String code;
?
    /**
     * 訊息模板Id
     * 【必填】
     */
    private Long messageTemplateId;
?
?
    /**
     * 訊息相關的引數
     * 當業務型別為"send"，必傳
     */
    private MessageParam messageParam;
    
}

而對于訊息撤回而言其實就是復用了責任鏈的其中兩個節點，沒有普通訊息下發時的引數校驗邏輯；后續其他渠道的訊息撤回如果變化不大，則在這些節點上擴展，如果變化比較大，可能就要單獨新增對應的責任鏈節點做統一的處理比較合適了，

    /**
     * pipeline流程控制器
     * 后續擴展則加BusinessCode和ProcessTemplate
     * @return
     */
    @Bean
    public ProcessController processController() {
        ProcessController processController = new ProcessController();
        Map<String, ProcessTemplate> templateConfig = new HashMap<>(4);
        templateConfig.put(BusinessCode.COMMON_SEND.getCode(), commonSendTemplate());
        templateConfig.put(BusinessCode.RECALL.getCode(), recallMessageTemplate());
        processController.setTemplateConfig(templateConfig);
        return processController;
    }

玩轉釘釘訊息推送！

01、群機器人

02、釘釘作業訊息

03、支持撤回和多種型別訊息

推薦專案