Limitations du connecteur Zendesk Support

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.

Produits Zendesk pris en charge

Zendesk propose une variété de produits, y compris l’aide Zendesk, Zendesk Chat, Zendesk Talk et d’autres. Databricks prend en charge l’ingestion uniquement à partir de l’aide Zendesk, y compris les données de tickets, le contenu de la base de connaissances et les données de forums de la Communauté.

Limites de débit de l'API

Zendesk applique des limites de taux à son API REST, en particulier pour les Endpoint de données incrémentielles. Pour garantir des performances d'ingestion cohérentes, Databricks recommande de limiter le nombre de tables que vous ingérez simultanément. Par exemple, vous pouvez répartir les tables sur plusieurs pipelines et les planifier à des moments différents.

Champs imbriqués et personnalisés

Certains champs du schéma peuvent être imbriqués dans des structures complexes, et les champs de niveau interne peuvent inclure des attributs personnalisés. Pour garantir la compatibilité et la cohérence, ces champs sont représentés comme un type de données chaîne. Par exemple, la colonne custom_fields de la table tickets est un tableau d’objets personnalisés, qui peut avoir un nombre illimité de sous-champs.

Les enregistrements d'audit peuvent changer après la création.

Zendesk documente les enregistrements d'audit de tickets comme immuables, mais certains champs d'un audit peuvent continuer de changer après sa création initiale. Par exemple, l’historique de discussion de l’événement ChatStartedEvent de la table ticket_audits peut continuer de croître pendant plusieurs minutes après le Timestamp created_at de l’audit, à mesure que des messages ultérieurs sont ajoutés à la conversation.

Puisque le connecteur ingère la table ticket_audits de manière incrémentielle à l'aide du curseur created_at, il lit chaque audit une seule fois et ne le revisite pas. Si un champ change après l'ingestion de l'audit par le connecteur, la table cible conserve la valeur présente au moment de l'ingestion et ne reflète pas la mise à jour ultérieure. Le connecteur ne signale aucune erreur, car il conserve les données exactes renvoyées par l'API Zendesk au moment de la lecture.

Pour obtenir les valeurs actuelles des enregistrements concernés, exécutez un refresh complet de la table ticket_audits.