Este artículo explica cómo replantearse la extensibilidad de Adobe Commerce mediante Adobe Developer App Builder y sustituir gran parte del PHP personalizado por una arquitectura más escalable puede mejorar la escalabilidad, la estabilidad y la facilidad de mantenimiento, con el fin de garantizar un crecimiento a largo plazo en un entorno de producción real.

Introducción

Durante años, la extensibilidad de PHP ha sido el pilar de la personalización de Adobe Commerce. Pero a medida que las arquitecturas nativas de la nube maduran, también lo hacen alternativas mejores. En una implementación reciente para un proveedor líder europeo de servicios financieros y de movilidad, hemos sustituido una parte significativa del desarrollo tradicional de módulos de Adobe Commerce por App Builder, la plataforma de extensibilidad nativa de la nube de Adobe. Lo logramos aprovechando las acciones en tiempo de ejecución (funciones sin servidor), los eventos y las API para ofrecer una solución más escalable y fácil de mantener. En este artículo se analizan las razones que motivaron esa decisión, la estructura de la arquitectura y las lecciones aprendidas.

Información general

Se puede adoptar gradualmente un enfoque de API con Adobe Commerce mediante la evaluación de qué funciones serían las más beneficiosas ejecutándolas como aplicaciones nativas en la nube fuera de la plataforma central de Adobe Commerce y migrando primero esas funciones.

Este proceso condujo a un resultado claro:

• El 70 % de la funcionalidad se implementó utilizando App Builder.

• El 30 % restante se mantuvo como personalizaciones PHP nativas de Adobe Commerce.

Este equilibrio nos permitió mantener la lógica nativa y la relacionada con el cierre de compra cerca de Commerce, mientras descargábamos integraciones, validación, procesamiento en segundo plano y orquestación a App Builder, donde destacan la escalabilidad, el aislamiento y la flexibilidad de implementación.

La arquitectura resultante (consulte el diagrama siguiente, en el que se presentan solo las extensiones de App Builder) refleja este enfoque híbrido: Adobe Commerce sigue siendo el núcleo transaccional, mientras que App Builder actúa como la base de la integración y la automatización. Esta estrategia conecta identidad (SSO), PIM, ERP, servicios de terceros y lógica empresarial personalizada a través de flujos impulsados por eventos y API Mesh (el servicio de orquestación de API de Adobe).

Recorrido de arquitectura: cómo funciona el modelo híbrido

En el centro de la solución se encuentra Adobe Commerce, que hace lo que mejor sabe hacer: catálogo, precios, carro de compras, cierre de compras y asignación de pedidos. Deliberadamente, mantuvimos el núcleo transaccional limpio y estable, lo que evita una personalización innecesaria dentro del tiempo de ejecución de Commerce.

Todo lo relacionado con ese núcleo (identidad, validación de datos, lógica de disponibilidad, procesamiento en segundo plano e integraciones de terceros) se gestiona a través de App Builder y Adobe API Mesh.

La experiencia del comprador se basa en el nuevo Commerce Storefront (con tecnología Edge Delivery Services).

1. Nivel de entrada: CDN, Commerce Storefront e identidad

Todo el tráfico de los visitantes habituales del sitio web llega primero al servicio CDN + Edge Delivery, que garantiza un rendimiento óptimo, seguridad y entrega global antes de que cualquier solicitud llegue a los sistemas back-end.

La autenticación se gestiona mediante el SSO de Keycloak, integrado mediante lo siguiente:

• Una integración SSO de App Builder.

• Un módulo PHP estándar de Adobe Commerce de Marketplace para la configuración y el ajuste básico de SSO.

• Esta configuración nos permite combinar la estabilidad de la plataforma con la flexibilidad nativa de la nube.

Ventajas principales de este enfoque

• Administración centralizada de identidades mediante un módulo de Marketplace de eficacia comprobada

  Confiamos en una extensión de Adobe Commerce con buena compatibilidad para la configuración del SSO, la asignación de usuarios y los flujos de autenticación principales, lo que evita mantener la lógica de autenticación personalizada dentro del tiempo de ejecución de Commerce.

• Modificación mínima, seguridad máxima

  En lugar de reescribir o ramificar el módulo SSO, solo aplicamos extensiones pequeñas y específicas a través de App Builder, lo que mantiene el módulo original totalmente actualizable.

• Modelo de integración basado en API

  Dado que toda la comunicación se basa estrictamente en las API de SSO, estamos desligados de los detalles de implementación interna del módulo PHP. Incluso si el módulo cambia internamente, nuestra integración permanece estable mientras se mantenga el contrato de la API.

2. Capa de orquestación: Adobe API Mesh

En el centro de nuestra arquitectura de integración se encuentra Adobe API Mesh, que actúa como centro de orquestación y comunicación entre todos los sistemas empresariales involucrados en la plataforma:

• Commerce Storefront (como front-end)

• Adobe Commerce

• PIM

• ERP

• servicios de validación externa

• y todas las aplicaciones de App Builder

En lugar de que EDS Frontend o Adobe Commerce establezcan integraciones directas de extremo a extremo con cada uno de estos sistemas, todas las comunicaciones se enrutan a través de la API Mesh.

Ventajas clave de usar Adobe API Mesh

• Una sola superficie de integración
  Los sistemas solo necesitan “conocer” un extremo de integración back-end: Mesh. Todas las dependencias externas quedan ocultas tras una puerta de enlace API unificada.

• Contratos de API consistentes
  Todos los sistemas se comunican a través de contratos bien definidos y con versiones, lo que elimina el acoplamiento oculto y reduce drásticamente el riesgo de cambios importantes.

• La desvinculación completa entre los sistemas back-end
  Las aplicaciones PIM, ERP, servicios de validación y App Builder están totalmente aisladas entre sí. Cualquier sistema puede evolucionar independientemente sin forzar cambios en todo el entorno.

• Seguridad y gobernanza centralizadas
  La autenticación, la autorización y el control del tráfico se aplican a nivel de Mesh, y no se dispersan en múltiples integraciones personalizadas.

• Código base simplificado de Commerce
  Adobe Commerce o Frontend ya no contiene una lógica de integración compleja. Simplemente consumen API expuestas por Mesh, manteniendo la capa de PHP ágil y transaccional.

3. Servicios de App Builder utilizados por la capa de Storefront y SSO

Estos servicios son consumidos directamente por Commerce Storefront y la capa SSO, no por Adobe Commerce, lo que permite que la lógica empresarial crítica funcione de forma independiente del tiempo de ejecución de Commerce.

Receptor de datos del cliente (SSO → App Builder)

Este servicio recibe y sincroniza los datos del cliente desde la capa de SSO sin afectar al rendimiento del escaparate o Commerce. El uso de App Builder garantiza un procesamiento seguro, una escalabilidad asincrónica y una dependencia de implementación nula en Adobe Commerce.

Disponibilidad de productos por cliente (Storefront → App Builder → PIM)

La disponibilidad del producto se resuelve en tiempo real en función del contexto del cliente y los datos de PIM antes de que las solicitudes lleguen a Commerce. App Builder permite que esta lógica se escale de forma independiente y protege Commerce de una carga de dependencia externa pesada.

Validación de datos de la compañía (Dun & Bradstreet) (tienda → App Builder → terceros)

La validación se activa directamente desde la tienda a través de App Builder + API Mesh y se verifica mediante servicios de terceros, lo que mantiene la latencia del servicio externo y los errores completamente desvinculados de Adobe Commerce.

Motor de redirección de ID externo (Escaparate → App Builder)

El tráfico entrante de sistemas externos se procesa y asigna mediante App Builder antes de entrar en la tienda, lo que permite la normalización segura del tráfico, reglas de redirección flexibles y cero riesgos para el núcleo de Commerce.

4. Procesamiento previo de Commerce Storefront: SEO sin poner en riesgo la experiencia de usuario

El escaparate de Commerce de AEM es una aplicación moderna impulsada por front-end que depende en gran medida de JavaScript para cargar datos de productos en el explorador. Aunque esto ofrece una excelente experiencia de usuario, presenta un reto clásico de SPA:

Los rastreadores de motores de búsqueda y los sistemas sin explorador suelen recibir HTML casi vacíos, ya que no ejecutan JavaScript de forma fiable.

Para solucionar este reto, implementamos el procesamiento previo de AEM Commerce, una solución oficial de Adobe basada en App Builder.

Funcionamiento del procesamiento previo en nuestra arquitectura

La aplicación de procesamiento previo de App Builder:

• Lee los datos de los productos directamente desde el servicio de catálogo de Adobe Commerce.

• Genera páginas de HTML totalmente hidratadas basadas en plantillas predefinidas.

• Almacena el resultado prerenderizado en su propio almacenamiento de blobs.

A continuación, se configura escaparate de Commerce para que utilice este almacenamiento como fuente de superposición. Cuando se produzca cualquiera de las siguientes situaciones:

• Un motor de búsqueda rastrea.

• Cualquier cliente sin explorador solicita una URL de producto.

Recibe inmediatamente una respuesta de HTML completamente procesada con datos de productos reales, sin ejecutar ningún JavaScript.

Al mismo tiempo:

• Los usuarios habituales siguen disfrutando de la experiencia SPA estándar, con renderización PDP en tiempo real en el explorador.

Por qué App Builder es el activador principal en este caso

App Builder es el plano de control central de todo el proceso de procesamiento previo. Nos permite definir lo siguiente:

• La frecuencia de obtención de datos

• Qué productos y configuraciones regionales se incluyen

• La estructura HTML y JSON-LD

• La generación de metadatos SEO

Todo esto se puede modificar mediante pequeños cambios en la configuración de App Builder, sin ningún tiempo de inactividad para el escaparate principal o Adobe Commerce.

Adobe también proporciona un kit de iniciación para la aplicación de procesamiento previo de App Builder, lo que nos permitió preparar la solución para la producción en muy poco tiempo y lograr un aumento inmediato de la SEO.

Ventajas clave de este enfoque

• Mejoras masivas en la optimización de los motores de búsqueda
  Los rastreadores reciben páginas de productos completamente procesadas con datos estructurados en lugar de HTML vacías.

• Sin impacto en el rendimiento del escaparate
  Los usuarios habituales mantienen la experiencia dinámica y rápida de SPA.

• Modelo de implementación sin riesgos
  Toda la lógica de procesamiento previo se ejecuta fuera de Adobe Commerce y del tiempo de ejecución del escaparate.

• Control total a través de App Builder
  Las reglas de procesamiento previo, los modelos de datos y las programaciones se pueden modificar sin tener que volver a implementar la plataforma.

5. Sincronización de pedidos y ERP: asincrónica por diseño

El proceso de cierre de compra y la asignación de pedidos se siguen gestionando completamente dentro de Adobe Commerce, preservando la integridad de los datos y la coherencia transaccional. Una vez creado un pedido, el proceso de exportación lo gestiona un exportador de pedidos programados específico creado en App Builder.

Este exportador sincroniza los pedidos con el ERP de forma asíncrona, fuera de la tienda y del ciclo de vida de la solicitud de Commerce.

Ventajas clave de este enfoque

• Tiempo de actividad de la tienda totalmente independiente de la disponibilidad del ERP.
  Incluso si el ERP es lento o no está disponible temporalmente, los clientes pueden seguir haciendo pedidos sin interrupciones.

• Sin bloqueos en el cierre de compra debido a fallos posteriores
  La creación de pedidos ya no depende de las respuestas de ERP en tiempo real, lo que elimina una fuente importante de riesgo de conversión.

• Reintentos seguros y flujo de datos controlado
  App Builder permite la ejecución programada, los mecanismos de reintento y la administración de errores sin afectar el rendimiento de Commerce.

• Escalabilidad y despliegue independientes
  La sincronización de pedidos puede escalarse según el volumen sin ninguna reimplementación ni efectos secundarios de rendimiento en Adobe Commerce.

¿Por qué no realizar un cambio completo a App Builder?

Una de las primeras y más importantes decisiones de arquitectura fue no tratar a App Builder como un reemplazo total de los módulos PHP y tampoco dejar todo por defecto a PHP “porque así es como siempre se ha hecho”.

En su lugar, cada requisito pasó por un filtro simple:

Lo que se quedó en PHP (el 30 %)

Mantuvimos las personalizaciones de PHP solo donde realmente tienen que estar:

• Cierre de compra y ajustes de asignación de pedidos

• Lógica de precios, carro de compras y presupuesto

• Enlaces GraphQL profundos y sensibles al rendimiento

• Áreas donde la latencia debe ser próxima a cero y totalmente sincrónica

Son lugares en los que el acceso directo a la base de datos, el acoplamiento estrecho a los internos de Commerce y el control del ciclo vital de las solicitudes siguen estando absolutamente justificados.

Qué se trasladó a App Builder (el 70 %)

Todo lo demás se trasladó:

• Orquestación de identidad y SSO

• Validación de clientes y empresas

• Resolución de disponibilidad del producto

• Coordinación del sistema externo

• Integraciones de ERP y de terceros

• Automatización y motores de redirección

• Trabajos y programadores en segundo plano

Todas estas son áreas en las que los módulos PHP han tenido problemas históricamente:

• acoplamiento estrecho,

• implementaciones difíciles,

• aislamiento deficiente del fallo,

• y escalabilidad limitada.

Ventajas clave obtenidas

Cambiando aproximadamente el 70 % de la lógica de integración y comercial a App Builder, cambiamos fundamentalmente la forma en que se crea, implementa y opera la plataforma. El impacto fue visible no solo en la calidad de la arquitectura, sino también en la velocidad de entrega, la estabilidad del sistema y el control de costes a largo plazo.

Implementaciones independientes

Con App Builder a cargo de la mayoría de las integraciones y los flujos de trabajo empresariales, la mayoría de los cambios ya no requieren una reimplementación completa de Adobe Commerce. Las actualizaciones de integración, las validaciones y los procesos en segundo plano se pueden implementar de forma independiente, lo que reduce considerablemente:

• el riesgo de lanzamiento,

• las ventanas de implementación y

• los gastos generales de coordinación entre equipos.

Esto por sí solo se convirtió en una de las mayores mejoras de productividad en las operaciones diarias.

Mejor escalabilidad donde más importa

Anteriormente, los picos de tráfico en:

• las comprobaciones de disponibilidad,

• la validación de la empresa,

• o las llamadas de API externas

repercutirían directamente en el rendimiento de Commerce.

Ahora, estas cargas de trabajo se escalan de forma independiente en App Builder. Como resultado:

• el rendimiento de la finalización de compra permanece estable,

• los recursos de Commerce se reservan únicamente para cargas de trabajo transaccionales

• y el tráfico impredecible de terceros ya no amenaza las tasas de conversión.

Aislamiento de errores verdadero

Una de las mejoras más críticas es la contención de errores. Cuando los sistemas de terceros experimentan latencia, degradación o interrupciones:

• App Builder absorbe el impacto,

• la lógica de reintento y reserva se aplica allí

• y Adobe Commerce sigue funcionando a pleno rendimiento.

Esto ha eliminado de forma efectiva toda una clase de escenarios de problemas que anteriormente provocaban un tiempo de inactividad parcial o total en el escaparate.

Propiedad del código más limpia y responsabilidades claras

La plataforma ahora tiene límites arquitectónicos claros:

• Adobe Commerce → lógica transaccional, finalización de compra, precios, carro de compras

• Integraciones de App Builder → integraciones, orquestación, validación, trabajos en segundo plano

Esta separación:

• simplifica la incorporación de nuevos desarrolladores,

• reduce las dependencias entre equipos

• y evita la erosión gradual del núcleo de Commerce mediante un código personalizado con una gran integración.

Diseñado para el futuro

Esta arquitectura híbrida está totalmente alineada con el SaaS a largo plazo, el enfoque basado en API y la estrategia de comercio componible de Adobe. Al externalizar la mayoría de la lógica personalizada:

• las actualizaciones de plataforma son más seguras,

• se reduce la restricción a un solo proveedor a nivel de código

• y la solución ya está preparada para pasar a Adobe Commerce as a Cloud Service.

No solo solucionamos los requisitos actuales, sino que creamos una plataforma estructuralmente preparada para lo que pasará a ser Adobe Commerce.