複雑な構造もオフセットとして使用することができます。スキーマの追跡ができる保証はないため、スキーマなしにする必要があります。これにより、コネクター開発者にとっては、信頼性の高いオフセットの解析を実現するのが少し難しくなりますが、シリアル化フォーマットの選択の柔軟性が高くなります。入力パーティションごとに多数のキーを読み取ることが必要な場合もあります。つになるのは、このようにシンプルなコネクターの場合のみです。インターフェイスでは、一括読み取りを実行して、すべてのオフセットを効率的に読み込み、適切な位置まで各入力パーティションをシークして、そのオフセットを適用することもできます。コネクターのメトリクス¶カスタムコネクターを開発する場合、コネクターのコードでアップデートを行う必要はありません。フレームワークによって収集されエクスポートされます。メトリクスの収集を参照してください。メトリクスの詳細については、以下のドキュメントも参照してください。多数のジョブを作成して各テーブルを個別にコピーするのではなく、データベース全体をコピーするなど、データを一括でコピーするジョブを定義するためのものです。このような設計になっているため、コネクター用の一連の入力パーティションまたは出力パーティションが時間の経過とともに変化する可能性があります。ソースコネクターは、データベース内のテーブルの追加や削除など、変更の有無についてソースシステムをモニタリングする必要があります。オブジェクトを介してフレームワークに通知する必要があります。this.context.requestTaskReconfiguration();}フレームワークは即座に新しい構成情報をリクエストしてタスクを更新し、タスクの再構成を行う前に、タスクが進捗情報を正常にコミットできるようにします。現時点ではこのモニタリングはコネクターの実装に依存することに注意してください。このモニタリングを実行するためのスレッドが必要な場合、コネクターがそのスレッドの割り当てを行う必要があります。内でのみ処理され、タスク側ではモニタリングについて何も行う必要がないのが理想です。つが破棄された場合、変更によりタスクにも影響が及ぶ可能性があります。処理を行う必要があります。これは通常、適切な例外をキャッチして処理することで、シンプルに対処できます。通常、パーティションの追加についてのみ対応する必要があります。追加されたパーティションは出力の新しいエントリに変換できます。入力に対するすべての変更を管理します。新しい入力パーティションを受け付ける必要があり、それにより、ダウンストリームシステムで新しいリソースの作成が必要になることがあります(データベース内に新しいテーブルを作成するなど)。新しい入力パーティションを初めて認識し、同時に新しいリソースの作成を試行したことにより競合が発生した場合でしょう。場合は通常、動的な一連のパーティションに対応するために特別なコードは必要ありません。実行するためにコネクターを送信する前に、コネクターの構成を検証することができ、エラーに関するフィードバックおよび推奨値を確認できます。実装して、構成の定義をフレームワークに公開する必要があります。以下のコードで構成を定義し、その構成の定義をフレームワークに公開します。クラスを使用して、想定される一連の構成を指定します。表示用の名前を指定できます。クラスをオーバーライドすることにより、単一の構成の検証に使用される特別な検証ロジックを提供できます。構成と構成の間に依存関係が存在する場合があるため、他の構成の値に従って、たとえば、有効な値や構成の可視性が変更される可能性があります。実装して、有効な値の取得や、現在の構成値に基づく構成の可視性の設定を行うことができます。メソッドでは、デフォルトの検証が実装されています。この実装では、許可されている構成のリストが、構成エラーおよび各構成の推奨値とともに返されます。構成の検証には、推奨値は使用されません。デフォルトの実装のオーバーライドを提供して、構成の検証をカスタマイズし、推奨値を使用することができます。コネクターは、シンプルでありながら、明確な構造を持つデータも含まれているため(各行は単なる文字列です)、例として優れています。すべてのコネクターで、より複雑なデータフォーマットを持つスキーマが必要になるでしょう。使用する必要があります。つのクラスとのやり取りが必要になります。ドキュメントを参照してください。作成に関する簡単な例を紹介します。.build();ソースコネクターを実装している場合、いつ、どのようにスキーマを作成するかを決定する必要があります。可能な限り、スキーマの再計算は避ける必要があります。つのインスタンスを再利用します。多くのコネクターでは動的なスキーマが使用されます。一例としてデータベースコネクターが挙げられます。つのテーブルに対してスキーマが固定ということはありません。作成して、適切に対応できる必要があります。シンクコネクターは通常、よりシンプルです。シンクコネクターはデータを消費する側であり、スキーマを作成する必要はないためです。受け取ったスキーマが想定されているフォーマットであることを検証する必要はあります。フレームワークに通知する必要があります。そのため、新しいスキーマは送信先トピックの互換性要件を満たす必要があります。使用して値をプロジェクションすることができます。互換性のないスキーマが与えられた場合は例外がスローされます。プロジェクションする方法を示しています。いう値が設定されます。これは、このフィールドのデフォルト値です。target);このユーティリティは、コネクターでスキーマの進化に対応し、スキーマの互換性を維持する必要がある場合に役立ちます。書き込まれる前に、古いスキーマが使用されているメッセージをコネクターで認識された最新のスキーマにプロジェクションする必要があります。書き込まれる最新のファイルでは最新のスキーマが使用されます。最新のスキーマは、すべてのデータのクエリに使用することができ、後方互換性が維持されます。スキーマの互換性の詳細については、「データのシリアル化とスキーマの進化」セクションを参照してください。テスト¶コネクターのテストには困難が伴う場合があります。コネクターの接続先システム)とやり取りしますが、それらのシステムはモックの作成が難しい場合があるためです。記述したくなることもあるでしょう。外部サービスのモックを作成する際には、コネクタークラスとタスククラスの機能をそれぞれ別々にテストする方法が優れています。十分な単体テストが完了してから、別途、統合テストを追加して、エンドツーエンドの機能を検証することをお勧めします。mechanism.コネクターをパッケージ化して、他のユーザーが使用できるように配布することを計画している場合、作成したコードの使用許諾および著作権保護を適切に行い、コードで使用するライブラリおよびディストリビューションに含めるライブラリのすべてについて使用許諾と著作権を遵守する義務があります。アーカイブを作成する方法です。アーカイブには、他のコネクターの実装に対して一意の名前を持つ単一のディレクトリを含める必要があります。そのため、多くの場合は、コネクターの名前とバージョンを含めます。ファイルおよびその他のリソースファイルはすべて、トップレベルディレクトリ内に配置する必要があります。ランタイムライブラリを含めないようにする必要があることに注意してください。作成する方法があります。ディレクトリの内部構造は不要です。新しいコネクターの開発を歓迎しています。貢献」を参照してください。FoundationFeedbackこのページの内容:。