Entrevista con Ludovic Genest Cloud Software Manager en Orisha Commerce Francia
En otoño de 2025, entrevistamos a Ludovic Genest, Responsable de Cloud Software en Orisha Commerce Francia, para comprender cómo las API están transformando la implementación del recommerce en el sector retail.
En esta conversación, analiza los principales retos de arquitectura, interoperabilidad y gobernanza que permiten a las enseñas conectar fácilmente sus módulos de recompra, taller o reventa con su sistema de información.
Resumen:
- Los principios de una arquitectura componible
- Los endpoints esenciales para el recommerce
- La seguridad y la gobernanza de las API
- Quick wins y experiencias prácticas
- La visión a 3 años para un retail conectado
Introducción
El RE-commerce abarca diversas actividades, como venta, reparación, alquiler y reventa. Hemos lanzado una nueva línea de productos que gestionan estas funciones mediante sistemas modulares. Estos módulos están diseñados para integrarse perfectamente con los productos actuales de nuestras subsidiarias (Ginkoia, Openbravo, Fastmag), manteniendo la independencia del ERP o del Punto de venta. Las APIs facilitan significativamente la comunicación entre estos módulos y el ERP o el Punto de venta.
En Ginkoia, hemos adoptado una nueva filosofía, ofreciendo no solo APIs sino también un portal para desarrolladores mediante el Ginkoia API Center, para brindar mejor soporte a nuestros clientes.
El uso de nuestras capacidades de RE-commerce mediante APIs permite a los sistemas de TI desarrollar soluciones flexibles. Sin embargo, trabajar con APIs requiere conocimientos técnicos no solo en la etapa inicial, sino también a largo plazo. La comprensión del uso y la funcionalidad de las APIs es un reto importante que no debe subestimarse.
Arquitectura e interoperabilidad
Es vital separar claramente el front end del back end, garantizando que la interfaz de usuario emplee APIs provenientes de diversas fuentes. Las APIs intermedias, más cercanas al ámbito funcional, deben conectarse con APIs técnicas a nivel inferior. Esto permite la utilización de múltiples APIs en las capas inferiores, provenientes de distintos sistemas ERP o POS, sin afectar la interfaz ni la funcionalidad.
Primero, es necesario comprobar que tu ERP o POS disponga de APIs adecuadas y asegurarse de que todas las funciones operativas se puedan realizar a través de esas APIs.
En mi taller, genero una orden de trabajo que facilita la gestión de tareas, técnicos y estados. La orden también puede manejar pagos en caja y actualizar automáticamente su estado tras el pago. Todo este proceso se gestiona mediante flujos de API/webhook.
Actualmente, herramientas como los buses de servicio evitan las llamadas directas a APIs. En su lugar, usamos buses de servicio y webhooks para soportar servicios asincrónicos y persistentes.
Al desarrollar APIs, solemos enfocarnos en las APIs CRUD (Crear, Leer, Actualizar, Eliminar) y podríamos considerar que la tarea está completada al proporcionar estas para todos los objetos gestionados. Sin embargo, frecuentemente se olvidan APIs esenciales, como las APIs funcionales, de búsqueda multicriterio y de procesamiento por lotes.
Endpoints y datos críticos
Utiliza APIs CRUD y GraphQL para búsquedas rápidas.
Mantén siempre capas de abstracción entre las APIs de la capa de datos y las APIs de la capa de negocio. Exponer las APIs de la capa de negocio garantiza que las actualizaciones en la capa de datos no afecten la funcionalidad del negocio.
Clasifica las APIs según tipos de datos, como MasterData y TransactionData.
Las APIs de MasterData deben ser eficaces en búsquedas, proporcionar incrementos y permitir grandes lecturas de datos (utilizando caché).
Las APIs de TransactionData deben enfocarse en la creación frecuente (utilizando colas).
La consistencia de los datos es un reto crucial y complicado de abordar, que requiere restricciones adecuadas. Por ejemplo, el análisis de ventas de los últimos tres meses puede tolerar saltarse los últimos quince minutos de datos. Sin embargo, el análisis de inventario, control de gestión y stock demandan alta precisión en los datos. Utiliza herramientas de control de consistencia regularmente, como realizar revisiones automáticas para detectar discrepancias y programar sincronizaciones globales en horarios menos concurridos.
Seguridad, gobernanza y cumplimiento
Implementa sistemas de autorización y tokens robustos, asegurando que ningún código contenga información sensible (URL, login, clave de API); en su lugar, usa mecanismos de bóveda para el almacenamiento.
La gestión de claves API para aplicaciones de terceros también debe seguir estándares. Existen muchas soluciones que permiten delegar estas tareas, evitando desarrollos personalizados y gestionados por el API Manager.
Las APIs no tienen requisitos únicos para GDPR; siguen los mismos principios que el acceso directo a bases de datos.
Es importante no olvidar las APIs de eliminación de datos personales cuando ya no se necesitan.
También es fundamental gestionar cuidadosamente los registros que puedan contener detalles de llamadas API con datos personales.
Utiliza un API manager para controlar todas las funcionalidades de un motor de APIs, evitando codificaciones personalizadas para este propósito.
Por ejemplo, las cuotas de llamadas API deben gestionarse de forma nativa mediante el API manager, no codificadas directamente en la API.
ROI, despliegue y “quick wins”
Es crucial dedicar tiempo a elegir el integrador adecuado o asegurarse de que tus equipos técnicos comprendan la filosofía detrás de las APIs propuestas para una integración eficaz. Una visión técnica y funcional sólida es esencial para implementar soluciones confiables y escalables.
En Orisha Passy, regularmente ofrecemos talleres de presentación, lo que ahorra tiempo valioso a todos los involucrados. Esto ayuda al integrador a evitar errores y tomar el rumbo correcto desde el principio.
Se siguen KPIs como tiempos de carga y cantidad de consultas, que aunque estándar, son esenciales.
Con el aumento del volumen, considera optimizaciones como la implementación de Redis Cache en diferentes APIs que comparten datos para reducir el acceso a la base de datos y mejorar los tiempos de respuesta. Aunque esta técnica es compleja y requiere una infraestructura robusta de Azure, se vuelve vital conforme crece el volumen.
Sin mencionar la marca, recuerdo una API diseñada para crear pedidos de clientes para ventas (colocación de pedidos, creación de clientes, almacenamiento de productos, emisión de facturas).
Un integrador utilizó esta API para alquileres, lo que resultó en la venta de equipo de esquí en el ERP a tarifas diarias de alquiler con almacenamiento. Esto enfatiza la importancia de una comunicación clara entre los equipos funcionales, técnicos, clientes, integradores y proveedores de APIs.
No pienses en las APIs como una solución mágica para todos los problemas.
- Recomendación 1: El uso de APIs no elimina la necesidad de diseñar tu proyecto.
- Recomendación 2: Planifica y define procesos para gestionar cambios (como actualizaciones de versión) con tus equipos o integrador, para anticiparlos en lugar de reaccionar a ellos.
- Recomendación 3: Implementa pruebas Mock para APIs para evitar realizar tests en un entorno de producción.
Visión y perspectivas
La relevancia de las APIs continuará en aumento, requiriendo herramientas para rastrear los flujos de datos de manera eficiente que aseguren consistencia y coherencia.
En el futuro, todos los proyectos incluirán APIs. Aunque los estándares pueden estancarse, las tecnologías y herramientas evolucionarán rápidamente.
Debemos desglosar las funciones de negocio en lugar de depender de una solución única y completa. Crear sistemas complejos es un desafío que requiere abandonar la idea de que un solo software puede manejarlo todo. Necesitamos más arquitectos y menos compradores de soluciones completas.
Define claramente tus objetos y establece una correcta mapeo de datos entre los objetos externos e internos.
Bonus
“La idea de que mi proveedor tiene todas las APIs, por lo tanto, el proyecto será fácil.” Pero si estás utilizando APIs de dos diferentes proveedores, ¿cómo has planificado que se comuniquen entre sí?
Más que una herramienta específica, es una cuestión de metodología: prioriza definir la arquitectura y realizar el trabajo de diseño antes de empezar cualquier desarrollo.
Las pruebas de carga y rendimiento suelen pasarse por alto. Recuerdo una situación donde una herramienta se usaba para enviar tickets para BI. Después de modificar mi POS para enviar tickets durante la creación, funcionó. Sin embargo, durante el primer sábado de ventas, el tiempo de creación de tickets se disparó de 2 segundos a 45 segundos debido al despacho lento de tickets y numerosos intentos fallidos causados por APIs no responsivas. Las pruebas de carga adecuadas habrían resaltado la necesidad de delegar el despacho de tickets a un sistema diferente de mi POS.
Cloud Software Manager
Orisha Commerce Francia