Do middleware à ligação nativa no Odoo: quando compensa mudar e como fazê-lo sem parar a operação

Compensa retirar o middleware quando essa camada guarda um estado que o Odoo deveria ter: o stock que se publica, o estado real de cada encomenda, o tracking que volta ao canal. Não compensa quando apenas transporta: recebe um ficheiro e deixa-o noutro sítio sem decidir nada. Essa é a regra inteira. O que se segue: quando a resposta honesta é «não mude» e como se faz a mudança sem deixar de servir encomendas, contado a partir da nossa própria migração para conectores que vivem dentro do Odoo, em produção.

O que o middleware lhe custa em trabalho diário, não em dinheiro

O argumento de retirar uma camada já o fizemos com a fatura eletrónica em SERES a partir do Odoo, e a comparação de fundo está em Odoo 19 face a conectores com middleware. Com marketplaces e transportadoras é o mesmo, multiplicado pelas encomendas do dia: quatro tarefas que ninguém orça.

A linha do log merece um aviso: «temos isso no Odoo» não significa que se escreva. Na auditoria do nosso conector de Mirakl, a função que registava cada chamada perguntava if not log_model, e o auxiliar devolvia um recordset vazio quando tudo corria bem; no Odoo um recordset vazio é falso, pelo que o registo foi um no-op desde o primeiro dia. A prova estava em produção: a sequência dessa tabela continuava em NULL passados meses de crons. Hoje a verificação é if log_model is False.

Quando não deve mudar: os três casos claros

1. Vários ERP. Se o Odoo gere uma sociedade e outro sistema gere outra, e ambas vendem nos mesmos canais, o middleware é o único sítio onde o stock publicado é a soma dos dois.
2. Orquestração entre terceiros. Se o fluxo é marketplace → operador logístico externo → transportadora e o Odoo só fica a saber no fim, a camada dirige sistemas que não são seus.
3. Ninguém que mantenha o Odoo. Um conector nativo é código dentro do seu ERP. Se ninguém, interno ou partner de Odoo, vai fazer esse trabalho, o middleware com a sua mensalidade é a opção barata.

O plano de migração sem parar a operação

Quatro passos e um princípio: a ligação nativa entra a ler e não escreve para fora até levar dias a ler o mesmo que o middleware. Aplicámo-lo em junho de 2026 ao substituir, na nossa própria produção no Odoo.sh, um módulo antigo da Amazon pelo conector que chama a SP-API a partir do Odoo.

1. Inventário de fluxos, com direção

Uma linha por fluxo: encomendas que entram, stock e preços que saem, tracking que sai, cancelamentos e devoluções que entram, faturas que sobem. Para cada uma, direção, frequência e desencadeador (cron, webhook ou pessoa). Um marketplace de Mirakl dá entre oito e doze linhas; uma transportadora, três ou quatro; uma plataforma de assinatura, duas.

2. Ordem: leitura antes de escrita

O conector nativo instala-se com todas as escritas para o terceiro desligadas: no nosso, um interruptor global mais um indicador por conta para cada ação que sai. Só lê encomendas, estados e inventário; o middleware continua a escrever e ninguém deixa de servir. Aqui surgiu a primeira falha do corte: o novo importador verificava se uma encomenda existia olhando para a sua própria tabela, recém-criada e vazia, e não para as encomendas de venda que o sistema anterior já tinha criado. Resultado: dezassete encomendas de venda duplicadas e confirmadas, cada uma a reservar stock outra vez. A correção foi procurar a referência do marketplace em sale.order antes de criar fosse o que fosse. A regra: deduplica-se contra o destino, nunca contra a tabela intermédia do próprio conector.

3. Período em paralelo com comparação diária

Uma ou duas semanas com os dois sistemas a ler o mesmo canal e, todas as manhãs, uma lista curta: encomendas que um importou e o outro não, estados que não coincidem, SKU sem correspondência. Zero dois dias seguidos, e então a primeira escrita.

4. Corte por canal, e escritas só para a frente

Corta-se um canal, não todos. E ao ligar as escritas, só as que são desencadeadas por uma transição: confirmar o envio ao validar uma guia de remessa é seguro, porque acontece uma vez por encomenda que realmente sai. O que não é seguro é um cron que percorra registos existentes e os reenvie. No nosso corte havia 534 guias de remessa históricas concluídas e marcadas como «pendente de sincronizar» pelo módulo antigo; o cron de tentativas encontrou-as e enviou 28 confirmações de envio à Amazon em quatro minutos, antes de o desligarmos. A lição: antes de ligar um cron de varrimento, reconcilie o histórico que resta no estado que esse cron procura.

Os dados históricos: o que se migra e o que se deixa só de leitura

Migra-se o que ainda pode mudar: encomendas abertas, o mapeamento SKU ↔ referência do canal, envios cujo tracking ainda não voltou ao marketplace e devoluções em curso. Não se migra o histórico de chamadas nem as encomendas fechadas: pede-se acesso só de leitura ao respetivo painel durante o prazo de reclamações. No nosso corte os dados de negócio não foram tocados: 1 838 encomendas de venda e 13 236 produtos continuaram onde estavam.

Como se comprova que a ligação nativa funciona antes do corte

Com uma build real do Odoo e a sandbox do terceiro, não com mocks. Contámo-lo com números em os testes estavam a verde e o conector não funcionava: um conector com 236 de 236 testes a verde no Odoo 19, 18 e 17 tinha 32 falhas reais por baixo, e outro com 163 de 163 nunca tinha escrito uma linha de log. As três provas que importam:

• A janela de sincronização pede o que mudou, não o que foi criado. Cometemo-lo duas vezes: o conector de Mirakl enviava start_date (criação) em vez de start_update_date, e o de AliExpress filtrava por data de criação desde a última passagem. Em ambos, uma encomenda criada de manhã e enviada à tarde não voltava a entrar na janela e o seu estado no Odoo ficava congelado.
• O log tem linhas. Depois da primeira importação, conte os registos do modelo de log. Zero significa que não se escreve, não que não haja erros.
• O rasto está na ficha. A partir de uma encomenda importada tem de chegar à encomenda de venda, à guia de remessa e ao tracking sem sair do Odoo.

O que fica depois: quem mantém o conector na versão seguinte do Odoo

Esta é a parte que o middleware lhe poupava e que agora é sua. Cada versão do Odoo muda algo em que um conector toca: na 19, read_group está marcado como obsoleto no próprio ORM; na 18 as vistas de lista passaram de <tree> a <list>; na 17 um ir.cron sem numbercall corre uma vez e desliga-se sozinho. Nenhuma das três dá erro ao instalar. Os nossos conectores são publicados para a 19, 18 e 17 em simultâneo e testados em builds reais de cada série. Antes de mudar, decida quem faz esse trabalho: a sua equipa, um partner de Odoo, ou o autor do conector se o publicar para várias versões e o migrar assim que sai a nova.

Se o conector é para o seu próprio software, em conector Odoo para o seu software explicamos como o fazemos com partners tecnológicos; em o catálogo estão os que já comunicam com a Amazon, Mirakl, ManoMano, AliExpress e as transportadoras. Com vários canais, a ordem de corte depende de que canal publica o stock: tratamo-lo em vender em vários marketplaces a partir de um só Odoo e stock em tempo real para marketplaces.

Checklist de decisão

• O middleware guarda stock, estado de encomenda ou tracking que o Odoo não tem? Se só transporta ficheiros, não mude.
• Um só ERP, ou vários a vender nos mesmos canais? O Odoo fica a saber da encomenda no início do fluxo ou no fim?
• Quem passa o conector para a versão seguinte do Odoo, e quando?
• Sabe quantos registos históricos restam no estado que um cron de tentativas procura?

Se quer que alguém analise o seu caso com estes critérios, em serviços e soluções está como trabalhamos.

Perguntas frequentes

Ligações úteis dentro da FlexigoTech

O que fazemos sobre isto