Odoo 19 vs connettori con middleware: quando conviene integrare dentro Odoo

Un connettore nativo in Odoo 19 conviene quando Odoo governa giacenze, ordini, spedizioni e fatture: ogni stato vive una sola volta, nella scheda in cui lavora il team. Un middleware conviene quando bisogna solo trasportare dati senza prendere decisioni operative, o quando nessuno manterrà codice dentro Odoo. Collegare un'API una volta non è mai stato il problema: il problema è tenere sotto controllo ordini, giacenze, errori e tracciabilità quando l'operatività cresce.

La differenza reale non sta nell'API

L'API di Amazon, di Mirakl o di un corriere è la stessa, chiunque la chiami. Cambia chi conserva il risultato e dove lo vede la persona che prepara l'ordine: la differenza è lì, non nell'API.

Se Odoo deve riservare giacenze, preparare ordini, generare documenti di consegna, creare etichette e restituire il tracking al canale, l'integrazione nativa lascia la tracciabilità dove lavora il team. Con un livello intermedio, ogni passaggio esiste due volte e le due copie coincidono solo se qualcuno le controlla.

Quando scegliere un connettore nativo in Odoo

Ha senso quando Odoo è il sistema master di prodotto, giacenze, ordini, logistica e fatturazione. Anche quando servono regole proprie: multi-magazzino, validazioni prima della spedizione, nuovi tentativi, registro delle chiamate per ordine ed errori che l'utente vede nella propria schermata.

Nei nostri connettori per marketplace, il registro di ogni chiamata è un modello di Odoo con metodo, endpoint, parametri, corpo inviato, codice e corpo della risposta, tentativo e durata in millisecondi, con pulizia configurabile. Si filtra come qualsiasi elenco di Odoo, senza dipendere da un pannello esterno.

Quando un middleware può servire

Se sposti solo dati semplici tra due sistemi, senza decisioni operative complesse, un middleware può accelerare l'avvio. Vale anche se più ERP vendono sugli stessi canali e la giacenza pubblicata deve essere la somma. E soprattutto se nessuno, né interno né partner di Odoo, manterrà codice dentro l'ERP.

Il rischio compare quando il team controlla tre pannelli per sapere se un ordine è venduto, riservato, spedito o fallito: quel giorno il middleware ha smesso di trasportare e ha iniziato a conservare stato.

Quanto costa un middleware nel lavoro quotidiano

Il conto che conta non è il canone mensile: sono le attività che compaiono appena c'è un livello intermedio e che nessuno mette a budget. Sono quattro.

1. Il doppio master. Il prodotto si crea in Odoo e inoltre si mappa nel middleware: SKU, categoria del canale, attributi obbligatori. Ogni inserimento, ogni cambio di EAN e ogni nuova variante sono due modifiche. Con un connettore nativo, la mappatura sul canale è un campo in più del prodotto in Odoo.
2. La riconciliazione degli stati. Un ordine di marketplace ha tre verità: quella del canale, quella del middleware e quella di Odoo. Quando non coincidono (un ordine annullato sul canale che in Odoo continua a riservare giacenza) qualcuno lo scopre a mano. Con il connettore dentro Odoo ne restano due, e lo stato remoto viene salvato così come lo restituisce l'API accanto all'ordine di vendita, con l'ora dell'ultima sincronizzazione.
3. Chi guarda il log. L'errore di una chiamata vive nel pannello del fornitore, con il suo utente e la sua conservazione. Chi vede l'ordine bloccato in Odoo di solito non ha accesso a quel pannello. Se il log è un modello di Odoo, lo vede chi ha il problema, nella stessa schermata.
4. L'aggiornamento di versione. Quando Odoo passa dalla 18 alla 19, il middleware promette che il suo lato non cambia. Quello che cambia è il lato di Odoo: il modulo ponte del fornitore, i campi che legge e i webhook che si aspetta. Quella migrazione la fai comunque, al ritmo del fornitore e non al tuo; noi pubblichiamo per 19, 18 e 17 insieme, come raccontiamo in mantenere un modulo su tre versioni.

Se già paghi un livello intermedio e sospetti che sia superfluo, il piano di passaggio canale per canale è in dal middleware alla connessione nativa in Odoo, raccontato a partire dalla nostra migrazione di Amazon in produzione.

Dove si perde la tracciabilità

Il punto esatto è il documento di consegna. In Odoo, il documento di consegna (stock.picking) eredita da mail.thread e il suo stato ha tracciamento, quindi ogni passaggio a «fatto» viene annotato con data e utente. Con il modulo di consegna, il numero di tracking del corriere è un campo del documento stesso (carrier_tracking_ref). Tutto questo è di serie.

Quello che Odoo non sa di serie è se quel tracking sia arrivato al marketplace. Con un middleware, la catena ordine → consegna → tracking → conferma al canale si spezza in due: i primi due anelli in Odoo, gli ultimi due nel pannello del fornitore. Il chatter del documento di consegna dice «fatto», e la prova che l'acquirente abbia visto il suo numero sta in un altro sistema.

Un connettore nativo chiude la catena nello stesso posto. Nel nostro connettore Mirakl, convalidare il documento di consegna fa partire l'invio del tracking se l'istanza lo ha attivato, e il risultato viene scritto nel chatter: una nota se è stato inviato, un'altra con l'errore se è fallito, e una diversa se il documento non aveva numero di tracking e non è stato inviato nulla. Le chiamate a Mirakl passano dal gateway di FlexigoTech Cloud, che non conserva né registra ciò che trasportano, quindi quello che è successo con ogni invio resta nel tuo Odoo.

Nativo non è magia: 32 difetti con i test verdi

La parte scomoda è nostra: «nativo» significa che il codice vive in Odoo, non che funzioni. Abbiamo fatto l'audit di un connettore per marketplace nostro prima di metterlo davanti a un venditore reale. La suite dava 236 su 236 verdi, su build reali di Odoo.sh in 19, 18 e 17. Sotto c'erano 32 difetti reali: 20 di contratto con l'API e 12 di versione di Odoo.

Quelli di contratto erano parametri che l'API richiedeva e non venivano inviati, e campi di risposta letti con il nome sbagliato, che restituiscono None senza sollevare nulla. Quattro sono emersi solo chiamando: l'intestazione di paginazione arrivava relativa e dalla pagina uno in poi non veniva importato nessun ordine; un 403 per quota non arrivava nel formato documentato e veniva letto come mancanza di permessi, fermando l'intera sincronizzazione. Quelli di versione erano di Odoo stesso: un cron che in 17 gira una volta e si spegne da solo, un campo dei gruppi che si chiama diversamente dalla 19 in poi, una vista elenco che la 17 rifiuta. Metà non dava errore: dava silenzio.

Il caso completo (incluso un secondo connettore con 163 su 163 verdi che non aveva mai scritto una riga di log) è in i test erano verdi e il connettore non funzionava. La conclusione per chi confronta: chiedi al connettore nativo quello che chiedi al middleware. Che sia installato davvero nella tua versione, non solo che compili; che sia stato confrontato con la specifica del fornitore e non con i suoi mock; e che abbia fatto almeno una chiamata reale per famiglia di endpoint. Se lo erediti da un altro, la lista è in fare l'audit di un connettore Odoo ereditato.

Checklist decisionale

• Dove si riserva la giacenza e quanti sistemi conservano una copia del disponibile?
• Chi crea il documento di consegna e l'etichetta?
• Dove si vede l'errore quando un'API fallisce, e lo vede la stessa persona che vede l'ordine?
• Il tracking torna al canale automaticamente e resta annotato nel documento di consegna che è tornato?
• Puoi riprovare senza duplicare ordini o spedizioni?
• Chi migra il connettore quando esce la prossima versione di Odoo, e in che tempi?
• È stato installato davvero nella tua versione e provato contro la sandbox del fornitore?

L'ordine in cui si collegano più canali dipende da quale pubblica la giacenza: ne parliamo in vendere su più marketplace da un solo Odoo. I connettori che già dialogano con Amazon, Mirakl, ManoMano, AliExpress e i corrieri sono nel catalogo e in integrazioni e automazione Odoo; se è per il tuo software, connettore Odoo per il tuo software.

Domande frequenti

Link utili dentro FlexigoTech

Cosa facciamo su questo