.svg)
Comprendre les entités de données dans Dynamics 365 F&O
Avant de choisir une méthode d'intégration, il est utile de comprendre comment Microsoft Dynamics 365 Finance & Operations (F&O) structure les données destinées à un échange externe.
Plutôt que d'exposer ses tables de base de données brutes directement à des systèmes externes, F&O utilise des entités de données : des représentations simplifiées et structurées des concepts de données sous-jacents tels que « client », « fournisseur » ou « ordre de fabrication ». Les entités de données appliquent automatiquement la logique métier, les règles de validation et les politiques de sécurité pertinentes, quelle que soit la méthode d'intégration qui y accède. Les trois modèles principaux, OData, DMF et Dual-write, interagissent avec F&O via ces entités de données plutôt que directement avec la base de données.
Cela est important dans la pratique, car cela signifie que les systèmes externes obtiennent une vue claire et contrôlée des données ERP au lieu d'avoir à naviguer dans des schémas normalisés complexes. Cela signifie également que toute intégration basée sur des entités de données hérite de la logique de validation que l'ERP applique à ces données, ce qui réduit le risque d'entrée d'enregistrements corrompus ou incohérents dans le système.
OData : intégration synchrone en temps réel pour les flux à faible volume
L'Open Data Protocol (OData) est le protocole standard pour la communication par API RESTful dans Dynamics 365 F&O. Il fonctionne de manière synchrone : lorsqu'un système externe envoie une demande, il attend que F&O traite et renvoie une réponse avant de continuer. Cela fait d'OData le bon choix pour les scénarios où la confirmation immédiate est importante et où les volumes de données sont faibles.
Quand les fabricants utilisent OData
- Intégrations PLM : Création d'une nouvelle fiche produit ou mise à jour d'une version spécifique de la nomenclature (BOM) directement à partir d'un système PLM, où le PLM doit confirmer que l'enregistrement a été accepté avant de poursuivre.
- Logistique et expédition : Consultation des taux de fret en temps réel ou mise à jour du statut d'une expédition lorsqu'un colis quitte le quai de chargement.
- Signaux MES légers : Envoi d'une notification en temps réel à F&O indiquant qu'une machine a terminé une étape de production et consommé une quantité définie de matières premières.
Où se décompose OData
Dynamics 365 F&O applique des limites de limitation strictes à OData afin de protéger les performances du système. Si un système externe, tel qu'un WMS à volume élevé ou un outil d'analyse agressif, envoie trop de demandes rapides, F&O les limitera ou les rejettera. Cela peut entraîner des demandes qui expirent et des échecs d'intégration exactement au moment où les systèmes opérationnels ont le plus besoin de données.
OData doit être réservé strictement aux données transactionnelles de faible volume et de haute urgence. Son utilisation pour les opérations en masse est l'une des sources les plus courantes d'instabilité de l'intégration de Dynamics 365 dans les environnements de fabrication.
DMF : traitement par lots asynchrone pour les gros volumes de données
Le Data Management Framework (DMF), également appelé DIXF dans les versions précédentes de Dynamics 365, gère le scénario inverse : des volumes de données importants ne nécessitant pas de réponse immédiate. Plutôt que de traiter les demandes de manière synchrone, DMF accepte les fichiers dans des formats tels que XML, CSV ou JSON via une file d'attente de stockage et les traite de manière planifiée, sans entrer en concurrence avec les opérations ERP en temps réel pour les ressources système.
Quand les fabricants utilisent le DMF
- Intégration WMS : Traitement des journaux d'inventaire de fin de quart de travail, des itinéraires de collecte en vrac ou des ajustements importants du nombre de cycles à partir d'un système d'entrepôt tiers.
- Mises à jour des achats : Importation de catalogues de fournisseurs ou mise à jour simultanée de milliers de dates de livraison de bons de commande depuis un portail fournisseur.
- Entreposage et analyse des données : L'exportation de grands ensembles de données vers un environnement BYOD (Bring Your Own Database) ou Azure Data Lake permet aux outils d'informatique décisionnelle d'exécuter des requêtes complexes sans affecter les performances réelles de l'ERP.
Le compromis à comprendre
Le DMF introduit la latence. Comme il est asynchrone, le système récepteur ne reçoit pas de confirmation immédiate de l'acceptation des données. Pour les opérations où le timing n'est pas critique et où les volumes de données sont élevés, ce compromis vaut clairement la peine d'être fait. Pour tout ce qui nécessite un feedback en temps réel, DMF n'est pas le bon outil.
Double écriture : synchronisation en temps quasi réel au sein de l'écosystème Microsoft
La double écriture est l'infrastructure native de Microsoft pour la synchronisation bidirectionnelle en temps quasi réel entre Dynamics 365 F&O et Microsoft Dataverse, qui est la base de données sous-jacente pour les applications Dynamics 365 Customer Engagement, notamment Sales, Field Service et Customer Service.
Lorsque la double écriture est configurée, un changement de données dans F&O déclenche une mise à jour correspondante dans Dataverse presque immédiatement, et vice versa. Il s'agit de l'outil idéal lorsqu'un fabricant a besoin de données de base pour rester aligné sur toutes les applications Microsoft sans étapes de synchronisation manuelles.
Quand les fabricants utilisent la double écriture
Un représentant commercial crée un nouveau compte client dans Dynamics 365 Sales. La double écriture propage automatiquement cette fiche client à F&O. Les catalogues de produits, les structures tarifaires et les dossiers clients restent cohérents dans l'ensemble de l'écosystème Microsoft, sans que personne ne saisisse à nouveau manuellement les données entre les systèmes.
Là où la double écriture a ses limites
Étant donné que la double écriture fonctionne de manière synchrone sur deux bases de données distinctes, elle entraîne une surcharge en termes de performances. Si l'un des systèmes est temporairement indisponible, la transaction peut échouer dans les deux systèmes. Il convient donc parfaitement à l'alignement des données de base, aux dossiers clients, aux catalogues de produits, à la tarification, mais pas aux données transactionnelles volumineuses telles que des milliers de mouvements de stocks individuels ou la télémétrie brute provenant de capteurs d'atelier, où DMF ou OData constituent le choix le plus approprié.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
