Transformación hacia Clean Core · 4 de 8
SAP BTP: extender S/4HANA sin modificar el ERP
En resumen
La extensibilidad side-by-side consiste en construir aplicaciones y servicios en SAP Business Technology Platform que consumen APIs y eventos publicados de S/4HANA, en lugar de desarrollarlos dentro del ERP. Su ventaja principal es la separación de ciclos de vida: la extensión evoluciona a su ritmo y las actualizaciones del ERP no la afectan mientras las APIs consumidas se mantengan estables.
Sacar una extensión del ERP tiene un coste evidente: hay que operar una plataforma más. La pregunta correcta no es si BTP es una buena tecnología, sino en qué casos ese coste se paga solo.
Qué es side-by-side
La extensibilidad side-by-side consiste en construir la extensión como una aplicación independiente en SAP Business Technology Platform, que consume APIs y eventos publicados del sistema central en lugar de vivir dentro de él.
El ERP no sabe que la extensión existe. Solo publica interfaces.
Qué se construye realmente
- Aplicaciones Fiori independientes, desplegadas en BTP e integradas en el launchpad junto a las aplicaciones estándar. El usuario no percibe la diferencia.
- Servicios de negocio con CAP, en Node.js o Java, que orquestan lógica que no pertenece al ERP.
- Integraciones y arquitecturas dirigidas por eventos, donde el ERP publica un hecho de negocio y varios consumidores reaccionan sin acoplarse entre sí.
- Automatizaciones de proceso, incluidos flujos con intervención humana.
- Modelos y servicios de datos para analítica que no debe ejecutarse sobre el sistema transaccional.
La ventaja que importa: ciclos de vida separados
Este es el argumento central, y conviene formularlo con precisión.
Una extensión dentro del ERP está atada a su calendario: se despliega con sus ventanas, se prueba con sus regresiones y se actualiza a su ritmo. Una extensión en BTP se despliega cuando el negocio lo necesita, sin esperar a nadie.
El corolario es igual de importante: cuando el ERP se actualiza, la extensión no se toca, siempre que las APIs consumidas mantengan su contrato de estabilidad. Esa condición no es automática, y verificarla forma parte del diseño.
Cuándo NO conviene
Un artículo honesto sobre BTP tiene que incluir esta sección.
Cuando la lógica pertenece al core. Si necesita ejecutarse dentro de la misma transacción, con los mismos bloqueos y la misma consistencia que los datos que manipula, sacarla fuera introduce complejidad distribuida a cambio de nada.
Cuando la latencia importa. Una llamada remota tiene un coste que una llamada local no tiene. En procesos interactivos con alto volumen, ese coste se nota.
Cuando no hay capacidad de operar la plataforma. BTP añade subcuentas, entitlements, despliegues, identidades, monitorización y una factura por consumo. Si nadie va a gobernar eso, la extensión funcionará hasta que deje de hacerlo.
Lo que hay que resolver desde el primer día
Tres cosas que, si se dejan para después, se convierten en deuda:
Identidad. La extensión debe autenticar contra el mismo proveedor que el resto del entorno, y las llamadas al backend deben propagar la identidad real del usuario en lugar de usar una cuenta técnica compartida. Es la diferencia entre poder auditar y no poder.
Estructura de cuentas. Decidir la jerarquía de subcuentas y entitlements antes de crear la primera es barato; reorganizarla después implica migrar aplicaciones y suscripciones.
Contratos de API. Documentar qué APIs consume cada extensión, con qué garantía de estabilidad, y quién revisa esa lista antes de cada actualización del ERP.
En una frase
Side-by-side no es “desarrollar fuera porque es más moderno”: es separar lo que cambia al ritmo del negocio de lo que cambia al ritmo del ERP.
Construimos extensiones side-by-side sobre BTP. Ver Fiori / SAPUI5 o reservar una sesión.