El Modelo 3-Tier en ABAP Cloud: Migración Estructurada desde Classic ABAP

Kategorie

ABAP Cloud

Veröffentlicht

15 feb 2026

Autor

El modelo 3-Tier es un patrón de arquitectura probado para la migración gradual de Classic ABAP a ABAP Cloud. Permite una coexistencia estructurada de ambos mundos y define responsabilidades claras para cada capa. Este artículo explica los tres Tiers, muestra ejemplos de código prácticos con el escenario de reserva de vuelos y proporciona consejos para la organización de paquetes.

¿Por qué un modelo Tier?

La migración de Classic ABAP a ABAP Cloud no es una tarea que pueda completarse de la noche a la mañana. En la mayoría de las empresas hay millones de líneas de código personalizado que deben modernizarse gradualmente. El modelo 3-Tier ofrece un enfoque estructurado para esto:

Separación clara entre código Cloud-ready y Legacy
Migración controlada sin riesgo de Big-Bang
Reutilización de funcionalidad existente a través de wrappers
Cumplimiento ATC mediante separación limpia de capas

Los tres Tiers en resumen

┌─────────────────────────────────────────────────────────┐
│ TIER-1: ABAP Cloud                                      │
│ ───────────────────                                     │
│ • Nuevos desarrollos                                    │
│ • RAP Business Objects                                  │
│ • Solo APIs Released                                    │
│ • Versión de lenguaje ABAP Cloud                        │
│ • A prueba de futuro y Cloud-ready                      │
└─────────────────────┬───────────────────────────────────┘
                      │ Llamadas solo vía Released APIs
                      ▼
┌─────────────────────────────────────────────────────────┐
│ TIER-2: API-Wrapper                                     │
│ ───────────────────                                     │
│ • Encapsula funcionalidad Classic ABAP                  │
│ • Proporciona Released APIs (C1-Contract)               │
│ • Puente entre Cloud y Classic                          │
│ • Contiene lógica de transformación                     │
└─────────────────────┬───────────────────────────────────┘
                      │ Llamadas internas
                      ▼
┌─────────────────────────────────────────────────────────┐
│ TIER-3: Classic ABAP                                    │
│ ───────────────────                                     │
│ • Código Legacy existente                               │
│ • APIs no-Released                                      │
│ • Accesos directos a BD                                 │
│ • Se migra gradualmente o se retira                     │
└─────────────────────────────────────────────────────────┘

TIER-1: ABAP Cloud

TIER-1 es la capa superior y contiene exclusivamente código conforme a ABAP Cloud. Aquí se realizan todos los nuevos desarrollos y se aplican reglas estrictas:

Características de TIER-1

Versión del lenguaje: ABAP for Cloud Development
APIs: Solo Released APIs (C1-Contract)
Modelo de programación: RAP (ABAP RESTful Application Programming Model)
Entorno de desarrollo: ABAP Development Tools (ADT)

Ejemplo de reserva de vuelos: RAP Business Object

" TIER-1: CDS View para reservas de vuelos (ABAP Cloud)
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Reserva de vuelo'
define root view entity ZI_FlightBooking
  as select from zflight_book
{
  key booking_id     as BookingId,
      flight_id      as FlightId,
      customer_id    as CustomerId,
      booking_date   as BookingDate,
      @Semantics.amount.currencyCode: 'CurrencyCode'
      price          as Price,
      currency_code  as CurrencyCode,
      booking_status as BookingStatus
}

La Behavior Definition asociada define la lógica de negocio:

" TIER-1: Behavior Definition
managed implementation in class zbp_i_flightbooking unique;
strict ( 2 );

define behavior for ZI_FlightBooking alias FlightBooking
persistent table zflight_book
lock master
authorization master ( instance )
{
  create;
  update;
  delete;

  " Acción para confirmar la reserva
  action confirmBooking result [1] $self;

  " Validación de datos de reserva
  validation validateCustomer on save
    { field CustomerId; }

  " Mapeo para campos legacy
  mapping for zflight_book
  {
    BookingId     = booking_id;
    FlightId      = flight_id;
    CustomerId    = customer_id;
    BookingDate   = booking_date;
    Price         = price;
    CurrencyCode  = currency_code;
    BookingStatus = booking_status;
  }
}

Más sobre RAP y Business Objects en el artículo Fundamentos de RAP.

TIER-2: API-Wrapper

TIER-2 es el puente entre ABAP Cloud y Classic ABAP. Aquí se crean clases wrapper que encapsulan la funcionalidad Classic y la proporcionan como Released APIs.

Características de TIER-2

Versión del lenguaje: Standard ABAP (Classic)
Estado de API: Released (C1-Contract)
Tarea: Encapsulación y transformación
Verificación ATC: Debe estar limpio para el release

Ejemplo de reserva de vuelos: API-Wrapper

" TIER-2: Clase Wrapper para acceso a datos de vuelo
" Estado de API: Released (C1-Contract)
CLASS zcl_flight_api DEFINITION
  PUBLIC
  FINAL
  CREATE PUBLIC.

  PUBLIC SECTION.
    TYPES:
      BEGIN OF ty_flight_info,
        flight_id    TYPE zflight_id,
        carrier_id   TYPE s_carr_id,
        connection   TYPE s_conn_id,
        flight_date  TYPE s_date,
        seats_free   TYPE s_seatsocc,
        price        TYPE s_price,
        currency     TYPE s_currcode,
      END OF ty_flight_info,
      tt_flight_info TYPE STANDARD TABLE OF ty_flight_info WITH EMPTY KEY.

    " API Released para TIER-1
    CLASS-METHODS get_available_flights
      IMPORTING
        iv_carrier    TYPE s_carr_id OPTIONAL
        iv_date_from  TYPE s_date OPTIONAL
        iv_date_to    TYPE s_date OPTIONAL
      RETURNING
        VALUE(rt_flights) TYPE tt_flight_info
      RAISING
        cx_flight_not_found.

    CLASS-METHODS check_seat_availability
      IMPORTING
        iv_flight_id  TYPE zflight_id
        iv_seats      TYPE i
      RETURNING
        VALUE(rv_available) TYPE abap_bool.

  PRIVATE SECTION.
    " Helpers internos para acceso TIER-3
    CLASS-METHODS _fetch_from_legacy
      IMPORTING
        iv_carrier   TYPE s_carr_id OPTIONAL
      RETURNING
        VALUE(rt_data) TYPE tt_flight_info.
ENDCLASS.

CLASS zcl_flight_api IMPLEMENTATION.
  METHOD get_available_flights.
    " Llama lógica TIER-3 y transforma datos
    DATA(lt_legacy_data) = _fetch_from_legacy( iv_carrier ).

    " Filtrado y preparación para consumidores Cloud
    LOOP AT lt_legacy_data INTO DATA(ls_flight).
      IF ( iv_date_from IS INITIAL OR ls_flight-flight_date >= iv_date_from )
         AND ( iv_date_to IS INITIAL OR ls_flight-flight_date <= iv_date_to ).
        APPEND ls_flight TO rt_flights.
      ENDIF.
    ENDLOOP.

    IF rt_flights IS INITIAL.
      RAISE EXCEPTION TYPE cx_flight_not_found.
    ENDIF.
  ENDMETHOD.

  METHOD check_seat_availability.
    " Wrapper para verificación de disponibilidad Legacy
    DATA(lo_legacy) = NEW zcl_flight_legacy( ).
    rv_available = lo_legacy->check_seats(
      iv_flight_id = iv_flight_id
      iv_seats     = iv_seats
    ).
  ENDMETHOD.

  METHOD _fetch_from_legacy.
    " Llamada TIER-3 - APIs no-released encapsuladas
    " Acceso directo a SFLIGHT (no released)
    SELECT flight_id, carrid, connid, fldate, seatsocc, price, currency
      FROM sflight
      WHERE carrid = @iv_carrier OR @iv_carrier IS INITIAL
      INTO CORRESPONDING FIELDS OF TABLE @rt_data.
  ENDMETHOD.
ENDCLASS.

TIER-3: Classic ABAP

TIER-3 contiene el código Legacy existente que se moderniza o retira gradualmente. Este código usa APIs no-released y accesos directos a base de datos.

Características de TIER-3

Versión del lenguaje: Standard ABAP (Classic)
APIs: No-released, objetos SAP internos
Acceso: Accesos directos a BD, BAPIs, Function Modules
Objetivo: Migración a TIER-1 o encapsulación por TIER-2

Ejemplo de reserva de vuelos: Código Legacy

" TIER-3: Clase Legacy (solo llamada desde TIER-2)
CLASS zcl_flight_legacy DEFINITION
  PUBLIC
  FINAL
  CREATE PUBLIC.

  PUBLIC SECTION.
    METHODS check_seats
      IMPORTING
        iv_flight_id TYPE zflight_id
        iv_seats     TYPE i
      RETURNING
        VALUE(rv_available) TYPE abap_bool.

    METHODS book_flight_legacy
      IMPORTING
        iv_flight_id  TYPE zflight_id
        iv_customer   TYPE kunnr
        iv_seats      TYPE i
      EXPORTING
        ev_booking_id TYPE zbook_id
      RAISING
        cx_booking_failed.
ENDCLASS.

CLASS zcl_flight_legacy IMPLEMENTATION.
  METHOD check_seats.
    " Acceso directo a tabla no-released
    SELECT SINGLE seatsmax, seatsocc
      FROM sflight
      WHERE flight_id = @iv_flight_id
      INTO @DATA(ls_flight).

    IF sy-subrc = 0.
      rv_available = xsdbool( ls_flight-seatsmax - ls_flight-seatsocc >= iv_seats ).
    ENDIF.
  ENDMETHOD.

  METHOD book_flight_legacy.
    " Llamada BAPI Legacy
    CALL FUNCTION 'BAPI_FLIGHT_BOOKING_CREATE'
      EXPORTING
        flight_id      = iv_flight_id
        customer       = iv_customer
        seats_required = iv_seats
      IMPORTING
        booking_number = ev_booking_id
      EXCEPTIONS
        flight_full    = 1
        OTHERS         = 2.

    IF sy-subrc <> 0.
      RAISE EXCEPTION TYPE cx_booking_failed.
    ENDIF.
  ENDMETHOD.
ENDCLASS.

Para información detallada sobre la diferencia entre Classic y Cloud ABAP ver ABAP Cloud vs Classic ABAP.

El objeto de autorización S_ABPLNGVS

Un elemento central para controlar las versiones del lenguaje es el objeto de autorización S_ABPLNGVS. Controla qué versión del lenguaje ABAP puede usar un desarrollador en qué paquetes.

Campos del objeto de autorización

Campo	Significado	Valores
`ACTIVITY`	Actividad	`01` (Crear), `02` (Modificar), `03` (Visualizar)
`DEVCLASS`	Paquete	Nombre del paquete o `*` para todos
`ABPLNGVS`	Versión del lenguaje	`STANDARD`, `ABAP_FOR_CLOUD_DEVELOPMENT`

Configuración de ejemplo

Rol: Z_ABAP_CLOUD_DEVELOPER
─────────────────────────────────
S_ABPLNGVS:
  ACTIVITY: 01, 02, 03
  DEVCLASS: ZT1_*
  ABPLNGVS: ABAP_FOR_CLOUD_DEVELOPMENT

S_ABPLNGVS:
  ACTIVITY: 01, 02, 03
  DEVCLASS: ZT2_*, ZT3_*
  ABPLNGVS: STANDARD

Esta configuración permite:

Desarrollo ABAP Cloud solo en paquetes con prefijo ZT1_
Classic ABAP en paquetes con prefijo ZT2_ y ZT3_

Consejos prácticos para organización de paquetes

Una estructura de paquetes bien pensada es decisiva para la implementación exitosa del modelo 3-Tier.

Convención de nombres recomendada

Z<PROYECTO>_<TIER>_<ÁREA>

Ejemplos:
─────────────────────────────────────────────
ZFB_T1_BOOKING     → TIER-1, Reserva de vuelos (ABAP Cloud)
ZFB_T1_REPORTING   → TIER-1, Reporting (ABAP Cloud)
ZFB_T2_FLIGHT_API  → TIER-2, Flight API Wrapper
ZFB_T2_CUSTOMER    → TIER-2, Customer API Wrapper
ZFB_T3_LEGACY      → TIER-3, Código Legacy
ZFB_T3_MIGRATION   → TIER-3, Objetos a migrar

Estructura de paquetes para reserva de vuelos

$ZFB (Superpaquete)
├── ZFB_T1 (Paquete principal TIER-1)
│   ├── ZFB_T1_BOOKING
│   │   ├── ZI_FlightBooking (CDS Entity)
│   │   ├── ZBP_I_FlightBooking (Behavior Impl.)
│   │   └── ZUI_FlightBooking_O4 (Service Binding)
│   ├── ZFB_T1_CUSTOMER
│   │   └── ... (Gestión de clientes)
│   └── ZFB_T1_REPORTING
│       └── ... (Informes)
│
├── ZFB_T2 (Paquete principal TIER-2)
│   ├── ZFB_T2_FLIGHT_API
│   │   ├── ZCL_FLIGHT_API (Released Wrapper)
│   │   └── ZIF_FLIGHT_API (Interface)
│   └── ZFB_T2_PRICING
│       └── ZCL_PRICING_API (Cálculo de precios)
│
└── ZFB_T3 (Paquete principal TIER-3)
    ├── ZFB_T3_LEGACY
    │   ├── ZCL_FLIGHT_LEGACY
    │   └── ZFLIGHT_BOOKING_FORM (report antiguo)
    └── ZFB_T3_DEPRECATED
        └── ... (objetos retirados)

Establecer versión del lenguaje por paquete

En las propiedades del paquete en ADT:

ZFB_T1_BOOKING:
  Propiedades → ABAP Language Version → "ABAP for Cloud Development"
  → ¡Compilador aplica reglas ABAP Cloud!

ZFB_T2_FLIGHT_API:
  Propiedades → ABAP Language Version → "Standard ABAP"
  → Permite Classic ABAP, pero API debe ser released

ZFB_T3_LEGACY:
  Propiedades → ABAP Language Version → "Standard ABAP"
  → Libertad total, pero solo uso interno

Estructura de componentes de software

Para proyectos más grandes se recomienda organizar en componentes de software:

" Componentes de software para sistema de reserva de vuelos
"
" Componente: ZFLIGHTBOOKING
" ───────────────────────────────────────────
" Transport Layer: ZDEV
" Delivery Unit: ZFLIGHTBOOKING_DU
"
" Estructura:
" ├── Capa de aplicación (TIER-1)
" │   └── Paquete: ZFB_T1 (ABAP Cloud)
" │
" ├── Capa API (TIER-2)
" │   └── Paquete: ZFB_T2 (Standard + Released)
" │
" └── Capa Legacy (TIER-3)
"     └── Paquete: ZFB_T3 (Standard, no released)

Reglas de dependencia

┌─────────────────────────────────────────────────────────┐
│                    Llamadas permitidas                   │
├─────────────────────────────────────────────────────────┤
│ TIER-1 → TIER-2    ✅ (vía Released APIs)               │
│ TIER-1 → TIER-3    ❌ (prohibido - ¡Error ATC!)         │
│ TIER-2 → TIER-3    ✅ (encapsulación interna)           │
│ TIER-3 → TIER-2    ⚠️ (posible, pero no recomendado)    │
│ TIER-3 → TIER-1    ❌ (Dependencia circular)            │
└─────────────────────────────────────────────────────────┘

Estrategia de migración: De TIER-3 a TIER-1

La estrategia a largo plazo es la migración gradual de TIER-3 a TIER-1:

Fase 1: Identificación
─────────────────────────
• Analizar código TIER-3
• Ejecutar verificaciones ATC
• Documentar dependencias

Fase 2: Wrapper (TIER-2)
─────────────────────────
• API-Wrappers para funciones críticas
• Definir Released APIs
• Escribir tests

Fase 3: Migración (TIER-1)
─────────────────────────
• Nueva implementación RAP
• Reemplazar wrappers TIER-2
• Retirar código Legacy

Fase 4: Limpieza
─────────────────────────
• Eliminar código TIER-3
• Eliminar wrappers TIER-2
• Solo queda TIER-1

Para una guía de migración detallada ver Guía de Migración ABAP Cloud.

Conclusión

El modelo 3-Tier ofrece un enfoque estructurado para la migración a ABAP Cloud:

TIER-1 (ABAP Cloud): Nuevos desarrollos a prueba de futuro
TIER-2 (API-Wrapper): Puente al mundo Legacy
TIER-3 (Classic ABAP): Legado a migrar

A través de una organización clara de paquetes con prefijos T1/T2/T3, el objeto de autorización S_ABPLNGVS y encapsulación API consistente, la modernización gradual se logra sin riesgos.

Importante: SAP ha introducido mientras tanto el Concepto de Niveles Clean Core (A-D) como alternativa simplificada, que reduce la complejidad del modelo 3-Tier. Evalúa ambos enfoques y elige el adecuado para tu proyecto.