はじめに
こんにちは！ 18卒のいっちーと呼ばれている者です。もう入社してから1年が経ちました。そんな1年のほとんどの期間で実装を行ってきたSlackbotについての記事をここで投稿しておこうと思います。 今回は僕がSlackbotを実装する上で苦労した所を書きます。 僕のこの記事を読んで一人でも同じ失敗をしない人が増えればいいなぁと思います。
TL;DR
学んだこと
長いので簡単にまとめると、大変だからこれは心がけよう！と学んだことは次の3つです。
- なるべくチャンネル間のやり取りを行う場合は、データベースを使ったほうがいいということ
- ダイアログの要素のサイズに注意すること
- ライブラリのチェックはこまめに行うようにリポジトリの通知をつけること
実際の申請画面のスクショはこちら。
対象読者
- これからSlackbotでチャンネル間のメッセージをダイアログで実現しようとしている人
- ライブラリのチェックをしてないとどんなことがあるのか気になる人
社内ツール(Slack)
弊社では、コミュニケーションツールとしてSlackを使っております。
最近よく聞く「オープンな文化」を目指し、みんなパブリックなチャンネルで意見を述べ、質問もしています。僕個人では、必要な情報が過去の投稿から見つかることがあり、コミュニケーションコストが削減されているのを感じています。
また、弊社ではチャンネルの乱立を防ぐべく、チャンネル作成者の制限を行っています。以前は、チャンネルを作成する際は、担当者にメンションをつけて作成依頼をしておりました。 しかし、メンションをつけると、相手に通知が飛ぶだけではなく、送り手も送っていいのかなぁ、迷惑じゃないのかなぁ、といった不安を感じてしまう側面もあり、なかなかチャンネル作成を依頼できない、、、といった状況が頻発しました。
そこでBotになら気兼ねなく送れるのでは？という発想の元、Slackbotプロジェクトが発足しました。
Slackbot
SlackbotとはSlack上で動くBotのことです。
社内では、「チャンネルを作成して」という依頼をSlackbotに送ることで、その依頼を権限持ちの「誰か」が実行してくれるように、申請承認チャンネルに投稿してくれます。
実装について
Techblogという位置づけ上、技術的な話もしておきます。
使用環境
- 言語: Golang 1.11.2
- パッケージ管理: dep
- slack用のパッケージ
- サーバ: AWS EC2
機能一覧
現在搭載されている機能としては大きく分けて次のとおりです。
- ユーザ招待機能
- チャンネル作成機能
- チャンネルリネーム機能
- チャンネルアーカイブ機能
実装で苦労した所
別チャンネルに対してのThreadでの返信機能実装が大変だった
作ってきたSlackbotは基本的にはThreadとチャンネル間でのやり取りを行います。つまり、Slackbotを通して申請用と承認用の2つのチャネルに投稿されます。
Slackの仕様として、Threadで返信するためには、Threadで返信したい対象メッセージのタイムスタンプ情報が必要です。つまり、申請用のチャンネルで申請を出したあと、申請メッセージのタイムスタンプを承認用のチャンネルで保持しないといけないのです。普通なら、ここでKVSのようなもので保持するんですが、初期段階では用意してませんでした。
KVSなどが無い状態でどうしたのか、というと次の画像が語っているのですが、申請メッセージの中にタイムスタンプ情報を入れてます。そうすることで、ダイアログで承認を実行すると、今の実装では、タイムスタンプ情報をリクエストの中に乗せて、送信してくれます。 あとは、ダイアログ送信時の処理部分で、タイムスタンプ情報を扱うことで、実現しました。
// 本来のコードとは違います // GetTimestamps ... get timestamp from message func GetTimestamps(message slack.AttachmentActionCallback) (string) { fieldLength := len(message.OriginalMessage.Msg.Attachments[0].Fields) applyTimestamp := message.OriginalMessage.Msg.Attachments[0].Fields[fieldLength-1].Value return applyTimestamp }
別チャンネルの投稿と紐付いているタイムスタンプを返り値として渡すという関数を作りました。
タイムスタンプは、一番最後の要素にするので、 fieldLengthを使って最後の要素の Valueを取得しています。
最後に、申請結果をThreadで返す機能を作ったということもあり、この大変さに気づくまで遅くなりました。 というのもCallbackなどを設定しているので、てっきり前のダイアログ送信イベントでトリガとなったメッセージのタイムスタンプ情報を持っていると思っていたからです。(持っているはずがなかった…)
Dialogを使用した別チャンネルへの投稿が大変だった
このテーマだと、 messageAPIをSubmission時に叩けばいいんじゃないか？と思われるかもしれません。まさしくその通りで僕もそのまま実装しました。
でも、なんのエラーもなく、投稿されないという状況に陥りました。
原因は確実にこれ！と言えるわけではありませんが、いろいろ試してみたところ、Submission時に渡せる要素の長さに制限がありそうでした。
timestamp情報を先程持たせているという話をしましたが、そのtimestamp情報は申請元と承認側のtimestampを一度に送信しているため、文字列の長さが比較的長くなります。
画像にあるように、 1552527866.001200が2つある状態でそれに追加で originalTimestampというようなstructのフィールド名もつけているため1要素で渡す情報が長くなりました。
最初は定義したstructに問題があったのか、とか受け取り側のプログラムに問題があったのかなど考えました。
最終的に、渡すデータを短めの適当な値で試したところ、思った通りに動作したため長さに原因があることがわかりました。
なので、もともとoriginalTimestamp: 1552527866.001200, timestamp: 1552527866.100000としていたところを、 originalTs: 1552527866.001200, ts: 1552527866.100000に変更することでギリギリしのげました。
長さについては特に言及されていなかったので、試行錯誤が大変でした。 原因っぽいところに気づいて、無事動く状態に持っていけたのは非常に良かったですが、この原因調査が全実装のなかで一番大変でした。
ライブラリ自体に大きな変更があったときの対処が辛かった
例えば次のコードは、メッセージをThreadに対して送信するための関数です。
// 変更前のコード // ReplyMessageToThread ... Threadで返信するための関数 // message: 返信する投稿内容, ts: Threadの対象の投稿のTimestamp, p: 投稿メッセージのパラメータ func (s *SlackListener) ReplyMessageToThread(channelID string, message string, ts string, p slack.PostMessageParameters) error { p.ThreadTimestamp = ts if _, _, err := s.Client.PostMessage(channelID, message, p); err != nil { return fmt.Errorf("faild to post message: %s", err) } return nil }
// 変更後のコード // message: 返信する投稿内容, ts: Threadの対象の投稿のTimestamp, p: 投稿メッセージのパラメータ func (s *SlackListener) ReplyMessageToThread(channelID string, message string, ts string, p slack.PostMessageParameters, a slack.Attachment) error { p.ThreadTimestamp = ts if _, _, err := s.Client.PostMessage(channelID, slack.MsgOptionText(message, false), slack.MsgOptionPostMessageParameters(p), slack.MsgOptionAttachments(a)); err != nil { return fmt.Errorf("faild to post message: %s", err) } return nil }
PostMessageParametersに、AttachmentsというPropertyが入っていたことで、スッキリとかけていましたが、ライブラリの変更により、 PostMessageParametersのstructから、Attachmentが分離されました。その変更により、すごい長くなりました…。
このように、 PostMessageParametesrsの Attachmentsを使っていた部分はほとんどが使えなくなりました。変更履歴を確認した所その変更が取り込まれたのが気づいた月の約3ヶ月ほど前でした…
ライブラリの変更を追わずに、実装をし続けることで、こんなに大変なことになるんだ…ということの勉強になりました。
それからは、Slackにライブラリの変更通知を飛ばすように設定しました。
現状の辛い運用
Threadで返信するために、タイムスタンプ情報が必要だ、と述べたんですがそのタイムスタンプ情報は申請メッセージの中にあります。 ただ、それは運用している人にとっては全く意味のないものなので、表に出すようなものではないです。本来必要なものは、申請メッセージとの紐付け、つまり申請メッセージへのパーマリンクです。 若干申請者とのやり取りをThreadで行うことがあるのですが、それを手助けする機能が今無いのです。 これは非常に辛いと思うので、改善していこうと考えています。
改善への道
まず、KVSを導入しメッセージ間の紐付けをそこで行います。
KeyとValueとしては、それぞれ 申請元メッセージのタイムスタンプと、承認メッセージのタイムスタンプとします。
そうすることで、承認メッセージのタイムスタンプ情報を元に、元のタイムスタンプ情報を得ることができます。
また、元メッセージのタイムスタンプ情報がKVSの中に保持されているので、承認メッセージにタイムスタンプ情報が不要になるため、代わりにパーマリンクを貼ることができます。
パーマリンクを取得するAPIとしては、chat.getPermalink - slackを使用します。
おわりに
学んだこと
- OSSのライブラリを使うときは、アップデートを気にしておかないと、動かなくなる
- 通知を飛ばすことでちゃんとアップデート情報を追う
- SlackのAPIについての知識
- ダイアログを送信したときのリクエストの長さに上限があり、正常なステータス返しても処理が実行されないこと
今後の改善
- KVSのような仕組みを導入
- タイムスタンプ情報ではなくパーマリンクを乗せる
以上の2つをこれから取り組んでいこうと考えています。
感想
全社で職種関係なく使うコミュニケーションツール内で、実現したいことをサポートをするBotを作って、色んな人に使ってもらえる経験をできてよかったなーと思います。社内で使用していることもあり、すぐにフィードバックを貰え、改善できる環境っていうのはエンジニアにとって非常に楽しい環境でもあります。 また、この開発を通して、Slack APIについては社内でも詳しい方になった気がして、なんか嬉しいです！
今後も社内で使っているSlackbotがより良いものになるようにしていきたいと思います。
ありがとうございました！
