Limitations du connecteur Rapports Workday

Cette page répertorie les limites et les considérations relatives à l'ingestion de rapports Workday à l'aide de Databricks Lakeflow Connect.

Limitations générales des connecteurs SaaS

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

• 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

• Databricks recommande d’utiliser un utilisateur système intégré (ISU) Workday, mais ce n’est pas obligatoire.
• Généralement, un jeton refresh est créé au nom d'un ISU. Vous pouvez choisir d'autoriser l'expiration du jeton refresh :
  • Si vous définissez une date d’expiration, vous devez modifier la connexion lorsque vous atteignez cette date.
  • Si vous ne définissez pas de date d'expiration, le jeton refresh ne peut expirer que si votre organisation réduit le niveau d'accès de l'ISU associé au jeton.

pipeline

• Le connecteur peut uniquement ingérer des rapports de moins de 2 Go de données ou de moins de 1 M d’enregistrements. Les limites de l’API Workday de votre organisation pourraient être inférieures à cela.
• L'ingestion incrémentielle est en Bêta et requiert une clé principale. Si vous configurez une clé principale pour un rapport, le connecteur ingère uniquement les lignes qui ont changé depuis la dernière exécution du pipeline. Si vous ne configurez pas de clé principale, le connecteur refresh entièrement le rapport à chaque exécution du pipeline.
• Le connecteur ne peut pas importer des rapports avec des clés primaires en double.

Ingestion incrémentielle

Les limitations suivantes s'appliquent à l'ingestion incrémentielle, qui est en version bêta.

• La colonne de curseur doit augmenter de façon monotone à chaque nouvelle ligne ou ligne mise à jour. Les lignes dont la valeur du curseur est supérieure à la dernière valeur de curseur ingérée sont ingérées (insertions et mises à jour de l'avancement du curseur). Les lignes supprimées ne sont jamais ingérées.
• La colonne de curseur doit être une colonne de date. Les autres types de curseurs ne sont pas pris en charge.
• Les invites des rapports Workday utilisées pour l'ingestion incrémentale doivent être inclusives (supérieur ou égal à / inférieur ou égal à). L'utilisation d'invites exclusives (supérieur à / inférieur à) peut entraîner des données manquantes. C'est un paramètre que le propriétaire du rapport sélectionne lorsqu'il crée le rapport et ses invites dans Workday.
• Lorsque vous utilisez current_date() dans une valeur d'invite, Databricks l'évalue comme la date UTC au moment où le pipeline start. Cependant, Workday interprète la date en fonction du fuseau horaire de vos paramètres de compte Workday.