¿Por qué dedicar un artículo entero a las soluciones API de Odoo?
Durante estos últimos años, hemos sido testigos de un número creciente de requerimientos de clientes para abrir sus entornos Odoo a sistemas dedicados y de terceros utilizando el sistema Odoo API y la interfaz XML-RPC Odoo API.
La razón no es descabellada, ya que también hemos notado que a medida que las empresas crecen y los casos de uso aumentan, las limitaciones estándar de la API de Odoo comienzan a afectar la productividad.
Entonces, ¿cuáles son las causas y qué debes hacer cuando esto sucede?
Limitaciones estándar de la API de Odoo
Al contemplar el rendimiento de la API de Odoo "fuera de la caja", uno se da cuenta rápidamente de que no puede manejar grandes flujos de datos combinados con una actividad intensa. Por ejemplo, incluso en la última versión de Odoo 14 & 15 Enterprise, nuestras pruebas revelan que crear más de dos o tres pedidos de ventas por segundo y por trabajador en un pedido de ventas estándar sin desarrollo ya es difícil.
Esto se debe principalmente a que las transacciones POST (transacciones movidas desde los registros de transacciones al libro de contabilidad) empujadas a Odoo todavía deben ser validadas a nivel de Odoo por los mecanismos ORM. Los mismos problemas ocurren con las importaciones de datos medianas y grandes.
He visto muchos proyectos fracasar porque los desarrolladores de Odoo no evaluaron las necesidades en términos de volumen y velocidad necesarios desde el principio. Sin embargo, los clientes saben desde el principio cuántos pedidos de venta, listas de recogida, movimientos de almacén y facturas van a generar a lo largo de su año comercial habitual.
Las cosas tienden a volverse trágicas por las mismas razones que cuando los desarrolladores de aplicaciones para teléfonos inteligentes creen que pueden usar la capa estándar de la API XML/RPC de Odoo para alimentar aplicaciones de usuario final con miles de usuarios concurrentes. Ellos exceden la capacidad del ORM de Odoo con aplicaciones B2C que involucran miles de usuarios simultáneos.
Diferentes escalas implican diferentes arquitecturas
Hay esencialmente tres maneras diferentes de tratar con la interfaz API.
1. El enfoque estándar de Odoo "light"
El enfoque estándar de Odoo "light" utiliza la API externa entregada por Odoo para acceder a las características y datos de la integración con otras herramientas externas. Los desarrolladores pueden acceder a ella a través de la interfaz XML-RPC de la API de Odoo, disponible en múltiples lenguajes como Python, Java, PHP y Ruby.
The first benefit of this approach is that it is easy to implement as all the heavy lifting has been done by Odoo, with clear documentation that can be found aquí. This approach also produces quick results, and data coherence is safe-guarded by the Odoo standard ORM validation before COMMIT.
En términos simples, usando este enfoque, los usuarios confían en la API - arquitectura e implementación estándar - tal como es entregada por Odoo sin ninguna modificación. Sin embargo, no permite la integración de grandes datos, y sólo se permite un número limitado de usuarios simultáneos.
Inconvenientes del enfoque estándar de la API de Odoo:
Sólo puede emplear un número limitado de transacciones y usuarios simultáneos sin fallar.
El sistema no puede aceptar más allá de una cantidad limitada de datos.
No es escalable.
2. Integración avanzada de la API
El enfoque estándar de la API de Odoo hace que la integración sea simple, pero ¿qué sucede cuando se necesitan procesar más transacciones? De ahí la necesidad de una integración avanzada de la API.
Este enfoque, por lo tanto, va más allá de las características estándar de Odoo ORM. Para que este enfoque funcione, la lógica de acceso a los datos debe ser rediseñada de acuerdo con las siguientes directrices:
Utilizar el ORM de Odoo para crear/actualizar los modelos de datos y objetos utilizados por los puntos finales.
Implementar un conector dedicado y evitar las características XML/RPC de Odoo cuando sea necesario.
Reemplazar las características de la API estándar de Odoo con otro motor de API para permitir un mayor rendimiento.
Integrar los procesos de validación de datos del ORM en el nuevo nivel del núcleo de la API para acelerar el tiempo de validación/respuesta.
Ventajas e inconvenientes
La integración avanzada de la API significa que se pueden acomodar muchos más usuarios simultáneos potenciales que con el enfoque estándar de la API. Esto significa que se pueden procesar más volúmenes de datos por llamada y en total. Y, sin duda, esta solución acepta más transacciones sin afectar al rendimiento.
El primer problema o inconveniente al que se enfrentarán los usuarios es que este enfoque introduce nuevos componentes tecnológicos en el proyecto, lo que significa que se requiere más experiencia para realizar el trabajo. Así, mientras que la API de Odoo es la solución principal, la arquitectura actualizada significa que el ETL (Extract, Transform, Load) se divide ahora en dos sistemas diferentes. Preservar la coherencia del ETL requiere entonces un mayor nivel de rigor.
¿Tienes problemas con la API estándar de Odoo?
3. Solución API de alto rendimiento
Este año, nuestros equipos han estado entregando un sistema dedicado de arquitectura de alta disponibilidad para un gran actor del "mundo transaccional" del mercado del sur de Asia. Los requisitos iniciales de rendimiento y carga nos dan hasta 1500 inserciones (peticiones POST) por segundo y hasta 10.000 descargas (peticiones GET) por segundo.
Con este tipo de carga, se han superado las capacidades especificadas de los módulos estándar de Odoo que utilizan la API de Odoo XML-RPC estándar. Incluso una integración avanzada de la API no sería suficiente, ya que la tensión impuesta por los usuarios simultáneos podría interrumpir fácilmente el rendimiento de la base de datos de Odoo y su capacidad para manejar las transacciones.
Debido a lo anterior, tuvimos que recurrir a las siguientes tecnologías:
Arquitectura dividida Odoo / API.
Servicio API que se ejecuta en segundo plano de manera automatizada (externo a Odoo) ejecutado en modo multihilo.
Cumplimiento del motor de la API con mecanismos de equilibrio de carga (que nos ofrecía un potencial de crecimiento casi infinito en términos de capacidad).
Autenticación y autorizaciones embebidas en SQL.
Tipos de datos SQL y discriminación tipo ORM.
Bibliotecas C+ PostgreSQL dedicadas.
Shell Haskell y ejecutable binario.
Gracias a estos nuevos componentes tecnológicos mejoramos el rendimiento en los siguientes niveles:
La autenticación / autorización se produce a bajo nivel en lugar de extraer los derechos de acceso del ORM.
La validación de datos es en tiempo real sin ir al ORM.
Mejora de la seguridad, ya que el conector XML-RPC del back-end del ERP ya no está abierto al acceso público.
Como puedes ver, esto es bastante impresionante, y las especificaciones del sistema no son exageradas. Sólo necesitarás una CPU con al menos 1GB de RAM y un SSD de 5GB.
El tiempo de ejecución de 1500 órdenes de venta se eleva a unos 3 segundos en una arquitectura sencilla. Se reduce a 200 ms cuando se divide entre varios núcleos y grupos de instancias gestionados con un balanceador o clústeres de instancias. La conclusión es que cuantos más núcleos e hilos se añadan, mayor será la capacidad de la API.
Su acceso a la solución API de alto rendimiento
Si el estrés impuesto por sus usuarios actuales perturba el rendimiento de la base de datos de Odoo y la capacidad para manejar las transacciones, entonces es el momento de buscar una nueva solución. Y Port Cities puede ayudarle. Tenemos un equipo global formado por más de 200 expertos en Odoo con experiencia en el manejo de integraciones API de alto rendimiento.
Póngase en contacto con nosotros aquí.
