Dal middleware alla connessione nativa in Odoo: quando conviene passare e come farlo senza fermare l'operatività

Conviene eliminare il middleware quando quel livello conserva uno stato che dovrebbe stare in Odoo: la giacenza che pubblichi, lo stato reale di ogni ordine, il tracking che torna al canale. Non conviene quando si limita a trasportare: riceve un file e lo deposita altrove senza decidere nulla. Questa è l'intera regola. Quello che segue: quando la risposta onesta è «non passare» e come si fa il cambio senza smettere di evadere ordini, raccontato a partire dalla nostra migrazione a connettori che vivono dentro Odoo, in produzione.

Quanto ti costa il middleware in lavoro quotidiano, non in denaro

L'argomento di togliere un livello lo abbiamo già affrontato con la fattura elettronica in SERES da Odoo, e il confronto di fondo è in Odoo 19 contro connettori con middleware. Con marketplace e corrieri è la stessa cosa moltiplicata per gli ordini del giorno: quattro attività che nessuno mette a budget.

La riga del log merita un avvertimento: «ce l'abbiamo in Odoo» non significa che venga scritto. Nell'audit del nostro connettore di Mirakl, la funzione che registrava ogni chiamata chiedeva if not log_model, e l'helper restituiva un recordset vuoto quando tutto andava bene; in Odoo un recordset vuoto è falso, quindi la registrazione è stata un no-op fin dal primo giorno. La prova era in produzione: la sequenza di quella tabella era ancora a NULL dopo mesi di cron. Oggi il controllo è if log_model is False.

Quando non conviene passare: i tre casi chiari

1. Più ERP. Se Odoo gestisce una società e un altro sistema ne gestisce un'altra, ed entrambe vendono sugli stessi canali, il middleware è l'unico posto in cui la giacenza pubblicata è la somma dei due.
2. Orchestrazione tra terzi. Se il flusso è marketplace → operatore logistico esterno → corriere e Odoo lo viene a sapere solo alla fine, il livello dirige sistemi che non sono tuoi.
3. Nessuno che mantenga Odoo. Un connettore nativo è codice dentro il tuo ERP. Se nessuno, interno o partner di Odoo, farà quel lavoro, il middleware con il suo canone è l'opzione economica.

Il piano di migrazione senza fermare l'operatività

Quattro passi e un principio: la connessione nativa entra in sola lettura e non scrive verso l'esterno finché non legge da giorni le stesse cose del middleware. Lo abbiamo applicato a giugno 2026 sostituendo, nella nostra produzione su Odoo.sh, un vecchio modulo di Amazon con il connettore che chiama SP-API da Odoo.

1. Inventario dei flussi, con direzione

Una riga per flusso: ordini in ingresso, giacenza e prezzi in uscita, tracking in uscita, annullamenti e resi in ingresso, fatture in invio. Per ciascuna, direzione, frequenza e innesco (cron, webhook o persona). Un marketplace Mirakl dà da otto a dodici righe; un corriere, tre o quattro; una piattaforma di firma, due.

2. Ordine: lettura prima della scrittura

Il connettore nativo si installa con tutte le scritture verso il terzo spente: nel nostro, un interruttore globale più un indicatore per account per ogni azione in uscita. Legge solo ordini, stati e magazzino; il middleware continua a scrivere e nessuno smette di evadere. Qui è emerso il primo errore del passaggio: il nuovo importatore controllava se un ordine esisteva guardando la propria tabella, appena creata e vuota, e non gli ordini di vendita che il sistema precedente aveva già creato. Risultato: diciassette ordini di vendita duplicati e confermati, ciascuno con una nuova prenotazione di giacenza. La correzione è stata cercare il riferimento del marketplace in sale.order prima di creare qualsiasi cosa. La regola: si deduplica rispetto alla destinazione, mai rispetto alla tabella intermedia del connettore stesso.

3. Periodo in parallelo con confronto giornaliero

Una o due settimane con i due sistemi che leggono lo stesso canale e, ogni mattina, un breve elenco: ordini che uno ha importato e l'altro no, stati che non coincidono, SKU non abbinati. Zero per due giorni di fila, e solo allora la prima scrittura.

4. Passaggio per canale, e scritture solo in avanti

Si passa un canale, non tutti. E quando si accendono le scritture, solo quelle innescate da una transizione: confermare la spedizione alla convalida di una consegna è sicuro, perché avviene una volta per ogni ordine che parte davvero. Non è sicuro un cron che scorre i record esistenti e li rinvia. Nel nostro passaggio restavano 534 consegne storiche completate e contrassegnate come «in attesa di sincronizzazione» dal vecchio modulo; il cron dei tentativi le ha trovate e ha inviato 28 conferme di spedizione ad Amazon in quattro minuti, prima che lo spegnessimo. La lezione: prima di accendere un cron di scansione, riconcilia lo storico che resta nello stato che quel cron cerca.

I dati storici: cosa si migra e cosa si lascia in sola lettura

Si migra ciò che può ancora cambiare: ordini aperti, la mappatura SKU ↔ riferimento del canale, spedizioni il cui tracking non è ancora tornato al marketplace e resi in corso. Non si migrano lo storico delle chiamate né gli ordini chiusi: si chiede accesso in sola lettura al pannello per il periodo dei reclami. Nel nostro passaggio i dati di business non sono stati toccati: 1.838 ordini di vendita e 13.236 prodotti sono rimasti dove erano.

Come si verifica che la connessione nativa funzioni prima del passaggio

Con una build reale di Odoo e la sandbox del terzo, non con mock. Lo abbiamo raccontato con i numeri in i test erano verdi e il connettore non funzionava: un connettore con 236 test su 236 verdi in Odoo 19, 18 e 17 aveva 32 errori reali sotto, e un altro con 163 su 163 non aveva mai scritto una riga di log. Le tre prove che contano:

• La finestra di sincronizzazione chiede ciò che è cambiato, non ciò che è stato creato. Lo abbiamo sbagliato due volte: il connettore di Mirakl inviava start_date (creazione) invece di start_update_date, e quello di AliExpress filtrava per data di creazione dall'ultimo passaggio. In entrambi, un ordine creato al mattino e spedito al pomeriggio non rientrava più nella finestra e il suo stato in Odoo restava congelato.
• Il log ha delle righe. Dopo la prima importazione, conta i record del modello di log. Zero significa che non si scrive, non che non ci siano errori.
• La traccia è nella scheda. Da un ordine importato devi arrivare all'ordine di vendita, alla consegna e al tracking senza uscire da Odoo.

Cosa resta dopo: chi mantiene il connettore nella versione successiva di Odoo

Questa è la parte che il middleware ti risparmiava e che ora è tua. Ogni versione di Odoo cambia qualcosa che un connettore tocca: nella 19, read_group è contrassegnato come obsoleto nello stesso ORM; nella 18 le viste elenco sono passate da <tree> a <list>; nella 17 un ir.cron senza numbercall viene eseguito una volta e si spegne da solo. Nessuna delle tre dà errore all'installazione. I nostri connettori si pubblicano per 19, 18 e 17 insieme e si testano su build reali di ogni serie. Prima di passare, decidi chi fa quel lavoro: il tuo team, un partner di Odoo, o l'autore del connettore se lo pubblica per più versioni e lo migra appena esce quella nuova.

Se il connettore è per il tuo software, in connettore Odoo per il tuo software spieghiamo come lavoriamo con i partner tecnologici; nel catalogo ci sono quelli che già dialogano con Amazon, Mirakl, ManoMano, AliExpress e i corrieri. Con più canali, l'ordine di passaggio dipende da quale canale pubblica la giacenza: ne parliamo in vendere su più marketplace da un unico Odoo e giacenza in tempo reale per i marketplace.

Checklist decisionale

• Il middleware conserva giacenza, stato degli ordini o tracking che Odoo non ha? Se trasporta solo file, non passare.
• Un solo ERP, o più sistemi che vendono sugli stessi canali? Odoo viene a sapere dell'ordine all'inizio del flusso o alla fine?
• Chi porta il connettore alla versione successiva di Odoo, e quando?
• Sai quanti record storici restano nello stato che cerca un cron di nuovi tentativi?

Se vuoi che qualcuno guardi il tuo caso con questi criteri, in servizi e soluzioni trovi come lavoriamo.

Domande frequenti

Link utili dentro FlexigoTech

Cosa facciamo in merito