コネクタ構成

コネクタ構成はウィザードフェーズの最初の必須ステップです。これにより、実際のソースシステムとドメインに関係なく、コネクタがすべてのコネクタタイプ間で共通のオブジェクトの構成を持つことが保証されます。 PUBLIC.CONFIGURE_CONNECTOR(config VARIANT) と呼ばれるプロシージャは、これを実行するための UI またはワークシートからのエントリポイントです。カスタムロジックで上書きする場合、このプロシージャはJavaの ConfigureConnectorHandler.configureConnector 静的メソッドをハンドラーとして指しているため、置き換える必要があることに注意してください。

このプロシージャを呼び出すには、ユーザーに ADMIN アプリケーションロールが割り当てられている必要があります。

コネクタ構成ステップは、内部的にいくつかのフェーズで構成されます。一部は完全にカスタマイズ可能で、デフォルトでは何も実行されません。フェーズは次のとおりです。

  1. ステータスの検証

  2. フィールドの検証

  3. 入力の検証

  4. 設定の更新

  5. 内部コールバック

  6. ステータスの更新

要件

コネクタ構成では、ネイティブアプリのインストール中に少なくとも次の SQL ファイルを実行する必要があります。

  • core.sql

  • configuration/app_config.sql

  • configuration/connector_configuration.sql

ステータスの検証

コネクタ構成を実行するには、コネクタの内部ステータスが CONFIGURING である必要があります。この検証は、 ConfigureConnectorHandlerBuilder を使用しても、ストアドプロシージャを上書きしても上書きできません。ただし、この種の検証を実行しないカスタムハンドラーを実装することはできます。

フィールドの検証

コネクタ構成には、特定のフィールドのセットが含まれている必要があります。これらはすべてオプションですが、その他のフィールドを指定すると例外がスローされます。許可されるキーは次のとおりです。

  • warehouse

  • destination_database

  • destination_schema

  • operational_warehouse

  • global_schedule

  • data_owner_role

  • agent_username

  • agent_role

ウェアハウス

ウェアハウスは、コネクタによってスケジューラの実行、タスクの実行、およびクエリの実行に使用されます。

Destination_database

宛先データベースは、コネクタによって取り込まれたデータを保存するために使用されます。このデータベースはコネクタの外部にある必要があります。既存のデータベースでも構いませんが、コネクタにはそのデータベースに対する書き込み権限が必要です。新しく作成されたデータベースにすることもできますが、これは自動的には行われず、コネクタの構成または構成の最終処理中に内部コールバックの一部として実装する必要があります。

Destination_schema

宛先スキーマは、上記のdestination_databaseで使用されるスキーマになります。

Operational_warehouse

場合によっては、コネクタは、ウェアハウスを必要とする実際の取り込みプロセスを、コネクタの内部操作に関連するプロセスから分割する必要があります。この2つ目のウェアハウスを指定することで、負荷を分割できます。

Global_schedule

このプロパティは、スケジューラタスクの実行スケジュールを定義します。現在、スケジューラは独自の scheduleType=GLOBAL を持つリソースのみを処理します。このプロパティの値は、次のようになります。

"global_schedule": {
    "scheduleType": "CRON",
    "scheduleDefinition": "*/10 * * * *"
}
Copy

Data_owner_role

コネクタのアンインストール時にデータを保持するための同期データベースの所有権を付与するために使用できるロール。

Agent_username

Snowflakeに接続するときにプッシュベースのコネクタのエージェントによって使用されるユーザー名。

Agent_role

Snowflakeに接続するときにプッシュベースのコネクタのエージェントによって使用されるロール。

入力の検証

入力は有効な Variant である必要があります。さらに、 SDK は PUBLIC.CONFIGURE_CONNECTOR_VALIDATE(config VARIANT) という内部ストアドプロシージャを提供します。デフォルトでは、このプロシージャは 'response_code': 'OK' を返すだけですが、このストアドプロシージャを上書きすることで変更できます。あるいは、 ConfigureConnectorHandlerBuilder を使用してカスタマイズし、 ConfigureConnectorValidator インターフェイスのカスタム実装を提供することもできます。

設定の更新

検証が正常に完了すると、構成は内部の APP_CONFIG テーブルに保存されます。これを担当するサービスは、提供された Variant を connector_configuration キーの下に保存します。

内部コールバック

内部コールバックは、もう1つのカスタマイズ可能なステップです。デフォルトでは、 PUBLIC.CONFIGURE_CONNECTOR_INTERNAL(config VARIANT) を呼び出し、 'response_code': 'OK' を返します。SQL スクリプトを通じて上書きすることも、 ConfigureConnectorHandlerBuilder を使用して ConfigureConnectorCallback インターフェイスのカスタム実装を提供することもできます。

ステータスの更新

上記のすべてのフェーズが正常に完了すると、コネクタの内部ステータスが次のように更新されます。

{
    "status": "CONFIGURING",
    "configurationStatus": "CONFIGURED"
}
Copy

状態遷移図については、 コネクタフロー をご参照ください。

応答

正常な応答

プロシージャが正常に終了すると、次の形式で応答が返されます。

{
  "response_code": "OK",
}
Copy

エラーの応答

エラーが発生した場合、応答は以下の形式になります。

{
  "response_code": "<ERROR_CODE>",
  "message": "<error message>"
}
Copy

考えられるエラーコードは次のとおりです。

  • INVALID_CONNECTOR_STATUS - すでに構成されているコネクタでプロシージャが呼び出されました

  • CONNECTOR_CONFIGURATION_PARSING_ERROR - 指定された構成は有効な JSON ではありません

  • CONNECTOR_STATUS_NOT_FOUND - コネクタのステータス記録がデータベースに存在しません

  • CONNECTOR_STATUS_PARSING_ERROR - connector_status キーのテーブル APP_STATE に格納されている値の形式が正しくないため、アプリケーションで解析できません

言語: 日本語