こんにちは。CData Software Japan の齋藤です。
CData Arc は、CData 製品の中で「自動化/Automate」を担うデータ連携ツールです。「B2B 連携をもっとシンプルに」をコンセプトに、ファイル連携 & DB 連携 & API 連携といったB2B 連携に必要なすべてをノーコード・ローコードでつなぐことができるプラットフォームです。
Arc ではビルディングブロックとして用意された豊富なコネクタ同士を接続することで、データ処理フローを構築することができます。そのため、運用中のフロー内でエラーが発生した際に、コネクタによる無制限の自動受信/送信を防止する「バックオフ機能」という安全メカニズムが実装されています。
バックオフ機能の概要
コネクタが3回連続してファイルの受送信に失敗した場合に、コネクタの自動化を一時停止する機能です。コネクタがバックオフ状態になると、自動化を介したファイル受送信を再試行する前に、60分の遅延が追加されます。追加された60分の遅延後にそのコネクタが再度受送信に失敗した場合には、さらに、120分の遅延を追加します。受送信失敗と遅延追加を繰り返した場合の最大遅延は12時間です。また、これらの遅延時間の間にユーザーがコネクタ内で発生している問題を修正することが推奨されています。
バックオフ機能実装の背景
過去にはコネクタが継続的に失敗している場合でもファイルの受送信を試みていましたが、多くの場合、大量のログとデータベースエントリが発生していました。さらに、この状態を放置していると、時間の経過とともにアプリケーションの速度の低下を招く恐れがありました。そこで、コネクタのバックオフ機能を実装することにより、以下の3つのメリットが実現されました。
バックオフの発生から解除までを体験
この章では、実際のフローを使い、意図的にバックオフを発生させてみます。また、受信/送信オートメーションの両方でコネクタがバックオフ状態になった際の画面表示を確認した後、バックオフ状態を解除させるまでの一連の流れをご紹介します。今回は以下のフローを使用し、実験を行います。
送信オートメーション失敗によるバックオフ
中間のCSV コネクタでは送信オートメーションが有効化されています。
ここでは、当コネクタに意図的に送信エラーを発生させるため、手動で不正なXML ファイルを繰り返しアップロードします。
計7回、invalid.xmlというファイルをアップロードしました。コネクタの送信ステータス（画像左側）を見ると、グレーのファイルアイコンの横に「7」と表示されています。さらに、インプットの詳細（画像右側）を確認すると、ステータスが「Unsent」の内訳は古いものから：
Unsent (試行回数：1)が3つ
Unsentが4つ
以上のことから、3度目の送信失敗以降は、未試行のファイルが滞留していくことがわかります。
ここで、アクティビティページのアプリケーションタブを確認すると、該当コネクタのエラーが3つ続いた後に、以下の要点を含むメッセージが表示されています。
The [Workspace_Playground:CSV_CDataJapanSample] connector has failed more than 3 times and has entered a backoff state. The automation service will skip this connector until 2025-09-12T17:19:26+09:00. The connector will remain in the backoff state until a message is successfully sent manually, the connector settings change, or all messages are sent successfully during an automated send attempt.
受信オートメーション失敗によるバックオフ
受信オートメーションは「コネクタが指定されたスケジュール間隔に従って、コネクタ（及び後続のフロー）に自動でファイルをインプットする処理」を担う機能です。今回、始点のPostgreSQL コネクタではエラーを発生させるための前提条件として、不正なSQLを実行するよう設定してあります。また、受信オートメーション機能は以下の設定で有効化してあります。
1分間隔でフローが自動的に処理を開始しましたが、3回目のエラー以降は1分以上待機してもアウトプットが生成されませんでした。以上のことから、3回目のエラー以降は自動受信処理を停止したことがわかります。
アプリケーションタブでは以下の画像のようなPostgreSQL_CDataJapanSample がバックオフ状態になった旨のメッセージが確認できます。
The [Workspace_Playground:PostgreSQL_CDataJapanSample] connector has failed more than 3 times and has entered a backoff state. The automation service will skip this connector until 2025-09-12T17:50:39+09:00. The connector will remain in the backoff state until a message is successfully sent manually, the connector settings change, or all messages are sent successfully during an automated send attempt.
ご参考までに、これらのバックオフに関する情報の出力先はアプリケーションログとなります。アプリケーションログをはじめとする各種ログの詳細については以下のブログ記事をご参考ください。
CData Arc のログファイル
バックオフ状態の解除
コネクタのバックオフ状態を解除するためには、以下の3つのうち、いずれか1つの操作が必要です。
手動でのファイル送信の成功
自動でのファイル送信の成功
バックオフ状態のコネクタ設定の保存
以降では、送信オートメーション失敗によるバックオフ状態のCSV コネクタは1の方法で、受信オートメーション失敗によるバックオフ状態であるPostgreSQL コネクタは3の方法で解除してみます。
送信オートメーション失敗後
CSV コネクタのバックオフ状態を解除するため、修正したXML ファイル(valid.xml)をアップロードしました。しかし、このコネクタは依然としてバックオフ状態であったため、アップロードしただけではステータスが「Unsent」のままでした。そこで、valid.xmlの行にチェックを付けた後、[送信]ボタンをクリックしました。
送信成功の通知が表示されました。また、valid.xmlの送信成功以後のトランザクションが立て続けに4回エラーとなっており、送信ファイル名はinvalid.xmlと表示されています（画像右側）。以上のことから、当コネクタが手動でのファイル送信成功によりバックオフ状態から回復し、それまで未試行のまま滞留していた「Unsent」ステータスのファイルが自動的に送信されたことがわかります。
結果として、再び送信オートメーションで3回以上の送信失敗が発生しました。しかし、今回はバックオフ状態になることはありませんでした。
受信オートメーション失敗後
PostgreSQL コネクタのバックオフ状態を解除するため、[保存]ボタンをクリックしました。ここでは意図的にSQLの修正は行っていません。
再び受信オートメーションが1分毎に起動するようになりました。ただし、SQL自体の修正を行っていないため3度目のエラー以降は受信オートメーションが停止しました。
アプリケーションタブを確認すると、再びバックオフ状態になったことが確認できます。
おわりに
この記事では、実際の挙動を交えてCData Arc のコネクタのバックオフ機能をご紹介しました。CData Arc のバックオフ機能については、こちらのコミュニティポストなども参考にしていただけます。
実際にフローを作成・実行する中で、意図しない形でフローのスケジュール起動しない場合や、Unsentのファイルが滞留する場合は、アプリケーションログを確認してバックオフ状態になっていないかご確認ください。
CData Arc はシンプルで拡張性の高いコアフレームワークに、豊富なMFT・EDI・エンタープライズコネクタを備えたパワフルな製品です。CData Drivers との組み合わせで275を超えるアプリケーションへの連携を実現できます。
皆さんのつなぎたいシナリオでぜひ CData Arc を試してみてください。
CData Arc | データ連携、EAI、マネージドファイル転送（MFT）、電子データ交換（EDI）のオールインワンツール
製品を試していただく中で何かご不明な点があれば、テクニカルサポートへお気軽にお問い合わせください。
CData - サポートフォーム
この記事では CData Arc™ 2025 - 25.2.9376.0 を利用しています。
