雜談：用Make設定了RSS傳送到Threads / TALK: Forword the RSS Feed to Threads in Make
在我寫完「RSS自動轉發到Threads跟X (Twitter)：使用dlvr.it」之後，dlvr.it就轉變成完全收費的制度，因此自動轉發也跟著無以後繼。最近我總算能騰出時間來撰寫Blog，同時也把Threads API整合到Make平臺裡，讓「布丁布丁吃什麼？」的新文章能夠自動轉發到Threads裡面。至於這個方法是否能夠成功，就要等時間來驗證了。以下就記錄我大致上的做法。
Make：自動化平臺 / About Make: an Automation Platform
https://www.make.com/en/product
Make 是一款資訊視覺化的自動化流程設計工具，讓使用者可以輕鬆地建立、建構和自動化各種工作流程。它提供一個使用者友善的無程式碼整合工具，讓即使不具備程式設計背景的使用者，也能夠透過直覺的拖拉操作，將不同的應用程式和服務串連起來，自動執行重複性的任務，進而提升工作效率。Make 強大的功能可以處理複雜的工作流程，並提供所有必要的工具來協助使用者自動化和擴展整個業務流程。
Make 的核心概念是透過視覺化的方式設計自動化流程，使用者可以將不同的應用程式模組（例如：Gmail、Google Sheets、Twitter 等）像拼圖一樣組合在一起，定義資料的流向和觸發條件。舉例來說，使用者可以設定一個自動化流程，當收到一封新的 Gmail 信件時，自動將信件內容擷取出來，並儲存到 Google Sheets 中。Make 支援超過 7000 個應用程式整合，涵蓋了各種不同的領域，例如：行銷、銷售、客戶服務、人力資源等等。這使得使用者可以根據自己的需求，靈活地組合不同的應用程式，打造客製化的自動化解決方案。
乍看之下Make跟我之前用的Zapier好像很相似，但Make能做到的功能可不僅僅只是把資料從A轉向B這麼簡單，它更是一個功能強大的整合平台。透過 Make，使用者可以設計和建構複雜的工作流程，而無需編寫任何程式碼。它提供各種進階功能，例如：資料轉換、條件判斷、迴圈控制、錯誤處理等等。這些功能讓使用者可以更精細地控制自動化流程的執行，並確保資料的準確性和完整性。綜合以上所述，Make 是一款功能強大且易於使用的自動化平台，適合各種規模的企業和個人使用，幫助使用者簡化工作流程、提升效率，並專注於更重要的任務。
那這次我就使用Make這個強大的平臺，來實作我那小小的自動轉發功能吧。
Make設計的靈感來源 / Inspiration to the Design of Make
一開始我是參考了yayapipifly在Make裡的設計。在整個流程中，最重要的其實是後面三個模組。至於這三個模組的細節內容，則需要從Threads API裡面取得線索。
建立Threads應用程式 / Building a Threads Application
https://nijialin.com/2024/08/17/python-threads-sdk-introduction/
接著我參考了忍者工坊的Threads API使用教學。文章裡面提及了建立應用程式、加入帳號、允許連動等細節操作。這些細節非常繁雜，真的很感謝忍者工坊仔細的說明。
直到後面取得個人帳號的ID跟ACCESS_TOKEN之後，後面的操作就可以接手看Threads API的說明了。
取得長期的取用權杖 / Get a Long-Lived Access Token
https://developers.facebook.com/docs/threads/get-started/long-lived-tokens/?locale=zh_TW
在應用程式的測試功能裡取得的短期ACCESS TOKEN (short lived access token)只能使用24小時。為了讓我們能在Make裡長久使用，我們必須要把短期ACCESS TOKEN換成長期ACCESS TOKEN (long-lived access token)。長期ACCESS TOKEN不僅可以使用60天，還能夠直接用API延長期限。
申請長期ACCESS TOKEN的做法除了需要短期ACCESS TOKEN之外，還需要應用程式的密鑰(secret)。忍者工坊的文章有提到secret的位置，不難找。
取得長期ACCESS TOKEN之後，就可以用上述的做法延長期限。不難。
使用Threads API / Using the Threads API
https://developers.facebook.com/docs/threads/posts/
有了長期ACCESS TOKEN之後，我們就可以來使用Threads API發送文章。整個流程必須分成兩個階段進行。第一階段是建立草稿(英文寫作container，但概念上當作草稿比較合適)，然後第二階段再將草稿發佈。考慮到我的Blog的類型，我只會使用以單張圖片為主、文字為輔的形式。此時的media_type使用的是IMAGE。其他就沒有什麼特別需要注意的地方了。
在Make裡的成果 / The Senario in Make
最後完成的場景設計(senario)如上圖所示，裡面包含了六個模組：
- RSS: Watch RSS feed items：當RSS Feed有新文章的時候執行後面的動作。
- Tooks: Set variable：儲存操作Threads API會使用的參數，包括使用者ID、長期ACCESS TOKEN。
- HTTP: Make a reqest：第一階段建立草稿，以POST跟Body type: Application/x-www-form-urlencoded，傳遞domain: "THREADS"、image_url、text、media_type: "IMAGE"、access_token參數。
- JSON: Parse JSON：分析第三個模組的回傳參數，取得草稿的ID。
- HTTP: Make a reqest：第二階段發佈草稿。類似第四個模組的分析結果，用POST傳入creation_id、access_token。
- HTTP: Make a reqest：延長長期ACCESS TOKEN的請求。
然後將Make設定每天執行一次即可。
Make的費用 / Pricing in Make
https://www.make.com/en/help/general/pricing-parameters
目前Make免費帳號的限制裡，最重要的大概是最多只能同時有兩個啟用的場景，而排程執行最短的間隔為15分鐘。由於我的Blog並不是這麼頻繁發文的關係，免費版就足以使用了。
結語 / In closing
在克服Theads API複雜的申請流程後，Make的使用倒是符合預期的容易上手，不愧是許多AI技術大佬們紛紛推崇的平臺。雖然我還沒有很深入的研究，但Make使用上比Dify或Coze都直覺許多，真的很厲害呢。
但這個做法最大的問題應該還是長期ACCESS TOKEN到底能不能撐過60天。雖然我在場景最後加上了延長期限的申請，但其實我總覺得這樣做好像哪裡會有問題。總之目前就先做到這樣吧，邊做邊改就是了。
