Limitations du connecteur Veeva Vault

info

Bêta

Cette fonctionnalité est en Bêta. Les administrateurs du Workspace peuvent contrôler l'accès à cette fonctionnalité à partir de la page Previews . Consultez Gérer les aperçus Databricks.

Le connecteur Veeva Vault présente les limitations suivantes.

Limitations générales

• Lorsque vous exécutez un pipeline planifié, les alertes ne se Trigger pas immédiatement. Au lieu de cela, ils Trigger lors de l’exécution de la prochaine mise à jour.
• Lorsqu’une table source est supprimée, la table de destination n’est pas automatiquement supprimée. Vous devez supprimer la table de destination manuellement. Ce comportement n'est pas cohérent avec le comportement de Spark Declarative Pipelines sur Lakeflow.
• Pendant les périodes de maintenance de la source, Databricks pourrait ne pas être en mesure d'accéder à vos données.
• Si un nom de table source entre en conflit avec un nom de table de destination existant, la mise à jour du pipeline échoue.
• La prise en charge des pipelines multi-destination est uniquement via l'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 qu'un pipeline a déjà start, le connecteur ne renseigne pas automatiquement les données historiques 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 sources différents.
• Le système source suppose que les colonnes du curseur augmentent de façon monotone.
• Le connecteur ingère des données brutes sans transformations. Utilisez les Spark Declarative Pipelines en aval sur les Lakeflow Pipelines pour les transformations.

Authentification

Seule l'authentification OAuth 2.0 de machine à machine (M2M) via un fournisseur d'identité OIDC externe (Microsoft Entra ID) est prise en charge. L'authentification par nom d'utilisateur et mot de passe n'est pas prise en charge.

Planification de pipeline

Veeva génère des archives incrémentielles toutes les 15 minutes. Les exécutions de pipeline planifiées plus fréquemment que toutes les 15 minutes ne voient pas de nouvelles données.

Rétention des archives

Veeva conserve les archives incrémentielles pendant 10 jours et les archives complètes pendant 2 jours. Si un pipeline prend plus de 10 jours de retard, la chaîne d'archives incrémentielle est rompue et un full refresh est requise.

Comportement de refresh complète

Lorsqu'un refresh complet est Trigger, le processus s'étend sur deux mises à jour du pipeline : la première mise à jour efface l'état d'archive intermédiaire du volume Unity Catalog, et le rechargement complet réel des données se produit lors de la mise à jour suivante.

Types de données de champ ID

id les champs sont toujours stockés comme le type STRING dans Databricks, quel que soit le type déclaré dans Veeva. Ceci est requis pour que la fonctionnalité de clé primaire de LakeFlow Pipelines fonctionne correctement.

Changements de schéma

Databricks recommande d'effectuer une full refresh après les modifications de schéma dans Veeva pour vous assurer qu'elles sont visibles dans vos tables de destination.

Le connecteur gère les changements de schéma comme suit :

• Suppression de champ : la colonne reste dans la table de destination, mais toutes les valeurs sont définies sur null et ne sont plus interrogeables.
• Renommage du champ : Les enregistrements existants sont découvrables sous l'ancien nom de champ. Les nouveaux enregistrements créés après le changement de nom apparaissent sous le nouveau nom de champ.
• Suppression d'objets : Les objets supprimés restent détectables dans le schéma.
• Renommage d'objet : l'ancien nom d'objet reste dans le schéma. Les nouveaux enregistrements ajoutés sous le nouveau nom d'objet apparaissent sous le nouveau nom de table.

Prise en charge des tables système

La version initiale prend en charge l'ingestion à partir d'un ensemble fixe de __sys tables :

• DOCUMENT_VERSION
• DOCUMENT_RELATIONSHIP
• PICKLIST
• WORKFLOW
• WORKFLOW_ITEM
• WORKFLOW_TASK
• WORKFLOW_TASK_ITEM
• ACTIVE_LEGACY_WORKFLOW
• ACTIVE_LEGACY_WORKFLOW_TASK
• INACTIVE_LEGACY_WORKFLOW
• INACTIVE_LEGACY_WORKFLOW_TASK

Les autres tables __sys ne sont pas ingérées dans cette version. Une version ultérieure étendra la prise en charge à toutes les tables système disponibles dans votre Vault. Après cette version, un full refresh sera nécessaire pour ingérer les tables nouvellement prises en charge.