# Tipos de integraciones — Odoo con sistemas externosGuía de arquitectura. Tres enfoques para conectar Odoo con sistemas externos, desde la conexión directa hasta plataformas de middleware completas.
# 1. Integración a través de API RESTLa comunicación se realiza mediante endpoints HTTP con payloads JSON. Puede ser bidireccional: Odoo consume APIs externas y sistemas externos consumen APIs expuestas por Odoo.
Operador Odoo Sistema Externo Operador Operador Odoo Odoo Sistema Externo Sistema Externo Odoo consume API externa dispara acción (botón, cron, workflow) GET/POST /api/... {headers, body JSON} 200 OK {data} procesa respuesta actualiza registros Sistema externo consume API Odoo POST /api/v1/... Authorization: Bearer {token} valida token valida payload ejecuta operación (create, write, search) 200 OK {id, status} # CaracterísticasAspecto Detalle Protocolo HTTP/HTTPS Formato JSON (también XML si se requiere) Autenticación Bearer Token, API Key, OAuth2 Ventaja Simple, estándar, fácil de testear con curl/Postman Limitación Sin cola de mensajes — si un extremo cae, se pierde la llamada Cuándo usarlo Integraciones punto a punto de baja criticidad o con reintentos manejados por el cliente
# Flujo de autenticación típicoSistema Externo Odoo API Sistema Externo Sistema Externo Odoo API Odoo API POST /api/v1/auth/token {api_key, secret} validar credenciales 200 {access_token, expires_in} GET /api/v1/contacts Authorization: Bearer {token} validar token verificar expiración 200 {data} Renovar token antes de que expire. Usar refresh_token si está disponible. Un middleware actúa como capa de abstracción entre Odoo y los sistemas externos. Centraliza autenticación, transformación de datos, encolado de mensajes, reintentos y observabilidad.
Middleware Infraestructura API Gateway (Kong / Traefik) Auth Service (JWT / API Key) Redis (caché + colas) Message Queue (RabbitMQ / SQS) Transform Service (Mapping / Enrichment) Mapping DB (external_id → odoo_id) Odoo Adapter (REST → JSON-RPC) Docker Containers Orquestador (k8s / Swarm) Proxy Inverso (NGINX / Traefik) Sistema Externo (ERP, CRM, MES) Odoo # Flujo de una solicitud a través del middlewareSistema Externo API Gateway Auth Service Transform Redis Message Odoo Odoo Sistema Externo Sistema Externo API Gateway API Gateway Auth Service Auth Service Transform Service Transform Service Redis Cache Redis Cache Message Queue Message Queue Odoo Adapter Odoo Adapter Odoo Odoo POST /api/v1/orders {external_ref, data} validar token ✅ autorizado forward request GET cache:external_ref alt [Cache hit] odoo_id encontrado [Cache miss] lookup external_ref search_read odoo_id odoo_id SET cache con TTL encolar evento order.created crear/actualizar orden create/write id confirmado resultado respuesta 201 Created {status, id} La cola permite procesamiento asincrónico: notificaciones, webhooks, conciliación nocturna # Componentes del middlewareComponente Rol Tecnologías típicas API Gateway Punto único de entrada, rate limiting, ruteo Kong, Traefik, NGINX, AWS API Gateway Auth Service Validación de tokens, API Keys, permisos OAuth2, JWT, API Key management Redis Caché de mapeo de IDs, contadores, sesiones Redis, ElastiCache, Memorystore Message Queue Encolado de eventos, reintentos, procesamiento async RabbitMQ, SQS, BullMQ, Kafka Transform Service Traducción de contratos, enrichment, validación Python, Node.js, Go Mapping DB Persistencia external_id → odoo_id por modelo PostgreSQL, MySQL, DynamoDB Odoo Adapter Traducción REST/JSON → JSON-RPC/ORM XML-RPC, OdooRPC, custom Docker Contenedores por servicio Docker, Podman Orquestador Escalado, health checks, despliegues Kubernetes, Docker Swarm, Nomad Proxy inverso TLS termination, balanceo de carga NGINX, Traefik, HAProxy, Caddy
# Ventajas del middlewareVentaja Explicación Desacoplamiento Ningún sistema conoce los detalles del otro Tolerancia a fallos Colas de mensajes con reintentos y dead-letter Observabilidad Logs, métricas y tracing centralizados Cache Reduce llamadas repetitivas a Odoo Transformación Adapta contratos sin modificar ningún sistema Seguridad Autenticación centralizada, rate limiting, IP whitelisting Escalabilidad Cada servicio escala independientemente
# 3. Integración a través de XML-RPCOdoo expone nativamente una API XML-RPC sobre HTTP. El sistema externo llama directamente a métodos del ORM de Odoo (execute_kw) sin necesidad de endpoints REST personalizados.
Sistema Externo Odoo XML-RPC Odoo XML-RPC Odoo DB Sistema Externo Sistema Externo Odoo XML-RPC /common Odoo XML-RPC /common Odoo XML-RPC /object Odoo XML-RPC /object Odoo DB Odoo DB Autenticación authenticate(db, user, password) validar credenciales uid (user id) Operación RPC execute_kw( db, uid, password, 'res.partner', 'search_read', [ 'is_company','=',True ], {{'fields':['name','email']}} ) SELECT name, email FROM res_partner WHERE is_company = true [{id: 42, name: "Acme", email: "..."}] XML-RPC usa serialización XML sobre HTTP. Más verboso que JSON pero 100% nativo de Odoo — no requiere módulos adicionales. # Modelo híbrido: RPC + RESTUn patrón común es combinar XML-RPC para operaciones internas del middleware con una API REST hacia el exterior:
Sistema Externo API REST Odoo XML-RPC Odoo Sistema Externo Sistema Externo API REST (Middleware) API REST (Middleware) Odoo XML-RPC /object Odoo XML-RPC /object Odoo Odoo POST /api/v1/contacts {name, vat, email} Authorization: Bearer {token} execute_kw( 'res.partner', 'create', [{name, vat, email}] ) crear registro partner_id: 42 execute_kw( 'res.partner', 'write', [[42], {ref: 'EXT-001'}]\n) actualizar referencia externa ok 201 Created {status: "created", odoo_id: 42} # CaracterísticasAspecto Detalle Protocolo XML-RPC sobre HTTP Formato XML (serialización automática) Endpoints nativos /xmlrpc/common, /xmlrpc/object, /xmlrpc/dbAutenticación Usuario + contraseña de Odoo (o API Key en v14+) Métodos execute_kw(model, method, args, kwargs)Ventaja Sin desarrollo en Odoo — acceso total al ORM Limitación Verboso, requiere conocer modelos internos, sin rate limiting nativo Cuándo usarlo Migraciones, scripts, conexiones internas con acceso controlado
# Híbrido REST + XML-RPCVentaja Cómo se logra REST para el exterior API REST documentada con Swagger/OpenAPI RPC para Odoo execute_kw en el adaptador — máxima flexibilidadSeparación de contratos La API REST define el contrato público; el RPC interno puede cambiar Seguridad Token Bearer en REST, API Key en RPC — doble capa
# Comparativa finalAPI REST Directa Middleware Intermediario XML-RPC Nativo Simple Estándar Sin colas Encolado Caché Observabilidad Escalable Tolerante a fallos ORM completo Sin desarrollo Híbrido REST evoluciona a puede usar como adaptador Criterio API REST directa Middleware XML-RPC Complejidad inicial Baja Alta Media Tolerancia a fallos ❌ ✅ ❌ Encolado de mensajes ❌ ✅ ❌ Transformación de datos Limitada ✅ Completa Manual Observabilidad Básica ✅ Centralizada Básica Escalabilidad ❌ ✅ ❌ Seguridad centralizada ❌ ✅ ❌ Desarrollo en Odoo Medio Medio Mínimo Ideal para MVPs, baja criticidad Producción, alta disponibilidad Migraciones, scripts
📄 Conclusión: Para integraciones en producción con múltiples sistemas, el middleware intermediario es la arquitectura recomendada. Para scripts puntuales o migraciones, XML-RPC directo es más rápido de implementar. La API REST directa sirve como primer paso antes de evolucionar a una arquitectura con middleware.
