Concepto de niveles Clean Core (A-D): El camino moderno hacia ABAP Cloud

Kategorie
ABAP Cloud
Veröffentlicht
Autor
Johannes

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/InterfacePropósito
CL_ABAP_CONTEXT_INFOInformació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_MESSAGEMensajes 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 liberada
DATA: 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 moneda
CALL 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 liberada
DATA(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 SAP
SELECT SINGLE *
FROM mara
WHERE matnr = @lv_matnr
INTO @ls_material.
" ❌❌ Nivel D: Acceso a módulo de función no público
CALL 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

AspectoModelo de 3 capasConcepto de niveles (A-D)
ClasificaciónPor capa de arquitecturaPor uso de API
ComplejidadAlta (requiere wrapper)Baja (clasificación directa)
AutomatizaciónAsignación manualAutomatizado por ATC
TransicionesEstrictamente separadasFluidas
EnfoqueEncapsulamientoModernización
ObjetivoAlcanzar TIER-1Alcanzar Nivel A

Mapeo entre los modelos

Modelo de 3 capas Concepto de niveles
─────────────────────────────────────
TIER-1 (ABAP Cloud) → Nivel A
TIER-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 API

Estrategia práctica de modernización

Fase 1: Inventario

  1. Ejecutar análisis ATC con Check-Variant para Clean Core
  2. Determinar distribución de niveles y contar objetos por nivel
  3. Identificar objetos críticos de Nivel D

Fase 2: Priorización

PrioridadMigraciónMedidas
1 (Alta)D → A/BReemplazar accesos directos a tablas
2 (Media)C → A/BModernizar objetos no clasificados
3 (Baja)B → AReemplazar BAPIs por Released APIs

Fase 3: Implementación

" ANTES: Código Nivel D
SELECT SINGLE * FROM mara WHERE matnr = @lv_matnr INTO @ls_material.
" DESPUÉS: Código Nivel A
SELECT 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

RequisitoNivel recomendadoJustificación
Nueva aplicación RAPNivel ACloud-ready desde el principio
Integración con estándarNivel A/BSegún API disponible
Modernización legacyNivel B → AMigración gradual
Quick Fix (temporal)Nivel BCon ticket de modernización
Lógica específica de clienteNivel AObjetos propios son libres

Mejores prácticas para Clean Core Nivel A

Do’s

  • ✅ Usa CL_ABAP_CONTEXT_INFO para 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.