Por qué un programa con pantalla clásica se queda en el nivel B
El nivel A exige ABAP Cloud, y ABAP Cloud no acepta pantallas del SAP GUI. Qué significa esto para los informes y las transacciones Z, y cuándo vale la pena llegar hasta el A.
Quien empieza la adecuación Clean Core suele sorprenderse con un detalle del panel de SAP Cloud ALM: un informe Z corregido por completo, sin ningún hallazgo, sigue en el nivel B. No es un error de medición. Es una regla, y entenderla cambia la forma de planificar el trabajo.
El nivel A exige ABAP Cloud
Un objeto en ABAP estándar, incluso sin ningún hallazgo, aparece como nivel B. Para llegar al A, tiene que estar en la versión de lenguaje ABAP Cloud, que solo permite API liberadas por SAP. La conversión es un paso propio del trabajo: además de dejar la deuda en cero, hay que quitar lo que ABAP Cloud no acepta, aunque no cuente como deuda.
Lo que ABAP Cloud no acepta
ABAP Cloud nació en la nube pública, donde SAP actualiza el sistema de todos los clientes sin probar el código de cada uno. Por eso es mucho más que "usar solo API liberadas": es una versión reducida del lenguaje, en la que lo que no existe simplemente no se activa. Las principales diferencias:
| Área | En el ABAP clásico | En ABAP Cloud |
|---|---|---|
| Interfaz | Dynpro, pantalla de selección, listas con WRITE, ALV, GUI status |
Fiori sobre RAP, con servicio OData. El desarrollo es solo en ADT, sin SAP GUI |
| Programas | REPORT, INCLUDE, module pool, SUBMIT, CALL TRANSACTION |
Solo clases, interfaces y grupos de funciones. El procesamiento en fondo se convierte en application job |
| Objetos de SAP | Cualquiera | Solo los liberados: la tabla de SAP da paso a la CDS liberada, y la BAPI a la interfaz RAP sucesora, cuando existe |
| Archivos | OPEN DATASET, carga y descarga desde el SAP GUI |
Sin acceso al sistema de archivos del servidor |
| Base de datos | SQL nativo (EXEC SQL), cursores, acceso a otro mandante |
ABAP SQL y AMDP, siempre solo en el mandante actual |
| Transacción | Update task, PERFORM ON COMMIT |
Actualización siempre local. Dentro de RAP, quien confirma la grabación es el propio framework |
| Paralelismo | STARTING NEW TASK, tRFC |
Frameworks liberados: CL_ABAP_PARALLEL y el Background Processing Framework |
| Ampliaciones | User exit, ampliación implícita o explícita, modificación | Solo BAdI liberado |
| Servicios técnicos | Funciones clásicas de log, numeración, correo electrónico y bloqueo; Smart Forms y SAPscript; destinos en la SM59 | API liberadas para cada servicio, Adobe Forms y escenarios de comunicación |
| Lenguaje | Macros, header line, MOVE, DESCRIBE y otras sentencias obsoletas |
Sin macros y sin obsoletos. Mensajes solo mediante excepción, RAP o log de aplicación |
Y lo que se suele presentar como prohibido, pero no lo es: crear y llamar módulos de funciones propios, RFC síncrono, COMMIT WORK fuera de RAP, AMDP, programación dinámica (con la verificación de liberación hecha durante la ejecución), AUTHORITY-CHECK y la lectura y escritura en las tablas propias de la empresa.
Para un programa con pantalla clásica (SAP GUI), la primera fila de la tabla ya lo decide: no tiene forma de ser ABAP Cloud. Por lo tanto, su máximo es el nivel B. Llevarlo al A significa rehacer la interfaz en Fiori, un proyecto aparte.
La lista completa, con las sentencias de cada área y lo que sustituye a cada una, está en ABAP Cloud: qué cambia respecto al ABAP clásico.
A y B no son lo mismo
Los dos niveles están del lado aceptado por Clean Core. La diferencia está en quién lo garantiza:
| Nivel B (ABAP estándar) | Nivel A (ABAP Cloud) | |
|---|---|---|
| Estabilidad | En la práctica: una BAPI casi nunca cambia, pero SAP no asume un compromiso formal | Por contrato: el objeto liberado solo cambia con aviso y con un sucesor indicado |
| Quién lo garantiza | El ATC, cuando se ejecuta | El propio sistema: el código con un uso no liberado no se activa |
| Puede empeorar después | Sí: una modificación futura puede volver a leer una tabla de SAP | No: la verificación de sintaxis lo rechaza |
| Dónde funciona | SAP S/4HANA on-premise y Private Edition | El mismo modelo vale en todas las ediciones; el código va adonde las mismas API están liberadas, como la Public Edition |
Hasta dónde puede llegar cada objeto
Antes de prometer un nivel, conviene clasificar cada objeto:
| Tipo de objeto | Cómo reconocerlo | Hasta dónde puede llegar |
|---|---|---|
| Clásico por naturaleza | Tiene pantalla: pantalla de selección, dynpro, WRITE o lista ALV |
B |
| Convertible a ABAP Cloud | No tiene pantalla: clases de reglas de negocio, funciones de cálculo, interfaces | A, si todo uso de SAP tiene una alternativa liberada o un wrapper |
En un objeto clásico por naturaleza, sustituir un hallazgo B por una API liberada reduce la deuda, pero el nivel sigue siendo B. Las sentencias clásicas que no generan hallazgos, como FORM, WRITE y las pantallas, pueden quedarse como están: no cambian ni la deuda ni el nivel.
Entonces, ¿vale la pena tratar un programa con pantalla?
Sí, y mucho. El riesgo real de un upgrade está en los hallazgos C y D: lecturas directas de tablas de SAP, que SAP considera internas, y usos fuera de Clean Core, que pueden romperse cuando SAP cambia el sistema. Un objeto sin hallazgos C y D ya elimina casi todo ese riesgo, y eso es lo que el panel muestra como mejora de la puntuación.
El nivel A compensa donde el código va a seguir evolucionando: reglas de negocio compartidas, wrappers y desarrollo nuevo. En esos casos, la garantía de que el código no vuelve a empeorar paga la conversión. Para entender cómo entran estos puntos en la cuenta del panel, véase Cómo calcula SAP Cloud ALM la deuda Clean Core.
Fuentes
- SAP Help, ABAP Keyword Documentation, Language Elements in ABAP Versions (S/4HANA 2025) y la documentación de ABAP for Cloud Development.
- SAP Community, ABAP Cloud FAQ.
- Thomas Schneider (SAP), ABAP Language Versions – FAQs, SAP Community.
- SAP, Cloudification Repository (GitHub SAP/abap-atc-cr-cv-s4hc), con los sucesores liberados de los objetos clásicos.