FAQ du connecteur Microsoft Dynamics 365

Trouvez des réponses aux questions fréquemment posées concernant le connecteur géré Microsoft Dynamics 365 dans Lakeflow Connect.

Pour les questions générales sur les connecteurs d'ingestion gérés, consultez les FAQ sur les connecteurs gérés.

FAQ spécifiques au connecteur

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

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

1. Synapse Link exporte en continu les données D365 vers ADLS Gen2 au format CSV.
2. Synapse Link tient à jour les journaux de modifications avec les Timestamp VersionNumber pour le suivi des changements.
3. Databricks lit les fichiers exportés depuis ADLS Gen2 à l'aide de l'authentification Microsoft Entra ID.
4. 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 pour Dataverse est requis car :

• Suivi des modifications : Synapse Link fournit des journaux des modifications avec versionnumber champs qui permettent l'ingestion incrémentale.
• Performances : la lecture de fichiers exportés depuis ADLS Gen2 est plus efficace que les appels d'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 :

1. Synapse Link exporte des données vers des dossiers Timestamp dans ADLS Gen2.
2. Chaque exportation comprend un fichier de journal des modifications avec des valeurs versionnumber indiquant quand les enregistrements ont changé.
3. Le connecteur traite les dossiers par ordre chronologique en fonction des Timestamp.
4. Pour chaque dossier, le connecteur lit le journal des modifications et applique les modifications (insertions, mises à jour, suppressions).
5. Le connecteur stocke le dernier versionnumber traité comme curseur.
6. 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.

Voir Activer le suivi de l'historique (SCD de type 2) pour des 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 éléments suivants :

Applications natives Dataverse (accès direct, aucune entité virtuelle ni table directe requise). Exemples :

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

Applications non natives Dataverse (nécessite des entités virtuelles ou des tables directes). Exemples :

• 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 de Dataverse et les applications non natives de Dataverse ?

Les applications natives Dataverse stockent les données directement dans les tables Dataverse. Le connecteur peut accéder à ces tables immédiatement après avoir 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, et non dans Dataverse. Pour ingérer des données à partir de ces applications, vous pouvez utiliser des entités virtuelles ou des tables directes.

Définitions :

• Une table virtuelle (ou entité) apparaît et se comporte comme une table normale dans Dataverse, mais elle-même ne stocke aucune donnée. Au lieu de cela, il récupère les données à la demande, directement à partir d'une source de données externe (par exemple, F&O). Cela signifie que les données ne sont pas matérialisées au sein de la base de données Dataverse, permettant aux utilisateurs d'interagir avec les données sans les dupliquer ni les stocker.
• Une table directe est une copie physique de données d'application qui est exportée et matérialisée hors de Dataverse (par exemple, dans Azure Data Lake Storage via Azure Synapse Link). Les données sont répliquées depuis le système source (par exemple, F&O) et stockées sous forme de tables transactionnelles brutes qui correspondent étroitement au schéma source. Parce que les données sont persistantes, elles prennent en charge l'analytique scalable et l'analyse historique sans interroger le système source.

Comment ils sont utilisés (en prenant F&O comme exemple) :

• Si vous utilisez des entités virtuelles, les données sont exposées dans Dataverse via la solution d'entité virtuelle F&O. Ces entités virtuelles apparaissent comme des tables de lecture directe (par exemple, mserp_) dans Dataverse et peuvent être exportées vers ADLS à l'aide d'Azure Synapse Link. De là, les pipelines Lakeflow Connect ingèrent les dossiers exportés dans vos tables cibles. Cette option fournit généralement des vues pré-jointes conviviales pour les entreprises avec moins d'effort de transformation en aval, étant donné que les entités F&O agrègent souvent des données de plusieurs tables sous-jacentes dans une vue dénormalisée.
• Si vous utilisez des tables directes, Azure Synapse Link vous permet d'exporter directement les tables brutes F&O. Ces tables sont disponibles dans une section distincte lors de la configuration de Synapse Link et sont écrites dans ADLS en tant que données transactionnelles brutes.

Facteurs à prendre en compte pour décider quand utiliser quoi :

Pour décider quelle est la meilleure option, vous pourriez considérer :

• Granularité et contrôle des données : Les tables directes fournissent les données transactionnelles brutes les plus granulaires pour un contrôle ultime sur la modélisation des données. Les tables virtuelles offrent une vue plus aplatie et agrégée — incluant potentiellement des champs calculés.
• Préparation des données et effort de Transformation : de manière connexe, les tables virtuelles offrent souvent des données pré-jointes et prêtes à l’emploi, ce qui peut aider à minimiser les Transformations en aval dans Databricks. Les tables directes exigent souvent un effort de Data Engineering supplémentaire pour les jointures et les transformations complexes.
• Performance : Bien que les deux options soient raisonnablement efficaces, elles entraînent une surcharge à différentes étapes du flux. Les tables virtuelles peuvent introduire une surcharge côté source (l'ampleur dépendant de la complexité de l'entité), tandis que les tables directes peuvent nécessiter plus de compute en aval pour 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 :

1. Ingérer les tables de métadonnées de pièces jointes (par exemple, annotation, attachment).
2. Utilisez les métadonnées pour identifier les fichiers dont vous avez besoin.
3. download les fichiers directement depuis D365 à l’aide de l’API Web Dynamics 365 ou de Power Automate.
4. Stockez les fichiers dans votre emplacement de stockage préféré (par exemple, ADLS Gen2, volume).

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 (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 ?

Pour configurer le connecteur Dynamics 365, vous avez besoin :

Dans Microsoft Dynamics 365 et Dataverse :

• 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 :

• 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 :

• 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 :

1. Ingérez les données brutes dans un schéma de zone d'atterrissage (par exemple, d365_landing).
2. Créez des LakeFlow Pipelines en aval pour les Transformations.
3. 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.