Intégration de boutique avec Microsoft Dynamics 365 Business Central : flux, prérequis et contrôles

Nous connectons la boutique à Microsoft Dynamics 365 Business Central selon un flux précis et l’interface disponible. Business Central exige le choix explicite de l’environnement et de la société avant toute lecture ou écriture métier. Le connecteur associe clients, articles et lignes de commande avec des identifiants confirmés plutôt que des correspondances approximatives par nom.

Business Central exige le choix explicite de l’environnement et de la société avant toute lecture ou écriture métier. Le connecteur associe clients, articles et lignes de commande avec des identifiants confirmés plutôt que des correspondances approximatives par nom. L’accès sans intervention humaine utilise une application Entra et des jeux d’autorisations limités. Nous recommandons une identité d’intégration distincte pour que le départ d’un salarié ne coupe pas la connexion. La procédure de changement d’identifiants et de validation des permissions doit accompagner le code.

Microsoft fournit des ressources salesOrder et des consignes d’accès autonome avec OAuth client credentials. L’application doit être enregistrée dans Entra et autorisée dans Business Central. Elle reçoit les jeux d’autorisations adaptés, jamais SUPER. Business Central diffère de Dynamics 365 Sales et Finance. En installation locale, il faut une configuration Entra/OIDC correcte et confirmer l’activation des API.

Une société d’importation possède deux sociétés dans Business Central, mais la boutique appartient à une seule. Le company ID est fixé dans l’intégration et vérifié avant de créer une commande client. Le connecteur associe client et articles aux véritables identifiants de la société cible. Si les permissions permettent la lecture mais pas l’écriture, la commande reste en attente avec une cause claire. Le test inclut le renouvellement des identifiants pour que cette maintenance planifiée n’impose pas des saisies manuelles en double.

Un scénario critique apparaît lorsque les permissions autorisent la lecture mais pas la création de commandes. Nous conservons une référence externe et l’identifiant cible confirmé avant de répéter l’action. Nous distinguons échec d’accès, rejet métier et résultat incertain. L’opérateur doit pouvoir examiner l’enregistrement et rétablir la situation sans répéter les étapes terminées. Nous convenons des champs journalisés et du responsable des éléments en attente.

Nous vérifions accès limité, bonne société et renouvellement des identifiants sans interruption. Pour chaque cas, nous documentons données initiales attendues, enregistrement cible et statut vu par le client. Nous ajoutons un échec de permissions et une interruption de réponse. Nous répétons un événement confirmé et vérifions que son effet métier ne change pas. Le procès-verbal d’acceptation définit l’équipe responsable et les preuves nécessaires à la résolution d’un écart.

L’étude initiale confirme : enregistrement Entra et consentement ; application active dans Business Central avec permissions minimales ; identifiants d’environnement/société et données de test. Avant production, nous documentons le flux Application OAuth → API autorisée → Bonne société → correspondance clients/articles → Commande client → enregistrement de l’identifiant confirmé. Nous attribuons renouvellement des accès, surveillance et corrections. Une modification de configuration ou de règle métier déclenche un contrôle ciblé. Nous partons de ce flux précis et ajoutons un autre canal après clarification de ses responsabilités et scénarios d’acceptation.