Oktaコネクタの制限

備考

ベータ版

この機能はベータ版です。使用するには、ワークスペース管理者は プレビュー ページから Lakeflow Connect for Okta を有効にする必要があります。Databricksのプレビューを管理するを参照してください。

Lakeflow Connect のマネージド Okta コネクタは、完全更新が行われるまで増分テーブルに削除済みレコードを保持し、default では最初の同期で前回の 365 日間の変更のみをインジェストし、グループのメンバーシップが変更された場合にのみグループメンバーシップデータを更新します。

一般的な ソフトウェア as a サービス（SaaS）コネクタの制限事項

このセクションの制限事項は、Lakeflowコネクト のすべてのSaaS コネクタに適用されます。

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

コネクタ固有の制限事項

このセクションの制限事項はOktaコネクタに適用されます。

• Okta は削除を報告しないため、完全更新を実行するまで、削除されたレコードは users、groups、devices、group_members、および group_push_mappings テーブルに残ります。完全更新テーブルは、次の同期で削除されたレコードを削除します。
• defaultでは、各インクリメンタルテーブルの最初の同期では、過去 365 日間に変更されたレコードのみが取り込まれます。最近変更されていないレコードを取り込むには、start_datetime を設定します。詳細については、コネクタのオプションをご覧ください。
• group_membersテーブルは、グループのメンバーシップが変更されたときにのみグループのメンバーを再読み込みするため、そのメンバープロファイルの値が古くなる可能性があります。現在のユーザープロファイルおよびステータス値については、usersテーブルを使用してください。
• Oktaはメンバーシップ、アプリ割り当て、グループプッシュマッピング、管理者ロールの変更をグループの変更として扱わないため、groupsテーブルの_embedded列のグループ統計が古くなっている可能性があります。それらを更新するには、完全更新をランします。
• policies テーブルと policy_rules テーブルには、Okta組織で有効になっているポリシータイプのみが含まれます。コネクタは、組織が保持していない機能を必要とするポリシータイプをスキップします。
• user_factors テーブルには、各ユーザーの最優先認証システム登録ポリシーで必須またはオプションとして設定されている登録済み要素のみが含まれます。すべての登録を表示するには、user_authenticator_enrollments テーブルを使用します。
• コネクタは Okta システムログイベントを取り込みません。代わりに Okta System Logs コネクタ を使用してください。