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. Pour obtenir des conseils de dépannage généraux applicables à tous les pipelines d’ingestion gérés, consultez Résoudre les problèmes liés aux pipelines d’ingestion gérés.

Comme le connecteur lit ce que Azure Synapse Link exporte vers ADLS Gen2, la plupart des échecs d'ingestion start avec l'exportation plutôt que du pipeline. Confirmez que Synapse Link est en cours d'exécution et écrit des fichiers avant d'examiner le pipeline lui-même.

Synapse Link n’exporte pas les données

Symptômes : aucun dossier n’apparaît dans votre conteneur ADLS Gen2 après la configuration de Synapse Link, les Timestamp des dossiers cessent de se mettre à jour ou les exécutions de pipeline échouent avec des erreurs « No data found ».

Cause : La connexion Synapse Link est suspendue 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 ou Synapse Link a rencontré une erreur lors de l’exportation.

Résolution :

1. Vérifiez 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’export est suspendu, cliquez sur Reprendre pour le redémarrer.

2. Vérifier les autorisations de stockage :

   • Dans le portail Azure, accédez à votre compte de stockage.
   • Cliquez sur Access Control (IAM) .
   • Vérifiez que l’identité gérée de Synapse Link dispose du rôle Storage Blob Data Contributor .
   • Si le rôle est manquant, ajoutez l’attribution de rôle.

3. Vérifiez la configuration de la table :

   • Dans Power Apps, sélectionnez votre connexion Synapse Link.
   • Examinez la liste des tables sélectionnées et vérifiez que les tables que vous souhaitez ingérer sont incluses.
   • Ajoutez les tables manquantes et attendez 5 à 15 minutes pour l’exportation initiale.

4. Consultez les logs de Synapse Link :

   • Dans Power Apps, sélectionnez votre connexion Synapse Link.
   • Cliquez sur Afficher les logs ou Historique .
   • Recherchez les messages d’erreur indiquant des échecs d’exportation et corrigez les erreurs spécifiques (par exemple, quota de stockage ou autorisations).

Synapse Link est actif, mais les fichiers n'apparaissent pas

Symptômes : Synapse Link affiche le statut « Actif », mais aucun fichier n’apparaît dans votre conteneur ADLS Gen2, ou les exécutions de pipeline échouent avec des erreurs « Aucune donnée trouvée ».

Cause : Synapse Link n’a pas terminé son exportation initiale, le profil Synapse Link est suspendu ou a rencontré une erreur d’exportation, ou les autorisations du compte de stockage sont incorrectes.

Résolution :

Le connecteur prend en charge l'exportation au format CSV et Parquet et détecte automatiquement le format écrit par Synapse Link. Vous n'avez donc pas besoin de reconfigurer le format d'exportation si des fichiers sont manquants. L’ingestion de Parquet est en version bêta. Pour résoudre les problèmes, confirmez que Synapse Link exporte bien les données :

1. Vérifiez que les fichiers existent dans ADLS Gen2 :

   • Dans le portail Azure, accédez à votre compte de stockage ADLS Gen2 et à votre conteneur.
   • Ouvrez un dossier de table et confirmez qu’il contient des fichiers de données. Pour l’exportation au format CSV, les fichiers ont une extension .csv. Pour l’exportation au format Parquet, Synapse Link écrit chaque table en tant que table Delta au format Parquet sous <profileRoot>/deltalake/<tableName>/.
   • Si les dossiers sont vides, l'exportation initiale est peut-être encore en cours.

2. Vérifiez l’état de Synapse Link :

   • Dans Power Apps, ouvrez votre profil Synapse Link et confirmez qu'il affiche le statut « Active ».
   • En cas de pause ou d'arrêt, cliquez sur Resume pour redémarrer l'exportation.
   • Consultez les logs ou l’historique de Synapse Link pour détecter les erreurs d’exportation, et corrigez celles qui apparaissent (par exemple, quota de stockage ou autorisations).

3. Attendez que l'exportation soit terminée :

   • L'exportation initiale de Synapse Link peut prendre des heures pour les grands datasets.
   • Une fois que les fichiers apparaissent dans votre conteneur, réessayez l’exécution de votre pipeline.

Erreur : FILE_PATH_DOES_NOT_EXIST

Symptômes : les exécutions du pipeline échouent avec une erreur FILE_PATH_DOES_NOT_EXIST, le connecteur ne parvient pas à trouver les fichiers attendus dans ADLS Gen2, ou l'erreur indique des dossiers ou des chemins d'accès manquants.

Cause : l’option Enable Incremental Update Folder Structure n’était pas activée lors de la configuration de Synapse Link ; le connecteur ne trouve donc pas les fichiers là où il les attend.

Résolution :

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

   • Dans Power Apps, modifiez votre connexion Synapse Link.
   • Cliquez sur Advanced pour afficher les paramètres de configuration avancés.
   • Activez Activer la structure de dossier de mise à jour incrémentielle .
   • 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érifiez 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 Timestamp (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. Le connecteur trouve désormais les fichiers aux emplacements attendus.

Le journal des modifications de Synapse Link est manquant versionnumber

Symptômes : les exécutions de pipeline échouent avec des erreurs « versionnumber field not found », l’ingestion incrémentielle ne fonctionne pas ou seule la complète refresh réussit.

Cause : Synapse Link n’est pas configuré pour exporter les journaux de modifications, le suivi des modifications n’est pas activé pour vos tables ou votre version de Synapse Link est obsolète.

Résolution :

1. Activez le suivi des modifications :

   • Dans Power Apps, modifiez votre connexion Synapse Link.
   • Vérifiez que Enable change tracking est sélectionné.
   • Enregistrez et patientez jusqu’à 30 minutes pour que Synapse Link régénère les exportations.

2. Vérifiez 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) et vérifiez qu’il contient une colonne versionnumber.
   • Si la colonne est manquante, contactez l’assistance 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, car les versions antérieures pourraient ne pas prendre en charge versionnumber.

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

Erreur : The selected storage account has restricted network access

Symptômes : la configuration de Synapse Link échoue avec l’erreur suivante :

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.

Cause : votre emplacement de mise en scène ADLS est sécurisé par un pare-feu et Dataverse ne peut pas l'atteindre.

Résolution : configurez une identité gérée (anciennement identité de service gérée) pour accéder à vos données. Consultez Use managed identities for Azure with your Azure data lake storage dans la documentation Microsoft.

L’authentification Microsoft Entra ID a échoué

Symptômes : la création du pipeline échoue avec des erreurs « Authentication failed », le test de connexion échoue dans Catalog Explorer ou les exécutions du pipeline échouent avec des erreurs « 401 Unauthorized ».

Cause : l'ID du tenant, l'ID client ou le secret client est incorrect, le secret client a expiré, l'application ne dispose pas des autorisations requises ou la portée est incorrecte.

Résolution :

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 que l’ ID de l’application (client) et l’ ID du répertoire (tenant) correspondent à votre configuration de connexion.
   • Copiez les valeurs correctes et mettez à jour votre connexion si nécessaire.

2. Vérifiez l'expiration du secret du client :

   • Dans votre application, cliquez sur Certificats et secrets .
   • Vérifiez que votre secret client n'a pas expiré.
   • S'il a expiré, cliquez sur + Nouveau secret client , saisissez une description et une période d'expiration, copiez la valeur du secret et mettez à jour votre connexion avec le nouveau secret.

3. Vérifiez la portée. Votre connexion doit utiliser la portée https://storage.azure.com/.default, qui accorde l’accès à Azure Storage plutôt qu’à Microsoft Dynamics 365 directement.

4. Testez la connexion :

   • Dans Catalog Explorer, accédez à votre connexion.
   • Cliquez sur Test connection pour vérifier l'authentification.
   • Si le test échoue, consultez le message d'erreur pour obtenir des instructions spécifiques.

Si l’authentification échoue toujours, utilisez les scripts suivants dans un Notebook Databricks pour isoler l’origine du problème.

Scripts de debugging

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.
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))

Vérifiez que vous pouvez répertorier le contenu du conteneur à l'aide de la connexion Unity Catalog :

Python

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 == "<uc-connection-name>":
        raise ValueError("Please update 'CONNECTION_NAME' with the name of your Unity Catalog connection.")
    if storage_account_name == "<storage-account-name>":
        raise ValueError("Please update 'storage_account_name' with your Azure Storage Account Name.")
    if container_name == "<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}")

Impossible d’accéder au stockage ADLS Gen2

Symptômes : les exécutions de pipeline échouent avec des erreurs « 403 Forbidden » ou « Access denied », le test de connexion réussit mais le pipeline échoue, ou certaines tables fonctionnent alors que d’autres échouent.

Cause : l’application Microsoft Entra ID ne dispose pas du rôle Storage Blob Data Contributor , l’attribution de rôle est limitée au mauvais conteneur ou chemin d’accès, ou des restrictions réseau et des règles de pare-feu de compte de stockage bloquent l’accès à Databricks.

Résolution :

1. Vérifiez l'attribution du rôle :

   • Dans le portail Azure, accédez à votre compte de stockage.
   • Cliquez sur Access Control (IAM) , puis sur Role assignments .
   • Vérifiez que votre application Microsoft Entra ID dispose du rôle Storage Blob Data Contributor .
   • Vérifiez que la portée est définie sur l’ensemble du compte de stockage plutôt que sur un conteneur spécifique.

2. Ajouter le rôle manquant :

   • Cliquez sur + Ajouter > Ajouter une attribution de rôle .
   • Recherchez **Contributeur de données BLOB de stockage**.
   • Cliquez sur Suivant et ajoutez votre application.
   • Cliquez sur Review + assign , puis patientez 5 à 10 minutes pour que les modifications d’autorisations prennent effet.

3. Vérifiez les restrictions réseau :

   • Dans votre compte de stockage, cliquez sur Mise en réseau .
   • Vérifiez que Public network access est défini sur Enabled from all networks ou inclut les plages d’adresses IP Databricks.
   • Si vous utilisez des endpoints privés, vérifiez que Databricks peut les atteindre.

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

   • Dans Networking , passez en revue les paramètres Firewall .
   • Ajoutez les adresses IP Databricks à la liste d’autorisation si nécessaire, ou activez Autoriser les services Azure dans la liste des services approuvés .

Les entités virtuelles n’apparaissent pas dans la découverte de schéma

Symptômes : les entités virtuelles n’apparaissent pas lors de la liste des tables, la création du pipeline échoue avec des erreurs « Table not found » pour les entités virtuelles, ou seules les tables natives Dataverse sont détectables.

Cause : les entités virtuelles ne sont pas configurées ou synchronisées, Synapse Link ne les exporte pas ou les noms des entités virtuelles ne correspondent pas à votre configuration de table.

Résolution :

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

   • Dans le centre d’administration Power Platform, 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. Attendez la synchronisation. La synchronisation des entités virtuelles prend généralement jusqu’à 15 minutes après la configuration, mais peut prendre jusqu’à 30 minutes pour apparaître dans Dataverse. Veuillez réessayer après cette période.

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

   • Dans Power Apps, modifiez votre connexion Synapse Link.
   • Examinez les tables sélectionnées et vérifiez 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 des entités virtuelles. Les noms logiques des entités virtuelles peuvent différer des noms de table F&O. Dans Power Apps, accédez à Tables , localisez vos entités virtuelles, puis copiez le Logical name exact et utilisez-le dans la configuration de votre pipeline.

Les modifications du schéma d’entité virtuelle ne sont pas reflétées

Symptômes : les nouvelles colonnes dans F&O n’apparaissent pas dans les tables Delta cibles, les exécutions de pipeline réussissent mais les données sont incomplètes, ou des avertissements de dérive (drift) de schéma apparaissent dans les logs du pipeline.

Cause : les métadonnées de l'entité virtuelle n'ont pas été actualisées dans Dataverse, Synapse Link utilise un schéma mis en cache ou des limitations d'évolution des schémas s'appliquent aux entités virtuelles.

Résolution :

1. refresh les métadonnées de l’entité virtuelle :

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

2. Recréez l’exportation Synapse Link :

   • Dans Power Apps, modifiez votre connexion Synapse Link.
   • Supprimez l’entité virtuelle concernée de la liste d’exportation, enregistrez et patientez 5 minutes.
   • Ajoutez à nouveau l’entité virtuelle à la liste d’exportation, enregistrez, puis attendez que l’exportation initiale soit terminée.

3. Effectuez un full refresh. Les changements de schéma d’entité virtuelle nécessitent souvent une refresh. Arrêtez votre pipeline, supprimez les tables Delta cibles pour les entités virtuelles concernées, puis redémarrez le pipeline pour recréer les tables avec le schéma mis à jour.

Le connecteur ne prend pas en charge l'évolution automatisée des schémas ; par conséquent, les modifications du schéma source nécessitent une intervention manuelle. See évolution des schémas.

Les modifications de type de données entraînent des échecs de pipeline

Symptômes : les exécutions de pipeline échouent avec des erreurs « Type mismatch » ou « Cannot cast », l’ingestion s’arrête après une mise à jour ou une modification de configuration de Dynamics 365, ou les messages d’erreur font référence à des colonnes et des types de données spécifiques.

Cause : un type de données de colonne a été modifié dans Dynamics 365 (par exemple, passage d'une chaîne à un entier), le schéma de la table Delta cible est donc incompatible avec les nouvelles données.

Résolution :

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-le avec le schéma de votre table Delta cible :

     SQL

     DESCRIBE main.d365_data.tablename;

2. Effectuez un full refresh. Les modifications de type de données nécessitent un full refresh pour recréer les tables. Arrêtez le pipeline concerné, supprimez la table cible, puis redémarrez le pipeline pour recréer la table avec le nouveau schéma :

   SQL

   DROP TABLE IF EXISTS main.d365_data.tablename;

3. Prévenez les problèmes futurs. Coordonnez-vous avec votre administrateur Dynamics 365 avant d’effectuer des changements de schéma, testez d’abord les changements de schéma dans un environnement hors production et planifiez les actualisations complètes pendant les fenêtres de maintenance.

important

Le connecteur Dynamics 365 ne gère pas automatiquement les changements de type de données. Vous devez effectuer un full refresh pour mettre à jour les schémas de table. See évolution des schémas.

Renommages de colonnes non gérés correctement

Symptômes : Les colonnes renommées apparaissent comme de nouvelles colonnes avec des valeurs NULL, les données des anciennes colonnes sont perdues, ou les tables cibles contiennent à la fois les anciens et les nouveaux noms de colonnes.

Cause : le connecteur traite le renommage d'une colonne comme une opération de suppression et d'ajout, sans migration automatique des données de l'ancien nom de colonne vers le nouveau.

Résolution :

1. Avant que le renommage n'ait lieu, coordonnez-vous avec votre administrateur Dynamics 365 pour effectuer un refresh complet, ce qui préserve les données historiques sous le nouveau nom de colonne.

2. Une fois le renommage effectué, effectuez un full refresh pour recharger toutes les données avec les nouveaux noms de colonnes. Les données historiques remplissent ensuite la nouvelle colonne.

3. Si un full refresh n’est pas réalisable, 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.

La synchronisation initiale prend trop de temps

Symptômes : un pipeline s’exécute pendant des heures sans se terminer, la synchronisation initiale est plus lente que prévu, ou le pipeline expire ou échoue lors de la première exécution.

Cause : volume de données important dans les tables sources, exportation Synapse Link lente, limitations de la bande passante réseau ou trop grand nombre de tables dans un seul pipeline.

Résolution :

1. Start avec moins de tables. Créez un pipeline avec 5 à 10 tables, vérifiez qu'il fonctionne correctement, puis ajoutez d'autres tables de manière incrémentielle.
2. Attendez l’exportation Synapse Link. Vérifiez que Synapse Link a terminé l’exportation initiale 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 peut prendre des heures pour les grands datasets.
3. Divisez le travail en plusieurs pipelines. Au lieu d’un pipeline avec 100 tables, créez 5 pipelines avec 20 tables chacun, puis exécutez-les en parallèle ou séquentiellement en fonction de la disponibilité des ressources. Cela réduit le temps d’exécution individuel du pipeline.
4. Surveillez la bande passante Azure. Vérifiez les métriques Azure Storage pour détecter les limitations de débit ou de bande passante. Si vous êtes limité, augmentez le niveau du compte de stockage ou ajoutez de la capacité réseau.

Les mises à jour incrémentielles sont lentes

Symptômes : les exécutions de pipeline incrémentielles prennent plus de temps que prévu, les performances du pipeline se dégradent avec le temps ou un volume de changements élevé entraîne des retards.

Cause : fichiers de journal des modifications volumineux, trop de dossiers s’accumulant dans ADLS Gen2, ou modifications à haute fréquence créant de nombreux petits dossiers.

Résolution :

1. Augmentez la fréquence d’exécution du pipeline. Les fichiers de journal des modifications plus petits et plus fréquents sont traités plus rapidement que les fichiers volumineux. Pour les environnements à forte évolution, exécutez toutes les 5 à 15 minutes au lieu d’une fois par heure.
2. Vérifiez la fréquence d’exportation de Synapse Link. Dans Power Apps, vérifiez votre planning d’exportation Synapse Link. Synapse Link crée des dossiers à intervalles réguliers, généralement toutes les 5 à 15 minutes. Alignez vos exécutions de pipeline sur cette fréquence.
3. Nettoyez les anciens dossiers d'exportation. Configurez des stratégies de cycle de vie dans votre compte de stockage pour supprimer les anciennes exportations, en ne conservant que les 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éduisez le volume de modification. Examinez les processus Dynamics 365 qui génèrent des mises à jour à haute fréquence, et regroupez les mises à jour par batch lorsque cela est possible afin de réduire les événements de modification individuels.

Enregistrements manquants après l'ingestion

Symptômes : le nombre de lignes dans les tables cibles ne correspond pas à celui des tables sources, des enregistrements spécifiques sont manquants ou il existe des lacunes intermittentes dans les données.

Cause : l’exportation Synapse Link est incomplète, le pipeline a ignoré des dossiers en raison d’erreurs, le filtrage ou les autorisations dans le système source restreignent la visibilité, ou Synapse Link n’exporte pas les enregistrements supprimés.

Résolution :

1. Comparez le nombre d'enregistrements. Vérifiez le nombre de lignes dans Dynamics 365 :

   SQL

   SELECT COUNT(*) FROM account;

   Vérifiez ensuite le nombre de lignes dans la table Delta cible et identifiez l’ampleur de l’écart :

   SQL

   SELECT COUNT(*) FROM main.d365_data.account;

2. Vérifiez que l'exportation Synapse Link est terminée. Dans ADLS Gen2, vérifiez que tous les dossiers de table contiennent des dossiers de timestamp récents. Recherchez des écarts dans les timestamps des dossiers, ce qui peut indiquer que Synapse Link s'est arrêté temporairement.

3. Vérifiez la présence de filtres. Certaines tables Dynamics 365 disposent de filtres de sécurité qui restreignent la visibilité des enregistrements. Vérifiez que votre compte de service Synapse Link dispose de l'autorisation de voir tous les enregistrements, et vérifiez si des filtres de propriété d'enregistrement ou d'unité commerciale s'appliquent.

4. Effectuez un full refresh. Si des enregistrements sont systématiquement manquants, effectuez un full refresh pour recharger toutes les données, puis comparez à nouveau les nombres.

5. Vérifiez la gestion des suppressions. Si les enregistrements manquants ont été supprimés dans Dynamics 365, vérifiez que Synapse Link exporte les suppressions. Dans Power Apps, vérifiez les paramètres de Synapse Link pour le suivi des suppressions. Si les suppressions ne sont pas exportées, les enregistrements supprimés ne sont pas reflétés dans vos tables cibles.

Les métadonnées de la pièce jointe sont incomplètes

Symptômes : les tables de pièces jointes (par exemple, annotation ou attachment) présentent des données manquantes ou incomplètes, ou les noms de fichiers et les métadonnées sont incorrects.

Cause : Synapse Link n'exporte pas les tables de pièces jointes, les autorisations de pièces jointes restreignent la visibilité ou les données des pièces jointes sont stockées dans des tables différentes.

Résolution :

1. Vérifiez que les tables de pièces jointes sont exportées. Dans Power Apps, vérifiez votre connexion Synapse Link et assurez-vous que les tables liées aux pièces jointes sont incluses, puis ajoutez celles qui manquent et attendez l'exportation :

   • annotation pour les notes et les pièces jointes
   • attachment pour les pièces jointes aux e-mails
   • activitymimeattachment pour les pièces jointes d’activité

2. Vérifiez les autorisations de la pièce jointe. Vérifiez que votre compte de service Synapse Link peut lire les enregistrements de pièces jointes, car certaines pièces jointes peuvent être restreintes par des rôles de sécurité.

3. Comprenez la limitation liée aux métadonnées uniquement. Le connecteur ingère les métadonnées des pièces jointes plutôt que le contenu des fichiers. Pour download des fichiers, utilisez séparément l’API Web Dynamics 365. Consultez Pièces jointes et fichiers.

4. 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 les conseils ci-dessus ne résolvent pas votre problème, collectez les données de diagnostic avant de contacter le support.

1. Collecter les diagnostics :

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

2. Recherchez les problèmes connus. Consultez les problèmes connus pour connaître les problèmes identifiés, et vérifiez les notes de version de Databricks pour les mises à jour récentes.

3. Créez un ticket d’assistance. Dans votre workspace, accédez à Help > Contact Support , puis sélectionnez Technical Support et fournissez une description claire du problème, les étapes pour le reproduire, les informations de diagnostic que vous avez collectées, ainsi que l’impact et l’urgence.

4. Fournir votre retour d'expérience. Partagez vos commentaires avec l’équipe chargée de votre compte Databricks, notamment les bugs, les demandes de fonctionnalités ou les problèmes de documentation.