Zendesk Supportコネクタの制限

一般的な制限

• スケジュールされたパイプラインを実行しても、アラートはすぐにはトリガーされません。代わりに、次の更新が実行されたときにトリガーされます。
• ソーステーブルを削除しても、宛先テーブルは自動的に削除されません。宛先テーブルを手動で削除する必要があります。この動作は、LakeflowでのSpark宣言型パイプラインの動作とは一致しません。
• ソースメンテナンス期間中、Databricks はデータにアクセスできない可能性があります。
• ソース テーブル名が既存の宛先テーブル名と競合する場合、パイプラインの更新は失敗します。
• 複数の宛先パイプラインのサポートは API のみです。
• オプションで、取り込むテーブルの名前を変更できます。パイプライン内のテーブルの名前を変更すると、そのパイプラインは API 専用となり、UI でパイプラインを編集できなくなります。
• パイプラインが既に開始された後に列を選択した場合、コネクタは新しい列のデータを自動的にバックフィルしません。履歴データを取り込むには、テーブルで完全な更新を手動で実行します。
• Databricks は、異なるソース スキーマからのものである場合でも、同じパイプラインに同じ名前を持つ 2 つ以上のテーブルを取り込むことはできません。
• ソース システムは、カーソル列が単調に増加すると想定します。
• コネクターは、変換なしで生データを取り込みます。変換のために、LakeFlow PipelinesでダウンストリームのSpark宣言型パイプラインを使用します。

サポートされているZendesk製品

Zendesk は、Zendesk Support、Zendesk Chat、Zendesk Talk など、さまざまな製品を提供しています。Databricks は、チケット データ、ナレッジ ベース コンテンツ、コミュニティ フォーラム データなど、Zendesk Support からの取り込みのみをサポートします。

API レート制限

Zendesk は、特に増分データ エンドポイントに対して、REST API にレート制限を適用します。一貫した取り込みパフォーマンスを確保するために、Databricks では、同時に取り込むテーブルの数を制限することをお勧めします。たとえば、テーブルを複数のパイプラインに分割し、異なる時間にスケジュールすることができます。

ネストされたフィールドとカスタムフィールド

スキーマ内の一部のフィールドは複雑な構造内にネストされている場合があり、内部レベルのフィールドにはカスタム属性を含めることができます。互換性と一貫性を確保するために、このようなフィールドは文字列データ型として表されます。たとえば、 ticketsテーブルのcustom_fields列はカスタム オブジェクトの配列であり、任意の数のサブフィールドを持つことができます。

監査レコードは作成後に変更される場合があります。

Zendesk はチケットの監査レコードを不変として文書化していますが、監査が最初に作成された後も、監査内のいくつかのフィールドは変更され続ける可能性があります。例えば、ticket_audits テーブルの ChatStartedEvent イベントにおけるチャットトランスクリプトは、会話の後続のメッセージが追加されるにつれて、監査の created_at タイムスタンプから数分間増え続ける可能性があります。

コネクタはcreated_atカーソルを使用してticket_auditsテーブルを増分的に取り込むため、各監査を一度だけ読み込み、再度読み込むことはありません。コネクタが監査を取り込んだ後にフィールドが変更された場合、ターゲットテーブルは取り込み時に存在した値を保持し、後続の更新は反映されません。コネクタは、読み取り時にZendesk APIによって返された正確なデータを保持するため、エラーを発生させません。

影響を受けるレコードの現在の値を取得するには、ticket_auditsテーブルのフル更新を実行します。