Clean core: extender SAP sin romperlo

Hace años, cuando una empresa quería personalizar SAP, los desarrolladores metían mano directamente en el código estándar. El resultado: después de cada actualización, todo se rompía. Tenías que volver a hacer los cambios, y los problemas se multiplicaban. Era como intentar reformar una casa mientras vives en ella.

Hoy existe una palabra mágica en SAP: clean core. Y cambia completamente cómo extiendes el sistema sin destrozarlo.

¿Qué es exactamente el clean core?

Clean core significa que el núcleo de SAP permanece intacto. Ninguna modificación directa al código estándar. Cero cambios en las tablas originales, cero funciones personalizadas dentro del sistema.

Suena restrictivo, ¿verdad? Pero en realidad te libera:

Las actualizaciones son seguras: cuando SAP publica una nueva versión, tu sistema actualiza sin miedo a que tus personalizaciones desaparezcan o causen conflictos.
El soporte funciona: SAP puede ayudarte porque sabe exactamente qué código está ejecutando.
La migración es posible: si en el futuro quieres cambiar de versión o plataforma, no arrastras 10 años de parches incompatibles.

Pero entonces, ¿cómo personalizas sin tocar el core? Bienvenido al mundo de las extensiones side-by-side.

Extensiones side-by-side: personalizaciones fuera del core

Instead de modificar SAP, construyes aplicaciones que viven al lado de SAP, conectadas pero independientes. Es como tener tiendas satélite alrededor del almacén central, en lugar de agregar estanterías dentro.

Estas extensiones viven principalmente en SAP BTP (como ya vimos en la lección 5):

Dónde se despliegan:

Cloud Foundry o Kyma en BTP: espacio donde corre tu código personalizado, sin tocar S/4HANA.
APIs y eventos: tu extensión se conecta a SAP mediante interfaces públicas y bien documentadas.
Datos propios: almacena datos específicos de tu negocio en bases de datos separadas, integradas con las de SAP.

Ejemplo real de oficina:

Eres analista de finanzas en una empresa. SAP tiene un módulo estándar de facturación. Pero tu jefe quiere un sistema de reglas especiales para descuentos según el cliente, la región y la fecha. No es estándar en SAP.

Opción antigua (modificación directa): Un developer entra a ABAP, modifica la lógica de facturación, crea tablas personalizadas. Tres meses después, SAP publica una actualización de seguridad. Tu modificación entra en conflicto. Todo se quiebra.

Opción clean core (extensión side-by-side): Creáis una microaplicación en BTP que escucha los eventos de facturación desde SAP. Cuando alguien intenta facturar, vuestra app calcula el descuento según vuestras reglas especiales, devuelve el resultado a través de una API, y SAP lo aplica. Vuestra lógica de negocio está completamente separada. SAP actualiza tranquilamente; vuestra app sigue funcionando.

El papel de la IA en las extensiones side-by-side

Aquí es donde todo se pone interesante. Crear extensiones side-by-side sigue siendo desarrollo: necesitas saber cómo llamar APIs, estructurar datos, escalar aplicaciones.

Pero la IA generativa acelera cada paso:

1. Generación de código

Le describes a Joule (o a Claude a través del Generative AI Hub) el comportamiento que necesitas:

"Necesito una función que lea facturas de SAP, calcule descuentos según estas reglas, y envíe el resultado de vuelta"

La IA te genera el código base. No desde cero; con lógica real, estructura profesional, manejo de errores. Tú revisas y ajustas.

2. Integración de APIs

Las APIs de SAP son complejas. La IA te ayuda a:

Entender qué endpoint necesitas.
Construir la solicitud con los parámetros correctos.
Parsear la respuesta.
Documentar todo.

Tareas que antes tomaban horas de documentación y prueba, ahora son 10 minutos con un buen prompt.

3. Pruebas y debugging

Describes qué no funciona. La IA te sugiere dónde mirar, qué logs revisar, qué podría estar mal en la integración.

4. Documentación viva

Tu código está documentado mientras lo escribes, porque le preguntabas a la IA qué hace mientras lo generabas. Futuro developer que mantenga esto: te lo agradecerá.

Clean core en la práctica: restricciones que libran

No todo se puede hacer "side-by-side". Hay límites:

Cambios en tablas estándar: no puedes agregar columnas a las tablas core de SAP. Pero puedes crear tablas relacionadas en tu extensión.
Modificación de procesos core: no editas el módulo de compras. Pero interceptas eventos y aplicas tu lógica.
Rendimiento en datos masivos: si necesitas procesar millones de registros del core, tienes que replicar datos en BTP y procesarlos ahí.

Estas restricciones suenan incómodas. Pero una vez que las integras, la vida es más simple: controlas qué está dónde, las dependencias están claras, los problemas son más fáciles de aislar.

La gobernanza detrás del clean core

Esto no es solo una recomendación técnica. SAP empuja activamente el clean core porque:

Reduce el costo de mantenimiento: menos código personalizado = menos bugs futuros.
Acelera las actualizaciones: puedes cambiar de versión sin proyectos gigantes de regresión.
Mejora la seguridad: SAP parchea el core sin afectar tus extensiones.

Muchas empresas tienen contratos donde SAP no garantiza soporte si has modificado el core. Clean core es la nueva realidad.

Para recordar

Clean core significa no modificar el código estándar de SAP; todas tus personalizaciones viven fuera, integradas por APIs y eventos.
Las extensiones side-by-side corren en SAP BTP (o Kyma) como aplicaciones independientes, conectadas pero aisladas del core.
La IA generativa acelera el desarrollo de estas extensiones: genera código de integración, ayuda con APIs, documenta y debuggea automáticamente.
Las restricciones son libertad: no puedes modificar SAP, pero tampoco necesitas hacerlo; ganas certeza de que las actualizaciones no te romperán el sistema.

Próxima lección: Seguridad y roles en SAP: lo mínimo que debes saber