Extensibilidad side-by-side

Una extensión side-by-side es una aplicación independiente que trata SAP S/4HANA como un sistema con el que se comunica, no como un código que modifica:

1. La extensión se construye y despliega en SAP BTP, en el runtime y el lenguaje que se ajustan al caso de uso: ABAP en el entorno ABAP de SAP BTP, o Java y Node.js, por ejemplo con CAP.
2. Lee y modifica datos de SAP S/4HANA solo a través de API remotas liberadas, que SAP documenta en SAP Business Accelerator Hub.
3. Puede reaccionar a los eventos de negocio que publica SAP S/4HANA, de modo que no tiene que consultar periódicamente si hay cambios.
4. La conectividad y la confianza se configuran entre SAP BTP y el ERP: destinations, además de SAP Cloud Connector para los sistemas on-premise.
5. La extensión tiene su propio ciclo de vida. Se despliega, escala y actualiza con independencia de las releases de SAP S/4HANA.

Por lo tanto, la extensibilidad side-by-side convierte una extensión en un problema de integración con su propia aplicación, en lugar de un cambio dentro del ERP.

Las directrices de extensión de SAP nombran varios arquetipos de aplicaciones side-by-side:

• Apps proxy y de conveniencia que simplifican o remodelan el acceso a SAP S/4HANA para un público específico.
• Apps sustitutas que reemplazan un paso estándar por uno personalizado.
• Apps de preprocesamiento y posprocesamiento que preparan los datos antes de que lleguen al ERP o actúan sobre lo que el ERP produjo.
• Apps analíticas que combinan datos de SAP S/4HANA con otras fuentes.

Los patrones típicos incluyen apps full-stack para un solo cliente, apps SaaS multitenant creadas por partners, escenarios hub que conectan varios sistemas ERP o servicios en la nube, apps móviles y automatización entre sistemas. En Alder Manufacturing, un portal de estado de entregas para los conductores de Bright Freight, que no tienen usuario de SAP S/4HANA, es un caso side-by-side natural. La extensibilidad side-by-side encaja mejor cuando la extensión atiende a nuevos usuarios, nuevos canales o varios sistemas.

• Clean core por arquitectura. El ERP no se modifica, y la extensión depende solo de API liberadas y eventos.
• Ciclo de vida independiente. La extensión puede publicarse cada semana mientras SAP S/4HANA sigue su propio calendario de releases, y las actualizaciones de SAP S/4HANA no tocan su código.
• Libre elección del stack. Los equipos pueden usar ABAP, Java o JavaScript y los servicios de SAP BTP que mejor se ajusten, desde SAP Build Apps hasta CAP.
• Alcance más allá de los usuarios de SAP. Partners externos, proveedores y clientes pueden usar la extensión sin cuentas de SAP S/4HANA.
• Alcance multisistema. Una sola aplicación puede combinar SAP S/4HANA con otros sistemas SAP y no SAP.

Para extensiones con público, necesidades de escalado o ritmo de releases propios, la extensibilidad side-by-side es la opción que SAP posiciona en SAP BTP.

• Sin transacción compartida. Una llamada remota no puede modificar datos de SAP y datos personalizados en una misma unidad de trabajo, por lo que la coherencia debe diseñarse con compensaciones o reintentos.
• Limitada por las API remotas. Si ninguna API liberada ni ningún evento cubre la operación necesaria, la extensión no puede llegar a ella de forma limpia; puede que primero haya que crear una API on-stack de ABAP Cloud.
• Más piezas en movimiento. Por cada extensión se añaden conectividad, propagación de identidad, supervisión y operación.
• Volumen de datos y latencia. Leer grandes cantidades de datos de SAP, o hacer muchas llamadas granulares, es más lento y costoso que el acceso on-stack.
• Un segundo ciclo de vida que asumir. Cada extensión necesita un responsable, un presupuesto y un modelo de soporte después de la puesta en producción.

La extensibilidad side-by-side mantiene limpio el núcleo trasladando la complejidad al panorama de sistemas que lo rodea, donde sigue siendo necesario gestionarla.

Las directrices de arquitectura de extensiones de SAP ofrecen una prueba práctica. Características que apuntan a cada opción:

Muchos requisitos necesitan ambas cosas: un servicio on-stack de ABAP Cloud que expone una API remota personalizada y una app side-by-side que la consume. La decisión se toma por requisito, y el acoplamiento con los datos de SAP S/4HANA es el criterio decisivo.

• SAP S/4HANA Cloud Public Edition: el servicio SAP S/4HANA Cloud Extensibility en SAP BTP conecta un sistema registrado a un subaccount, con el plan de servicio api-access para las API y el plan messaging para los eventos; para las conexiones entrantes, se genera una destination HTTP al crear la instancia de servicio.
• Private Edition y on-premise: SAP Cloud Connector y las destinations conectan SAP BTP con el sistema, y las API OData liberadas se activan en SAP Gateway; los eventos salen del sistema a través del componente Enterprise Event Enablement.
• Todas las ediciones: para las llamadas que se ejecutan como el usuario que ha iniciado sesión, se configura principal propagation, con single sign-on mediante SAP Cloud Identity Services para Public Edition y mediante Cloud Connector para Private Edition y on-premise.

El patrón de extensión es idéntico en todas las ediciones; solo difieren la conectividad, la configuración de eventos y la configuración de confianza.