Transformación hacia Clean Core · 5 de 8
ABAP Cloud: la evolución del desarrollo SAP hacia un modelo gobernado
En resumen
ABAP Cloud es el modelo de desarrollo de SAP en el que solo se pueden consumir objetos y APIs que SAP ha liberado explícitamente, con un contrato de estabilidad asociado. Sustituye al acceso sin restricciones del ABAP clásico —donde cualquier tabla o función estándar era invocable— por un conjunto acotado de interfaces cuya compatibilidad SAP se compromete a mantener.
Durante décadas, un desarrollador ABAP podía leer cualquier tabla, llamar a cualquier función y modificar prácticamente cualquier cosa. Esa libertad fue una ventaja competitiva: permitía resolver cualquier requisito. También fue el origen de la deuda técnica que hoy pesa en cada upgrade.
Qué cambia
ABAP Cloud es el modelo en el que el código propio solo puede consumir objetos que SAP ha liberado explícitamente, cada uno con un contrato de estabilidad.
| ABAP clásico | ABAP Cloud |
|---|---|
| Acceso a cualquier tabla | Solo vistas y APIs liberadas |
| Llamada a cualquier función | Solo interfaces con contrato |
| Modificación del estándar posible | No disponible |
| Compatibilidad: sin garantía | Compromiso explícito de SAP |
| Patrones libres | CDS y RAP |
El cambio técnico es acotado. El cambio de mentalidad no.
El concepto que sostiene el modelo: el objeto liberado
Un objeto liberado es aquel que SAP ha marcado como consumible por código de cliente, asumiendo el compromiso de mantener su compatibilidad.
Lo contrario es un objeto interno. En un sistema clásico también era accesible — técnicamente nada lo impedía— pero sin ninguna garantía. Cuando una actualización cambiaba su estructura, el código que dependía de él se rompía, y la responsabilidad era del cliente.
ABAP Cloud no inventa esa distinción: la hace explícita y la aplica. Lo que antes era una recomendación que se ignoraba, ahora es una restricción del compilador.
Por qué es un cambio cultural
Para un equipo acostumbrado al modelo clásico, la primera experiencia con ABAP Cloud suele ser de frustración: el objeto que necesitas no está liberado.
La reacción instintiva es buscar cómo saltarse la restricción. La reacción productiva es preguntarse dos cosas: si existe una API liberada que resuelve lo mismo por otro camino, y si el hecho de que SAP no haya liberado ese objeto indica que la solución iba por donde no debía.
Con frecuencia la respuesta es la segunda. Un objeto no liberado suele ser un detalle de implementación, y depender de detalles de implementación ajenos es exactamente lo que causa que los upgrades duelan.
El modelo por niveles: no hay que reescribirlo todo
SAP plantea una transición por niveles que permite convivencia:
- Desarrollo nuevo en ABAP Cloud. Todo lo que se construye a partir de ahora sigue el modelo.
- Envolturas para lo que falta. Cuando un desarrollo en ABAP Cloud necesita algo aún no liberado, se construye una envoltura que aísla esa dependencia en un único punto. El día que SAP libere la funcionalidad, se cambia la envoltura y no los veinte sitios que la usaban.
- Código clásico que se mantiene. Lo existente que sigue siendo necesario no se reescribe por principio. Se documenta, se acota y se planifica.
La clave del segundo nivel es que concentra el riesgo. Una dependencia no liberada dispersa por todo el código es ingobernable; la misma dependencia encapsulada en una clase es un elemento de inventario.
Cómo cambia el rol
El desarrollador deja de preguntarse “¿cómo lo hago?” para preguntarse primero “¿qué me han dado para hacerlo?”. Es un trabajo más de composición y menos de construcción desde cero.
El arquitecto asume una responsabilidad nueva: decidir qué se construye dentro y qué fuera, mantener el catálogo de envolturas y revisar qué se ha liberado en cada release. Ese seguimiento no es opcional: cada versión libera APIs que pueden eliminar envolturas existentes.
El error más común en la transición
Adoptar ABAP Cloud como una norma de codificación sin cambiar el proceso de decisión previo. El resultado es código formalmente correcto que sigue haciendo cosas que no deberían estar en el core.
ABAP Cloud garantiza que lo que escribes sobreviva a la actualización. No garantiza que debiera haberse escrito. Esa segunda pregunta se responde en el árbol de decisión de extensibilidad.
En una frase
ABAP Cloud no limita lo que puedes construir: limita aquello de lo que puedes depender, que es de donde venía el problema.
Trabajamos con CDS, RAP y ABAP Cloud sobre S/4HANA. Ver CDS & RAP o reservar una sesión.