Bubble の Workflow の実行順序について

みなさんこんにちは！

昨年、Bubble Forum で Workflow の実行順序について議論されていました。とても重要な内容なので今日はそちらについてご紹介します。

該当の Forum はこちらです。 https://forum.bubble.io/t/order-of-operation/151699

1. 概要

Forum で議論されていた内容は、「Workflow 内の Step (Action) は、Step 1, Step 2, Step 3, ..... と番号通りに順番に実行が完了しない可能性がある」という事です。Step 2 が始まる前に Step 5 や Step 10 がトリガーされてしまう可能性があるのです。

では、どのような場合に意図した動きをしない可能性があるのか？またそれらを制御するにはどうすれば良いのでしょうか？

本記事では、Workflow の実行順序のルールについての解説と、意図しない実行となってしまわないようにする解決策について解説したいと思います。

2. 全体図

この議論について Bubble Forum の中で、とても分かりやすくまとめられた図があるので、この図をお借りして詳しく解説します。

（この図の作成者は Jessica Getty さんです。記事への図の使用許可をいただきました：https://www.linkedin.com/in/jessicagetty）

では１つずつ確認していきましょう。

3. Workflow のロジックに関する基本知識

図の解説の前に、前提となる基本事項を整理します。

Bubble では "Step" と "Action" はほぼ同じ意味で使用されますが、主に順序に配慮することが必要な場合に "Step" という単語が使用されます。

本記事は順序に関しての考察なので、"Step" を使用します。

次に、Bubble の Workflow は、効率性の観点からサーバーとフロントエンドで並列実行されます。 この特性により、必ずしも前の Step が完了するのを待ってから次の Step がトリガーされるわけではない、という事象が発生します。

なお、この Forum での議論の後、本記事の内容は Bubble Doc にも正式に記載されております。

https://manual.bubble.io/help-guides/building-workflows/the-basics#execution-rules

では、先程の図の中身を一つずつ理解していきましょう。

4. Workflow の実行順序のルール

4.1. 必ずしも前の Step が完了するのを待ってから次の Step がトリガーされるわけではない

上の図の赤く四角で囲った場所の説明になります。

Step 2 は Step 1 が完了する前に開始してしまっています。

必ずしも前の Step が完了するのを待ってから次の Step がトリガーされるわけではないため、Step 1 がある程度の時間を要するアクションだと、図のように処理が重なる可能性があるということを意味しています。

4.2. Backend Workflow がトリガーされるタイミング

上の図の赤く四角で囲った場所の説明になります。

Event から Step 1 と Step 3 へ赤い矢印が出ています。

Backend Workflow である Step 3 は、前の結果に依存関係がない限り（Result of Step 2など）、たとえ最終 Step に定義されていたとしても Workflow の Event が呼び出されるとすぐにトリガーされることを意味しています。

よって、Backend Workflow である Step 3 は、Step 2 より先に呼び出されてしまう可能性があるのです。

この内容は Forum の中でも多くのユーザーから議論を呼ぶものとなっていました。

4.3. Custom Events を使うとそのイベントは順番が保証される

上の図の赤く囲った部分の説明になります。

Step 4 では Custom Events を活用しています。Custom Events は並列ではなく、順番に実行されるため、例えば Workflow 1（ここではスタート地点の Event のこと）が Workflow 2（ここでは Custom Event 内の Action 群）を開始するCustom Events をトリガーした場合、Workflow 1の残りのアクションが実行される前に、Workflow 2 が完了することを意味しています。

4.4. Custom Events は順番を保証するが、Custom Events 内の Action は、後の Action が必ずしも先の Action の完了を待つわけではない

上の図の赤く囲った部分の説明になります。

4.3. で説明した通りCustom Events は順番が保証されますが、Custom Events 内に複数の Action がある場合、その Action 達は、必ずしも前の Action が完了するのを待ってから次の Action がトリガーされるわけではないため、Action 1 がある程度の時間を要するアクションだと、図のような状態になり、実行に重なりが生じる可能性があります。

5. Workflow の一貫性を確保するための回避策

ここからは意図しない実行順序となる事を防ぐ解決策についてご説明します。

5.1. [Do a Search for] ではなく [Result of new thing] が安全

上の図の赤く囲った部分の説明になります。

ある Step のデータを別の Step に使用する最も安全な方法は、[Do a Search for] を用いた検索ではなく、[Result of new thing] を使用することになります。

Step 6 のように [Do a Search for] を用いると、Step 5 が完了していないまま実行がスタートする可能性があり、その場合取得するデータに誤りが生じてしまい Step 6 で正しい結果を得られない事になります。

一方、[Result of new thing] を使用すると、Step 5 の完了を待ってそのデータを使用するため、[Result of new thing] では正確にデータを取得する事ができ、より安全な解決策となります。

5.2. Backend Workflow を他の Step の後にトリガーしたい場合は Custom Events を使用する

4.2. で説明した通り、Backend Workflow は Workflow の Event が呼び出されるとすぐにトリガーされてしまいます。これを回避するには、先に来る必要のある Step の後に置かれた Custom Events として実装します。

5.3. Event の中に複数の [Action if...] を設置するよりも、複数の [Event if...] を設置する方が安全

上の図の赤く囲った方法よりも緑で囲った方法の方が安全です。

Event の中に複数の [Action if...] を設置すると、前の Action が完了するのを待たず次の Action が始まってしまう可能性があります。

独立を保ちたい場合は、[Event if...] を使用してください。

5.4. [Create/Update thing] を使う時も、Custom Event や [Result of thing] を使って独立させよう

上の図の赤く囲った方法よりも緑で囲った方法の方が安全です。

一番上は Custom Event を使って [Create/Update thing] を順番を保証させる方法です。Custom Event 内の Action は独立が維持されるため、次の [Action if thing...] が [Create/Update thing] の完了を待って実行されます。

真ん中は [Result of thing] を使って順番を保証させる方法です。[Result of thing] は前の [Create/Update thing] の結果に依存するため、[Create/Update thing] の完了を待って実行されます。

一番下は安全でない方法です。[Create/Update thing] のあと直接 [Action if thing...] を設置すると、[Create/Update thing] が完了していないのに [Action if thing...] がスタートしてしまう可能性があるため安全と言えません。

5.5 [Schedule API Workflow on a list] が [Make changes to a list of things] より安全

リストで変更を加える場合は [Schedule API Workflow on a list] の活用が安全です。意図しない順序での実行を防いでくれます。

一方、[Make changes to a list of things] を使用する場合、特に長いリストだと、この Step が完了を待たずに次の Step が始まってしまう可能性があります。

5.6. [add a pause before next action] を設置する

Workflow の終了を待って次の Action に移るという明示的な機能ではありませんが、[add a pause before next action（次のアクションの前に一時停止を追加する）] も効果的な回避策となり得ます。

5.7. おまけ

上記の内容については Workflow に関するエラーのヒントとなりますので、ご参考までに日本語訳をさせていただきます。

Timeout - 「長いリストに Action を実行しようとしていませんか？ Action の代わりにリストで Schedule API を使うか、Workflow をバラバラにしてみましょう。」

Capacity - 「同時に開始するようスケジュールされたものがたくさんある場合、Workflow 同士の間を空けるか、プランをアップグレードするか、容量を購入するなどの方法があります。」

6. まとめ

いかがでしたでしょうか？

細かい内容ではありますが、意図しない動きを防ぐためにも、重要なポイントになりますのでぜひご確認ください。

この他にも、Bubble で Workflow を作成するときは考慮が必要な項目がいくつかありますので、また別の記事で詳しく紹介させていただきます。

※ 本記事は、Bubble Document と Bubble Forum を参考にさせていただきました。