Transformación hacia Clean Core · 3 de 8
Extensibilidad SAP: cómo decidir antes de desarrollar
En resumen
Antes de escribir código en SAP conviene recorrer cinco opciones en orden: adoptar la funcionalidad estándar, resolverlo por configuración, usar Key User Extensibility (extensibilidad in-app sin código), usar Developer Extensibility con ABAP Cloud dentro del sistema, y por último construir una extensión side-by-side en SAP BTP. Cada escalón añade coste de ciclo de vida, así que la regla es detenerse en el primero que resuelva la necesidad.
La pregunta que más dinero cuesta en un proyecto SAP no es cómo desarrollar algo. Es si hay que desarrollarlo.
El árbol de decisión
SAP propone recorrer las alternativas en orden y detenerse en la primera que resuelva la necesidad. Cada escalón añade coste de construcción y, sobre todo, coste de ciclo de vida.
1. Adoptar el estándar
Antes de cualquier otra cosa: ¿la funcionalidad ya existe y no se está usando?
Es más frecuente de lo que parece, especialmente en organizaciones que vienen de ECC. Se construyó una solución propia hace años porque el estándar no lo cubría, y desde entonces lo cubre. La modificación sobrevive por inercia.
Este escalón suele requerir una conversación incómoda: adoptar el estándar significa que algún proceso cambia. Merece la pena tenerla.
2. Configuración
Si el estándar lo cubre pero no exactamente como se necesita, la siguiente pregunta es si se resuelve configurando. Coste de actualización: cero.
3. Key User Extensibility
Extensibilidad in-app, sin programar. Permite añadir campos personalizados, definir lógica en puntos de extensión predefinidos, crear vistas de datos personalizadas y adaptar interfaces, desde aplicaciones del propio sistema.
La ventaja decisiva es que lo construido así es compatible con las actualizaciones por diseño: se apoya en puntos de extensión que SAP mantiene estables deliberadamente.
Su límite es la lógica compleja. Cuando el requisito empieza a necesitar estructuras de control elaboradas o integración con varios objetos, se ha salido del terreno de este escalón.
4. Developer Extensibility
Desarrollo ABAP dentro del sistema, pero bajo el modelo ABAP Cloud: solo se consumen objetos y APIs liberados por SAP, con contratos de estabilidad explícitos.
Es la opción cuando la lógica pertenece al core, está fuertemente acoplada a los datos transaccionales y el equipo que la mantendrá es ABAP. Se construye con CDS y RAP, no con los patrones clásicos.
La diferencia con el ABAP de siempre no es el lenguaje: es que ya no se puede acceder a cualquier tabla ni llamar a cualquier función. Solo a lo liberado. Trataremos ese cambio en profundidad en ABAP Cloud y el nuevo rol del desarrollador.
5. Side-by-Side Extensibility
Una aplicación independiente en SAP BTP que consume APIs y eventos publicados del ERP.
Es la opción cuando la lógica no pertenece al core, cuando necesita un ciclo de vida propio, cuando requiere tecnologías que la pila ABAP no ofrece, o cuando la mantendrá un equipo que no es ABAP.
La tabla que conviene tener a mano
| Opción | Quién lo hace | Impacto en upgrade | Cuándo |
|---|---|---|---|
| Estándar | Funcional | Ninguno | Siempre que sea viable |
| Configuración | Funcional | Ninguno | El estándar casi encaja |
| Key User | Usuario experto | Muy bajo | Campos y lógica acotada |
| Developer (ABAP Cloud) | Desarrollador ABAP | Bajo si respeta lo liberado | Lógica del core |
| Side-by-Side (BTP) | Equipo de desarrollo | Aislado del core | Lógica que no pertenece al ERP |
El criterio que resuelve la mayoría de los casos
Cuando la duda es entre los escalones 4 y 5 —desarrollar dentro o fuera—, dos preguntas suelen bastar:
¿La lógica cambia al ritmo del ERP o al ritmo del negocio? Si cambia varias veces al año por decisiones comerciales, atarla al calendario de actualizaciones de S/4HANA es un error. Debe salir.
¿Quién la va a mantener dentro de tres años? Si la respuesta no es el equipo ABAP, no la pongas en la pila ABAP.
Lo que hay que documentar
Independientemente del escalón elegido, cada extensión debería dejar registro de tres cosas:
- Qué necesidad de negocio justifica su existencia. Sin esto, dentro de cinco años nadie sabrá si se puede retirar.
- Qué escalones se descartaron y por qué. Es lo que impide repetir la discusión cada vez.
- Quién es el responsable de su ciclo de vida. Una extensión sin dueño es una extensión que nadie retirará jamás.
Esto no es burocracia: es lo que separa un catálogo de extensiones de un vertedero. Lo desarrollamos en Gobierno de extensiones.
En una frase
Cada línea de código propio debe tener una justificación de negocio y una estrategia de ciclo de vida. Si no tiene ambas, la decisión correcta es no escribirla.
Diseñamos extensiones sobre S/4HANA y BTP bajo estos criterios. Ver CDS & RAP o reservar una sesión.