Bubbleは、ワークフローベースのプログラミングシステムを中心に構築されています。ワークフローとは、トリガーされたときに一連のアクションを実行するイベントのことです。例えば、ユーザーがボタン「保存」をクリックすると（イベント）、「何か」が起こるはずです（一連のアクション）。
ワークフローの構築
ワークフローは、ワークフローの引き金となるイベントと、実行される一連のアクションで構成されます。イベントと一連のアクションの組み合わせが、ワークフローを定義する。ワークフローの例は、「Signupというボタンがクリックされたら、ユーザーをサインアップし、メールを送信し、その後ページを変更する」というものです。ワークフローは、アプリ内のページに固有のもので、「ワークフロー」タブで変更します。アクションが情報を返す場合、’Result of previous step’ としてこの情報にアクセスすることができます。
まず、新しいワークフローを起動するイベントを選択することから始めます。ほとんどの場合、ボタンがクリックされた時で、このイベントが適用される要素を選択する必要があります。もし、ワークフローが特定の状況下でのみ実行されるべきものであれば、いくつかの条件を追加することができます。
イベントが作成されると、ワークフローパネルが表示され、さまざまなアクションを1つずつ選択することができます。例えば、Sign the user upアクションのためのEメールをどこで見つけるかなどです。
ワークフローやアクションを右クリックして、関連するオプションを選択すると、ワークフローやアクションをコピーペーストできます。イベントをコピーペーストするとワークフロー全体がコピーされ、個々のアクションをコピーペーストすることができます。アクションを他のアクションに貼り付けると、そのアクションは現在のアクションの前に挿入されます。
アクションの順序は重要です。あるアクションを他のアクションの前に挿入する必要がある場合、矢印をクリックするとアクションメニューが表示され、現在のアクションの前にアクションを追加することができるようになります。
ワークフロー内でリピーターグループ内の要素にアクセスしたい場合、そのワークフローはリピーターグループセル内の要素によってトリガーされる必要があります。
実行ルール
ワークフローは直線的なアクションの集合として作成されますが、ワークフローの実行時には舞台裏で多くのことが行われています。このため、まれに、あるステップが他のステップより先に実行されることがあります。
ワークフローのアクションは、クライアントのブラウザで発生するものもあれば、Bubbleサーバーで発生するものもあり、さらにはブラウザとサーバーの両方で発生するものもあります！ワークフローのアクションは、クライアントのブラウザで発生するものもあれば、Bubbleサーバーで発生するものもあります。ワークフローにこれら3つのアクションが混在している場合、ブラウザとサーバーで発生するアクションの順序が、線形設計と異なる可能性があります。
効率化のために、ワークフローはサーバーとフロントエンドで並行して実行されます。「ステップ1」「ステップ2」という名前がついていますが、あるステップが次のステップを起動する前に、必ずしも前のステップが完了するのを待つ必要はないことに注意することが重要です。以下は、Bubbleワークフローのロジックと一般的な推奨事項に関する情報です。また、ステップとアクションは同じ意味で使われていますが、これらの例では順番に注意することが重要な場合、ステップを使用することがあることに注意してください。
ワークフローの実行方法に関する一般的なルール：
・Frontendワークフローのアクションは順番に実行されますが、次のアクションは前のアクションの完了を待たずにトリガーされます。
・バックエンドワークフローは、ステップとは無関係に、ワークフローが起動されると同時にトリガーされます。例えば、”Schedule API Workflow “アクションは、ワークフローのアクションシーケン スの最後に配置されていたとしても、ワークフローがトリガーされると同時にトリガーされま す。
・カスタムイベントは並列ではなく、順番に実行されます。ワークフロー1がワークフロー2を開始するカスタムイベントをトリガーした場合、ワークフロー1の残りのアクションが実行される前に、ワークフロー2が完了します。
・検索は常に新しいデータですぐに更新されるわけではありません。そのため、新しい項目を作成し、検索でそれを取得しようとすると、うまくいく場合といかない場合がありますので、これに依存しないようにしてください。
・ステップXが「Create…」ステップである場合、「ステップXの結果」から物を取り出すことは、常に安全であるべきです。
ワークフローの一貫性を実現するための回避策：
・ワークフローのトリガー（例：ボタン）が、条件によって複数の結果を持つことができる場合、すべての可能なアクションで1つのワークフローを作成し、アクションレベルで条件を配置するのではなく、複数のワークフローを作成し、ワークフローレベルで条件を配置することが安全である。
・2つのアクションを持つワークフローにおいて、ステップ2でステップ1で操作したデータに応じて検索による条件を使用する場合、ステップ1をカスタムイベントに実装し、それが終了したことを確認してからステップ2へ移行する必要があります。
・もし、バックエンドワークフローがワークフローの他のステップの後にトリガーされるべきならば、それは最初に来る必要があるステップの後に置かれたカスタムイベントとして実装されるべきです。
・あるステップのデータを別のステップに使用する最も安全な方法は、検索ではなく「ステップXの結果」演算子を使用することです。
・ワークフローの終了を待って次のアクションに移るという明示的な機能はありませんが、「次のアクションの前に一時停止を追加する」アクションを使用することで、通常、効果的な回避策をとることができます。
エンドユーザーが短い時間内に同じワークフローを何度もキックするようなことをした場合（例：非常に素早く繰り返しボタンをクリックする）、Bubbleはそのワークフローの実行をスマートにしようとします：繰り返すことに意味のあるアクション（例：物の変更）は繰り返し、繰り返すことに意味のないアクション（例：別のページへの移動）は繰り返さないようにします。
イベント＆アクションの種類
イベントやアクションは、空のイベントやアクションのプレースホルダーをクリックすると、メニューのカテゴリーごとにソートされます。
一般的に、イベントは大きく3種類に分けられます。
・要素イベント – これらのイベントは、Bubbleで構築する際に最も一般的なものです。ユーザーが要素と相互作用したときにトリガーされます。たとえば、マップのマーカーがクリックされたときや、ボタンがクリックされたときなどです。それぞれのイベントに対して、どの要素に適用されるかを定義する必要があります。これらのイベントは、関連する要素がページ上にある場合にのみ、リストに表示されることに注意してください。
・一般的なイベント – ‘The current is user logged in’ や ‘Do when a condition…’ などのこれらのイベントは、アプリの一般的なプロパティが変更されるとすぐにトリガーされます（この場合、ユーザーはログインしています）。ユーザーからの特定のアクションとは関係ありません。これらのイベントは、何かが変更されたときに発生しますが、必ずしもユーザーがアプリで行ったこととは限らないため、デバッグが複雑になる可能性があります。デバッガは、このような状況をデバッグするのに非常に便利です。
・カスタムイベント – この非常に特殊なタイプのイベントでは、他のワークフローで使用できる再利用可能な一連のアクションを定義することができます。
同様に、アクションもいくつかのカテゴリーに分けることができます。
・アカウント管理 – これらのアクションにより、ユーザーのサインアップ、ログイン、ログアウトなどを行うことができます。
・ナビゲーション – これらのアクションは、アプリケーションのページ間でユーザーをナビゲートします。
・データ（モノ） – このカテゴリには、データの読み取りと書き込みを行うアクションが含まれる
・メール – このカテゴリは、ユーザーにメールを送信するいくつかのアクションを収集します。
・決済と分析 – クレジットカード決済、購読管理、分析に関するバブル組み込みアクションは、この2つのカテゴリにあります。コミュニティが作成したプラグインによるアクションは、これらのトピックをカバーする可能性があり、プラグイン セクションにあることに注意してください。
・プラグイン – このカテゴリには、ほとんどのプラグインのアクションが集められています。
・要素 – これらのアクションは、要素固有のアクションです。例えば、繰り返しグループ内のリストを表示したり、カスタム状態を設定したり、要素にスクロールしたりします。各アクションのために、ページ上の関連する要素を選ぶ必要があります。イベントの場合と同様に、ページが関連するタイプの要素を含んでいる場合にのみ、アクションはリストで表示されることに注意してください。
クライアント側のアクションとサーバー側のアクション
アクションの中には、サーバーのみ、クライアントのみ、またはその両方で実行できるものがあります。一般に、データを書き込んだり、外部サービスに接続したりするアクションは、両方の環境で実行されます。ページ移動アクション、要素へのトグルやスクロール、カスタムステートの設定などは、クライアントサイドのアクションの例となります。また、クライアントサイドのワークフローは、アプリケーションのサーバーログに表示されません。
ワークフローにおけるエラー
ワークフローがエラーになった場合、例えば、サインアップアクションで2つのパスワードが一致しなかったり、クレジットカードアクションでカードが拒否されて失敗した場合、ワークフローは直ちに停止します。ここまで実行されたアクションは元に戻りませんし、データの修正やメールの送信も元に戻りませんが、次のアクションは実行されません。エラー発生時のメッセージやユーザーエクスペリエンスを変更したい場合など、ワークフローエラーのカスタム処理を追加することが可能です。
なお、ワークフローはタイムアウトする可能性があります。ワークフローが〜5分以上経過すると、停止してエラーになります（つまり、すでに起こったアクションはすべて起こっていることになります）。一般的に、ワークフローはこれを回避するために再構築することができます。例えば、「Make changes to a list of things」については、よく問題が発生します。これは、小さなリストに対してアクションを起こすには良いのですが、クエリーが複雑な場合、すぐにタイムアウトエラーにつながる可能性があります。これを再構築するには、API Workflowを作成し、可能であれば「Schedule API Workflow on a list」を使用するか、おそらく他の方法でワークフローを分割することをお勧めします。ワークフローがタイムアウトしたかどうかは、Server Logsで確認することができます。
また、ワークフローを実行するのに十分な容量がない場合、エラーになることがあります。これは、たとえば、まったく同じ時刻にキックオフするようスケ ジュールされた多数のワークフローがある場合に起こります。この場合、サーバーログに対応するメッセージが表示されます。これを軽減するには、可能な限りワークフローを分散させる、プランをアップグレードする、またはより多くの容量を購入することを検討してください。
参考英語サイト
https://manual.bubble.io/help-guides/building-workflows/the-basics
