この記事は「make Advent Calendar 2024」24日目の記事です。
このアドベントカレンダーについて
このアドベントカレンダーは25日間でIPaaS製品の「make」について使い方や、実践を学べる連続ブログ企画です。
「おかしん」「ばるす」「たにあん」の3名がリレー形式でお届けします。
25日間のスケジュールは以下の通りです。
| 日付 | 内容 | 担当 |
| 12/1 | 話題のIPaaS製品「make」とは | おかしん |
| 12/2 | makeで作ってみたScenario紹介 | ばるす |
| 12/3 | make 基本操作編 機能紹介：Organization | たにあん |
| 12/4 | make 基本操作編 機能紹介：Scenario、Template | おかしん |
| 12/5 | make 基本操作編 機能紹介：Connections | ばるす |
| 12/6 | make 基本操作編 機能紹介：Webhooks | たにあん |
| 12/7 | make 基本操作編 機能紹介：DataStores、DataStructures | おかしん |
| 12/8 | make 基本操作編 機能紹介：Devices | ばるす |
| 12/9 | make 基本操作編 機能紹介：Functions | たにあん |
| 12/10 | make 基本操作編 機能紹介：CustomApps | おかしん |
| 12/11 | make 基本操作編 機能紹介：Flow Control,Tools,Text parser | ばるす |
| 12/12 | make ドキュメント動線の話：ResourceHub | たにあん |
| 12/13 | make 検証：Make Bridge | おかしん |
| 12/14 | make 検証：Make REST API | ばるす |
| 12/15 | make 検証：AI Search | たにあん |
| 12/16 | make Community Hub：Overview | おかしん |
| 12/17 | make Community Hub：Academy Courses,Blog Articles | ばるす |
| 12/18 | make Community Hub：Showcase,CustomApps | たにあん |
| 12/19 | makeの管理運用の話：Github連携 | おかしん |
| 12/20 | makeの管理運用の話：実行ログと再実行と停止中リクエスト滞留 | ばるす |
| 12/21 | makeの管理運用の話：Connection権限管理 | たにあん |
| 12/22 | makeで作ってみた事例：（未定） | おかしん |
| 12/23 | makeで作ってみた事例：（未定） | ばるす |
| 12/24 | makeで作ってみた事例：（未定） | たにあん |
| 12/25 | makeの総論を語る | ばるす |
はじめに
どうも、たにあんです。今日が僕のmakeアドベントカレンダー最終回です。
普段から読書は人並みにしている（はず）のですが、読んだ本の記録を残さずにはいられない性分なので、ISBNを手動でLINE Botに投稿し、GASで処理してNotion DBに登録するという仕組みを使っています。
ISBNのバーコードをカメラで読み取って番号を取得する方法もありますが、実装が面倒だったので見送りました。でも、そんな面倒なことをしなくても大丈夫…そう、makeならね。
Scenarioの大まかな流れ
こんな感じです。
以下のような流れで動作します。
- iOSアプリでバーコードをスキャンし、openBDから情報を取得
- Data Storeを検索もしくはiOSに通知
- 検索結果に応じて、Notionに登録もしくはiOSに通知
- Notion DBへの処理結果をiOSに通知
Notion DBはこのように作成しています。
それぞれ解説していきます。
iOSアプリでバーコードをスキャン
赤枠内の説明です。
トリガーはiOSデバイスでのバーコードスキャンです。事前にiOSにmakeアプリをインストールし、Deviceを登録しておく必要があります。
Apple iOSとHTTPモジュールの間にはフィルターを設定しています。ISBNの先頭3桁は978か979なので、それ以外のバーコードがスキャンされた場合は処理を中止します。スキャンした数値が誤っていることもあるため、このフィルターは必須です。
バーコードがスキャンされると、HTTP ModuleでopenBDから情報を取得します。エラーハンドリングはResumeに設定し、エラーが出ても、openBDに情報がなくてもnull になるのでとりあえずは処理を続行させ、後続のフィルターで弾きます。
Data Storeを検索もしくはiOSに通知
赤枠内の説明です。
openBDから取得結果を元に、処理を分岐させています。 値がnullでない場合：Data Storeを検索 nullの場合：iOSデバイスに「情報を取得できなかった」旨をプッシュ通知
Data Storeには過去に登録した書籍情報を格納しています。Notion DBへの登録重複を防ぐために利用します。Notion DBから直接情報を取得することも可能ですが、Database Item IDが必要で手間がかかるため、この方式を採用しています。
（考えてみればNotionに登録したときにDatabase Item IDが返ってくるはずなので、保存しておけばよかったかもです。結局はData Storeに入れなきゃいけないですけど。）
Data Storeへの保存については最後のステップで説明します。
検索結果に応じて、Notionに登録もしくはiOSに通知
赤枠内の説明です。
Data Storeの検索結果に応じて、処理を分岐させています。 ヒットしなかった場合：Toolsで日付を処理してNotion DBに登録 Data Storeで検索がヒットした場合：iOSデバイスに登録済みの旨を通知
Toolsでは、openBDから取得した日付情報を処理します。openBDからの情報はyyyyMM形式が多く、このままではNotion DBのDateプロパティに適合しないため変換が必要です。
具体的にはyyyyMMをyyyy/MM/01に、yyyyをyyyy/01/01に変換するよう設定しています。Item1→Item2の順に処理されるため、より厳しい条件をItem1（上位）に設定しています。
Notionモジュールの設定は以下のとおりです。openBDのデータとToolsで加工した日付を渡しています。
Notion DBへの処理結果をiOSに通知
赤枠内の説明です。
Notion DBへの処理でエラーが発生したかどうかで条件分岐します。 エラーがない場合：iOSデバイスに登録完了を通知し、Data Storeへ保存 エラーが発生した場合：エラー内容を通知
エラーがない場合は、iOSデバイスへの通知とともにData Storeへ格納します。これはステップ2で検索に使用したData Storeと同じです。Notionへの登録完了を確認してからData Storeに登録することで、Notion DBとData Store間の整合性を確保しています。Data Storeでエラーが発生したら…それはmakeが悪い。
エラーハンドリング側の通知には、Error Messageを動的に取得して表示するよう設定しています。
その他Tips
Deviceのトリガーは端末指定
これな〜〜〜〜〜〜
仕組み上やむを得ない気もしていますが、トリガーとして使える端末が1台に限定されるのは厳しい。企業での利用を考えると、端末をトリガーにしたScenarioはほとんど使えないんじゃ…と思っています。
めっちゃスキャンされる
すべてのモジュールが実行され、iOSデバイスに通知が返ってくるまで数秒かかります。この間にバーコードのスキャンが3回ほど実行されます（通知が返ってくるまで状態が分からないため、バーコードをスキャンしっぱなし）。各モジュールで処理を分岐させておかないと、想定していない挙動になりまくりです。
Scenarioの処理設定
実はScenarioの設定に「Sequential processing」という項目があります。
Scenarioの実行を「順次処理にさせる」設定で、処理の実行中は次の処理が開始されないようにできます。
前項「めっちゃスキャンされる」で説明したように、複数回スキャンされてしまいます。Data Storeへの登録が完了する前に次の処理が始まると重複が発生するため、Sequential processingを有効化しています。
バーコードの読み取りが甘い
日本の書籍の場合、2つのバーコードが並んでいることもあってなのか、読み取りに誤りが発生したり、ISBNではない日本図書コードを読み取ってしまったりすることがあります。この問題はScenario内で適切に制御し、Notion DBへの不適切な登録を防ぐしかありません。そのため、「iOSアプリでバーコードをスキャン」で記載した通り、フィルターを設けて意図していない値は処理されないようにしています。
あたりまえのエラーハンドリング
条件分岐で処理の流れをコントロールすることも重要ですが、エラーハンドリングも必須です。これがないと、モジュールでエラーが発生した際にScenarioが停止してしまいます。
実際に動作させてエラーを検出することが重要なので、テストケースを考えた上で適切なエラー処理を実装しましょう。
最悪、「Ignore」モジュールを接続しておけば大丈夫です。
Scenario以外の話
書籍情報の取得先について
openBD APIは提供終了が決定しているのでご注意ください。今回はScenario作成に注力したかったためopenBDを利用しました。無料で使えることにずっと「なんで？」と感じていたので、残念ですが仕方ないです。
Googleブックスは、手持ちの書籍3冊ほど未登録であることを確認してそっと閉じました。おそらく登録数も少ないのでしょう。知らんけど。
応用例
スマートフォンをきっかけに何か処理を走らせるようなものを企業で利用するのであれば、以下のような形でしょうか。（ちょっと無理があるかも）
- 企業内図書があれば利用履歴に使用
- 企業内の備品在庫管理に利用
- バーコードがあればスキャンして発注が必要なもののリストを作る程度は自動化できそう。
- 経費精算系の事務処理をmakeを経由して自動化
- 今回の内容と近いかと聞かれると微妙ですが、似たような考え方で実現できるとは思います。
おわりに
1から考えてScenarioを作ってみることが理解の最短ルートだと思います。AI Assistantも機能を知らないと適切な指示を出しにくいので、触ってみていただけるとよいと思います。また、今回作成したものは、makeとNotionどちらも無料プランで実現可能（なはず）ですので、ぜひ試してみてください。
余談ですが、実は今回紹介したものとは別に、並行してPerplexity APIを利用したSlackチャットボットをmakeで作成していましたが、間に合わなかったので、また機会があれば紹介します。一つの記事で終わらせるには厳しいそうな分量になりそうな予感が…
最後に、makeアドベントカレンダーを読んでくださった方、ありがとうございました！！！
社内でこれからmakeを使っていくので、引き続きよろしくお願いしますー。
ではでは、またのブログで。さいなら。
