En un proyecto de SAP Commerce, las integraciones suelen implementarse de distintas formas, veamos los pros y contras de algunas

planteamiento

Cuando se requiere implementar integraciones con servicios externos, se escoge separar estos componentes en una extensión más, esto es para desacoplar la implementación

extensión de integraciones

En esta publicación, miraremos a un par de diseños para solucionar este escenario considerando la generación de una extensión que llamaremos integrations

integraciones depende de core

En este caso, integrations depende de core, por lo que podríamos utilizar nuestros servicios en capas superiores (como en facades), pero no en capas inferiores como core

Dependiendo del escenario, corremos el riesgo de comprometer el diseño. Por ejemplo, si algún cronjob, servicio, etc. debe ser utilizado/compartido en core, tendríamos que refactorizar y hacer un pequeño hack haciendo uso de la inyección de dependencias:

Sería necesario mover la interface de la integración a core y dejar la implementación e inyección en integrations. Esto permitirá que spring resuelva la dependencia para las inyecciones, sin embargo, el código de las integraciones tendría una alta dependencia entre los componentes, es decir, core e integrations no podrían existir el uno sin el otro

core depende de integrations

Este es el caso contrario al anterior, ahora core puede utilizar abiertamente las implementaciones de integrations sin la necesidad que contener las interfaces de los consumos de servicios, sería como "instalar/usar una nueva extensión"

Esta versión es adecuada para la mayoría de los casos, ya que:

• una integración puede ser ocupada en un servicio, cronjob, interceptor, etc.
• dado que core depende de integrations. Facades también puede hacer uso de las integraciones (como se muestra en la imagen anterior)

extensión de services desacoplada de core e integrations

Yo inicié en el mundo de SAP Commerce hace unos años ya, aún se llamaba hybris, y en el tutorial inicial indicaba que para las nuevas implementaciones era recomendable crear una extensión de services inmediatamente después de generar el acelerador. No tenía una justificación o una pista sobre la ventaja de hacer esto, pero esto nos servirá para mejorar nuestro diseño

Si tenemos una extension de services, podemos indicar que core dependa de esta (como ya lo analizamos en el caso anterior), esto quiere decir que nuestra extensión de services será el proxy para cualquier otra extensión que sea requerida, por ejemplo, para integrations:

Si hacemos esto, aún aún tenemos los beneficios del caso anterior. Además, mediante el uso de interfaces y prácticas en integraciones como mocking, podemos:

• definir la interface del componente de integración en la extensión de services
• implementar e inyectar en spring un cliente mock en services
• implementar el cliente real y sobreescribir el cliente en spring desde la extension de integrations
• elegir si utilizar el cliente mock o el real, dependiendo de nuestra configuración en el archivo de `localextensions.xml`

Como puedes notar, aunque es un poco más complejo, esta versión encapsula de forma adecuada los servicios; provee una forma sencilla de cambiar las implementaciones y reutilizar el código en las distintas capas; y desacopla la implementación del mock y el cliente real

Entonces, este "patrón" se puede seguir replicando por cada integración, donde los servicios serán los comprometidos, ya que estos son el proxy hacia las dependencias que utilizaremos en nuestra solución

conclusión

Como cualquier tema en programación, existen distintas formas de implementar una solución. Sin embargo, diseñado nuestra solución a priori, podemos tener un diseño y código más escalable y resiliente a los cambios que se requieran en el futuro