Le letture e le scritture
non fanno la stessa strada.
Dal data lake in lettura. Via API in scrittura.
Microsoft Dynamics espone i suoi dati su un data lake: è da lì che leggiamo. Le scritture invece vanno diritte, via API. Non è una complicazione: sono due strade perché servono a due cose diverse - la lettura deve reggere il volume senza appoggiarsi all'ERP, la scrittura deve arrivare subito.
Cosa passa, e da che parte.
La domanda tecnica non è con che protocollo. È chi è la fonte di verità: per ogni dato si decide una volta sola, e si scrive nella mappatura prima di scrivere codice. Con Dynamics la fonte è Dynamics per tutto quello che si legge; l'unica cosa che nasce fuori è l'ordine.
- Articoli e variantida Dynamics
- Il catalogo di stagione con taglie, colori e attributi, ricomposto in una forma su cui una piattaforma B2B può costruire una griglia.
- Listini e condizionida Dynamics
- Prezzi per cliente, scaglioni, valute, termini. Restano configurati in Dynamics; fuori si applicano, non si reinventano.
- Giacenze e magazzinoda Dynamics
- Disponibilità e movimentazioni. Arrivano dal lake, quindi hanno l'età dell'ultimo giro - e il progetto si disegna sapendolo, invece di far finta che siano di adesso.
- Anagrafiche clientida Dynamics
- Codici, condizioni, blocchi. Un cliente non si crea fuori da Dynamics: si legge, così non esistono due versioni della stessa azienda.
- Ordiniverso Dynamics
- L'unica cosa che nasce fuori. L'ordine raccolto in showroom o dal cliente viene scritto in Dynamics via API, sincrono: qui la strada lunga non andrebbe bene, perché chi ha appena confermato vuole vederlo passare.
Sono i flussi che abbiamo già portato in produzione: esempi, non un catalogo. Quello che sta in Dynamics in linea di principio si può leggere tutto; per quello che deve entrare in Dynamics si decide caso per caso, ed è una delle cose che la mappatura mette per iscritto prima di cominciare.
Due strade, perché servono a due cose diverse.
- // data lake
Per leggere, dal lake
Dynamics espone i dati su un data lake, e noi leggiamo da lì. Due vantaggi che si sentono: il volume non passa mai dall'ERP, quindi nessuna lettura pesante lo rallenta mentre l'azienda ci lavora; e si prendono in blocco le quantità che a record singolo costerebbero migliaia di chiamate. Il costo è uno, e va detto: il dato ha l'età dell'ultimo giro.
- // api
Per scrivere, la strada diretta
L'ordine non può aspettare un giro di pipeline: chi lo ha appena confermato deve vederlo arrivare. Le scritture escono quindi via API, sincrone, ed è l'unica strada che modifica Dynamics - motivo per cui la lista di cosa può essere scritto sta nella mappatura, non in un permesso generico.
Le scritture sono progettate per essere ripetibili senza danni: se la rete cade a metà, l'ordine non finisce due volte in Dynamics. E ogni chiamata resta nel registro - quando qualcuno chiede perché quell'ordine è arrivato così, la risposta è un record e non una ricostruzione a memoria.
Un dato vecchio di mezz'ora non è un problema. Uno che finge di essere di adesso, sì.
Il dato ha un'età. Conviene dichiararla.
Quando le letture passano da una pipeline, la tentazione è non parlarne e lasciar credere che tutto sia in tempo reale. È la scelta che si paga il giorno in cui un commerciale vende una taglia che non c'è più. Meglio il contrario: si dichiara ogni quanto gira, chi legge lo sa, e le decisioni che non tollerano ritardo passano da un'altra parte.
- // freschezza
L'età del dato è scritta
Ogni flusso ha un momento di aggiornamento noto, e chi lo consuma lo vede. Un dato vecchio di mezz'ora dichiarata è utilizzabile; uno che sembra di adesso e non lo è, no.
- // permessi
Permessi per ruolo
Chi legge e chi scrive cosa è deciso fuori da Dynamics. La piattaforma vede articoli, listini e giacenze, non i costi; un agente AI vede quello che gli è stato concesso e nient'altro.
- // registro
Registro di ogni chiamata
Sia le scritture via API sia i giri della pipeline restano scritti. Serve il giorno in cui un ordine è arrivato strano e bisogna sapere con che dati era stato costruito.
- // no-copie
Quello che leggiamo non è una seconda verità
Il dato che arriva dal lake è una copia di lavoro, dichiarata tale: si legge da lì per non pesare sull'ERP, ma la verità resta in Dynamics. Se i due divergono, ha ragione Dynamics - e questo è scritto, non implicito.
Non siamo revendor Microsoft e non prendiamo provvigioni su licenze: ci colleghiamo a Dynamics come a qualunque altro sistema. Se il problema è collegarlo ad altri sistemi, la logica è quella del middleware; se è renderne i dati leggibili e incrociabili, è quella del layer dati. E se lavorate nel fashion B2B, la pagina del settore racconta l'anno intorno a cui tutto questo gira.
Un progetto vero, non uno schema.
La filiale europea di un brand globale di sportswear aveva appena adottato Dynamics come gestionale. La piattaforma wholesale che abbiamo costruito sopra - pre-order, ordini da magazzino, carryover e listini multi-stagionali - legge articoli, listini e giacenze dal suo data lake e le riscrive gli ordini via API, ed è andata in produzione poco dopo l'ERP invece di aspettarne l'assestamento.
Le domande che ci fanno sempre.
Le giacenze sono in tempo reale?
No, e chi vi dice di sì con questa architettura non vi sta dicendo tutto. Passando dal data lake, la disponibilità ha l'età dell'ultimo giro: si dichiara quanto è, e la piattaforma la mostra per quello che è. Se un singolo dato deve essere davvero istantaneo si porta su un'altra strada, e si decide in mappatura - non a go-live.
Perché passare da un data lake invece di leggere da Dynamics?
Per due ragioni pratiche. Il volume non passa mai dall'ERP, quindi nessuna lettura pesante lo rallenta mentre l'azienda ci lavora; e i dati si prendono in blocco invece di fare migliaia di chiamate a record singolo. Il prezzo è la latenza, ed è un prezzo che si può pagare in modo consapevole.
E i dati del lake dove finiscono?
Dipende dal progetto, e si decide in mappatura. Il layer può interrogare il lake direttamente; in un caso li abbiamo portati su un SQL Server, perché lì serviva interrogarli in SQL con strumenti che il cliente aveva già. È un'opzione, non un passaggio obbligato: è un pezzo in più da mantenere, quindi si aggiunge quando serve davvero.
Siete partner o revendor Microsoft?
No, e non prendiamo provvigioni su licenze. Ci colleghiamo a Dynamics come a qualunque altro sistema. Il vantaggio per voi è tutto qui: quando diciamo che una cosa non conviene farla, non stiamo difendendo un margine.
E se un domani cambiamo gestionale?
Cambia il connettore verso Dynamics - la pipeline da un lato e le chiamate dall'altro - non la piattaforma che ci sta sopra. È il motivo per cui il punto in mezzo esiste. E il codice è vostro in ogni caso.