Desde un Sistema de Inventario a Ecommerce Marketplace — APIs & Cloud & ERP
La idea de esta serie de artículos es mostrar cómo se puede actualizar la información de un Ecommerce marketplace desde un sistema de inventarios en un ERP.
En los artículos siguientes vamos a ver las implementaciones en detalle, pero en este vamos a ver los distintos modelos de arquitectura que podemos aplicar.
Modo Batch
El modelo más sencillo de implementar es el modelo batch, donde un componente es el encargado de tomar la información del sistema de inventarios, transformar la respuesta en lo que necesita el marketplace — mapping — y publicar los cambios. Normalmente, este proceso se ejecutaría cada cierto tiempo prefijado.
Este modelo funciona aunque tiene varias desventajas desde el punto de vista del diseño. Lo primero, es que se ejecuta desde principio a fin sin importar que los datos de inventario sean los mismos, generando un gasto en tiempo de ejecución innecesario al transmitir la misma información más de una vez.
Podríamos estar tentados de poner un repositorio intermedio de datos — seria algo más que un cache — para poder comparar si los datos cambiaron pero esto podría una practica peor, ya que duplicamos datos, podríamos tener problemas de sincronía y sigue existiendo lógica a ejecutar aunque los datos sean los mismos.
Obviamente si la ejecución es una vez por día, el tiempo de ejecución no es un problema tan significativo, pero podríamos terminar con información no actualizada en el marketplace la mayor parte del día. A mayor frecuencia de ejecución, mayor probabilidad de un desperdiciar tiempo de ejecución, en particular si la fuente de datos no cambia con tanta frecuencia.
El otro problema es la baja capacidad de reutilizar lo desarrollado, ya que el componente en medio de los dos sistemas tiene toda la lógica.
Modelo Webhook
En este modelo, el principal cambio es que el sistema origen notifica cuando hay un cambio en el nivel de inventario, solo ejecutando el flujo cuando es necesario. Al tener que recibir las notificaciones, es recomendable desacoplar la lógica para recibir la notificación y realizar el mapping, de la acción de actualizar el marketplace. Esto permite que este modelo conviva con el anterior luego de una re-ingeniería del modelo batch.
El reutilizar los componentes tiene mayores probabilidades en este caso, ya que se desacopla distintas parte de la lógica en distintos componentes aunque siguen existiendo limitaciones de lo que podemos hacer. Qué pasa en el momento que queremos informar el inventario a dos marketplaces distintos? Además todo el modelo es sincrónico.
Pero el mayor desafío es que la implementación de webhooks o disparadores pueden no estar disponibles en el sistema origen.
Modelo Event Driven
Este es el modelo más complejo de implementar ya que tiene muchos más componentes aunque los mismos son mucho más simples y fáciles. El desafío es la coreografía entre los mismo, el todo es más que la suma de las partes — muy filosófico, no? — La verdad es que las plataformas cloud ofrecen servicios especializados que nos ayudan a mitigar las complejidades de este modelo.
Al desacoplar la lógica, este modelo soporta tanto flujos batch como flujos basados en notificaciones así como el permitir actualizar distintos marketplaces al mismo tiempo.
Otra ventaja de este modelo es que no es más sincrónico desde el punto de vista del sistema origen. Su única responsabilidad es propagar los cambios.
Ahora este modelo puede ser extendido más allá de una comunicación en un solo sentido. Si el sistema origen o sus usuarios quieren saber el estado de los marketplaces y si los datos fueron transmitidos correctamente, su única opción es consultar cada uno de ellos. La extensión es incluir un mecanismo de re-alimentación o feedback para comunicar al sistema origen cualquier novedad. Este mecanismo también permite al modelo incluir notificaciones directas a los usuarios, por ejemplo usando SMS o notificaciones mobile o simplemente un email.
Incluso es recomendable incluir un mecanismo de manejo de errores para tener control sobre cualquier situación anómala, aunque en un caso como este, ya que estamos transmitiendo niveles de inventario, no sería necesario re-procesar los eventos con errores, simplemente se necesita que un nuevo evento se procese correctamente. Esta situación es distinta en el caso de que los eventos sean transacciones como ser órdenes o pagos, ya que si no se perdería información.
Notas finales
Espero poder probar estos modelos con diferentes marketplaces y plataformas cloud. El acceso a sistemas de inventario es un poco más difícil.
Como marketplace podemos considerar MercadoLibre, eBay, Amazon Marketplace e incluso Magento.
Como plataforma cloud podemos usar Azure, Amazon Web Services o Google Cloud Platform.
Como sistema de inventarios y ERP podemos considerar SAP S/4HANA Cloud o Microsoft Dynamics.
En los próximos artículos veamos cómo acceder y utilizar estos sistemas para luego armar nuestros modelos de principio a fin. Empezando por SAP S/4HANA Cloud y MercadoLibre.
Links
Otros Artículos
Todas las opiniones expresadas son mías y no representan opiniones de ninguna entidad con la que he estado, estoy o estaré afiliado.
All views expressed are my own and do not represent opinions of any entity whatsoever with which I have been, am now, or will be affiliated
