El concepto de niveles Clean Core (A-D) es el enfoque más reciente de SAP para la clasificación y modernización del código ABAP. Reemplaza el más complejo modelo de 3 capas por un sistema escalonado más simple. Este artículo explica los cuatro niveles, muestra la integración con ATC y ofrece ayuda práctica para decisiones de modernización.
¿Por qué un nuevo concepto de niveles?
El modelo de 3 capas demostró ser complejo en la práctica. La clara separación en TIER-1, TIER-2 y TIER-3 era teóricamente limpia, pero difícil de mantener en proyectos reales. SAP respondió a esto introduciendo el concepto de niveles como un enfoque más pragmático:
- Clasificación más simple sin separación estricta de capas
- Detección automática mediante checks ATC
- Transiciones fluidas entre niveles
- Enfoque en uso de APIs en lugar de capas de arquitectura
Los cuatro niveles en resumen
┌─────────────────────────────────────────────────────────────┐│ Nivel A: Released APIs ││ ────────────────────── ││ • Solo APIs SAP liberadas (contrato C1) ││ • Compatibilidad Cloud completa ││ • Preparado para el futuro y estable ante upgrades ││ • ✅ Conforme con Clean Core │└──────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────┐│ Nivel B: Classic APIs ││ ────────────────────── ││ • APIs clásicas estables (BAPIs, RFC) ││ • No liberadas para Cloud, pero documentadas ││ • Riesgo de upgrade moderado ││ • ⚠️ Modernización recomendada │└──────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────┐│ Nivel C: No clasificado ││ ────────────────────── ││ • Acceso a objetos no clasificados ││ • Sin contrato SAP, sin garantía de estabilidad ││ • Alto riesgo de upgrade ││ • ❌ Modernización requerida │└──────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────┐│ Nivel D: noAPI (accesos directos) ││ ────────────────────── ││ • Accesos directos a tablas (SELECT en tablas SAP) ││ • Módulos de función no públicos ││ • Máximo riesgo de upgrade ││ • ❌ Modernización inmediata necesaria │└──────────────────────────────────────────────────────────────┘Nivel A: Released APIs
El Nivel A es el objetivo de toda modernización. El código en este nivel usa exclusivamente APIs SAP liberadas con contrato estable (C1).
Características del Nivel A
- Contrato API: C1 (Released for Cloud Development)
- Estabilidad ante upgrades: Garantizada por SAP
- Cloud-Readiness: Totalmente compatible
- Documentación: Documentación oficial de SAP disponible
Ejemplo: Código Nivel A
CLASS zcl_flight_booking_a DEFINITION PUBLIC FINAL CREATE PUBLIC.
PUBLIC SECTION. METHODS get_user_info RETURNING VALUE(rs_user) TYPE cl_abap_context_info=>ty_context_info.
METHODS get_current_date RETURNING VALUE(rv_date) TYPE d.
METHODS read_flights RETURNING VALUE(rt_flights) TYPE zt_flights.
ENDCLASS.
CLASS zcl_flight_booking_a IMPLEMENTATION. METHOD get_user_info. " ✅ Nivel A: Released API para info de usuario rs_user-user_id = cl_abap_context_info=>get_user_technical_name( ). rs_user-user_alias = cl_abap_context_info=>get_user_alias( ). rs_user-system_date = cl_abap_context_info=>get_system_date( ). ENDMETHOD.
METHOD get_current_date. " ✅ Nivel A: Released API para fecha rv_date = cl_abap_context_info=>get_system_date( ). ENDMETHOD.
METHOD read_flights. " ✅ Nivel A: Acceso a tabla Z propia (siempre permitido) SELECT * FROM zflight_book INTO TABLE @rt_flights. ENDMETHOD.ENDCLASS.APIs Nivel A frecuentemente usadas
| Clase/Interface | Propósito |
|---|---|
CL_ABAP_CONTEXT_INFO | Información de usuario y sistema |
XCO_CP_* | Extension Components (DDIC, CDS, Repository) |
CL_ABAP_RANDOM_* | Números aleatorios |
CL_ABAP_CONV_* | Conversión de juego de caracteres |
IF_ABAP_BEHV_MESSAGE | Mensajes RAP |
Nivel B: Classic APIs
El Nivel B comprende APIs clásicas estables como BAPIs y módulos de función RFC. Estas están documentadas y son relativamente estables, pero no están liberadas para la Cloud.
Características del Nivel B
- Contrato API: Estable, pero no C1
- Estabilidad ante upgrades: Generalmente dada, pero no garantizada
- Cloud-Readiness: No directamente, se requiere wrapper
- Documentación: Disponible (BAPI Explorer, documentación de módulo de función)
Ejemplo: Código Nivel B
" ⚠️ Nivel B: BAPI - estable pero no liberadaDATA: lt_return TYPE TABLE OF bapiret2.
CALL FUNCTION 'BAPI_CUSTOMER_GETDETAIL2' EXPORTING customerno = lv_customer_id IMPORTING customerdata = ls_customer TABLES return = lt_return.
" ⚠️ Nivel B: Módulo de función clásico de monedaCALL FUNCTION 'CONVERT_TO_LOCAL_CURRENCY' EXPORTING date = sy-datum foreign_amount = lv_amount foreign_currency = 'USD' local_currency = 'EUR' IMPORTING local_amount = lv_result.Objetos típicos de Nivel B
- BAPIs (módulos de función BAPI_*)
- Módulos de función RFC
- Elementos de datos y dominios documentados
Nivel C: No clasificado
El Nivel C contiene accesos a objetos SAP no clasificados. Estos no tienen contrato API y pueden cambiar en upgrades.
Características del Nivel C
- Contrato API: Ninguno
- Estabilidad ante upgrades: No garantizada
- Cloud-Readiness: No dada
- Documentación: A menudo solo disponible internamente
Ejemplo: Código Nivel C
" ❌ Nivel C: Clase no liberadaDATA(lo_flight_srv) = NEW cl_flight_service( ).DATA(lt_schedule) = lo_flight_srv->get_connections( lv_carrier ).
" ❌ Nivel C: Uso de clases GUI (no Cloud-capable)DATA(lo_alv) = NEW cl_gui_alv_grid( i_parent = lo_container ).lo_alv->set_table_for_first_display( CHANGING it_outtab = lt_data ).Nivel D: noAPI (accesos directos)
El Nivel D es el nivel más crítico. El código en este nivel accede directamente a estructuras internas de SAP y tiene el mayor riesgo en upgrades.
Características del Nivel D
- Contrato API: Ninguno, implementación interna
- Estabilidad ante upgrades: No dada
- Cloud-Readiness: Excluida
- Documentación: Ninguna pública
Ejemplo: Código Nivel D
" ❌❌ Nivel D: Acceso directo a tabla interna SAPSELECT SINGLE * FROM mara WHERE matnr = @lv_matnr INTO @ls_material.
" ❌❌ Nivel D: Acceso a módulo de función no públicoCALL FUNCTION 'SD_SALES_DOCUMENT_READ_INT' EXPORTING document_number = lv_vbeln IMPORTING sales_header = ls_header.Comparación: Concepto de niveles vs. Modelo de 3 capas
| Aspecto | Modelo de 3 capas | Concepto de niveles (A-D) |
|---|---|---|
| Clasificación | Por capa de arquitectura | Por uso de API |
| Complejidad | Alta (requiere wrapper) | Baja (clasificación directa) |
| Automatización | Asignación manual | Automatizado por ATC |
| Transiciones | Estrictamente separadas | Fluidas |
| Enfoque | Encapsulamiento | Modernización |
| Objetivo | Alcanzar TIER-1 | Alcanzar Nivel A |
Mapeo entre los modelos
Modelo de 3 capas Concepto de niveles─────────────────────────────────────TIER-1 (ABAP Cloud) → Nivel ATIER-2 (API-Wrapper) → Nivel A + B (según contenido del wrapper)TIER-3 (Classic) → Nivel B, C o D (según uso de API)Integración ATC para monitoreo de niveles
El ATC (ABAP Test Cockpit) detecta automáticamente qué nivel tiene un objeto de desarrollo.
Check-Variant ATC para Clean Core
Check-Variant: Z_CLEAN_CORE_LEVELS─────────────────────────────────────Checks:├── ABAP Cloud Readiness│ ├── Released API Usage (Nivel A)│ ├── Classic API Detection (Nivel B)│ ├── Unclassified Objects (Nivel C)│ └── Direct Table Access (Nivel D)│├── Prioridades:│ ├── Nivel D Findings: Prioridad 1 (Error)│ ├── Nivel C Findings: Prioridad 2 (Advertencia)│ └── Nivel B Findings: Prioridad 3 (Info)│└── Excepciones: └── Tablas Z: siempre Nivel A (objetos propios)Interpretar resultados ATC
" ATC Finding: Nivel D - Acceso directo a tabla" ────────────────────────────────────────────────" Objeto: ZCL_FLIGHT_LEGACY" Línea: 45" Finding: SELECT FROM MARA (tabla no liberada)" Prioridad: 1 (Error)" Recomendación: Usa CDS View I_Product o BAPI
" ATC Finding: Nivel C - Objeto no clasificado" ────────────────────────────────────────────────" Objeto: ZCL_CUSTOMER_SERVICE" Línea: 78" Finding: Uso de CL_GUI_ALV_GRID" Prioridad: 2 (Advertencia)" Recomendación: Migra a Fiori/RAP
" ATC Finding: Nivel B - Classic API" ────────────────────────────────────────────────" Objeto: ZCL_ORDER_PROCESSOR" Línea: 112" Finding: CALL FUNCTION 'BAPI_SALESORDER_CREATEFROMDAT2'" Prioridad: 3 (Info)" Recomendación: Verifica alternativa Released APIEstrategia práctica de modernización
Fase 1: Inventario
- Ejecutar análisis ATC con Check-Variant para Clean Core
- Determinar distribución de niveles y contar objetos por nivel
- Identificar objetos críticos de Nivel D
Fase 2: Priorización
| Prioridad | Migración | Medidas |
|---|---|---|
| 1 (Alta) | D → A/B | Reemplazar accesos directos a tablas |
| 2 (Media) | C → A/B | Modernizar objetos no clasificados |
| 3 (Baja) | B → A | Reemplazar BAPIs por Released APIs |
Fase 3: Implementación
" ANTES: Código Nivel DSELECT SINGLE * FROM mara WHERE matnr = @lv_matnr INTO @ls_material.
" DESPUÉS: Código Nivel ASELECT SINGLE Product, ProductType, BaseUnit FROM I_Product WHERE Product = @lv_matnr INTO @ls_material.Ayuda para decisiones: Qué nivel para qué caso de uso
Matriz de decisión
| Requisito | Nivel recomendado | Justificación |
|---|---|---|
| Nueva aplicación RAP | Nivel A | Cloud-ready desde el principio |
| Integración con estándar | Nivel A/B | Según API disponible |
| Modernización legacy | Nivel B → A | Migración gradual |
| Quick Fix (temporal) | Nivel B | Con ticket de modernización |
| Lógica específica de cliente | Nivel A | Objetos propios son libres |
Mejores prácticas para Clean Core Nivel A
Do’s
- ✅ Usa
CL_ABAP_CONTEXT_INFOpara info de sistema/usuario - ✅ Usa librerías XCO para acceso a metadatos
- ✅ Apuesta por CDS Views (I_*) para datos SAP
- ✅ Implementa nueva lógica en RAP Business Objects
- ✅ Usa Released Exceptions (CX_*)
Don’ts
- ❌ Sin SELECT directos a tablas SAP (MARA, VBAK, …)
- ❌ Sin SY-UNAME, SY-DATUM para código Cloud
- ❌ Sin llamadas a módulos de función no liberados
- ❌ Sin uso de clases CL_GUI_*
- ❌ Sin CALL TRANSACTION ni SUBMIT REPORT
Conclusión
El concepto de niveles Clean Core (A-D) simplifica considerablemente la modernización del código ABAP:
- Nivel A: El objetivo - totalmente Cloud-ready
- Nivel B: Solución de transición aceptable con APIs clásicas
- Nivel C: Necesidad de modernización reconocible
- Nivel D: Acción inmediata requerida
En comparación con el modelo de 3 capas, el concepto de niveles ofrece un enfoque más pragmático que puede monitorearse automáticamente mediante la integración ATC. El enfoque está en el uso de APIs en lugar de capas de arquitectura rígidas.
Para la implementación práctica de una estrategia Clean Core consulta Estrategia de niveles Clean Core - ¿Y ahora qué?. Más información sobre Released APIs en Definición de ABAP Cloud.