Clean core explicado para desarrolladores ABAP
"Clean core" aparece en todas las presentaciones de SAP desde hace unos años y suele explicarse con diagramas de arquitectura. Para quien escribe código, la idea se resume en una frase: tus desarrollos solo pueden usar lo que SAP se compromete a no romper.
El problema que intenta resolver
En un ECC típico, los desarrollos Z leen directamente tablas de SAP, llaman a módulos de función internos, modifican objetos estándar y usan user exits. Todo eso funciona hasta que SAP cambia algo por dentro. Por eso cada actualización de versión es un proyecto: hay que revisar qué se ha roto.
En S/4HANA Cloud Public Edition, SAP actualiza el sistema varias veces al año y no puede esperar a que cada cliente revise su código. La solución es un contrato: SAP marca ciertos objetos como liberados (released) y garantiza que seguirán funcionando. Tu código solo puede usar esos.
ABAP Cloud: el lenguaje con el contrato aplicado
ABAP Cloud no es otro lenguaje. Es ABAP con dos restricciones que el compilador comprueba:
- Lenguaje restringido. Desaparece lo ligado a SAP GUI y al sistema operativo:
WRITE, dynpros, pantallas de selección,CALL TRANSACTION,SUBMIT, ficheros del servidor,EXEC SQL, la memoria ABAP. - Solo objetos liberados. Tablas, vistas, clases y funciones de SAP solo se pueden usar si tienen contrato de liberación.
MARAno;I_Productsí.
En BTP ABAP Environment y en S/4HANA Cloud Public Edition no hay alternativa. En S/4HANA on-premise y Private Edition se elige por paquete: el paquete se marca con versión de lenguaje "ABAP for Cloud Development" y a partir de ahí el compilador aplica las reglas.
Lo que cambia al escribir código
| Antes | En ABAP Cloud |
|---|---|
SELECT FROM mara | SELECT FROM I_Product |
sy-datum, sy-uname | cl_abap_context_info=>get_system_date( ), get_user_technical_name( ) |
BAPI_PO_CREATE1 | EML sobre el BO liberado I_PurchaseOrderTP_2 |
| Report con ALV | Vista CDS + app Fiori Elements |
| Report en fondo (SM36) | Application Job |
BAL_LOG_CREATE | cl_bali_log |
SO_NEW_DOCUMENT_ATT_SEND_API1 | cl_bcs_mail_message |
| User exit, modificación | BAdI liberada, extensión de BO RAP, campos personalizados |
Los niveles de extensibilidad
SAP organiza las extensiones por niveles según lo "limpias" que son:
- Nivel A. ABAP Cloud puro: solo APIs liberadas. Es el objetivo para todo lo nuevo.
- Nivel B. ABAP clásico usando APIs clásicas que SAP considera estables (por ejemplo, BAPIs documentadas), sin modificar el estándar. Aceptable en Private Edition y on-premise.
- Nivel C. Uso de objetos internos de SAP no liberados. Funciona, pero hay que revisarlo en cada actualización.
- Nivel D. Modificaciones del estándar, implementaciones implícitas, objetos que SAP desaconseja. Es lo que hay que ir eliminando.
¿Y el código Z que ya existe?
Nadie reescribe diez mil programas de golpe. El enfoque razonable es:
- Medir. Ejecutar el ATC con la variante de S/4HANA (y, si se quiere ir más lejos, con
ABAP_CLOUD_READINESS) y cruzar el resultado con el uso real de cada programa (transacción SUSG o el monitor de uso). Lo que nadie usa se retira. - Lo nuevo, en ABAP Cloud. Desde ya, los desarrollos nuevos van en paquetes de ABAP Cloud siempre que las APIs necesarias estén liberadas.
- Lo que se toca, se moderniza. Cuando hay que modificar un programa antiguo, se aprovecha para quitar sintaxis obsoleta y accesos directos a tablas, aunque siga siendo ABAP clásico.
- Envolver lo que falta. Si una funcionalidad no tiene API liberada todavía, se encapsula en una clase en un paquete clásico con una interfaz limpia, liberada para uso propio (contrato C1 de cliente). Cuando SAP libere la API, solo cambia esa clase.
Cómo saber si un objeto está liberado
- En ADT, la pestaña Properties > API State del objeto.
- En el SAP Business Accelerator Hub (api.sap.com), sección de vistas CDS y BO de RAP.
- En el Cloudification Repository en GitHub, que además indica el sucesor recomendado de cada objeto no liberado.