Integrazione Eshop con Microsoft Dynamics 365 Business Central: flussi, requisiti e verifiche

Colleghiamo l'Eshop a Microsoft Dynamics 365 Business Central con un flusso specifico e l'interfaccia disponibile nell'installazione. Business Central richiede una scelta esplicita di ambiente e società prima di leggere o registrare qualsiasi dato operativo. Il connettore mappa customer, item e righe sales order, conservando ID confermati anziché corrispondenze ambigue sui nomi.

Business Central richiede una scelta esplicita di ambiente e società prima di leggere o registrare qualsiasi dato operativo. Il connettore mappa customer, item e righe sales order, conservando ID confermati anziché corrispondenze ambigue sui nomi. L'accesso non presidiato viene organizzato con un'applicazione Entra e permission set limitati. Proponiamo un'identità d'integrazione separata, affinché l'uscita di un dipendente non interrompa il collegamento del negozio. La procedura di modifica delle credenziali e approvazione dei permessi deve essere consegnata insieme al codice.

Microsoft offre risorse salesOrder e indicazioni per l'accesso non presidiato con credenziali client OAuth. Occorrono registrazione dell'applicazione in Entra e concessione dell'accesso in Business Central. L'applicazione riceve permission set appropriati, non SUPER. Business Central differisce da Dynamics 365 Sales o Finance. In ambiente on-premise occorrono configurazione Entra/OIDC corretta e conferma dell'attivazione delle API.

Un'impresa di importazione ha due società in Business Central, ma l'Eshop appartiene a una sola. Il company ID è vincolato alla specifica integrazione e verificato prima di registrare un sales order. Il connettore associa cliente e articoli ai veri ID della società di destinazione. Se i permessi consentono lettura ma non scrittura, l'ordine resta in sospeso con una causa chiara. La prova comprende il cambio delle credenziali, affinché la manutenzione programmata dell'accesso non richieda registrazioni manuali duplicate.

Uno scenario critico si presenta quando i permessi dell'applicazione consentono la lettura ma non la registrazione degli ordini. Conserviamo riferimento esterno e ID di destinazione confermato prima di ripetere l'azione. Distinguiamo fallimento dell'accesso, rifiuto operativo e risultato incerto. L'operatore deve poter esaminare il record pertinente e ripristinare lo stato senza ripetere passaggi completati. Concordiamo quali campi compaiano nei log e chi gestisca le attività in sospeso.

Verifichiamo accesso limitato, società corretta e rinnovo delle credenziali senza interruzioni. Per ogni caso documentiamo dati iniziali attesi, record di destinazione e stato visto dal cliente. Aggiungiamo un errore di autorizzazione e un'interruzione della risposta. Ripetiamo un evento già confermato e verifichiamo che il risultato operativo non cambi. Il verbale di accettazione definisce il team responsabile e le prove necessarie per chiudere una discrepanza.

Lo studio iniziale conferma: registrazione dell'app Entra e consenso; applicazione attiva in Business Central con privilegi minimi; ID ambiente/società e dati di prova. Prima della produzione documentiamo la mappatura del flusso Applicazione OAuth → API autorizzata → Società corretta → mappatura customer/item → Sales order → salvataggio dell'ID confermato. Definiamo responsabilità per rinnovo degli accessi, monitoraggio e correzioni. Una modifica alla configurazione del prodotto o alla regola operativa concordata attiva una nuova verifica mirata. Partiamo da questo flusso specifico e aggiungiamo un altro canale dopo averne chiarito responsabilità e scenari di accettazione.