Sin cabeza, pero no descabezado

Productos configurables con SAP Commerce y SAP Spartacus

Para responder a la heterogeneidad de los requisitos de venta, SAP Commerce se adapta a las necesidades individuales mediante paquetes de extensión modulares. La extensión Configurator Complex Products (CCP) permite la gestión de productos configurables y complejos y realiza la integración con SAP Variant Configuration and Pricing Services (a menudo abreviado como CPS), que se encarga de implementar la lógica de configuración. Una abstracción adecuada también permite la integración de entornos de configuración no nativos de SAP, por ejemplo, configuradores heredados históricamente.

Además de la implementación funcional y lógica de la individualizabilidad de los productos configurables, CCP proporciona un escaparate rudimentario para mostrar e interactuar con los productos en el catálogo de productos del sistema de comercio. El mapeo coherente de las estructuras de producto -desde el motor de configuración hasta el catálogo de productos en el punto de venta central- crea una experiencia de cliente coherente y permite la automatización de los procesos de producción internos de la empresa sobre la base de los datos de producto gestionados centralmente.

SAP Espartaco

SAP Spartacus es un proyecto de código abierto con licencia Apache 2.0, gestionado y desarrollado principalmente por el equipo de SAP Commerce Cloud. Basado en el framework Angular, Spartacus implementa una interfaz de usuario headless que se integra con el sistema SAP Commerce como un storefront out of the box. El término headless en este contexto significa que SAP Commerce y SAP Spartacus son aplicaciones independientes y autosuficientes, en las que la responsabilidad de la entrega de contenidos recae en el sistema SAP Commerce, mientras que el escaparate de Spartacus implementa el diseño y la interacción.

A diferencia de los escaparates convencionales, que suelen ser páginas de servidor Java (JSP), la aplicación de página única (SPA) desvincula el frontend del backend. Esto significa que los ciclos de desarrollo pueden gestionarse y llevarse a cabo de forma independiente y que la base de código puede separarse entre sí. La comunicación entre las aplicaciones tiene lugar exclusivamente a través de API basadas en web. En la versión estándar, Spartacus ofrece todas las funciones esperadas de una tienda electrónica, incluida la página de inicio, la página de detalles del producto, la cesta de la compra y el pago. 

Al principio del desarrollo de un escaparate configurador está la elección de la tecnología adecuada. Para crear transparencia en la base de decisión de una tecnología para la implementación del frente de tienda individual, ayuda una comparación de las alternativas de decisión. Los escaparates de acelerador clásicos se consideran obsoletos en las versiones actuales de SAP Commerce y se eliminarán por completo del sistema en el segundo trimestre de 2024. SAP justifica la decisión por las ventajas de desacoplar el front-end y el back-end. Como resultado de esta decisión por parte de SAP, el nuevo desarrollo de un escaparate acelerador tradicional ya no es una opción desde la perspectiva actual.

Las alternativas restantes son el desarrollo individual de un escaparate desde cero y el uso de las funcionalidades prefabricadas del marco Spartacus. 

Spartacus proporciona un escaparate ejecutable desde el primer momento, con una personalización basada en los conceptos de configurabilidad y adaptabilidad. Las configuraciones cambian el comportamiento de Spartacus, por ejemplo, la dirección de backend a conectar, la autenticación y el diseño. En beneficio de la personalización, la base de código de Spartacus también está explícitamente diseñada para reutilizar y personalizar elementos de código basados en los conceptos de inyección de dependencias del marco SPA Angular. Gracias a la implementación del proyecto Spartacus por parte de SAP Commerce Cloud, los proyectos de desarrollo basados en Spartacus se benefician de la profunda experiencia técnica en el entorno del comercio.

Además, Spartacus implementa una gestión de estado de frontend escalable. El desarrollo interno de estos componentes básicos en un proyecto individual retrasa la puesta en marcha del primer escaparate totalmente ejecutable y aumenta notablemente el esfuerzo de mantenimiento y desarrollo posterior. Por tanto, los criterios de calidad clásicos del desarrollo de software también son responsabilidad del equipo de desarrollo. Por otro lado, el equipo de desarrollo en el proyecto individual es tecnológicamente independiente y tiene la custodia de cada decisión e implementación de la lógica.

Conceptos transversales

Tanto el sistema SAP Commerce como SAP Spartacus utilizan el patrón de diseño de software Facade. Una fachada forma una capa de abstracción sobre una o más fuentes de datos para preparar datos para un propósito específico. SAP Commerce implementa una fachada de configuración rudimentaria en el backend para obtener, agregar y preparar datos de configuración para su uso en un escaparate de configuración. Dado que las funcionalidades rudimentarias rara vez son suficientes para los requisitos de configuración individuales, los desarrolladores deben poder ampliar esta fachada con funcionalidades específicas. La base tecnológica para el desarrollo en SAP Commerce es el framework Java Spring webmvc. 

SAP Spartacus también utiliza el patrón de diseño Facade en el frontend para preparar los datos obtenidos del backend para su uso en el frontend web. Para personalizar esta funcionalidad, se requieren conocimientos en el manejo de Angular Dependency Injection y los Injection Tokens inherentes. Basándose en los tokens de inyección, los componentes pueden intercambiarse y ampliarse para crear una experiencia de usuario individual. Como concepto adicional, tanto SAP Commerce como SAP Spartacus utilizan el denominado OCC, Omnichannel Commerce. OCC persigue el objetivo de una experiencia de cliente sin fisuras en todos los puntos de contacto del cliente con la empresa, independientemente del medio de comunicación utilizado.

Desde un punto de vista técnico, OCC en SAP Commerce significa la interfaz para proporcionar los datos preparados en la fachada sobre la base de servicios web. SAP Spartacus retoma este concepto y obtiene los datos en su capa OCC antes de reenviarlos a la fachada. Tanto las fachadas como OCC son bases elementales para poder desarrollar un storefront robusto, escalable y mantenible.

Conjunto de competencias SAP Commerce

La personalización del sistema de comercio de SAP también se basa en la configuración y la ampliación de la base de código prefabricada. A efectos de configuración, el sistema de comercio de SAP incluye el motor ImpEx (importación y exportación) patentado. La sintaxis en forma de tabla de los scripts ImpEx permite realizar modificaciones fáciles de entender y reproducibles en el comportamiento de SAP Commerce. Ejemplos de ello son las personalizaciones de destino y diseño. Los denominados "destinos consumidos" permiten la integración en otros sistemas back-end. Aplicando un script ImpEx correspondiente, el destino consumido puede redirigirse al motor personalizado con información de autenticación específica. El diseño también puede personalizarse en lo que respecta a los contenedores que se mostrarán en el frontend, que un escaparate utilizará para mostrar el contenido correspondiente.

SAP Commerce utiliza los conceptos de populator y mapper junto con las fachadas para preparar los datos. Un populator se encarga de transferir datos a un objeto existente. Se pueden conectar varios populators en serie para mapear una transformación de datos holística. Los mapeadores se encargan de generar un nuevo objeto de datos a partir de otro tipo de datos dentro de un populador. Juntos, populadores y mapeadores forman la transformación de datos que proporciona la entrada para la fachada.

El uso coherente de este tipo de transformación de datos tiene un efecto claramente positivo en los criterios de calidad del código escrito. En el corazón del storefront Spartacus se encuentra su concepto de manejo de datos, que consiste en la implementación de la gestión de estados con NgRx (Redux), el uso coherente de observables y los conceptos de normalización y serialización. La combinación de estos elementos hace que el storefront sea reactivo y centrado en los datos. NgRx es una implementación de Angular de código abierto del marco Redux. El estado de los datos almacenados en NgRx se comunica exclusivamente a través de observables, lo que permite que la interfaz de usuario reaccione siempre a los cambios en los datos. 

Habilidades de Spartacus 

La normalización se refiere al proceso de transformación de los datos del backend de comercio en la fachada Spartacus para prepararlos para su visualización. Todos los datos entrantes pasan por normalizadores específicos. A la inversa, todos los datos modificados por la interacción del usuario fluyen desde la fachada Spartacus hacia el backend de comercio a través de serializadores responsables de transformar los datos de nuevo en el modelo OCC.

Conclusión

CCP y SAP Spartacus ofrecen desde el principio una interfaz de configuración ejecutable que se integra perfectamente con los configuradores SAP existentes. Sin embargo, si se desea asignar una experiencia de cliente individual con ambos sistemas, las empresas no pueden evitar adaptar la lógica existente. Para ello se requieren conocimientos tanto en el backend, es decir, Java Spring webmvc, como en el frontend, es decir, Angular. Aunque la visualización de los configuradores reacciona de forma adaptativa a los datos del backend, las empresas alcanzarán rápidamente sus límites con la implementación estándar en ambos sistemas. Desarrollar su propio escaparate desde cero es posible, pero implica riesgos completamente diferentes. Para dominarlos, el equipo de desarrollo necesita profundos conocimientos en diversos ámbitos de la ingeniería de software.