API Connectorの「returned_an_error」を使って、502 / 503 / 504 / 独自900エラーを後続処理につなぐ実装メモ
Makeから返したHTTPエラーをBubbleで受け取る方法
・Makeから返したHTTPエラーをBubbleで止めずに受け取る方法
・returned_an_error と error.status_code の使い分け
※この記事は、既存のBubble→Make連携を壊さずにエラー耐性を追加するために、実際にテスト環境を作って確認した内容をまとめています。
1. もともとの課題
BubbleからMakeのWebhookを呼び出し、Make側でCSVを分割してBubble Data APIへ登録する処理を長期間運用していました。通常時は問題ありませんが、
通信系の一時エラーが起きたときに
「どこで失敗したのか」
「Bubble側でどうリトライするか」が曖昧でした。
今回、特に整理したかったのは次の2系統です。
| 発生箇所 | エラー例 | 担当する処理 |
|---|---|---|
| Bubble → Make | 502 / 503 / 504、接続エラー | Bubble側で検知して再実行 |
| Make → Bubble Data API | 520など | Makeで検知し、Bubbleへ失敗を通知 |
2. まずはテスト用Makeシナリオを作る
本番のImport処理で意図的にエラーを発生させるのは危険なので、HTTPステータスだけを返すテスト用シナリオを別に作りました。
構成はシンプルです。
Webhookで status_code を受け取り、RouterのFilterで
- 200
- 502
- 503
- 504
- 520
へ分岐し、それぞれ対応するWebhook Responseを返します。
図1：Make側でHTTP 502を意図的に返すWebhook Response
ポイント
MakeのRouterと、各ルートにFilterを設定し、status_code = 502のときは、502用のルートだけが通るようにしました。
3. Bubble API Connectorでエラーを「止めずに」受け取る
BubbleのAPI Connectorでは、通常はHTTPエラーが返ると、その時点でWorkflowがエラー終了します。後続処理でリトライしたい場合は、API Connectorの設定で次を有効にします。
| Include errors in response and allow workflow actions to continue = ON |
これを有効にして再Initializeすると、レスポンスにエラー情報が追加され、Workflowの後続ステップから参照できるようになります。
図2：Makeから504を返したテスト。Bubble側で status_code=504 / Gateway Timeout を取得できた
テストでは、HTTP 504をMakeから返すとBubble側で次のように取得できました。
| returned_an_error = yes error.status_code = 504 error.status_message = Gateway Timeout |
また、Makeから独自にHTTP 900を返した場合でも、テスト環境では returned_an_error = yes になりました。
図3：独自900エラーでもBubble側では returned_an_error = yes
4. 判定は「status」より returned_an_error が分かりやすい
当初はレスポンスBodyに status を追加して、分岐する案も考えました。しかし、HTTPエラー時はBodyの status 自体が空になることがありました。一方、今回のテストではHTTPエラー時に returned_an_error = yes を安定して取得できました。
| おすすめの判定 正常：returned_an_error = no 異常：returned_an_error = yes 異常時だけ error.status_code / error.status_message をログや分岐に使う。 |
図4：Bubble Workflowから returned_an_error を参照できる
まとめ
Bubble × Make連携では、「エラーが起きたらMakeのシナリオが止まる」で終わらせず、Bubble側までエラー情報を戻して状態を管理すると運用がかなり安定します。特に今回のポイントは、Bubble API Connectorで returned_an_error を取得できるようにしたことです。
既存処理を大きく作り直さなくても、API Connectorの設定変更だけで、Bubble→Make接続障害のリトライを組み込めます。
一方、520のように「処理済みかどうかが分からない」エラーは、DB件数を確認してから再実行するなど、単純リトライとは分けて設計するのが安全ですので、ご注意ください。
■ システムエンハンスってどんな会社？
私たちは、最新のノーコード技術とアイデアでお客様の課題解決に取り組むITソリューション企業です。ノーコード開発を活用して、短期間・低コストでのシステム開発を実現しています。許諾の都合上、ご紹介できるのはごく一部ですが、私たちの開発事例をご覧ください。
これからも株式会社システムエンハンスをどうぞよろしくお願いいたします。
