皆さん、ごきげんよう！！
今回の記事では、Bubbleにおけるサーバーログについて解説していきます。サーバーログを見ることにより、何かしらのエラーが発生した時に過去の記録を確認することができます。Bubbleの中でエラーが起こった時のために今回の記事を是非参考にしてみてください。
概要
Bubbleにあるデバッガ機能は、現状の問題発生への理解に役立ちます。課題を再現する方法がわかれば、このツールを使うことができます。しかし、いくつかのケースでは、問題は過去のものとなります。例えば、支払いに関する問題を報告するユーザーがいる場合、請求書が送信されていない場合など、最初のステップは過去に何が起こったかを確認することです。これはパターンを特定するのに役立ち、再現する方法を見つけることにつながります（そしてその後にデバッガ機能を使用することになります）。
これがサーバーログ機能の目的です。これにより、サーバー上で発生したワークフローの過去の実行を確認することができます。Logsタブでサーバーログにアクセスできます。
サーバーログはアプリのバージョンに依存するため、問題が報告されたバージョン（ライブ版と開発版）を確認する必要があります。
ログ検索
ログを検索するには、検索の開始日と終了日を定義する必要があります。ログの検索には時間がかかることがあり、エディタはエントリーを表示します。すでにいくつかの結果が表示されていて、下にスクロールすると、エディタはより多くのエントリを取得します。そして、検索ボタンのキャプションは状況に応じて変化します。
アプリのトラフィックが多い場合は、ログがたくさん表示されます。
いくつかの検索条件を使って絞り込みを行うと便利です。
ログを検索するときに使用できる最も一般的な基準は、興味のあるイベントのタイプを選ぶことです。
・Workflow starts:条件が満たされてワークフローが実行されたかどうか、サーバー上で実行されている開始されたワークフローをすべて表示します。
・Passed events:条件が「yes」と評価された後に実行されたすべてのワークフローを表示します。
・Non-passed events: 条件が 「no」 と評価された後に実行されなかったすべてのワークフローを表示します。これは、何も起こらなかったことをデバッグしようとするときに便利です。
・Actions: アクションのみを表示し、このアクションの実行につながったイベントは表示しません。
・Errors:ワークフローの実行時に発生したサーバー側のエラーを表示します。例えば、クレジットカードの失敗やメール送信の失敗などです。これは特に問題の診断に役立ちます。
ログを検索する際に、問題のあるワークフローに関する情報があれば、特定のユーザーや用語で検索することで、さらに絞り込みが可能です。最初の入力では、ユーザーのメールやユーザー固有のIDを入力することができます。これを入力すると、このユーザーが開始したワークフローのみが検索されます。
最後のボックスには、検索する文字列を入力できます。アクションに何らかのテキストに評価されるプロパティがあり、このテキストを検索すると、ワークフローが検索されます。例えば、テキスト「Boston」を含むメールが送信されたことがわかっている場合、「Boston」を検索すると、メール送信アクションが返ってきます。
結果を見る
結果が取得されると、最近のイベントから順に結果エリアに表示されます。各エントリには、アクション/イベントの名前、EメールとユーザーのID(ユーザーがサインアップされていない場合、Eメールは’Anonymous user’となります)が表示され、右側にはこのアクション、イベントのプロパティの評価、またはエラーの場合はエラーメッセージが表示されます。アクション名（またはイベント）をクリックすると、このアクションが定義されているエディタの場所に移動します。
このワークフローのズームボタンは、現在のワークフローのイベント、アクション、 エラーのみを表示するのに便利な方法です。連続したアクションを見ることで、何が起こったのかを理解し、パターンを特定するのに役立ちます。
まとめ
今回の記事では、Bubbleにおけるサーバーログの一通りのやり方についてみていきました。サーバーログを確認することで、ワークフローのエラーの原因を特定できるのが強みになっています。このサーバーログとデバッガを活用して、Bubble内で発生したエラーを容易に対処していきましょう。
ここまでご覧頂き、ありがとうございました！！
