今回のお話

AWS Lambda環境でBoltを動かしてみた話と動かすまでのアプローチの方法について書いていきます。

下記記事のコード部分のみ参考にさせていただきました。

Boltに関してはWindowsのvenv環境でpip installしたライブラリで問題ありません。

API Gatewayについて

概ね参考記事の通りで、公式の通りSlackアプリとLambda環境を整えていきます。

さて、API Gatewayですが、諸々諸事情により使い始めた頃から、プロキシの統合の使用を使わずマッピングテンプレートなるものを使ってました。

正確ではないかと思いますが、指定のContent-Typeでリクエストが来た場合にヘッダーを取り除いたり、Bodyの部分をJSONに整形したりなどLambdaに渡す前にデータを変換してくれるものです。

あまりちゃんと調べて使っていたわけでないので、Boltに渡すデータ形式とは？という所で躓きました。

結論はリクエストペイロードはそのまま渡せばいい（統合プロキシを有効とする）が正解でした。

それまでは、期待する結果とならず、なぜなのか悩んでいましたが後述するアプローチ方法により解決できました。

アプローチの仕方が正しいかはさておき、コード内のSlackRequestHandlerから読み解いてみます。どのようなデータを受け付けて処理しているのか中身から確認するスタイルです。

from slack_bolt.adapter.aws_lambda import SlackRequestHandler

slack_handler = SlackRequestHandler(app=app)

下記venv環境下のフォルダを参照します。initを見るとhandler.pyを読み取っていました。

venv\Lib\site-packages\slack_bolt\adapter\aws_lambda

eventのキー値はヘッダー情報なので統合プロキシを有効化していないと取得できずエラーとなるため、統合プロキシを使用するのがよさそうです。そもそも統合プロキシを使用していていも赤枠のコード自体存在しないキー値を指定しているので必ずNoneになるのですけどね。

body部分を取得してBoltReqestに返しています。統合プロキシを使用していればbody部分も取得できるのでこれで確認できました。

中々ソースから読むというのに慣れていないため、最初は壁が大きいですが、洗練されたコードの書き方や新しい発見があって、こういった原因調査以外でも何か作りたいけど何を作ればいいか分からないといった場面では、OSSのコードを読み解くというのも一つ勉強になるのかと思いました。