ABAP Cloud Implementation Checklist: Everything You Need to Know

Overview: The Five Phases

┌─────────────────────────────────────────────────────────────┐
│ Phase 1: Project Preparation                                  │
│ ────────────────────────────                                  │
│ • System Landscape & Authorizations                          │
│ • Package Structure & Naming Conventions                     │
│ • Set Up Development Tools                                   │
└──────────────────────────────────────────────────────────────┘
                              ▼
┌─────────────────────────────────────────────────────────────┐
│ Phase 2: Data Model                                           │
│ ────────────────────                                          │
│ • Table Design & Data Elements                               │
│ • CDS Views & Associations                                   │
│ • Identify Released APIs                                     │
└──────────────────────────────────────────────────────────────┘
                              ▼
┌─────────────────────────────────────────────────────────────┐
│ Phase 3: RAP Development                                      │
│ ──────────────────────                                        │
│ • Behavior Definition & Implementation                       │
│ • Validations, Determinations, Actions                       │
│ • Authorization & Feature Control                            │
└──────────────────────────────────────────────────────────────┘
                              ▼
┌─────────────────────────────────────────────────────────────┐
│ Phase 4: Service & UI                                         │
│ ────────────────────                                          │
│ • Service Definition & Binding                               │
│ • UI Annotations                                             │
│ • Fiori Elements App                                         │
└──────────────────────────────────────────────────────────────┘
                              ▼
┌─────────────────────────────────────────────────────────────┐
│ Phase 5: Quality Assurance & Go-Live                          │
│ ───────────────────────────────────                           │
│ • Unit Tests & ATC                                           │
│ • Performance & Security                                     │
│ • Transport & Documentation                                  │
└──────────────────────────────────────────────────────────────┘

Phase 1: Project Preparation

System Landscape & Authorizations

Check	Description	Status
☐	ABAP Cloud language version activated in system
☐	Developer users have S_ABPLNGVS for Cloud packages
☐	Transport route defined (DEV → QAS → PRD)
☐	ADT/BAS access set up for all developers
☐	Git repository created (if using abapGit)

Create Package Structure

" Recommended package structure for ABAP Cloud project
"
" $Z_PROJECT (Super package)
" ├── Z_PROJECT_MODEL
" │   ├── Tables (ZTAB_*)
" │   ├── CDS Views (ZI_*, ZC_*)
" │   └── Data Elements
" │
" ├── Z_PROJECT_BDEF
" │   ├── Behavior Definitions
" │   └── Behavior Implementations (ZBP_*)
" │
" ├── Z_PROJECT_SERVICE
" │   ├── Service Definitions
" │   └── Service Bindings
" │
" └── Z_PROJECT_TEST
"     └── Unit Test Classes (ZTC_*)

Define Naming Conventions

Object Type	Prefix	Example
Database Table	`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`
Unit Test Class	`ZTC_`	`ZTC_Booking_Test`

Phase 2: Data Model

Table Design Checklist

Check	Description
☐	Primary key defined (CLIENT + Key fields)
☐	Technical fields present (CREATED_BY, CREATED_AT, …)
☐	Data elements used instead of built-in types
☐	Foreign key relationships documented
☐	Delivery class correctly set (A, C, L, …)

Example: Table Definition

@EndUserText.label : 'Bookings'
@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;

  " Technical fields
  created_by       : abp_creation_user;
  created_at       : abp_creation_tstmpl;
  last_changed_by  : abp_locinst_lastchange_user;
  last_changed_at  : abp_locinst_lastchange_tstmpl;
}

CDS View Checklist

Check	Description
☐	Root View Entity with `define root view entity`
☐	Access Control defined (`@AccessControl.authorizationCheck`)
☐	Semantic annotations (`@Semantics.amount`, `@Semantics.quantity`)
☐	Associations to dependent entities
☐	Key fields correctly marked

Example: CDS View Entity

@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Booking'
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,

      " Admin fields
      @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,

      " Associations
      _Items,
      _Customer
}

Released APIs for SAP Data

SAP Data	Released API (Level A)	Do Not Use (Level D)
Material	`I_Product`	`MARA`, `MAKT`
Customer	`I_Customer`	`KNA1`, `KNB1`
Supplier	`I_Supplier`	`LFA1`, `LFB1`
Sales Document	`I_SalesOrder`	`VBAK`, `VBAP`
User Info	`CL_ABAP_CONTEXT_INFO`	`SY-UNAME`, `USR02`

More on Released APIs in the article Clean Core Level Concept.

Phase 3: RAP Development

Behavior Definition Checklist

Check	Description
☐	Implementation type chosen (`managed` or `unmanaged`)
☐	`strict ( 2 )` for latest RAP version
☐	Persistent table or draft table defined
☐	Lock master/dependent correctly set
☐	Authorization master defined
☐	Validations for required fields
☐	Determinations for automatic values
☐	Actions for business processes

Example: 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;

  " Automatic field values
  field ( readonly ) BookingUuid, CreatedBy, CreatedAt,
                     LastChangedBy, LastChangedAt;
  field ( numbering : managed ) BookingUuid;

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

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

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

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

  " Composition
  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;
  }
}

Behavior Implementation Checklist

Check	Description
☐	Every validation has `failed` and `reported` handling
☐	Determinations fill all automatic fields
☐	Actions check preconditions (`IF booking-Status = ...`)
☐	Feature control for dynamic action availability
☐	Messages use `if_abap_behv_message` interface

Example: Validation

METHOD validateCustomer.
  " Read all relevant bookings
  READ ENTITIES OF ZI_Booking IN LOCAL MODE
    ENTITY Booking
      FIELDS ( CustomerId )
      WITH CORRESPONDING #( keys )
    RESULT DATA(lt_bookings).

  " Check customer data
  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     = |Customer { ls_booking-CustomerId } not found| )
                      %element-CustomerId = if_abap_behv=>mk-on
                    ) TO reported-booking.
    ENDIF.
  ENDLOOP.
ENDMETHOD.

Authorization & 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.

Phase 4: Service & UI

Service Layer Checklist

Check	Description
☐	Service definition created with `define service`
☐	All required entities exposed
☐	Service binding for OData V4 (recommended)
☐	Service binding activated and tested
☐	Fiori Preview works in ADT

Example: 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;
}

UI Annotations Checklist

Check	Description
☐	`@UI.headerInfo` for entity header
☐	`@UI.lineItem` for list view
☐	`@UI.facet` for Object Page structure
☐	`@UI.selectionField` for filter criteria
☐	`@UI.identification` for Object Page fields
☐	`@UI.fieldGroup` for logical grouping

Example: 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: 'Items',
      position: 20,
      targetElement: '_Items' }
  ]

  @UI.headerInfo: {
    typeName: 'Booking',
    typeNamePlural: 'Bookings',
    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;
}

Phase 5: Quality Assurance & Go-Live

Unit Tests Checklist

Check	Description
☐	Test class with `FOR TESTING` and `RISK LEVEL HARMLESS`
☐	Validations tested (positive & negative cases)
☐	Determinations tested
☐	Actions tested with status transitions
☐	At least 70% code coverage achieved

Example: 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.
    " Prepare test data
    DATA(lt_customers) = VALUE zt_customer( ( customer_id = 'CUST001' ) ).
    environment->insert_test_data( lt_customers ).

    " Execute RAP operation
    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.
    " RAP operation with invalid customer
    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: Validation must fail
    cl_abap_unit_assert=>assert_not_initial( failed-booking ).
  ENDMETHOD.
ENDCLASS.

ATC Checks

Check	Description
☐	ATC without priority 1 errors
☐	No Level D findings (direct table access)
☐	No Level C findings (unclassified objects)
☐	Check variant `ABAP_CLOUD_DEVELOPMENT` used

Go-Live Checklist

Check	Description
☐	All unit tests green
☐	ATC without critical findings
☐	Performance tests completed
☐	End-to-end test in QAS successful
☐	Fiori app functionally tested
☐	Transport request documented
☐	Rollback plan available
☐	Technical documentation updated
☐	User training completed

Quick Reference: Do’s & Don’ts

Do’s

Use strict ( 2 ) in Behavior Definitions
Set @AccessControl.authorizationCheck: #CHECK
Use Managed Scenario with Draft when possible
Implement Feature Control for Actions
Write Unit Tests before transport
Use Metadata Extensions for UI annotations

Don’ts

No direct SELECTs on SAP tables
No SY-UNAME, use CL_ABAP_CONTEXT_INFO
No CALL FUNCTION for standard BAPIs
No COMMIT WORK in RAP context
No hardcoded texts, use Message Classes
No global variables in Behavior Classes

Conclusion

This checklist covers the key aspects of an ABAP Cloud implementation. Use it as a guide for your project and adapt it to your specific requirements as needed.

The five phases provide a clear workflow:

Project Preparation: Lay the foundation
Data Model: Solid basis with CDS Views
RAP Development: Implement business logic
Service & UI: Deploy the application
Quality Assurance: Ensure stability

For more detailed information on individual topics, see:

3-Tier Model in ABAP Cloud - Architecture pattern
Clean Core Level Concept - API classification
RAP Basics - RESTful Application Programming
ATC (ABAP Test Cockpit) - Static code analysis