Checklist de implementación ABAP Cloud: Todo lo importante de un vistazo

Kategorie

ABAP Cloud

Veröffentlicht

15 feb 2026

Autor

Esta checklist de implementación ayuda a líderes de proyecto y desarrolladores a no olvidar nada importante en proyectos ABAP Cloud. Desde la preparación inicial del sistema, pasando por el desarrollo RAP hasta el Go-Live, todos los pasos críticos están cubiertos.

Resumen: Las cinco fases

┌─────────────────────────────────────────────────────────────┐
│ Fase 1: Preparación del proyecto                             │
│ ────────────────────────────────                             │
│ • Landscape del sistema y autorizaciones                    │
│ • Estructura de paquetes y convenciones de nombres          │
│ • Configurar herramientas de desarrollo                     │
└──────────────────────────────────────────────────────────────┘
                              ▼
┌─────────────────────────────────────────────────────────────┐
│ Fase 2: Modelo de datos                                      │
│ ────────────────────                                         │
│ • Diseño de tablas y elementos de datos                     │
│ • CDS Views y asociaciones                                  │
│ • Identificar Released APIs                                 │
└──────────────────────────────────────────────────────────────┘
                              ▼
┌─────────────────────────────────────────────────────────────┐
│ Fase 3: Desarrollo RAP                                       │
│ ──────────────────────                                       │
│ • Behavior Definition e Implementation                       │
│ • Validaciones, Determinations, Actions                     │
│ • Authorization y Feature Control                           │
└──────────────────────────────────────────────────────────────┘
                              ▼
┌─────────────────────────────────────────────────────────────┐
│ Fase 4: Service y UI                                         │
│ ────────────────────                                         │
│ • Service Definition y Binding                              │
│ • Anotaciones UI                                            │
│ • Fiori Elements App                                        │
└──────────────────────────────────────────────────────────────┘
                              ▼
┌─────────────────────────────────────────────────────────────┐
│ Fase 5: Aseguramiento de calidad y Go-Live                   │
│ ───────────────────────────────────                          │
│ • Unit Tests y ATC                                          │
│ • Performance y seguridad                                   │
│ • Transporte y documentación                                │
└──────────────────────────────────────────────────────────────┘

Fase 1: Preparación del proyecto

Landscape del sistema y autorizaciones

Check	Descripción	Estado
☐	Versión de lenguaje ABAP Cloud activada en el sistema
☐	Usuarios desarrolladores tienen S_ABPLNGVS para paquetes Cloud
☐	Ruta de transporte definida (DEV → QAS → PRD)
☐	Acceso ADT/BAS configurado para todos los desarrolladores
☐	Repositorio Git creado (si se usa abapGit)

Crear estructura de paquetes

" Estructura de paquetes recomendada para proyecto ABAP Cloud
"
" $Z_PROYECTO (Superpaquete)
" ├── Z_PROYECTO_MODEL
" │   ├── Tablas (ZTAB_*)
" │   ├── CDS Views (ZI_*, ZC_*)
" │   └── Elementos de datos
" │
" ├── Z_PROYECTO_BDEF
" │   ├── Behavior Definitions
" │   └── Behavior Implementations (ZBP_*)
" │
" ├── Z_PROYECTO_SERVICE
" │   ├── Service Definitions
" │   └── Service Bindings
" │
" └── Z_PROYECTO_TEST
"     └── Clases de Unit Test (ZTC_*)

Establecer convenciones de nombres

Tipo de objeto	Prefijo	Ejemplo
Tabla de base de datos	`ZTAB_`	`ZTAB_BOOKING`
Interface View (CDS)	`ZI_`	`ZI_Booking`
Consumption View	`ZC_`	`ZC_Booking`
Behavior Pool	`ZBP_`	`ZBP_I_Booking`
Service Definition	`ZSRV_`	`ZSRV_Booking`
Service Binding	`ZUI_`	`ZUI_Booking_O4`
Clase de Unit Test	`ZTC_`	`ZTC_Booking_Test`

Fase 2: Modelo de datos

Checklist de diseño de tablas

Check	Descripción
☐	Clave primaria definida (CLIENT + campos clave)
☐	Campos técnicos presentes (CREATED_BY, CREATED_AT, …)
☐	Elementos de datos usados en lugar de tipos incorporados
☐	Relaciones de clave foránea documentadas
☐	Delivery Class correctamente configurada (A, C, L, …)

Ejemplo: Definición de tabla

@EndUserText.label : 'Reservas'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
define table ztab_booking {
  key client       : abap.clnt not null;
  key booking_uuid : sysuuid_x16 not null;
  booking_id       : ze_booking_id;
  customer_id      : ze_customer_id;
  flight_date      : abap.dats;
  @Semantics.amount.currencyCode : 'ztab_booking.currency_code'
  price            : abap.curr(15,2);
  currency_code    : abap.cuky;
  status           : ze_booking_status;

  " Campos técnicos
  created_by       : abp_creation_user;
  created_at       : abp_creation_tstmpl;
  last_changed_by  : abp_locinst_lastchange_user;
  last_changed_at  : abp_locinst_lastchange_tstmpl;
}

Checklist de CDS View

Check	Descripción
☐	Root View Entity con `define root view entity`
☐	Access Control definido (`@AccessControl.authorizationCheck`)
☐	Anotaciones semánticas (`@Semantics.amount`, `@Semantics.quantity`)
☐	Asociaciones a entidades dependientes
☐	Campos clave correctamente marcados

Ejemplo: CDS View Entity

@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Reserva'
define root view entity ZI_Booking
  as select from ztab_booking
  composition [0..*] of ZI_BookingItem as _Items
  association [1..1] to ZI_Customer    as _Customer
    on $projection.CustomerId = _Customer.CustomerId
{
  key booking_uuid    as BookingUuid,
      booking_id      as BookingId,
      customer_id     as CustomerId,
      flight_date     as FlightDate,
      @Semantics.amount.currencyCode: 'CurrencyCode'
      price           as Price,
      currency_code   as CurrencyCode,
      status          as Status,

      " Campos admin
      @Semantics.user.createdBy: true
      created_by      as CreatedBy,
      @Semantics.systemDateTime.createdAt: true
      created_at      as CreatedAt,
      @Semantics.user.lastChangedBy: true
      last_changed_by as LastChangedBy,
      @Semantics.systemDateTime.lastChangedAt: true
      last_changed_at as LastChangedAt,

      " Asociaciones
      _Items,
      _Customer
}

Released APIs para datos SAP

Datos SAP	Released API (Nivel A)	No usar (Nivel D)
Material	`I_Product`	`MARA`, `MAKT`
Cliente	`I_Customer`	`KNA1`, `KNB1`
Proveedor	`I_Supplier`	`LFA1`, `LFB1`
Documento de ventas	`I_SalesOrder`	`VBAK`, `VBAP`
Info de usuario	`CL_ABAP_CONTEXT_INFO`	`SY-UNAME`, `USR02`

Más sobre Released APIs en el artículo Concepto de niveles Clean Core.

Fase 3: Desarrollo RAP

Checklist de Behavior Definition

Check	Descripción
☐	Tipo de implementación elegido (`managed` o `unmanaged`)
☐	`strict ( 2 )` para la versión más reciente de RAP
☐	Persistent Table o Draft Table definida
☐	Lock Master/Dependent correctamente configurado
☐	Authorization Master definido
☐	Validaciones para campos obligatorios
☐	Determinations para valores automáticos
☐	Actions para procesos de negocio

Ejemplo: Behavior Definition

managed implementation in class zbp_i_booking unique;
strict ( 2 );

define behavior for ZI_Booking alias Booking
persistent table ztab_booking
draft table ztab_book_d
lock master total etag LastChangedAt
authorization master ( instance )
etag master LastChangedAt
{
  create;
  update;
  delete;

  " Valores automáticos de campos
  field ( readonly ) BookingUuid, CreatedBy, CreatedAt,
                     LastChangedBy, LastChangedAt;
  field ( numbering : managed ) BookingUuid;

  " Soporte de Draft
  draft action Edit;
  draft action Activate optimized;
  draft action Discard;
  draft action Resume;
  draft determine action Prepare;

  " Validaciones
  validation validateCustomer on save
    { field CustomerId; create; }
  validation validateFlightDate on save
    { field FlightDate; create; update; }

  " Determination para Booking-ID
  determination setBookingId on modify
    { field BookingUuid; create; }

  " Actions
  action ( features : instance ) confirm result [1] $self;
  action ( features : instance ) cancel result [1] $self;

  " Composición
  association _Items { create; }

  mapping for ztab_booking
  {
    BookingUuid   = booking_uuid;
    BookingId     = booking_id;
    CustomerId    = customer_id;
    FlightDate    = flight_date;
    Price         = price;
    CurrencyCode  = currency_code;
    Status        = status;
    CreatedBy     = created_by;
    CreatedAt     = created_at;
    LastChangedBy = last_changed_by;
    LastChangedAt = last_changed_at;
  }
}

Checklist de Behavior Implementation

Check	Descripción
☐	Cada Validation tiene manejo de `failed` y `reported`
☐	Determinations rellenan todos los campos automáticos
☐	Actions verifican precondiciones (`IF booking-Status = ...`)
☐	Feature Control para disponibilidad dinámica de Actions
☐	Messages usan el interface `if_abap_behv_message`

Ejemplo: Validation

METHOD validateCustomer.
  " Leer todas las reservas relevantes
  READ ENTITIES OF ZI_Booking IN LOCAL MODE
    ENTITY Booking
      FIELDS ( CustomerId )
      WITH CORRESPONDING #( keys )
    RESULT DATA(lt_bookings).

  " Verificar datos de cliente
  SELECT CustomerId FROM ZI_Customer
    FOR ALL ENTRIES IN @lt_bookings
    WHERE CustomerId = @lt_bookings-CustomerId
    INTO TABLE @DATA(lt_valid_customers).

  LOOP AT lt_bookings INTO DATA(ls_booking).
    IF NOT line_exists( lt_valid_customers[ CustomerId = ls_booking-CustomerId ] ).
      APPEND VALUE #( %tky = ls_booking-%tky ) TO failed-booking.
      APPEND VALUE #( %tky = ls_booking-%tky
                      %msg = new_message_with_text(
                               severity = if_abap_behv_message=>severity-error
                               text     = |Cliente { ls_booking-CustomerId } no encontrado| )
                      %element-CustomerId = if_abap_behv=>mk-on
                    ) TO reported-booking.
    ENDIF.
  ENDLOOP.
ENDMETHOD.

Authorization y Feature Control

METHOD get_instance_authorizations.
  READ ENTITIES OF ZI_Booking IN LOCAL MODE
    ENTITY Booking
      FIELDS ( Status )
      WITH CORRESPONDING #( keys )
    RESULT DATA(lt_bookings).

  LOOP AT lt_bookings INTO DATA(ls_booking).
    APPEND VALUE #(
      %tky = ls_booking-%tky
      %update = COND #( WHEN ls_booking-Status = 'CONFIRMED'
                        THEN if_abap_behv=>auth-unauthorized
                        ELSE if_abap_behv=>auth-allowed )
      %delete = COND #( WHEN ls_booking-Status = 'CONFIRMED'
                        THEN if_abap_behv=>auth-unauthorized
                        ELSE if_abap_behv=>auth-allowed )
      %action-confirm = COND #( WHEN ls_booking-Status = 'NEW'
                                THEN if_abap_behv=>auth-allowed
                                ELSE if_abap_behv=>auth-unauthorized )
      %action-cancel = COND #( WHEN ls_booking-Status <> 'CANCELLED'
                               THEN if_abap_behv=>auth-allowed
                               ELSE if_abap_behv=>auth-unauthorized )
    ) TO result.
  ENDLOOP.
ENDMETHOD.

Fase 4: Service y UI

Checklist de Service Layer

Check	Descripción
☐	Service Definition creada con `define service`
☐	Todas las entidades necesarias expuestas
☐	Service Binding para OData V4 (recomendado)
☐	Service Binding activado y probado
☐	Fiori Preview funciona en ADT

Ejemplo: Service Definition

@EndUserText.label: 'Booking Service'
define service ZSRV_Booking {
  expose ZC_Booking as Booking;
  expose ZC_BookingItem as BookingItem;
  expose ZI_Customer as Customer;
}

Checklist de anotaciones UI

Check	Descripción
☐	`@UI.headerInfo` para encabezado de entidad
☐	`@UI.lineItem` para vista de lista
☐	`@UI.facet` para estructura de Object Page
☐	`@UI.selectionField` para criterios de filtro
☐	`@UI.identification` para campos de Object Page
☐	`@UI.fieldGroup` para agrupación lógica

Ejemplo: Metadata Extension

@Metadata.layer: #CUSTOMER
annotate view ZC_Booking with
{
  @UI.facet: [
    { id: 'GeneralInfo',
      purpose: #STANDARD,
      type: #IDENTIFICATION_REFERENCE,
      label: 'General',
      position: 10 },
    { id: 'Items',
      purpose: #STANDARD,
      type: #LINEITEM_REFERENCE,
      label: 'Posiciones',
      position: 20,
      targetElement: '_Items' }
  ]

  @UI.headerInfo: {
    typeName: 'Reserva',
    typeNamePlural: 'Reservas',
    title: { value: 'BookingId' },
    description: { value: 'CustomerId' }
  }

  @UI: { lineItem: [{ position: 10 }],
         selectionField: [{ position: 10 }],
         identification: [{ position: 10 }] }
  BookingId;

  @UI: { lineItem: [{ position: 20 }],
         selectionField: [{ position: 20 }],
         identification: [{ position: 20 }] }
  CustomerId;

  @UI: { lineItem: [{ position: 30 }],
         identification: [{ position: 30 }] }
  FlightDate;

  @UI: { lineItem: [{ position: 40, criticality: 'StatusCriticality' }],
         identification: [{ position: 40, criticality: 'StatusCriticality' }] }
  Status;
}

Fase 5: Aseguramiento de calidad y Go-Live

Checklist de Unit Tests

Check	Descripción
☐	Clase de test con `FOR TESTING` y `RISK LEVEL HARMLESS`
☐	Validaciones probadas (casos positivos y negativos)
☐	Determinations probadas
☐	Actions probadas con transiciones de estado
☐	Al menos 70% de Code Coverage alcanzado

Ejemplo: Unit Test

CLASS ztc_booking_test DEFINITION
  FOR TESTING
  RISK LEVEL HARMLESS
  DURATION SHORT.

  PRIVATE SECTION.
    CLASS-DATA:
      environment TYPE REF TO if_cds_test_environment.

    CLASS-METHODS:
      class_setup,
      class_teardown.

    METHODS:
      setup,
      test_create_booking FOR TESTING,
      test_validate_customer_invalid FOR TESTING.
ENDCLASS.

CLASS ztc_booking_test IMPLEMENTATION.
  METHOD class_setup.
    environment = cl_cds_test_environment=>create_for_multiple_cds(
      VALUE #( ( i_for_entity = 'ZI_BOOKING' )
               ( i_for_entity = 'ZI_CUSTOMER' ) ) ).
  ENDMETHOD.

  METHOD class_teardown.
    environment->destroy( ).
  ENDMETHOD.

  METHOD setup.
    environment->clear_doubles( ).
  ENDMETHOD.

  METHOD test_create_booking.
    " Preparar datos de prueba
    DATA(lt_customers) = VALUE zt_customer( ( customer_id = 'CUST001' ) ).
    environment->insert_test_data( lt_customers ).

    " Ejecutar operación RAP
    MODIFY ENTITIES OF ZI_Booking
      ENTITY Booking
        CREATE FIELDS ( CustomerId FlightDate Price CurrencyCode )
        WITH VALUE #( ( %cid = 'CID1'
                        CustomerId = 'CUST001'
                        FlightDate = sy-datum + 30
                        Price = '500.00'
                        CurrencyCode = 'EUR' ) )
      MAPPED DATA(mapped)
      FAILED DATA(failed)
      REPORTED DATA(reported).

    " Assertions
    cl_abap_unit_assert=>assert_initial( failed ).
    cl_abap_unit_assert=>assert_not_initial( mapped-booking ).
  ENDMETHOD.

  METHOD test_validate_customer_invalid.
    " Operación RAP con cliente inválido
    MODIFY ENTITIES OF ZI_Booking
      ENTITY Booking
        CREATE FIELDS ( CustomerId FlightDate )
        WITH VALUE #( ( %cid = 'CID1'
                        CustomerId = 'INVALID'
                        FlightDate = sy-datum + 30 ) )
      MAPPED DATA(mapped)
      FAILED DATA(failed)
      REPORTED DATA(reported).

    " Assertion: La validación debe fallar
    cl_abap_unit_assert=>assert_not_initial( failed-booking ).
  ENDMETHOD.
ENDCLASS.

Verificación ATC

Check	Descripción
☐	ATC sin errores de prioridad 1
☐	Sin findings de Nivel D (accesos directos a tablas)
☐	Sin findings de Nivel C (objetos no clasificados)
☐	Check-Variant `ABAP_CLOUD_DEVELOPMENT` utilizada

Checklist de Go-Live

Check	Descripción
☐	Todos los Unit Tests en verde
☐	ATC sin findings críticos
☐	Pruebas de rendimiento realizadas
☐	Test End-to-End en QAS exitoso
☐	App Fiori probada funcionalmente
☐	Transport Request documentada
☐	Plan de rollback disponible
☐	Documentación técnica actualizada
☐	Capacitación de usuarios realizada

Referencia rápida: Do’s y Don’ts

Do’s

✅ Usa strict ( 2 ) en Behavior Definitions
✅ Configura @AccessControl.authorizationCheck: #CHECK
✅ Usa Managed Scenario con Draft cuando sea posible
✅ Implementa Feature Control para Actions
✅ Escribe Unit Tests antes del transporte
✅ Usa Metadata Extensions para anotaciones UI

Don’ts

❌ Sin SELECTs directos a tablas SAP
❌ Sin SY-UNAME, usa CL_ABAP_CONTEXT_INFO
❌ Sin CALL FUNCTION para BAPIs estándar
❌ Sin COMMIT WORK en contexto RAP
❌ Sin textos hardcodeados, usa Message Classes
❌ Sin variables globales en Behavior Classes

Conclusión

Esta checklist cubre los aspectos más importantes de una implementación ABAP Cloud. Úsala como guía para tu proyecto y adáptala según sea necesario a tus requisitos específicos.

Las cinco fases ofrecen un flujo claro:

Preparación del proyecto: Establecer las bases
Modelo de datos: Base sólida con CDS Views
Desarrollo RAP: Implementar lógica de negocio
Service y UI: Proporcionar la aplicación
Aseguramiento de calidad: Asegurar estabilidad

Para información más profunda sobre temas individuales consulta:

Modelo de 3 capas en ABAP Cloud - Patrones de arquitectura
Concepto de niveles Clean Core - Clasificación de APIs
Fundamentos de RAP - RESTful Application Programming
ATC (ABAP Test Cockpit) - Análisis estático de código