Limitations du connecteur Okta

info

Bêta

Cette fonctionnalité est en Bêta. Pour l’utiliser, un administrateur du workspace doit activer Lakeflow Connect for Okta sur la page Aperçus . Consultez Gérer les aperçus Databricks.

Le connecteur Okta géré dans Lakeflow Connect conserve les enregistrements supprimés dans les tables incrémentielles jusqu’à un refresh complet, n’ingère par default que les modifications des 365 derniers jours lors de la première synchronisation, et ne fait un refresh des données d’appartenance aux groupes que lorsque l’appartenance d’un groupe change.

Limitations générales des connecteurs SaaS (outil/solution/technologie/plateforme as a Service)

Les limites de cette section s'appliquent à tous les connecteurs SaaS dans Lakeflow Connect.

• Lorsque vous exécutez un pipeline planifié, les alertes ne Trigger pas immédiatement. Au lieu de cela, elles Trigger lors de la prochaine exécution de la mise à jour.
• Lorsqu'une table source est supprimée, la table de destination n'est pas supprimée automatiquement. Vous devez supprimer manuellement la table de destination. Ce comportement n'est pas conforme au comportement des Spark Declarative Pipelines sur Lakeflow.
• Pendant les périodes de maintenance de la source, Databricks peut ne pas être en mesure d'accéder à vos données.
• Si un nom de table source est en conflit avec un nom de table de destination existant, la mise à jour du pipeline échoue.
• La prise en charge des pipelines à destinations multiples est uniquement disponible par API.
• Vous pouvez éventuellement renommer une table que vous ingérez. Si vous renommez une table dans votre pipeline, il devient un pipeline API uniquement, et vous ne pouvez plus modifier le pipeline dans l'interface utilisateur.
• Si vous sélectionnez une colonne après le start d’un pipeline, le connecteur ne remplit pas automatiquement les données pour la nouvelle colonne. Pour ingérer des données historiques, exécutez manuellement un refresh complet sur la table.
• Databricks ne peut pas ingérer deux tables ou plus portant le même nom dans le même pipeline, même si elles proviennent de schémas source différents.
• Le système source suppose que les colonnes de curseur augmentent de manière monotone.
• Le connecteur ingère des données brutes sans transformations. Utilisez des Spark Declarative Pipelines en aval sur des LakeFlow Pipelines pour les Transformations.

Limites spécifiques aux connecteurs

Les limitations décrites dans cette section s’appliquent au connecteur Okta.

• Okta ne rapporte pas les suppressions, donc les enregistrements supprimés restent dans les tables users, groups, devices, group_members et group_push_mappings jusqu'à ce que vous exécutiez un full refresh. Les tables en full-refresh suppriment les enregistrements supprimés lors de la prochaine synchronisation.
• Par default, la première synchronisation de chaque table incrémentielle n’ingère que les enregistrements modifiés au cours des 365 derniers jours. Pour ingérer des enregistrements qui n’ont pas été modifiés récemment, définissez start_datetime. Consultez les options du connecteur.
• La table group_members ne relit les membres d’un groupe que lorsque l’appartenance à ce groupe change ; les valeurs du profil des membres peuvent donc être obsolètes. Pour les valeurs actuelles du profil et du statut de l’utilisateur, utilisez la table users.
• Okta ne traite pas les modifications d'appartenance, d'attribution d'application, de mappage de poussée de groupe ou de rôle d'administrateur comme des modifications de groupe. Par conséquent, les statistiques de groupe dans la colonne _embedded de la table groups peuvent être obsolètes. Pour les mettre à jour, exécutez un refresh complet.
• Les tables policies et policy_rules ne contiennent que les types de politique que votre organisation Okta a activés. Le connecteur ignore les types de politique qui nécessitent une fonctionnalité que votre organisation n'a pas.
• La table user_factors contient uniquement les facteurs inscrits qui sont requis ou optionnels dans la politique d'inscription de l'authentificateur de plus haute priorité pour chaque utilisateur. Pour voir chaque inscription, utilisez la table user_authenticator_enrollments.
• Le connecteur n’ingère pas les événements du journal système Okta. Utilisez plutôt le connecteur de système Logs Okta.