Créer une data entity D365 F&O et l'exporter avec DMF
Créer une data entity dans Visual Studio (assistant, staging, clé), la synchroniser puis l'exporter via l'espace Gestion des données. Étapes et pièges.
La réponse courte
Pour exposer vos tables Dynamics 365 Finance & Operations à l'import/export : dans Visual Studio, ajoutez au projet un élément « Data Entity », renseignez l'assistant (data source principale, nom public, options « Enable public API » pour OData et « Enable data management capabilities » pour l'import/export), choisissez les champs et la clé naturelle, puis compilez avec synchronisation de la base. L'assistant crée l'entité et sa table de staging.
Côté application, actualisez la liste des entités si besoin, puis créez un projet d'export dans l'espace de travail Gestion des données : choisissez l'entité, le format de fichier et un filtre éventuel, lancez l'export et téléchargez le fichier ou le package.
Étape 1 : créer l'entité dans Visual Studio
D'après le tutoriel Microsoft Learn « Build and consume data entities » :
- Créez un projet finance and operations rattaché à votre modèle.
- Ajoutez un nouvel élément Data Entity. Le nom de l'entité ne doit contenir ni « _ » ni chiffre, sous peine d'erreurs de mapping plus tard.
- Dans l'assistant, choisissez la data source principale, le nom public, la collection publique, et cochez les options OData et/ou gestion des données. L'option gestion des données génère la table de staging.
- Sélectionnez les champs. Renommez-les selon un contrat public lisible (ou utilisez « Convert labels to field names »). Désélectionnez les champs container si vous n'en avez pas besoin.
- Marquez comme obligatoire le champ qui sert de clé naturelle ; il formera l'EntityKey.
- Ajoutez au besoin les champs d'une data source liée (par exemple l'adresse), puis terminez.
Donnez à l'entité un libellé unique : Microsoft signale que deux entités avec le même libellé peuvent disparaître de la liste après actualisation.
Étape 2 : compiler, synchroniser, vérifier
Les entités sont créées comme des vues SQL, avec leur table de staging : il faut synchroniser la base. Passez la propriété du projet « Synchronize database on build » à True, puis compilez.
Ouvrez ensuite l'entité dans le designer pour vérifier les propriétés, la clé (EntityKey) et, pour une data source liée par clé étrangère, la propriété Is Read Only (à No pour pouvoir écrire). Vérifiez aussi la table de staging générée.
Après déploiement sur un environnement où la gestion des données est déjà utilisée, lancez l'actualisation manuelle : Gestion des données > Paramètres de structure > Paramètres d'entité > Actualiser la liste des entités. Sinon, la nouvelle entité n'apparaît pas.
Étape 3 : exporter avec DMF
- Ouvrez l'espace de travail Gestion des données et sélectionnez la vignette Exporter.
- Nommez le projet, ajoutez votre entité, choisissez le format cible (Microsoft indique 14 formats disponibles à l'export) et appliquez un filtre si besoin.
- Enregistrez puis exportez : un travail est créé, avec un suivi du statut et du nombre d'enregistrements.
- Téléchargez le résultat : un fichier par entité, ou un package (zip contenant les fichiers, un en-tête et un manifeste) réimportable tel quel.
Pour l'import, le principe est symétrique (vignette Importer, chargement du fichier, vérification du mapping avec « View map »). En cas d'erreur d'export, consultez le journal d'exécution ; si le message demande de ne pas ignorer le staging, désactivez « Skip staging » pour cette entité.
Erreurs fréquentes et performances
- Plus de 26 jointures dans l'entité : c'est la limite par défaut ; au-delà, l'entité échoue. Pour l'export, Microsoft recommande de rester à 0-3 jointures si possible ; à partir de 8, les performances sont lentes.
- Des colonnes calculées qui contiennent des jointures : ajoutez plutôt les tables comme data sources. Voir champ calculé Dynamics 365 F&O.
- Une méthode postLoad ou un champ virtuel : l'export doit alors passer par le staging, ce qui le ralentit.
- Des champs container à exporter sans implémenter getFieldsToBeConvertedToFile.
- Un nom d'entité avec « _ » ou des chiffres, ou un libellé en double.
- Oublier « Refresh entity list » après un déploiement.
Faire générer l'entité
Entité, staging, champs calculés, sécurité et tests : Skalp AI génère ce développement à partir de votre besoin, livré sur votre Azure DevOps et validé par votre DSI. Voir data entities et packages DMF D365, le cadre général dans développer en X++ sans consultant en 2026, et les offres Basic, Pro et Max. Si l'entité doit servir à un agent IA, lisez aussi serveur MCP Dynamics 365 ERP : les agents lisent et écrivent d'abord via les data entities.
Sources
- Microsoft Learn, « Build and consume data entities », mise à jour du 29/10/2025, consultée le 11/10/2026.
- Microsoft Learn, « Data entities overview », mise à jour du 03/04/2026, consultée le 11/10/2026.
- Microsoft Learn, « Data management overview », mise à jour du 14/01/2026, consultée le 11/10/2026.
- Microsoft Learn, « Data entity export performance tips », mise à jour du 26/09/2026, consultée le 11/10/2026.
Questions fréquentes
Pourquoi ma nouvelle data entity n'apparaît-elle pas dans Gestion des données ?
Après un déploiement sur un environnement déjà utilisé, il faut lancer manuellement « Refresh entity list » (Gestion des données > Paramètres de structure > Paramètres d'entité). Vérifiez aussi que l'option de gestion des données est activée et que le libellé est unique.
Faut-il passer par la table de staging à l'export ?
Pas en général. Microsoft conseille de ne l'utiliser que si l'entité a une méthode postLoad, un champ virtuel, des images à exporter, ou des colonnes liées à des clés de configuration désactivées.
Combien de jointures une data entity peut-elle avoir ?
La limite par défaut est de 26 jointures, et Microsoft déconseille de l'augmenter. Pour l'export, visez 0 à 3 jointures pour de bonnes performances.
Prêt à transformer votre D365 ?
Rejoignez les DSI qui développent leurs tickets D365 en 1h pour 1 crédit (≈ 400 € en Basic, 200 € en Pro).