FAQ du connecteur Microsoft Dynamics 365

Trouvez des réponses aux questions fréquemment posées sur le connecteur géré Microsoft Dynamics 365 dans Lakeflow Connect. Pour des questions générales sur les connecteurs d’ingestion gérés, consultez la FAQ sur les connecteurs gérés.

FAQ spécifiques au connecteur

Les questions suivantes couvrent la manière dont le connecteur lit vos données via Azure Synapse Link, les applications et autorisations Dynamics 365 requises, ainsi que la planification des connexions, des coûts et des modifications de schéma.

Comment le connecteur accède-t-il aux données D365 ?

Le connecteur Dynamics 365 utilise Azure Synapse Link for Dataverse comme intermédiaire :

Synapse Link exporte en continu les données D365 vers ADLS Gen2 au format CSV.
Synapse Link tient à jour les journaux de modifications avec les Timestamp VersionNumber pour le suivi des changements.
Databricks lit les fichiers exportés depuis ADLS Gen2 à l'aide de l'authentification Microsoft Entra ID.
Le connecteur traite les journaux de modifications pour effectuer l'ingestion incrémentielle.

Avec cette architecture, vous pouvez ingérer des données D365 sans effectuer d'appels d'API basés sur OData à D365, ce qui réduit la charge sur votre environnement D365.

Pourquoi ai-je besoin d'Azure Synapse Link ?

Azure Synapse Link for Dataverse est requis pour :

Suivi des modifications : Synapse Link fournit des journaux de modifications avec des champs versionnumber qui permettent une ingestion incrémentielle.
Performances : la lecture des fichiers exportés depuis ADLS Gen2 est plus efficace que l'exécution d'appels API basés sur OData vers D365.

Comment fonctionne l'ingestion incrémentielle ?

Le connecteur Dynamics 365 utilise le champ versionnumber des journaux de modifications Azure Synapse Link pour suivre les modifications :

Synapse Link exporte des données vers des dossiers Timestamp dans ADLS Gen2.
Chaque exportation comprend un fichier de journal des modifications avec des valeurs versionnumber indiquant quand les enregistrements ont changé.
Le connecteur traite les dossiers par ordre chronologique en fonction des Timestamp.
Pour chaque dossier, le connecteur lit le journal des modifications et applique les modifications (insertions, mises à jour, suppressions).
Le connecteur stocke le dernier versionnumber traité comme curseur.
Les exécutions de pipeline ultérieures ne traitent que les nouveaux dossiers créés après le dernier curseur.

Cette approche garantit que le connecteur capture toutes les modifications sans retraiter les données inchangées. Consultez Activer le suivi de l’historique (SCD de type 2) pour plus d’informations sur la façon dont le connecteur gère les mises à jour et les suppressions.

Quelles applications Dynamics 365 sont prises en charge ?

Le connecteur Dynamics 365 prend en charge les applications natives Dataverse et les applications non natives Dataverse.

Les applications natives Dataverse, auxquelles le connecteur accède directement sans entités virtuelles ni tables directes, incluent :

Dynamics 365 Ventes
Dynamics 365 Customer Service
Dynamics 365 Marketing
Dynamics 365 Field Service

Les applications non natives de Dataverse, qui nécessitent soit des entités virtuelles, soit des tables directes, incluent :

Dynamics 365 Finance et Opérations (F&O)

Voir Configurer la source de données pour l'ingestion de Microsoft Dynamics 365 pour les détails de configuration.

Quelle est la différence entre les applications natives Dataverse et celles qui ne le sont pas ?

Les applications natives Dataverse stockent les données directement dans les tables Dataverse. Le connecteur peut accéder à ces tables immédiatement après que vous avez configuré Azure Synapse Link.

Les applications non natives de Dataverse, telles que F&O, stockent les données dans leur propre base de données plutôt que dans Dataverse. Pour ingérer leurs données, vous utilisez soit des entités virtuelles, soit des tables directes :

Une table virtuelle , également appelée entité virtuelle, apparaît et se comporte comme une table Dataverse classique, mais ne stocke aucune donnée elle-même. Il récupère les données à la demande depuis la source externe, de sorte que les données ne sont jamais matérialisées dans Dataverse. Vous pouvez travailler avec les données sans les dupliquer.
Une table directe est une copie physique des données d'application, exportée et matérialisée en dehors de Dataverse. Azure Synapse Link réplique les données du système source dans ADLS Gen2 sous forme de tables transactionnelles brutes qui correspondent étroitement au schéma source. Comme les données persistent, cela prend en charge l'analytique évolutive et l'analyse historique sans interroger le système source.

En prenant F&O comme exemple :

Les entités virtuelles sont exposées dans Dataverse via la solution F&O Virtual Entity. Elles apparaissent sous forme de tables en lecture seule préfixées par mserp_, qu'Azure Synapse Link exporte vers ADLS Gen2 pour que les pipelines Lakeflow Connect puissent les ingérer. Les entités F&O agrègent souvent plusieurs tables sous-jacentes dans une vue dénormalisée ; cette option vous fournit donc généralement des données pré-jointes et adaptées aux besoins métier, nécessitant moins de transformations en aval.
Les tables directes sont des tables F&O brutes qu'Azure Synapse Link exporte sans les faire transiter par Dataverse. Ils apparaissent dans une section distincte lors de la configuration de Synapse Link et arrivent dans ADLS Gen2 sous forme de données transactionnelles brutes.

Pour décider quelle option est adaptée à votre charge de travail :

Considération	Tables virtuelles	Tables directes
Granularité des données	Une vue plus plate et agrégée pouvant inclure des champs calculés.	Les données transactionnelles brutes les plus granulaires, vous offrant un contrôle total sur la modélisation des données.
Effort de transformation	Souvent pré-jointes et prêtes à l’emploi, ce qui minimise les transformations en aval dans Databricks.	Nécessitent généralement une Data Engineering supplémentaire pour les jointures et les transformations complexes.
Performance	Peut ajouter une surcharge côté source, en fonction de la complexité de l’entité.	Peut nécessiter davantage de compute en aval pour appliquer la logique métier.

Considération	Tables virtuelles	Tables directes
Granularité des données	Une vue plus plate et agrégée pouvant inclure des champs calculés.	Les données transactionnelles brutes les plus granulaires, vous offrant un contrôle total sur la modélisation des données.
Effort de transformation	Souvent pré-jointes et prêtes à l’emploi, ce qui minimise les transformations en aval dans Databricks.	Nécessitent généralement une Data Engineering supplémentaire pour les jointures et les transformations complexes.
Performance	Peut ajouter une surcharge côté source, en fonction de la complexité de l’entité.	Peut nécessiter davantage de compute en aval pour appliquer la logique métier.

Puis-je ingérer des pièces jointes de D365 ?

Le connecteur Dynamics 365 ingère les métadonnées de pièce jointe (nom de fichier, taille, type MIME, associations d'enregistrements) mais ne download pas le contenu des fichiers de pièce jointe. C'est parce que Synapse Link exporte les données de table et non les contenus de fichiers binaires.

Pour accéder aux fichiers joints :

Ingérer les tables de métadonnées des pièces jointes telles que annotation et attachment.
Utilisez les métadonnées pour identifier les fichiers dont vous avez besoin.
download les fichiers directement depuis D365 à l’aide de l’API Web Dynamics 365 ou de Power Automate.
Stockez les fichiers dans votre emplacement de stockage préféré, tel qu’ADLS Gen2 ou un volume Unity Catalog.

Avez-vous besoin de connexions distinctes pour différentes applications D365 ?

Non, vous pouvez utiliser une seule connexion Unity Catalog pour toutes les applications D365 dans le même environnement Dataverse. La connexion s'authentifie au compte de stockage ADLS Gen2, et non aux applications D365 individuelles.

Cependant, vous avez besoin de pipelines distincts pour chaque environnement Dataverse, identifiés par sa valeur source_schema. Par exemple :

Connexion unique : s'authentifie auprès de votre conteneur ADLS Gen2.
Plusieurs pipelines : un pipeline par environnement Dataverse, chacun spécifiant une valeur source_schema différente.

Cette approche simplifie la gestion de l'authentification tout en vous permettant d'ingérer à partir de plusieurs environnements.

Quelles autorisations sont requises dans D365 ?

La configuration du connecteur Dynamics 365 nécessite des autorisations à trois endroits : Microsoft Dynamics 365 et Dataverse, Azure, et Databricks.

Dans Microsoft Dynamics 365 et Dataverse, vous avez besoin des autorisations suivantes :

Rôle d'administrateur système ou autorisations équivalentes pour configurer Azure Synapse Link.
Autorisations de lecture pour toutes les tables que vous souhaitez ingérer.
Autorisations de configurer des entités virtuelles ou des tables directes (pour des applications comme F&O).

Dans Azure, vous avez besoin des autorisations suivantes :

Autorisations pour créer et configurer des comptes de stockage et des conteneurs ADLS Gen2.
Autorisations pour créer et configurer des applications Microsoft Entra ID.
Autorisations pour attribuer le rôle de Contributeur de données Blob de stockage à l'application Entra ID.

Dans Databricks, vous avez besoin des autorisations suivantes :

Autorisations d'administrateur de Workspace ou d'administrateur de metastore pour créer des connexions Unity Catalog.
Autorisations CREATE sur le catalogue et le schéma cibles.

Consultez Configurer la source de données pour l'ingestion de Microsoft Dynamics 365 pour connaître les exigences d'autorisation détaillées.

Puis-je ingérer des données provenant de plusieurs environnements Dataverse ?

Oui, vous pouvez ingérer des données depuis plusieurs environnements Dataverse à l’aide d’une connexion unique. Créer des pipelines séparés pour chaque environnement :

Python
# Pipeline for production environment
prod_pipeline = w.pipelines.create(
    name="d365_prod_ingestion",
    ingestion_definition=IngestionPipelineDefinition(
        channel="PREVIEW",
        connection_name="d365_connection",  # Same connection
        source_schema="https://prod.crm.dynamics.com",  # Production
        source_table=["account", "contact"],
        destination_catalog="main",
        destination_schema="d365_prod",
        scd_type="SCD_TYPE_2"
    )
)

# Pipeline for test environment
test_pipeline = w.pipelines.create(
    name="d365_test_ingestion",
    ingestion_definition=IngestionPipelineDefinition(
        channel="PREVIEW",
        connection_name="d365_connection",  # Same connection
        source_schema="https://test.crm.dynamics.com",  # Test
        source_table=["account", "contact"],
        destination_catalog="main",
        destination_schema="d365_test",
        scd_type="SCD_TYPE_2"
    )
)

Vous devez soit exporter tous les environnements vers le même compte et conteneur de stockage ADLS Gen2, soit créer des connexions distinctes pour chaque emplacement de stockage.

Comment réduire les coûts d'ingestion ?

Pour optimiser les coûts :

Utilisez la sélection de colonnes pour ingérer uniquement les colonnes requises. Consultez Sélectionner les colonnes à ingérer.
N'incluez que les tables dont vous avez besoin dans le pipeline.
Désactivez le suivi de l'historique (SCD de type 1) si vous n'avez pas besoin de suivi historique pour réduire le stockage.

Voir les limitations du connecteur Microsoft Dynamics 365 pour plus de considérations.

Puis-je transformer des données pendant l'ingestion ?

Lakeflow Connect ingère les données brutes de Microsoft Dynamics 365 sans transformations. Pour transformer des données :

Ingérez des données brutes dans un schéma de destination tel que d365_landing.
Créez des LakeFlow Pipelines en aval pour les Transformations.
Utilisez SQL ou Python pour transformer des données en schémas organisés.

Cette séparation des préoccupations préserve les données brutes tout en permettant des transformations flexibles en aval.

Comment gérer les modifications de schéma dans D365 ?

Actuellement, toutes les modifications de schéma nécessitent un refresh complet de la table. Surveillez vos modifications de schéma D365 et planifiez des refresh complètes en conséquence.

L'instance Dataverse Synapse Link doit-elle se trouver dans la même région que le workspace Databricks ?

Non.

FAQ spécifiques au connecteur​

Comment le connecteur accède-t-il aux données D365 ?​

Pourquoi ai-je besoin d'Azure Synapse Link ?​

Comment fonctionne l'ingestion incrémentielle ?​

Quelles applications Dynamics 365 sont prises en charge ?​

Quelle est la différence entre les applications natives Dataverse et celles qui ne le sont pas ?​

Puis-je ingérer des pièces jointes de D365 ?​

Avez-vous besoin de connexions distinctes pour différentes applications D365 ?​

Quelles autorisations sont requises dans D365 ?​

Puis-je ingérer des données provenant de plusieurs environnements Dataverse ?​

Comment réduire les coûts d'ingestion ?​

Puis-je transformer des données pendant l'ingestion ?​

Comment gérer les modifications de schéma dans D365 ?​

L'instance Dataverse Synapse Link doit-elle se trouver dans la même région que le workspace Databricks ?​