ABAP Cloud
RAP
BAdI
Developer

Developer Extensibility

ABAP Cloud development patterns for extending S/4HANA — RAP behaviour extensions, BAdI implementations, CDS view extensions, and the ABAP Cloud language rules that keep every line of code upgrade-safe.

Developer Extension Toolchain & Extension Types

Developers work in ADT (Eclipse) or SAP BAS. Code is version-controlled via abapGit and flows through a CI/CD pipeline with ATC as the mandatory quality gate before any transport is released.

Developer Extensibility Architecture
Rendering diagram…

Executive Summary

Three non-negotiable rules
Developer extensibility in a clean core context means ABAP development restricted to the ABAP Cloud programming model. Three core rules: (1) Only released APIs (C1 contract), (2) ABAP Cloud language version on all new objects, (3) ATC checks pass at BLOCKER + CRITICAL level before any transport. Available patterns: BAdI implementations, RAP behaviour extensions, CDS view extensions, and enhancement implementations at released spots.

ABAP Cloud Language Restrictions

ABAP Cloud is a restricted subset of classic ABAP. The compiler enforces these restrictions at activation time — violations are caught before code can be transported.

FeatureClassic ABAPABAP Cloud
Direct SELECT on SAP tablesAllowedForbidden — use CDS views
CALL FUNCTION (RFCs)AllowedForbidden — use released APIs
CALL TRANSACTION / SUBMITAllowedForbidden
SAP System variables (SY-*)Most availableOnly released SY-vars
Dynamic programming (ASSIGN COMPONENT)AllowedRestricted
CDS View accessAllowedRequired (preferred)
Released BAdI interfacesAllowedAllowed
RAP BDEF / Handler / SaverAllowedPreferred
ABAP Unit TestsOptionalRequired

CDS View Extension Pattern

Extend a released SAP projection view to expose custom fields (defined via F1481 Custom Fields) in OData APIs and Fiori UIs. The extend view entity statement appends fields without modifying the original CDS view.

abap
" Extending a SAP-released CDS projection view with a custom field
" The standard view is I_SalesOrder — we extend the projection C_SalesOrder

@AbapCatalog.sqlViewAppendName: 'ZSO_EXT_DEWA'
extend view entity C_SalesOrderItemTp with
{
  " Expose custom field defined via Custom Fields (F1481)
  SalesOrderItem.YY1_ApprovalStatus_SDH  as ApprovalStatus,
  SalesOrderItem.YY1_ApprovalRequired_SDH as ApprovalRequired,

  " Association to custom business object data
  _DEWAApprovalData.ApproverName as AssignedApprover
}

RAP Behaviour Extension (Custom Validation)

A RAP behaviour extension adds a custom validation to the standard SalesOrder business object. The validation fires on save and enforces a DEWA-specific approval rule for high-value orders. All data access uses EML (Entity Manipulation Language) — not direct SELECT.

abap
" Extend standard SalesOrder RAP BO with a custom validation
" File: ZBP_C_SALESORDERTP.abap

CLASS lhc_salesorder DEFINITION INHERITING FROM cl_abap_behavior_handler.
  PRIVATE SECTION.
    METHODS validate_dewa_approval FOR VALIDATE ON SAVE
      IMPORTING keys FOR SalesOrder~CheckDewaApproval.
ENDCLASS.

CLASS lhc_salesorder IMPLEMENTATION.
  METHOD validate_dewa_approval.
    " Read sales order items to check approval status
    READ ENTITIES OF c_salesordertp IN LOCAL MODE
      ENTITY SalesOrder
        FIELDS ( TotalNetAmount TransactionCurrency )
        WITH CORRESPONDING #( keys )
      RESULT DATA(lt_salesorders).

    LOOP AT lt_salesorders INTO DATA(ls_so).
      " DEWA rule: Sales orders > AED 1,000,000 require approval
      IF ls_so-TotalNetAmount > 1000000
         AND ls_so-TransactionCurrency = 'AED'
         AND ls_so-YY1_ApprovalRequired_SDH = abap_true
         AND ls_so-YY1_ApprovalStatus_SDH <> 'APPROVED'.

        APPEND VALUE #(
          %tky        = ls_so-%tky
          %state_area = 'ZCHK_DEWA_APPROVAL'
        ) TO failed-salesorder.

        APPEND VALUE #(
          %tky        = ls_so-%tky
          %state_area = 'ZCHK_DEWA_APPROVAL'
          %msg        = new_message_with_text(
            severity = if_abap_behv_message=>severity-error
            text     = 'High-value orders require approval before saving'
          )
        ) TO reported-salesorder.
      ENDIF.
    ENDLOOP.
  ENDMETHOD.
ENDCLASS.

Enterprise Example: DEWA ABAP Developer Team Workflow

Team size
12 ABAP developers
Development environment
SAP BAS ABAP Dev Space (cloud-based)
Source control
abapGit → GitHub (private repo)
CI/CD pipeline
Jenkins — ATC check on every push
ATC profile
ZCLEANCORE_STRICT — transport blocked on BLOCKER
Change registration
SAP Cloud ALM auto-registers on transport creation
BLOCKER violations in production since 2024
Zero

Best Practices

ABAP Cloud language version — no exceptions

Never skip the "ABAP Cloud Language Version" setting on new development objects. One missed object creates a compliance gap that grows silently.

ABAP Unit tests for every BAdI

Write ABAP Unit tests for every BAdI implementation — testability is built into the ABAP Cloud model. Untested BAdIs cause production incidents.

CDS views for all data access

Use released CDS views (not SELECT on database tables) for all data access in extensions. Direct table access causes ATC BLOCKER findings.

abapGit for source control

Use abapGit for source control — enables proper PR review workflows for ABAP code, same other language team.

Train developers on ABAP Cloud restrictions

Profile all developers on ABAP Cloud restrictions before project start — the rules differ significantly from classic ABAP and cannot be learned on the job.

Common Pitfalls

Mixed language versions across objects
Setting "ABAP Cloud" on some objects and "Standard ABAP" on others creates inconsistent enforcement — ATC violations slip through on the standard objects.
Test data dependencies in ABAP Unit tests
Tests that depend on production data fail in sandbox and CI environments. Isolate test data using CDS test doubles or ABAP Unit test injection patterns.
CALL FUNCTION inside BAdI
CALL FUNCTION (RFC) is forbidden in ABAP Cloud. Use released class-based APIs instead. This is a common mistake from developers with classic ABAP backgrounds.
BAdI implementation never registered in filter
Forgetting to register a BAdI implementation in the Enhancement Spot filter means the implementation compiles but is never called at runtime — silent failures.
Direct SELECT in ABAP Cloud context
SELECT directly on DDIC tables in an ABAP Cloud context causes ATC BLOCKER findings and prevents transport. Always use released CDS interface views.

Security Considerations

ABAP Cloud reduces attack surface
ABAP Cloud enforces a reduced attack surface by forbidding dangerous APIs (CALL TRANSACTION, dynamic SELECT, etc.). Always use SAP authority checks in BAdI implementations — never assume the caller is authorised just because the BAdI fired. Never build privilege escalation paths. ABAP Unit tests must include negative authorisation test cases to verify that unauthorised users cannot trigger sensitive BAdI logic.