はじめに
応答するbotをslackとintegromatを連携して作成し、やっと疑問が残るところが解消されたので、まとめました。
ポイントは
- 受けたWebhookは3秒以内にレスポンスを返す
- botとユーザ（bot以外）を見分けよう
です。
メッセージ送信時のEventAPIの発生
認証時のEventAPIについては、こちらに記載しました。
ユーザのメッセージ送信以外にbotからのメッセージ送信についてもEventAPIが送信されます。
ユーザがslackからメッセージ送信した時のフロー
Webhookの内容
要素のいくつかはマスクしています。
使用しているパラメータは
event.typeevent.textevent.user-
event.channel
webhookへのレスポンスは3秒以内に
Webhookへのリクエストはbotもユーザ同様に送信されてきます。
いずれもレスポンスにステータス200を返し、EventAPIに3秒以内でリターンします。
以降の処理はbotのuseridを取得してフィルターの対象にします。
ただ、実際組んだこのシナリオでは3秒以内にリターンできないことがままありました。
取得したtextからデータを取得
ものすごく適当なテストデータです。
data storeから取得する時も、別のリソースから取得する方法はいくつもありますので
参考程度に。
Bundle別に取得したデータをひとつのBundleのArrayに
Arrayをフィルタして要素を取り出す
メッセージを送信
channelにはevent.channelを使用します。
メッセージ送信にはim.openでチャンネルを開ける必要がありますが、botアプリのメッセージ欄では最初から開いています。
botからのメッセージ送信をした後のフロー
リクエストを受けてレスポンスを返すだけ、を適当に対応すると
繰り返しbotメッセージが送信されるループに入ります。
エラーと判定される条件の確認
こちらを確認してください。
https://api.slack.com/events-api#the-events-api__field-guide__error-handling__failure-conditions
RouterでWebhookのレスポンスと、テキストによる検索を並列にしていた時に繰り返し送信したメッセージが表示されるので、直列に修正しました。
VirifyずみのWebhookには3秒ルールしないと、最高三回メッセージが投げられます
ヘッダーに理由と実施回数を乗せて送信されてくるので、メッセージが繰り返されたら要チェックです。
リトライのリクエストを受けた後のフロー
ステータスコードに502、headerにX-slack-No-Retryをつけて返しています。
最後に
integromatでslackを扱う場合、モジュールが用意されているので概ねそちらを使えば支障はないかと思います。workspaceにintegromatアプリを追加するあたりが忌避要素でした。
シナリオだとAPIレベルで何をやっているか知るためには、サーバもいらないですし、エラー対応も独自で組めるのが良いところだと思います。
よくないところでは、Webhookの初期化で1秒近くかかる場合も確認していて、
使用するモジュールが増えると全てを初期化する時間がWebhookの応答を遅らせました。