Del middleware a la connexió nativa a Odoo: quan val la pena moure's i com es fa sense aturar l'operació

Val la pena treure el middleware quan aquesta capa guarda un estat que Odoo hauria de tenir: l'estoc que es publica, l'estat real de cada comanda, el seguiment que torna al canal. No val la pena quan només transporta: rep un fitxer i el deixa en un altre lloc sense decidir res. Aquesta és tota la regla. El que ve a continuació: quan la resposta honesta és «no et moguis» i com es fa el canvi sense deixar de servir comandes, explicat des de la nostra pròpia migració a connectors que viuen dins d'Odoo, en producció.

Què et costa el middleware en feina diària, no en diners

L'argument de treure una capa ja el vam fer amb la factura electrònica a SERES des d'Odoo, i la comparativa de fons és a Odoo 19 davant de connectors amb middleware. Amb marketplaces i transportistes és el mateix multiplicat per les comandes del dia: quatre tasques que ningú pressuposta.

La fila del log mereix un avís: «ho tenim a Odoo» no vol dir que s'escrigui. A l'auditoria del nostre connector de Mirakl, la funció que registrava cada crida preguntava if not log_model, i l'ajudant retornava un recordset buit quan tot anava bé; a Odoo un recordset buit és fals, així que el registre va ser un no-op des del primer dia. La prova era a producció: la seqüència d'aquella taula seguia a NULL després de mesos de crons. Avui la comprovació és if log_model is False.

Quan no cal moure's: els tres casos clars

1. Diversos ERP. Si Odoo porta una societat i un altre sistema en porta una altra, i totes dues venen als mateixos canals, el middleware és l'únic lloc on l'estoc publicat és la suma dels dos.
2. Orquestració entre tercers. Si el flux és marketplace → operador logístic extern → transportista i Odoo només se n'assabenta al final, la capa dirigeix sistemes que no són teus.
3. Ningú que mantingui Odoo. Un connector natiu és codi dins del teu ERP. Si ningú, intern o partner d'Odoo, farà aquesta feina, el middleware amb la seva quota és l'opció barata.

El pla de migració sense aturar l'operació

Quatre passos i un principi: la connexió nativa entra llegint i no escriu cap a fora fins que fa dies que llegeix el mateix que el middleware. El vam aplicar el juny de 2026 en substituir, a la nostra pròpia producció a Odoo.sh, un mòdul antic d'Amazon pel connector que crida SP-API des d'Odoo.

1. Inventari de fluxos, amb direcció

Una fila per flux: comandes que entren, estoc i preus que surten, seguiment que surt, cancel·lacions i devolucions que entren, factures que pugen. Per a cadascuna, direcció, freqüència i disparador (cron, webhook o persona). Un marketplace de Mirakl dona entre vuit i dotze files; un transportista, tres o quatre; una plataforma de signatura, dues.

2. Ordre: lectura abans que escriptura

El connector natiu s'instal·la amb totes les escriptures cap al tercer apagades: al nostre, un interruptor global més un indicador per compte per a cada acció que surt. Només llegeix comandes, estats i inventari; el middleware continua escrivint i ningú deixa de servir. Aquí va sortir la primera errada del tall: l'importador nou comprovava si una comanda existia mirant la seva pròpia taula, acabada de crear i buida, i no les comandes de venda que el sistema anterior ja havia creat. Resultat: disset comandes de venda duplicades i confirmades, cadascuna reservant estoc una altra vegada. L'arranjament va ser buscar la referència del marketplace a sale.order abans de crear res. La regla: es deduplica contra la destinació, mai contra la taula intermèdia del propi connector.

3. Període en paral·lel amb comparació diària

Una o dues setmanes amb els dos sistemes llegint el mateix canal i, cada matí, una llista curta: comandes que un va importar i l'altre no, estats que no coincideixen, SKU sense casar. Zero dos dies seguits, i llavors la primera escriptura.

4. Tall per canal, i escriptures només cap endavant

Es talla un canal, no tots. I en encendre les escriptures, només les que dispara una transició: confirmar l'enviament en validar un albarà és segur, perquè passa una vegada per comanda que de veritat surt. Allò que no és segur és un cron que recorri registres existents i els reenviï. Al nostre tall quedaven 534 albarans històrics fets i marcats «pendent de sincronitzar» pel mòdul antic; el cron de reintents els va trobar i va enviar 28 confirmacions d'enviament a Amazon en quatre minuts, abans que l'apaguéssim. La lliçó: abans d'encendre un cron d'escombrada, reconcilia l'històric que queda en l'estat que aquest cron cerca.

Les dades històriques: què es migra i què es deixa en només lectura

Es migra el que encara pot canviar: comandes obertes, el mapatge SKU ↔ referència del canal, enviaments amb un seguiment que encara no ha tornat al marketplace i devolucions en curs. No es migra l'històric de crides ni les comandes tancades: es demana accés de només lectura al seu tauler durant el termini de reclamacions. Al nostre tall les dades de negoci no es van tocar: 1.838 comandes de venda i 13.236 productes van seguir on eren.

Com es comprova que la connexió nativa funciona abans del tall

Amb una build real d'Odoo i el sandbox del tercer, no amb mocks. Ho vam explicar amb números a els tests estaven en verd i el connector no funcionava: un connector amb 236 de 236 tests en verd a Odoo 19, 18 i 17 tenia 32 errades reals a sota, i un altre amb 163 de 163 mai no havia escrit una línia de log. Les tres proves que importen:

• La finestra de sincronització demana el que ha canviat, no el que s'ha creat. Ho vam cometre dues vegades: el connector de Mirakl enviava start_date (creació) en lloc de start_update_date, i el d'AliExpress filtrava per data de creació des de l'última passada. En tots dos, una comanda creada al matí i enviada a la tarda no tornava a entrar a la finestra i el seu estat a Odoo es quedava congelat.
• El log té files. Després de la primera importació, compta els registres del model de log. Zero vol dir que no s'escriu, no que no hi hagi errors.
• La traça és a la fitxa. Des d'una comanda importada has d'arribar a la comanda de venda, a l'albarà i al seguiment sense sortir d'Odoo.

Què queda després: qui manté el connector a la versió següent d'Odoo

Aquesta és la part que el middleware t'estalviava i ara és teva. Cada versió d'Odoo canvia alguna cosa que un connector toca: a la 19, read_group està marcat com a obsolet al propi ORM; a la 18 les vistes de llista van passar de <tree> a <list>; a la 17 un ir.cron sense numbercall corre una vegada i s'apaga sol. Cap de les tres dona error en instal·lar. Els nostres connectors es publiquen per a la 19, la 18 i la 17 alhora i es proven en builds reals de cada sèrie. Abans de moure't, decideix qui fa aquesta feina: el teu equip, un partner d'Odoo, o l'autor del connector si el publica per a diverses versions i el migra tan bon punt surt la nova.

Si el connector és per al teu propi programari, a connector Odoo per al teu programari expliquem com ho fem amb partners tecnològics; a el catàleg hi ha els que ja parlen amb Amazon, Mirakl, ManoMano, AliExpress i els transportistes. Amb diversos canals, l'ordre de tall depèn de quin canal publica l'estoc: ho tractem a vendre a diversos marketplaces des d'un sol Odoo i estoc en temps real per a marketplaces.

Checklist de decisió

• El middleware guarda estoc, estat de comanda o seguiment que Odoo no té? Si només transporta fitxers, no et moguis.
• Un sol ERP, o diversos venent als mateixos canals? Odoo s'assabenta de la comanda al principi del flux o al final?
• Qui passa el connector a la versió següent d'Odoo, i quan?
• Saps quants registres històrics queden en l'estat que cerca un cron de reintents?

Si vols que algú miri el teu cas amb aquests criteris, a serveis i solucions hi ha com treballem.

Preguntes freqüents

Enllaços útils dins de FlexigoTech

El que fem sobre això