Leggere da NetSuite,
e scriverci dentro.
Via API REST e ODBC.
Oracle NetSuite è il sistema che ha ragione su ordini, articoli, clienti e costi. Integrarlo sono due lavori insieme: tirare fuori i dati in una forma che gli altri sistemi e le persone riescano a usare - la sua struttura interna distribuisce una singola entità su più tabelle - e scriverci dentro quello che nasce altrove, un ordine da un portale, un'anagrafica da un e-commerce. Entrambi passano dalle sue API REST, e da un punto solo in mezzo.
Cosa passa, e in che direzione.
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. Su NetSuite la fonte è quasi sempre NetSuite; dove invece una cosa nasce fuori, ci viene scritta dentro, non ribattuta a mano.
- Anagrafiche clienti e fornitorinei due sensi
- Si leggono ricomposte in un record unico. E se un cliente nasce in un portale o in un e-commerce, viene creato in NetSuite invece di finire in una mail all'amministrazione.
- Ordininei due sensi
- Lo storico si legge per data, cliente e commessa. L'ordine nuovo - portale, e-commerce, web app del commerciale - viene scritto in NetSuite via API REST.
- Articoli e listinida NetSuite
- Le informazioni di un singolo articolo, sparse su più tabelle, diventano una riga leggibile senza conoscere lo schema.
- Costi e centri di costoda NetSuite
- Il pezzo che rende possibile la domanda che conta: quanto è costato davvero quel cliente, quel progetto, quella commessa.
- Magazzino e movimentida NetSuite
- Giacenze e movimentazioni, storicizzate: serve a guardare l'andamento e non solo la fotografia di oggi.
- Documentida NetSuite
- Fatture, DDT, conferme d'ordine, resi disponibili a chi li deve consultare senza chiederli in amministrazione.
Sono i flussi che abbiamo già portato in produzione: esempi, non un catalogo. Quello che sta in NetSuite in linea di principio si può leggere tutto - con la strada giusta fra le due qui sotto; per le scritture si decide caso per caso, e finisce nella mappatura prima di cominciare.
Due strade, perché servono a due cose diverse.
- // suiteanalytics connect · odbc
Per leggere a volume
Quando il lavoro è portare fuori molti dati - storici, costi, movimenti - li leggiamo via SuiteAnalytics Connect in ODBC: si interroga in SQL, e si prendono in un colpo le quantità che a record singolo costerebbero migliaia di chiamate. Ha una proprietà che vale più della velocità: è in sola lettura per progetto, quindi da quella strada NetSuite non può essere toccato nemmeno per errore.
- // api rest
Per il singolo record, e per scrivere
Tutto quello che riguarda un record alla volta - leggere un ordine appena creato, scriverne uno nuovo, aggiornare un'anagrafica - passa dalle API REST. È l'unica strada che scrive, ed è la ragione per cui la lista di cose che il layer può scrivere sta scritta nella mappatura.
Le scritture sono progettate per essere ripetibili senza danni: se la rete cade a metà, l'ordine non finisce due volte in NetSuite. E ogni chiamata, in lettura o in scrittura, resta nel registro - quando qualcuno chiede perché quel record è fatto così, la risposta è un record e non una ricostruzione a memoria.
Il gestionale ha ragione sui numeri. Non sulla forma in cui li tiene.
Un punto in mezzo, non le credenziali sparse in giro.
La scorciatoia è dare a ogni strumento le credenziali di NetSuite e lasciarlo fare da sé. Il giorno dopo avete quattro strumenti che interrogano l'ERP quando gli pare, nessuno che sappia chi ha letto o scritto cosa, e una query pesante che rallenta il gestionale a fine mese. Il punto in mezzo importa, normalizza, distribuisce - e scrive solo quello che gli è stato chiesto di scrivere.
- // forma
Normalizzazione, non copia
Non spostiamo le tabelle di NetSuite da un'altra parte: le ricomponiamo. Un'entità che stava su cinque tabelle diventa un record con un nome, e da lì una domanda diventa possibile.
- // permessi
Permessi per ruolo
Chi legge e chi scrive cosa è deciso fuori da NetSuite. L'e-commerce vede listini e giacenze, non i costi; un agente AI vede quello che gli è stato concesso e nient'altro.
- // api
API controllate, non chiavi in tasca
Gli altri applicativi parlano con il punto in mezzo, non con NetSuite. Nessuno gira con le credenziali dell'ERP, e ogni accesso passa da un posto che si può guardare.
- // scritture
Scritture esplicite
Cosa il layer può scrivere in NetSuite è una decisione del progetto, scritta nella mappatura. Non è un permesso generico: è una lista, e fuori da quella lista il gestionale è in sola lettura.
Non siamo revendor Oracle e non prendiamo provvigioni su licenze: ci colleghiamo alle sue API come a quelle di qualunque altro sistema. Se il problema è collegare NetSuite ad altri sistemi, la logica è quella del middleware; se è renderne i dati leggibili e incrociabili, è quella del layer dati - e con quel layer in piedi, aggiungere l'interrogazione in linguaggio naturale è un pezzo in più, non un progetto nuovo.
Un progetto vero, non uno schema.
Uno dei modi in cui questo lavoro prende forma - qui il pezzo in lettura, spinto fino in fondo. Un'agenzia nel settore eventi fashion e luxury: NetSuite, il sistema HR e dei fogli di calcolo vivevano in silos separati, ognuno con la propria logica. Oggi c'è una fonte unica, e chi ha una domanda la scrive in italiano invece di aprire un ticket, vedendo solo i dati per cui è autorizzato.
Le domande che ci fanno sempre.
Scrivete dentro NetSuite?
Sì, quando il progetto lo richiede: lo facciamo via le sue API REST. Ma è una decisione presa in chiaro e messa nella mappatura, non un permesso generico: fuori dalla lista di cose che può scrivere, il layer è in sola lettura. Ci sono progetti in cui non scrive niente - ed è la ragione per cui il responsabile del gestionale può dire sì senza rischi.
Siete partner o revendor Oracle?
No, e non prendiamo provvigioni su licenze. Ci colleghiamo alle API di NetSuite come a quelle di qualunque altro sistema. Il vantaggio per voi è tutto qui: quando diciamo che una cosa non conviene farla, non stiamo difendendo un margine.
Serve la licenza SuiteAnalytics Connect?
Solo se conviene prendere la strada ODBC, ed è un modulo a pagamento di NetSuite che non rivendiamo noi. Se non l'avete si legge via API REST: più chiamate per lo stesso risultato, e sui volumi bassi non cambia niente. La differenza si sente quando i dati da portare fuori sono molti - e la mappatura, prima di qualunque preventivo, dice se nel vostro caso vale la licenza o no.
Quanto tempo serve?
Dipende da quanti flussi servono davvero, e sono quasi sempre meno di quelli che sembrano all'inizio. Si parte da uno - di solito le anagrafiche o gli ordini - si mette in produzione, e si aggiunge il resto quando il primo regge. Non consegniamo sei flussi tutti insieme il giorno del go-live.
E se i dati non stanno solo in NetSuite?
È il caso normale, non l'eccezione: quasi sempre ci sono un applicativo HR, un e-commerce, qualche foglio di calcolo. Il punto in mezzo nasce per tenerli insieme, e le domande che incrociano le fonti sono quelle che nessuno riusciva a farsi prima.