Limitations du connecteur Oracle Eloqua

info

Bêta

Cette fonctionnalité est en version bêta. Pour l’utiliser, un administrateur du workspace doit activer Lakeflow Connect for Oracle Eloqua depuis la page Prévisualisations . Consultez Gérer les aperçus Databricks.

Le connecteur Oracle Eloqua géré dans Lakeflow Connect réingère cinq tables en entier à chaque exécution, ne capture pas les enregistrements supprimés des tables incrémentielles tant que vous n’exécutez pas un refresh complet, et peut manquer des activités qu’Oracle Eloqua enregistre tardivement.

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

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 déclenchent pas immédiatement. Au lieu de cela, ils 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 automatiquement supprimée. Vous devez supprimer la table de destination manuellement. Ce comportement n’est pas cohérent avec le comportement des Spark Declarative Pipelines sur Lakeflow.
• Pendant les périodes de maintenance de la source, Databricks risque de ne pas pouvoir accéder à vos données.
• Si le nom d’une table source entre en conflit avec le nom d’une table de destination existante, la mise à jour du pipeline échoue.
• La prise en charge des pipelines multi-destination n’est disponible que par API.
• Vous pouvez éventuellement renommer une table que vous ingérez. Si vous renommez une table dans votre pipeline, celui-ci devient un pipeline réservé à l’API et vous ne pourrez plus le modifier dans l’interface utilisateur.
• Si vous sélectionnez une colonne après le démarrage d’un pipeline, le connecteur ne complète pas automatiquement les données pour la nouvelle colonne. Pour ingérer des données historiques, exécutez manuellement une refresh complète 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 de curseur augmentent de façon monotone.
• Le connecteur ingère des données brutes sans transformation. Utilisez des Spark Declarative Pipelines en aval sur les LakeFlow Pipelines pour les Transformations.

Limitations spécifiques aux connecteurs

Les limitations de cette section s'appliquent au connecteur Oracle Eloqua.

• Attendez-vous à ce que chaque exécution de pipeline réingère intégralement les tables option_list, event_registration_registrant, custom_object, contact_list_contact et contact_segment. Ces tables ne prennent pas en charge l’ingestion incrémentielle. Par conséquent, chaque exécution lit tous leurs enregistrements à partir d’Oracle Eloqua, et les tables de destination reflètent les insertions, les mises à jour et les suppressions au moment de cette exécution.
• Exécuter une refresh complète d'une table incrémentielle pour supprimer les enregistrements supprimés dans Oracle Eloqua. Les tables incrémentielles capturent uniquement les enregistrements insérés et mis à jour. Les enregistrements supprimés restent donc dans la table de destination jusqu'au prochain refresh complet. Les activités d'un contact supprimé restent également dans les tables activity_* jusqu'à un refresh complet.

Tables d'activité

• Attendez-vous à ce que les activités arrivant en retard soient manquantes. Chaque synchronisation relit la dernière heure d'activités, ou le dernier jour pour activity_email_clickthrough, trois jours pour activity_external_activity, et sept jours pour activity_bounceback. Les activités qu'Oracle Eloqua enregistre plus tard que cela, y compris les activités externes antidatées de plus de trois jours, sont manquantes jusqu'à ce que vous effectuiez un refresh complet. Oracle Eloqua enregistre les retours avec des heures ou des jours de retard et ne documente pas de délai maximal.
• activity_bounceback ingère les activités jusqu’à une heure avant le start de chaque synchronisation, car Oracle Eloqua enregistre les rebonds de manière asynchrone. Les autres tables d’activités ingèrent les activités jusqu’au start de la synchronisation.
• Une table d’activité sans lignes relit tout son historique, jusqu’à start_datetime, à chaque synchronisation. Pour limiter les coûts, définissez un start_datetime récent.
• Oracle Eloqua renvoie au plus 5 000 000 d’enregistrements par exportation d’activité, et chaque exportation couvre 30 jours default. Si une table produit plus d’environ 160 000 enregistrements par jour, définissez un activity_window_step plus court pour cette table. Voir Options du connecteur.
• Dans activity_page_view et activity_web_visit, ContactId désigne le contact associé au visiteur au moment où l’activité a été enregistrée. Pour obtenir le contact actuel du visiteur, joignez VisitorId à la table visitor.

Tables d'appartenance aux listes de contacts et aux segments

• contact_list_contact ignore les listes de contacts vides. Il ignore également une liste dont le nombre de membres dans Oracle Eloqua n’a pas encore été mis à jour après l’ajout de membres, jusqu’à ce que le compte soit mis à jour.
• contact_segment exporte chaque segment à chaque synchronisation. Sa durée de synchronisation augmente donc avec le nombre de segments dans votre instance. Oracle Eloqua applique une limite souple de 2 000 exportations par heure à chaque instance. Planifiez donc contact_segment pour qu'il s'exécute quotidiennement et à une heure différente de contact_list_contact.
• Après une synchronisation, Oracle Eloqua bloque la suppression d'une liste de contacts ou d'un segment exporté pendant une durée allant jusqu'à deux heures.
• Si une liste de contacts ou un segment est supprimé pendant l’exécution d’une synchronisation, celle-ci échoue, et la synchronisation suivante rétablit la situation. Si Oracle Eloqua ne parvient pas à exporter un segment, la table contact_segment est en échec jusqu’à ce que vous corrigiez le segment dans Oracle Eloqua.