Odoo 19 vs connectors amb middleware: quan convé integrar dins d'Odoo

Un connector natiu a Odoo 19 convé quan Odoo mana sobre l'estoc, les comandes, els enviaments i les factures: cada estat viu una sola vegada, a la fitxa on treballa l'equip. Un middleware convé quan només cal transportar dades sense prendre decisions operatives, o quan ningú no mantindrà codi dins d'Odoo. Connectar una API una vegada mai no ha estat el problema: el problema és mantenir comandes, estoc, errors i traçabilitat quan l'operació creix.

La diferència real no és a l'API

L'API d'Amazon, de Mirakl o d'un transportista és la mateixa la cridi qui la cridi. El que canvia és qui guarda el resultat i on el veu la persona que prepara la comanda: aquí hi ha la diferència, no a l'API.

Si Odoo ha de reservar estoc, preparar comandes, generar albarans, crear etiquetes i tornar el tracking al canal, la integració nativa deixa la traçabilitat on treballa l'equip. Amb una capa intermèdia, cada pas existeix dues vegades i les dues còpies només coincideixen si algú ho comprova.

Quan triar un connector natiu a Odoo

Té sentit quan Odoo és el sistema mestre de producte, estoc, comandes, logística i facturació. També quan necessites regles pròpies: multimagatzem, validacions abans d'enviar, reintents, registre de crides per comanda i errors que l'usuari vegi a la seva pantalla.

Als nostres connectors de marketplace, el registre de cada crida és un model d'Odoo amb mètode, endpoint, paràmetres, cos enviat, codi i cos de resposta, intent i durada en mil·lisegons, amb purga configurable. Es filtra com qualsevol llista d'Odoo, sense dependre d'un tauler extern.

Quan un middleware pot servir

Si només mous dades senzilles entre dos sistemes, sense decisions operatives complexes, un middleware pot accelerar l'arrencada. També si diversos ERP venen als mateixos canals i l'estoc publicat ha de ser la suma. I, sobretot, si ningú, ni intern ni partner d'Odoo, mantindrà codi dins de l'ERP.

El risc apareix quan l'equip revisa tres taulers per saber si una comanda està venuda, reservada, enviada o fallida: aquell dia el middleware ha deixat de transportar i ha començat a guardar estat.

Què costa un middleware en feina diària

El compte que importa no és la quota mensual: són les tasques que apareixen tan bon punt hi ha una capa intermèdia i que ningú no pressuposta. Són quatre.

1. El doble mestre. El producte es dona d'alta a Odoo i, a més, es mapeja al middleware: SKU, categoria del canal, atributs obligatoris. Cada alta, cada canvi d'EAN i cada variant nova són dues edicions. Amb un connector natiu, el mapatge al canal és un camp més del producte a Odoo.
2. La reconciliació d'estats. Una comanda de marketplace té tres veritats: la del canal, la del middleware i la d'Odoo. Quan no coincideixen (una comanda cancel·lada al canal que a Odoo continua reservant estoc) algú ho descobreix a mà. Amb el connector dins d'Odoo en queden dues, i l'estat remot es guarda tal com el retorna l'API al costat de la comanda de venda, amb l'hora de l'última sincronització.
3. Qui mira el log. L'error d'una crida viu al tauler del proveïdor, amb el seu usuari i la seva retenció. Qui veu la comanda encallada a Odoo normalment no té accés a aquest tauler. Si el log és un model d'Odoo, el veu qui té el problema, a la mateixa pantalla.
4. La pujada de versió. Quan Odoo passa de 18 a 19, el middleware promet que el seu costat no canvia. El que sí que canvia és el d'Odoo: el mòdul pont del proveïdor, els camps que llegeix i els webhooks que espera. Aquesta migració la fas igualment, al ritme del proveïdor i no al teu; publiquem per a 19, 18 i 17 alhora, com expliquem a mantenir un mòdul en tres versions.

Si ja pagues una capa intermèdia i sospites que et sobra, el pla de tall per canal és a del middleware a la connexió nativa a Odoo, explicat des de la nostra pròpia migració d'Amazon en producció.

On es perd la traçabilitat

El punt exacte és l'albarà. A Odoo, l'albarà (stock.picking) hereta de mail.thread i el seu estat té seguiment, així que cada pas a «fet» queda anotat amb data i usuari. Amb el mòdul de lliurament, el número de seguiment del transportista és un camp de l'albarà mateix (carrier_tracking_ref). Tot això ve de sèrie.

El que Odoo no sap de sèrie és si aquest tracking ha arribat al marketplace. Amb un middleware, la cadena comanda → albarà → tracking → confirmació al canal es parteix en dos: els dos primers eslavons a Odoo, els dos últims al tauler del proveïdor. El chatter de l'albarà diu «fet», i la prova que el comprador va veure el seu número és en un altre sistema.

Un connector natiu tanca la cadena al mateix lloc. Al nostre de Mirakl, validar l'albarà dispara l'enviament del tracking si la instància ho té activat, i el resultat s'escriu al chatter: una nota si es va enviar, una altra amb l'error si va fallar, i una altra de diferent si l'albarà no tenia número de seguiment i no es va enviar res. Les crides a Mirakl passen per la passarel·la de FlexigoTech Cloud, que no guarda ni registra el que porten, així que el que va passar amb cada enviament queda al teu Odoo.

Natiu tampoc no és màgia: 32 errors amb els tests en verd

La part incòmoda és nostra: «natiu» vol dir que el codi viu a Odoo, no que funcioni. Vam auditar un connector de marketplace propi abans de posar-lo davant d'un venedor real. La suite donava 236 de 236 en verd, sobre builds reals d'Odoo.sh a 19, 18 i 17. Per sota hi havia 32 errors reals: 20 de contracte amb l'API i 12 de versió d'Odoo.

Els de contracte eren paràmetres que l'API exigia i no s'enviaven, i camps de resposta llegits amb el nom equivocat, que retornen None sense llançar res. Quatre només van sortir cridant: la capçalera de paginació arribava relativa i a partir de la pàgina u no s'importava cap comanda; un 403 per quota no venia en el format documentat i es llegia com a manca de permisos, aturant tota la sincronització. Els de versió eren del mateix Odoo: un cron que a 17 corre una vegada i s'apaga sol, un camp de grups que es diu diferent a partir de 19, una vista de llista que 17 rebutja. La meitat no donava error: donava silenci.

El cas complet (inclòs un segon connector amb 163 de 163 en verd que mai no havia escrit una línia de log) és a els tests eren en verd i el connector no funcionava. La conclusió per a qui compara: demana al connector natiu el mateix que al middleware. Que estigui instal·lat de debò a la teva versió, no només que compili; que s'hagi contrastat amb l'especificació del proveïdor i no amb els seus propis mocks; i que hagi fet almenys una crida real per família d'endpoint. Si l'heretes d'un altre, la llista és a auditar un connector Odoo heretat.

Llista de verificació per decidir

• On es reserva l'estoc, i quants sistemes guarden una còpia del disponible?
• Qui crea l'albarà i l'etiqueta?
• On es veu l'error quan una API falla, i el veu la mateixa persona que veu la comanda?
• El tracking torna al canal automàticament, i queda anotat a l'albarà que ha tornat?
• Pots reintentar sense duplicar comandes o enviaments?
• Qui migra el connector quan surti la propera versió d'Odoo, i en quin termini?
• S'ha instal·lat de debò a la teva versió i provat contra el sandbox del proveïdor?

L'ordre en què es connecten diversos canals depèn de quin publica l'estoc: ho tractem a vendre a diversos marketplaces des d'un sol Odoo. Els connectors que ja parlen amb Amazon, Mirakl, ManoMano, AliExpress i els transportistes són al catàleg i a integracions i automatització Odoo; si és per al teu propi programari, connector Odoo per al teu programari.

Preguntes freqüents

Enllaços útils dins de FlexigoTech

El que fem sobre això