Résoudre les problèmes d'ingestion de Microsoft Dynamics 365

Cette page fournit des conseils de dépannage pour les problèmes courants liés au connecteur Microsoft Dynamics 365 dans Lakeflow Connect.

Problèmes Azure Synapse Link

Synapse Link n'exporte pas de données

Symptômes :

• Aucun dossier n'apparaît dans votre conteneur ADLS Gen2 après avoir configuré Synapse Link.
• Les horodatages des dossiers arrêtent de se mettre à jour.
• Les exécutions de pipeline échouent avec les erreurs « Aucune donnée trouvée ».

Causes possibles :

• La connexion Synapse Link est mise en pause ou arrêtée.
• Les autorisations du compte de stockage Azure sont incorrectes.
• Les tables sélectionnées ne sont pas configurées pour l'exportation.
• Synapse Link a rencontré une erreur lors de l'exportation.

Solutions:

1. Vérifier l'état de Synapse Link :

   • Connectez-vous à Power Apps.
   • Accédez à **Azure Synapse Link** dans votre environnement.
   • Vérifiez que votre connexion affiche le statut « Active ».
   • Si l'exportation est suspendue, sélectionnez Reprendre pour la redémarrer.

2. Vérifier les autorisations de stockage :

   • Dans le portail Azure, naviguez jusqu'à votre compte de stockage.
   • Sélectionner **Contrôle d'accès (IAM)**.
   • Vérifiez que l'identité managée Synapse Link a le rôle Contributeur aux données Blob du stockage .
   • Si manquant, veuillez ajouter l'attribution de rôle.

3. Vérifiez la configuration de la table :

   • Dans Power Apps, sélectionnez votre connexion Synapse Link.
   • Consultez la liste des tables sélectionnées.
   • Vérifiez que les tables que vous souhaitez ingérer sont incluses.
   • Ajouter les tables manquantes et attendre l'export initial (5 à 15 minutes).

4. Consultez les logs Synapse Link :

   • Dans Power Apps, sélectionnez votre connexion Synapse Link.
   • Sélectionnez Afficher les Logs ou Historique .
   • Recherchez les messages d'erreur indiquant des échecs d'exportation.
   • Corrigez les erreurs spécifiques (par exemple, quota de stockage, autorisations).

Erreur FILE_PATH_DOES_NOT_EXIST

Symptômes :

• Les exécutions de pipeline échouent avec l'erreur FILE_PATH_DOES_NOT_EXIST.
• Le connecteur ne peut pas trouver les fichiers attendus dans ADLS Gen2.
• L'erreur indique des dossiers ou des chemins de fichiers manquants.

Causes possibles :

• L’option **Activer la structure de dossier de mise à jour incrémentielle** n’est pas activée dans la configuration Synapse Link.
• Le connecteur attend une structure de dossiers spécifique qui n'existe pas.

Solutions:

1. Activer la structure de dossiers de mise à jour incrémentielle :

   • Dans Power Apps, modifiez votre connexion Synapse Link.
   • Sélectionnez **Avancé** pour afficher les paramètres de configuration avancés.
   • Basculez **Activer la structure de dossier de mise à jour incrémentielle** pour l'activer.
   • Enregistrez la configuration.
   • Attendez que Synapse Link régénère la structure des dossiers (cela peut prendre plusieurs heures pour les grands datasets).

2. Vérifier la structure des dossiers :

   • Dans le portail Azure, accédez à votre compte de stockage ADLS Gen2 et à votre conteneur.
   • Vérifiez que les dossiers de table contiennent désormais des sous-dossiers horodatés (par exemple, 2025-12-19T10-30-00-000Z).
   • Ces dossiers Timestamp contiennent les mises à jour incrémentielles dont le connecteur a besoin.

3. Réessayez le pipeline :

   • Après avoir activé la structure de dossier incrémentielle, exécutez votre pipeline à nouveau.
   • Le connecteur devrait maintenant trouver des fichiers dans les emplacements prévus.

Synapse Link est configuré, mais les fichiers n'apparaissent pas.

Symptômes :

• Synapse Link affiche le statut « Actif », mais aucun fichier CSV n'apparaît dans votre conteneur ADLS Gen2.
• Les exécutions de pipeline échouent avec « Aucune donnée trouvée » ou des erreurs de format de fichier.

Causes possibles :

• Synapse Link est configuré pour exporter des données au format Parquet au lieu du format CSV.
• L'option Se connecter à votre Azure Synapse Analytics Workspace est sélectionnée, ce qui force l'exportation Parquet.

Solutions:

1. Vérifier le format de fichier dans ADLS Gen2 :

   • Dans le portail Azure, accédez à votre compte de stockage ADLS Gen2 et à votre conteneur.
   • Ouvrez un dossier de table et vérifiez les extensions de fichier.
   • Si les fichiers ont l'extension .parquet au lieu de .csv, le format est incorrect.

2. Reconfigurer Synapse Link pour l'exportation CSV :

   • Le connecteur Dynamics 365 ne prend en charge que le format CSV. Vous devez reconfigurer Synapse Link.
   • Dans Power Apps, modifiez ou recréez votre connexion Synapse Link.
   • Décochez la case Connecter à votre Azure Synapse Analytics Workspace.
   • Cela garantit que les données sont exportées au format CSV au lieu de Parquet.
   • Enregistrer la configuration et attendre que Synapse Link réexporte les données (cela peut prendre plusieurs heures pour les grands datasets).

3. Vérifiez que les fichiers CSV sont créés :

   • Après reconfiguration, vérifiez votre conteneur ADLS Gen2.
   • Confirmez que les nouveaux dossiers contiennent .csv fichiers.
   • Une fois que les fichiers CSV apparaissent, réessayez l'exécution de votre pipeline.

Journal des modifications de Synapse Link manquant versionnumber

Symptômes :

• Les exécutions de pipeline échouent avec des erreurs « versionnumber field not found ».
• L’ingestion incrémentielle ne fonctionne pas.
• Seule la refresh complète réussit.

Causes possibles :

• Synapse Link n'est pas configuré pour exporter les journaux de modifications.
• Le suivi des modifications n'est pas activé pour les tables.
• La version de Synapse Link est obsolète.

Solutions:

1. Activer le suivi des modifications :

   • Dans Power Apps, modifiez votre connexion Synapse Link.
   • Assurez-vous que l'option Activer le suivi des modifications est sélectionnée.
   • Enregistrez et attendez que Synapse Link regénère les exportations (jusqu'à 30 minutes).

2. Vérifier les fichiers du journal des modifications :

   • Dans le portail Azure, accédez à votre conteneur ADLS Gen2.
   • Ouvrez un dossier de table et localisez le sous-dossier SynapseLink.
   • Ouvrez un fichier de journal des modifications récent (CSV ou JSON).
   • Vérifiez que le fichier contient une colonne versionnumber.
   • Si manquant, contactez le support Microsoft pour activer le suivi des modifications.

3. Mettre à jour Synapse Link :

   • Vérifiez que vous utilisez Azure Synapse Link for Dataverse version 1.0 ou ultérieure.
   • Les versions plus anciennes peuvent ne pas prendre en charge versionnumber.
   • Mettez à jour Synapse Link vers la dernière version si nécessaire.

4. Effectuez un full refresh :

   • Si le suivi des modifications ne peut pas être activé, vous ne pouvez utiliser que le mode refresh complète.
   • Notez qu'une full refresh recharge toutes les données à chaque exécution, ce qui est plus lent et plus coûteux.

Problèmes d'authentification

L'authentification Entra ID échoue

Symptômes :

• La création du pipeline échoue avec des erreurs « Authentication failed ».
• Le test de connexion échoue dans Catalog Explorer.
• Les exécutions de pipeline échouent avec des erreurs « 401 Unauthorized ».

Causes possibles :

• ID du tenant, ID client ou clé secrète client incorrects.
• Secret du client a expiré.
• L'application ne dispose pas des autorisations requises.
• Périmètre spécifié incorrect.

Solutions:

1. Vérifiez les paramètres d'authentification :

   • Dans le portail Azure, accédez à Microsoft Entra ID > Inscriptions d'applications .

   • Localisez votre application et vérifiez :

     • L' ID de l'application (client) correspond à votre configuration de connexion.
     • **ID de répertoire (tenant)** correspond à votre configuration de connexion.

   • Copiez les valeurs correctes et mettez à jour votre connexion si nécessaire.

2. Vérifier l’expiration du secret client :

   • Dans votre application, sélectionnez Certificats et secrets .
   • Vérifiez que votre secret client n'a pas expiré.
   • S'il est expiré, créez un nouveau secret :
     • Sélectionnez + Nouveau secret client .
     • Saisissez une description et une période d'expiration.
     • Copier la valeur secrète.
     • Mettez à jour votre connexion avec le nouveau secret.

3. Vérifier la portée :

   • Assurez-vous que votre connexion utilise le périmètre correct : https://storage.azure.com/.default
   • Cette étendue octroie l'accès à Azure Storage, pas directement à Microsoft Dynamics 365.

4. Test de connexion :

   • Dans l'Explorateur de catalogue, accédez à votre connexion.
   • Sélectionnez Tester la connexion pour vérifier l'authentification.
   • Si le test échoue, consultez le message d'erreur pour obtenir des instructions spécifiques.

Impossible d'accéder au stockage ADLS Gen2

Symptômes :

• Les exécutions de pipeline échouent avec des erreurs « 403 Interdit » ou « Accès refusé ».
• Le test de connexion réussit, mais le pipeline échoue.
• Certaines tables fonctionnent, mais d'autres échouent.

Causes possibles :

• L'application Entra ID ne dispose pas du rôle Contributeur aux données Blob du stockage.
• L'affectation de rôle est limitée à un conteneur ou un chemin incorrect.
• Les restrictions réseau bloquent l'accès.
• Les règles de pare-feu du compte de stockage bloquent l'accès à Databricks.

Solutions:

1. Vérifier l'attribution des rôles :

   • Dans le portail Azure, naviguez jusqu'à votre compte de stockage.
   • Sélectionner **Contrôle d'accès (IAM)**.
   • Sélectionnez Attributions de rôles .
   • Vérifiez que votre application Entra ID possède le rôle **Contributeur aux données d’objet blob du stockage**.
   • Vérifiez que la portée est définie sur l'intégralité du compte de stockage, et non un conteneur spécifique.

2. Ajouter un rôle manquant :

   • Sélectionnez + Ajouter > Ajouter une attribution de rôle .
   • Recherchez **Contributeur de données BLOB de stockage**.
   • Sélectionnez Suivant et ajoutez votre application.
   • Sélectionner Vérifier + attribuer .
   • Attendez de 5 à 10 minutes pour que les modifications d’autorisations se propagent.

3. Vérifiez les restrictions réseau :

   • Dans votre compte de stockage, sélectionnez **Mise en réseau**.
   • Vérifiez que l'**accès réseau public** est **activé à partir de tous les réseaux** ou inclut les plages IP de Databricks.
   • Si vous utilisez des Endpoint privés, assurez-vous que Databricks peut y acheminer.

4. Examiner les règles de pare-feu :

   • Dans **Mise en réseau**, vérifiez les paramètres du **pare-feu**.
   • Ajoutez les adresses IP Databricks à la liste d'autorisation si nécessaire.
   • Sinon, activez Autoriser les services Azure sur la liste des services de confiance .

Problèmes d'entité virtuelle

Entités virtuelles n'apparaissant pas dans la découverte de schéma

Symptômes :

• Les entités virtuelles n'apparaissent pas lors de l'affichage des tables.
• La création du pipeline échoue avec les erreurs « Table introuvable » pour les entités virtuelles.
• Seules les tables natives de Dataverse sont détectables.

Causes possibles :

• Les entités virtuelles ne sont pas configurées ou synchronisées.
• Synapse Link n'exporte pas d'entités virtuelles.
• Les noms d'entités virtuelles ne correspondent pas à la configuration de la table.

Solutions:

1. Vérifier la configuration de l'entité virtuelle :

   • Dans le Power Platform admin center, accédez à votre environnement.
   • Allez dans Paramètres > Produit > Fonctionnalités .
   • Vérifiez que la source de données d'entité virtuelle est activée.
   • Vérifiez que vos entités virtuelles F&O sont configurées et actives.

2. Attendre la synchronisation :

   • La synchronisation des entités virtuelles peut prendre jusqu'à 15 minutes après la configuration.
   • Prévoyez jusqu'à 30 minutes pour que les entités virtuelles apparaissent dans Dataverse.
   • Veuillez vérifier à nouveau après la période de synchronisation.

3. Vérifiez que Synapse Link inclut des entités virtuelles :

   • Dans Power Apps, modifiez votre connexion Synapse Link.
   • Examiner les tables sélectionnées.
   • Assurez-vous que les entités virtuelles sont incluses dans la liste d’exportation.
   • Ajouter les entités virtuelles manquantes et enregistrer.

4. Vérifiez les noms d'entités virtuelles :

   • Les noms logiques d'entités virtuelles peuvent différer des noms de table F&O.
   • Dans Power Apps, accédez à Tables et localisez vos entités virtuelles.
   • Copiez le nom logique exact et utilisez-le dans la configuration de votre pipeline.

Les modifications de schéma d'entité virtuelle ne sont pas reflétées.

Symptômes :

• Les nouvelles colonnes dans F et O n'apparaissent pas dans les tables Delta cibles.
• Les exécutions de pipeline réussissent, mais les données sont incomplètes.
• Avertissements de drift de schéma dans les Logs du pipeline.

Causes possibles :

• Métadonnées d'entité virtuelle non actualisées dans Dataverse.
• Synapse Link utilisant un schéma en cache.
• Limites de l'évolution des schémas pour les entités virtuelles.

Solutions:

1. Refresh les métadonnées d’entité virtuelle :

   • Dans le centre d’administration Power Platform, accédez à votre environnement.
   • Accéder aux paramètres de Virtual entities .
   • Sélectionnez Refresh les métadonnées pour les entités virtuelles affectées.
   • Patientez jusqu'à 30 minutes pour que les métadonnées se synchronisent.

2. Recréer l’exportation Synapse Link :

   • Dans Power Apps, modifiez votre connexion Synapse Link.
   • Supprimer l’entité virtuelle affectée de la liste d’exportation.
   • Enregistrer et attendre 5 minutes.
   • Ajoutez l'entité virtuelle à nouveau à la liste d'exportation.
   • Veuillez enregistrer et attendre que l'exportation initiale soit terminée.

3. Effectuez un full refresh :

   • Les changements de schéma d'entité virtuelle nécessitent souvent un refresh complet.
   • Arrêtez votre pipeline.
   • Supprimer les tables Delta cibles pour les entités virtuelles affectées.
   • Redémarrez le pipeline pour recréer les tables avec un schéma mis à jour.

Problèmes d'évolution des schémas

Les modifications de type de données provoquent des échecs de pipeline

Symptômes :

• Les exécutions de pipeline échouent avec les erreurs « Incompatibilité de type » ou « Impossible d'effectuer le cast ».
• L'ingestion s'arrête après une mise à jour D365 ou une modification de la configuration.
• Les messages d’erreur font référence à des colonnes et des types de données spécifiques.

Causes possibles :

• Le type de données de la colonne a changé dans D365 (par exemple, de chaîne à entier).
• La table Delta cible a un ancien schéma incompatible avec les nouvelles données.
• Synapse Link exporte les données dans un nouveau format, mais la table cible s'attend à l'ancien format.

Solutions:

1. Identifiez la colonne modifiée :

   • Examinez les Logs d'erreur du pipeline pour trouver la colonne et la table affectées.

   • Dans Power Apps, vérifiez la définition de la table pour le type de données actuel de la colonne.

   • Comparez avec le schéma de votre table Delta cible :

     SQL

     DESCRIBE main.d365_data.tablename;

2. Effectuez un full refresh :

   • Les modifications du type de données nécessitent un full refresh pour recréer les tables.

   • Arrêtez le pipeline concerné.

   • Supprimer la table cible :

     SQL

     DROP TABLE IF EXISTS main.d365_data.tablename;

   • Redémarrez le pipeline pour recréer la table avec le nouveau schéma.

3. Prévenir les problèmes futurs :

   • Coordonnez-vous avec votre administrateur D365 avant les modifications de schéma.
   • Testez d'abord les changements de schéma dans un environnement hors production.
   • Planifiez des refresh complètes pendant les fenêtres de maintenance.

important

Le connecteur Dynamics 365 ne gère pas automatiquement les modifications de type de données. Vous devez effectuer un refresh complet pour mettre à jour les schémas de table. Consultez les limitations pour plus de détails.

Renommages de colonnes non gérés correctement

Symptômes :

• Les colonnes renommées apparaissent comme de nouvelles colonnes avec des valeurs nulles.
• Les anciennes données de colonne sont perdues.
• Les tables cibles ont à la fois des noms de colonnes anciens et nouveaux.

Causes possibles :

• Le connecteur traite les renommages de colonnes comme une opération de suppression et d'ajout.
• Aucune migration automatique des données de l'ancien vers le nouveau nom de colonne.

Solutions:

1. Avant le renommage :

   • Si possible, coordonnez-vous avec votre administrateur D365 pour effectuer une refresh complète avant le renommage.
   • Ceci préserve les données historiques dans le nouveau nom de colonne.

2. Après le renommage :

   • Effectuez une full refresh pour recharger toutes les données avec de nouveaux noms de colonnes.
   • Les données historiques rempliront la nouvelle colonne.

3. Migration manuelle (si la refresh complète n'est pas réalisable) :

   • Si vous ne pouvez pas effectuer un refresh complet, migrez les données manuellement :

     SQL

     -- Copy data from old column to new column
     UPDATE main.d365_data.tablename
     SET new_column_name = old_column_name
     WHERE new_column_name IS NULL AND old_column_name IS NOT NULL;
     
     -- Drop old column after verification
     ALTER TABLE main.d365_data.tablename DROP COLUMN old_column_name;

astuce

Pour minimiser les disruptions, planifiez les renommages de colonnes pendant les fenêtres de maintenance programmées et effectuez des actualisations complètes immédiatement après.

Problèmes de performance

Synchronisation initiale prenant trop de temps

Symptômes :

• Le pipeline est exécuté pendant des heures sans se terminer.
• Synchronisation initiale plus lente que prévu.
• Le pipeline expire ou échoue lors de la première exécution.

Causes possibles :

• Grand volume de données dans les tables sources.
• Exportation Synapse Link lente.
• Limites de bande passante réseau.
• Trop de tables dans un seul pipeline.

Solutions:

1. start par moins de tables :

   • Créez un pipeline avec un petit sous-ensemble de tables (5 - 10 tables).
   • Vérifiez que le pipeline fonctionne correctement.
   • Ajoutez d'autres tables de manière incrémentielle après la validation initiale.

2. Attendez l'exportation Synapse Link :

   • Vérifiez que Synapse Link a terminé l'export initial avant d'exécuter le pipeline.
   • Dans le portail Azure, vérifiez que tous les dossiers de table contiennent des fichiers de données.
   • L'exportation initiale de Synapse Link peut prendre des heures pour les grands datasets.

3. Divisé en plusieurs pipelines :

   • Au lieu d'un pipeline avec 100 tables, créez 5 pipelines avec 20 tables chacun.
   • Exécutez les pipelines en parallèle ou séquentiellement en fonction de la disponibilité des ressources.
   • Cette approche réduit le temps d'exécution individuel du pipeline.

4. Surveiller la bande passante Azure :

   • Vérifiez les métriques de Stockage Azure concernant les limitations ou les limites de bande passante.
   • En cas de limitation, augmentez le niveau du compte de stockage ou ajoutez de la capacité réseau supplémentaire.

Mises à jour incrémentielles lentes

Symptômes :

• Les exécutions de pipeline incrémentielles prennent plus de temps que prévu.
• La performance du pipeline se dégrade au fil du temps.
• Un volume de modifications élevé entraîne des retards.

Causes possibles :

• Fichiers de journal des modifications volumineux.
• Trop de dossiers s'accumulent dans ADLS Gen2.
• Modifications fréquentes créant de nombreux petits dossiers.

Solutions:

1. Augmenter la fréquence d'exécution du pipeline :

   • Si les journaux des modifications sont volumineux, exécutez les pipelines plus fréquemment.
   • Les fichiers de journal des modifications plus petits et plus fréquents traitent plus rapidement que les fichiers volumineux.
   • Pour les environnements à changements fréquents, exécutez toutes les 5 à 15 minutes au lieu de toutes les heures.

2. Examiner la fréquence d'exportation Synapse Link :

   • Dans Power Apps, vérifiez votre calendrier d'exportation Synapse Link.
   • Synapse Link crée des dossiers à intervalles réguliers (généralement toutes les 5 à 15 minutes).
   • Aligner les exécutions de pipeline avec la fréquence d'exportation de Synapse Link.

3. Nettoyer les anciens dossiers d'exportation :

   • Configurez les stratégies de cycle de vie dans votre compte de stockage pour supprimer les exports obsolètes.
   • Conservez uniquement les exportations des 7 à 30 derniers jours en fonction de vos besoins de récupération.
   • Cela réduit le nombre de dossiers que le connecteur doit analyser.

4. Réduire le volume des changements :

   • Examinez les processus D365 qui génèrent des mises à jour à haute fréquence.
   • Mises à jour batch si possible pour réduire les événements de changement individuels.
   • Examinez si toutes les mises à jour doivent être capturées (certaines pourraient être transitoires).

Problèmes de qualité des données

Enregistrements manquants après ingestion

Symptômes :

• Le nombre de lignes dans les tables cibles ne correspond pas à celui des tables sources.
• Enregistrements spécifiques manquants dans les tables cibles.
• Lacunes de données intermittentes.

Causes possibles :

• Exportation Synapse Link incomplète.
• Le pipeline a ignoré des dossiers en raison d'erreurs.
• Filtrage ou autorisations dans le système source.
• Supprimez les enregistrements non exportés par Synapse Link.

Solutions:

1. Comparer les décomptes d'enregistrements :

   • Vérifier le nombre de lignes dans D365 :

     SQL

     -- In D365/Dataverse
     SELECT COUNT(*) FROM account;

   • Vérifiez le nombre de lignes dans la table Delta cible :

     SQL

     -- In Databricks
     SELECT COUNT(*) FROM main.d365_data.account;

   • Identifier l'ampleur de l'écart.

2. Vérifier l'intégrité de Synapse Link :

   • Dans ADLS Gen2, vérifiez que tous les dossiers de table ont des dossiers de timestamp récents.
   • Recherchez les écarts dans les Timestamp de dossier qui pourraient indiquer des exportations manquées.
   • S'il existe des lacunes, il est possible que Synapse Link se soit arrêté temporairement.

3. Vérifier le filtrage :

   • Certaines tables D365 ont des filtres de sécurité qui limitent les enregistrements visibles.
   • Vérifiez que votre compte de service Synapse Link dispose des autorisations nécessaires pour afficher tous les enregistrements.
   • Vérifiez si les filtres de propriété des enregistrements ou d'unité commerciale s'appliquent.

4. Effectuez un full refresh :

   • Si des enregistrements manquent systématiquement, effectuez un refresh complet.
   • Cela recharge toutes les données et garantit l'exhaustivité.
   • Comparez à nouveau les décomptes après le full refresh.

5. Vérifier la gestion des suppressions :

   • Si des enregistrements manquants ont été supprimés dans D365, vérifiez les suppressions de vos exports Synapse Link.
   • Dans Power Apps, vérifiez les paramètres Synapse Link pour le suivi des suppressions.
   • Si les suppressions ne sont pas exportées, les enregistrements supprimés ne seront pas répercutés dans les tables cibles.

Métadonnées de la pièce jointe incomplètes

Symptômes :

• Les tables de pièces jointes (par exemple, annotation, attachment) ont des données manquantes ou incomplètes.
• Noms de fichier ou métadonnées incorrectes.

Causes possibles :

• Synapse Link n'exporte pas les tables de liaison.
• Les autorisations d'attachement restreignent la visibilité.
• Données de pièce jointe stockées dans différentes tables.

Solutions:

1. Vérifier que les tables de pièce jointe sont exportées :

   • Dans Power Apps, vérifiez votre connexion Synapse Link.

   • Assurez-vous que les tables liées aux pièces jointes sont incluses :

     • annotation (pour les notes et les pièces jointes)
     • attachment (pour les pièces jointes d'e-mail)
     • activitymimeattachment (pour les pièces jointes d'activité)

   • Ajoutez les tables manquantes et attendez l'exportation.

2. Vérifiez les autorisations des pièces jointes :

   • Vérifiez que votre compte de service Synapse Link peut lire les enregistrements de pièces jointes.
   • Certaines pièces jointes peuvent être soumises à des restrictions en fonction des rôles de sécurité.
   • Ajustez les autorisations si nécessaire.

3. Comprendre la limitation des métadonnées uniquement :

   • Le connecteur Dynamics 365 ingère les métadonnées des pièces jointes, et non le contenu des fichiers.
   • Pour download des fichiers, utilisez l'API Web Dynamics 365 séparément.
   • Voir les limitations pour plus de détails.

4. Métadonnées de rattachement de requête :

   • Vérifiez que vous interrogez les champs de pièce jointe corrects :

     SQL

     SELECT
       annotationid,
       objectid,
       subject,
       filename,
       filesize,
       mimetype,
       documentbody  -- Usually NULL; binary content not ingested
     FROM main.d365_data.annotation;

Assistance supplémentaire

Si vous ne parvenez pas à résoudre les problèmes à l'aide de ce guide :

1. Collecter les diagnostics :

   • ID de pipeline et timestamps d'exécution.
   • Messages d'erreur complets des logs du pipeline.
   • Logs et état d’Azure Synapse Link.
   • Captures d'écran des messages d'erreur ou des configurations.

2. Vérifiez les problèmes connus :

   • Examinez les limitations pour les problèmes connus.
   • Consultez les notes de version de Databricks pour les dernières mises à jour.

3. Créer un ticket d'assistance :

   • Dans votre Workspace, accédez à Aide > Contacter le support .
   • Sélectionnez **Assistance technique** et indiquez :
     • Description claire du problème.
     • Étapes pour reproduire le problème.
     • Toutes les informations de diagnostic collectées ci-dessus.
     • Impact et urgence du problème.

4. Fournir des commentaires :

   • Pour la version bêta, partagez vos commentaires avec votre équipe de compte Databricks.
   • Signalez les bugs, les demandes de fonctionnalités ou les problèmes de documentation.

Synapse Link est configuré, mais je ne vois pas de fichiers.

Tout d’abord, confirmez que les fichiers sont écrits au format CSV par Synapse Link (pas Parquet). Pour ce faire, décochez la case Connecter à votre Workspace Azure Synapse Analytics lors de la liaison à Azure Synapse Link.

Erreur d’authentification/de connexion

Essayez les scripts de debugging suivants :

Confirmez que l'identifiant client et le secret client fonctionnent correctement :

Python

%pip install azure-storage-blob==12.22.0 azure-identity==1.17.1 azure-storage-file-datalake==12.16.0
%restart_python

# Required libraries
from azure.identity import ClientSecretCredential
from azure.storage.blob import BlobServiceClient


# --- Your Azure Credentials and Storage Details ---
# Replace the placeholder values with your actual information


# Entra ID (Azure Active Directory) details
tenant_id = "<tenant-id>"
client_id = "<client-id>"
client_secret = "<client-secret>"


# Azure Storage details
storage_account_name = "<storage-account>"
container_name = "<container-name>"


# --- Script to List Folders ---


# Construct the Blob Storage URL
storage_account_url = f"https://{storage_account_name}.blob.core.windows.net"


# 1. Authenticate using the service principal
# The ClientSecretCredential object will handle the OAuth 2.0 flow
try:
   credential = ClientSecretCredential(tenant_id, client_id, client_secret)
except Exception as e:
   print(f"Error creating credential: {e}")
   # You may want to stop execution if credentials are not valid
   dbutils.notebook.exit("Failed to create credentials")


# 2. Create a BlobServiceClient
# This client is the main entry point for interacting with the Blob service
try:
   blob_service_client = BlobServiceClient(account_url=storage_account_url, credential=credential)
except Exception as e:
   print(f"Error creating BlobServiceClient: {e}")
   dbutils.notebook.exit("Failed to create BlobServiceClient")


# 3. Get a client for the specific container
try:
   container_client = blob_service_client.get_container_client(container_name)
except Exception as e:
   print(f"Error getting container client for '{container_name}': {e}")
   dbutils.notebook.exit("Failed to get container client")


# 4. List the "folders" in the container
# Folders in Blob Storage are virtual and are represented by prefixes in blob names.
# This code iterates through the blobs and extracts the top-level directory names.
try:
   blob_list = container_client.list_blobs()
   folder_list = set()


   for blob in blob_list:
       if "/" in blob.name:
           folder_name = blob.name.split('/')[0]
           folder_list.add(folder_name)


   # Print the list of unique folder names
   if folder_list:
       print(f"Folders found in container '{container_name}':")
       for folder in sorted(list(folder_list)):
           print(folder)
   else:
       print(f"No folders found in container '{container_name}'.")


except Exception as e:
   print(f"An error occurred while listing blobs: {e}")

Confirmez que la connexion Unity Catalog est capable de distribuer le jeton d'accès :

Python

import requests
import json
import os


# --- Databricks Notebook Context and API Token Retrieval ---
# This section securely retrieves the necessary API token from your Databricks environment
# to interact with Unity Catalog.
notebook_context = dbutils.notebook.entry_point.getDbutils().notebook().getContext()
WORKSPACE_URL = notebook_context.apiUrl().get()
API_TOKEN = notebook_context.apiToken().get()
# --- Unity Catalog Connection Configuration ---
# IMPORTANT: Replace with the name of your Unity Catalog external connection to ADLS Gen2.
# This connection must be configured in Unity Catalog and granted necessary permissions
# to access your Azure Data Lake Storage Gen2 account.
# Example: CONNECTION_NAME = "my_adls_gen2_connection"
CONNECTION_NAME = "<uc-connection-name>"
def get_uc_connection_access_token(connection_name: str, api_token: str) -> str:
   """
   Retrieves the access token for a Unity Catalog external connection to ADLS Gen2.
   """
   url = f"{WORKSPACE_URL}/api/2.1/unity-catalog/foreign-credentials"
   body = '{{"securables": [{{"type": "CONNECTION", "full_name": "{}"}}]}}'.format(
       connection_name
   )
   headers = {
       "Authorization": "Bearer {}".format(api_token),
       "Content-Type": "application/json",
   }
   response = requests.post(url=url, headers=headers, data=body)
   response.raise_for_status() # Raise an exception for HTTP errors (e.g., 401, 403, 404)

   print(response.json())


   credentials = response.json()["securable_to_credentials"][0]["credentials"]["foreign_credential"]["options"]["options"]
   access_token = credentials["access_token"]
   return access_token
 print(get_uc_connection_access_token(CONNECTION_NAME, API_TOKEN))


Verify we are able to list container contents using UC connection

import requests
import json
import os
from datetime import datetime, timedelta
from azure.core.credentials import AccessToken, TokenCredential
from azure.storage.filedatalake import DataLakeServiceClient


notebook_context = dbutils.notebook.entry_point.getDbutils().notebook().getContext()
WORKSPACE_URL = notebook_context.apiUrl().get()
API_TOKEN = notebook_context.apiToken().get()


CONNECTION_NAME = "<uc-connection-name>"
storage_account_name = "<storage-account-name>"
container_name = "<container-name>"
# --- Custom Credential Object for Azure SDK ---
class StaticTokenCredential(TokenCredential):
   """
   A simple credential class to wrap an existing access token for Azure SDKs.
   The expiration is set arbitrarily for the SDK's internal logic;
   your token's real expiry is governed by its issuer.
   """
   def __init__(self, token: str):
       self._token = AccessToken(token, expires_on=(datetime.now() + timedelta(hours=1)).timestamp())
   def get_token(self, *scopes, **kwargs) -> AccessToken:
       return self._token
# ==================== Main Logic to List Top-Level Folders ====================
try:
   # --- Input Validation ---
   if CONNECTION_NAME == "<YOUR_UNITY_CATALOG_CONNECTION_NAME>":
       raise ValueError("Please update 'CONNECTION_NAME' with the name of your Unity Catalog connection.")
   if storage_account_name == "<YOUR_STORAGE_ACCOUNT_NAME>":
       raise ValueError("Please update 'storage_account_name' with your Azure Storage Account Name.")
   if container_name == "<YOUR_CONTAINER_NAME>":
       raise ValueError("Please update 'container_name' with your ADLS Gen2 Container Name.")
   print(f"Retrieving access token from Unity Catalog connection: '{CONNECTION_NAME}'...")
   access_token_string = get_uc_connection_access_token(CONNECTION_NAME, API_TOKEN)
   print("Access token retrieved successfully.")
   # 1. Initialize the DataLakeServiceClient using the retrieved token
   account_url = f"https://{storage_account_name}.dfs.core.windows.net"
   credential = StaticTokenCredential(access_token_string)
   datalake_service_client = DataLakeServiceClient(account_url=account_url, credential=credential)
   file_system_client = datalake_service_client.get_file_system_client(file_system=container_name)

   print(f"\nSuccessfully connected to ADLS Gen2 container: '{container_name}' in storage account: '{storage_account_name}'.")

   # 2. Get and print only the top-level directories
   print("\n--- Listing Top-Level Folders ---")

   all_paths = file_system_client.get_paths(path="/")


   for path in all_paths:
     print(path.name)
except Exception as e:
   print(f"An unexpected error occurred during execution.")
   print(f"Error details: {e}")

Erreur : The selected storage account has restricted network access...

The selected storage account has restricted network access. To proceed, please setup an enterprise policy and connect it to your Dataverse environment. Once done, please enable the 'Select Enterprise Policy with Managed Service Identity' option below.

Cela peut se produire lorsque votre emplacement de staging ADLS est sécurisé par un pare-feu et que Dataverse ne peut pas y accéder. Suivez Utiliser des identités gérées pour Azure avec votre stockage Azure data lake dans la documentation Microsoft pour configurer une identité gérée (anciennement identité de service gérée) afin d'accéder à vos données.

Erreur : FILE_PATH_DOES_NOT_EXIST

Cela se produit généralement lorsque l'option Activer la structure de dossier de mise à jour incrémentielle n'a pas été activée lors de la configuration de Synapse Link. Par conséquent, le connecteur ne trouve pas le fichier là où il s'attend à le trouver.