皆さん、こんにちは！ Bubbleでノーコードライフいかがお過ごしでしょうか？
先日、同じタイトル「Bubble の Schedule API Workflow を使った簡単バッチ処理をしよう！」と「Bubble の Schedule API Workflow を使った簡単バッチ処理をしよう！～2: List編」いう記事を書きました。
まだ読んでいない方はこちらを先に読んでください！
今回はこのシリーズの３つめの記事です。
Schedule API Workflow を使った「動的な再帰スケジューリング」についてご説明します。
定期スケジューリング（Recurring event）と Integromat でのスケジューリングの弱点
前回の記事の最後に Recurring の Workflow について記載させていただきました。
これは Bubble の Personal 以上で利用でき、定期スケジューリングでワークフローを実行できる機能になります。
便利な機能ではあるのですが、結構弱点だらけで正直あまり利用をオススメできない状況です。
具体的な弱点は次のとおりです。
- 短い単位の繰り返しができない。Personal プランだと月１、Professional / Production でも毎日実行まで。1時間おきに実行などの細かい繰り返し処理はできない。
- Recurring event の登録の制限が厳しい。Personal プランでは、Things（テーブル）ごとに1つだけ。Professional で 5つ、Production でも 20 まで。
この２つ、とても厳しい弱点だと思います。
これが理由で弊社ではほとんど Recurring event は使っていません。
それでは、どうするのか？
解決策の一つは既に記事にしたことがありますが、Integromat を使う方法です。
Integromat であれば、無料で利用することも可能です。
しかも Integromat には Bubble と連携するためのモジュールが予め用意されているため、設定も簡単です！
zapier 派の皆さん、Bubble を使うなら Integromat に乗り換えるべきですよ〜w
定期的なスケジューリングであれば、この方法でほとんど解決します。
ただ、一つだけ、Integromat では解決できない問題があります。
それは 動的なスケジューリング です！
例えば、ユーザーが登録されたら毎週特定の曜日の特定の時間にメールが送られるように Bubble から動的にスケジュールを組めるようにしたいとします。
Integromat には API があります。Bubble から API 経由で動的にスケジューリングできれば問題ないのですが、残念ながら Integromat の API のドキュメントを見ても Create Scenario がありません！！
そのため、Integromat を使って動的にスケジュールを組むことは不可能です！！
それではどうするか？
Backend Workflow の中で次の実行を予約する
前フリが長くなりましたが、解決策は実に簡単なものでした。
それは、Schedule API Workflow で呼ばれる Backend Workflow の中で次の実行を予約するというものでした。
こちらの画像を見ていただけますでしょうか？
これは 3分おきに処理を実行するための Backend Workflow です。
Step2 以降が実際に行いたい処理です。通常でしたら、Step2 以降だけで良いのですが、ここに Step1 の処理を追加しています。
この Step1 では、次の Schedule API Workflow を予約しています。Scheduled date を見ていただくと Current date/time +(second): 180 と記述されています。これは今の時間から 180秒後、つまり 3分後に同じ API Workflow（= Backend Workflow）を設定しています。
これだけで 3分後にまた同じ Backend Workflow が動きますので、また 3分後に予約、実行・・・と延々と続いていきます。
この画像では 3分ごとですが、Scheduled date の設定を変更して、Current date/time +(days): 7 で毎週同じ曜日、Current date/time +(months): 1 で毎月同じ日、Current date/time +(years): 1 で毎年同じ日にBackend Workflow が動作します。
Schedule API Workflow であれば、Recurring events とは違って登録の制限はありません！
また、Integromat と違って動的にスケジュールを組むことも可能です！
ただ、やはり心配な点もあります。
心配な点
Workflow が動かない？
一番心配なのは、なんらかの要因でスケジュールした Workflow が動かなかった場合です。
例えば、Bubble の不具合などで予定の時間に Workflow が実行できないことがあった場合、Recurring events や Integromat であれば、1度動かなくても次の実行はしてくれると思うのですが、この方法の場合では、次以降全て動作しなくなってしまいます。
せめて「Workflow が動かなかった」というのを検出できればいいのですが、Bubble の Workflow などを調べてもできそうな感じはありません。
何かいい検出方法をご存知の方いらっしゃいましたら、ご教示いただけると幸いです。
今のところは Bubble での障害があったら、Scheduler のチェックと、万一の時に備えて、再度スケジューリングできる体制を整えておくくらいしか対応策がありません。
なお、Integromat であれば、動作できなかった場合などはメールが飛んできます。エラーの検出を考えると、Integromat の方が安心できます。そのため、固定の定期的なスケジューリングであれば、Integromat を利用することの方が良いでしょう。
ID が枯渇する？
今回の処理の場合、予約するたびにスケジュールされた処理に ID が発行されます。ID は数字です。恐らくは十分な数を確保していると思います。ただ、仮に毎秒ごとに繰り返し実行する場合には１年で 31,536,000 もの ID を消費します。多分大丈夫なのでしょうけど、ちょっと心配です。
そもそもこんなことやっていいの？
Recurring events を制限しているのは、そもそもサーバの負荷を低減させるためなんじゃないかな？と思っていたので、この方法は Bubble 側に怒られてしまうのではないか？と思いました。
しかしながら、2018年9月に co-CEO の josh さんが次のアナウンスをしています。
この記事は「再帰的にスケジューリングすることを許可する」というアナウンスです。
今回やっている処理と同じ内容です。
ということは、一応、この方法は Bubble が正式に OK を出している方法だと考えて良いと思います。
まとめ
今回ご紹介した方法を使うと Personal プラン以上で動的な再帰スケジューリングが可能になり、細かい単位でのバッチ処理が可能になります。動的に定期的なバッチ処理をスケジュールする必要がある場合はこちらを試してみてください！
それでは、また！
