Abap Cloud

ABAP Cloud

Enforces clean-core compliance: every piece of ABAP Cloud code MUST use only released APIs, restricted syntax, and RAP patterns — no exceptions.

Content Routing

Iron Laws

1. NEVER USE UNRELEASED APIS. If the API does not appear in the SAP API Business Hub or is not annotated @ReleaseState: RELEASED, it CANNOT be used. Using unreleased APIs breaks upgrades — your code will fail silently in the next release.
2. ALWAYS CHECK RELEASE STATUS BEFORE CODING. Run transaction ABAPDOC or check the object in ADT "Released Objects" view before referencing any SAP object. Checking after writing is too late — rewrites are expensive.
3. NEVER USE CLASSIC STATEMENTS EXCLUDED FROM RESTRICTED SYNTAX. Forbidden: SELECT * INTO TABLE without field list, EXEC SQL, CALL FUNCTION (use CALL METHOD of a released function group), direct table access to DDIC tables without CDS. Restricted syntax is not a suggestion.
4. NEVER BYPASS THE RAP FRAMEWORK FOR TRANSACTIONAL OPERATIONS. Do not write UPDATE/INSERT/DELETE on application tables directly. All transactional operations go through the RAP EML (MODIFY ENTITY). Direct DML breaks the framework's consistency model.
5. ALWAYS TEST IN ABAP TEST COCKPIT (ATC) BEFORE TRANSPORT. ATC with the Cloud Readiness check variant is the gate. A clean ATC run is required evidence — not optional.

Rationalization Table

Red Flags

Watch for these in your own reasoning — each signals an Iron Law violation:

• "This table has always been available..." → You're about to access a non-released DB object. Check VDM equivalents first.
• "I'll just use the BAPI for now and refactor later..." → Unreleased BAPIs cannot be activated. There is no "later."
• "ATC can wait until the transport is ready..." → ATC must pass before transport creation, not after.
• "This ABAP statement works in on-prem too..." → On-prem compatibility is irrelevant. Cloud syntax rules apply.
• "Let me query BSEG directly..." → BSEG does not exist in ACDOCA-based S/4HANA Cloud. Use I_JournalEntry CDS.

Key Concepts

• Restricted Syntax: Subset of ABAP allowed in Cloud; enforced by compiler. Check via ADT syntax check or ATC Cloud Readiness variant.
• Released APIs: SAP objects annotated for external use. Two categories: C0 (use in key user apps), C1 (use in developer extensibility).
• VDM (Virtual Data Model): Released CDS views prefixed I_ (interface), C_ (consumption), P_ (private).
• RAP (RESTful Application Programming Model): Framework for transactional and query apps. Components: CDS view, behavior definition (.bdef), behavior implementation (class), service definition, service binding.
• EML (Entity Manipulation Language): ABAP syntax for RAP operations: READ ENTITY, MODIFY ENTITY, COMMIT WORK AND WAIT.

Key Transaction Codes / ADT Tools

Key CDS View Patterns (Released VDM)

RAP Development Checklist

1. Define root CDS view — annotate @AbapCatalog.viewEnhancementCategory, add define root view entity
2. Define behavior definition — specify managed or unmanaged; declare operations (create, update, delete, actions, determinations, validations)
3. Generate behavior implementation class — implement handler and saver methods
4. Add validations — use FAILED, REPORTED structures; report to field level
5. Define service definition — expose root + compositions
6. Create service binding — OData V4 UI or Web API binding; publish and test in Fiori Preview

Integration Points

• Event Mesh: Raise RAP business events via RAISE ENTITY EVENT; consume via Event Consumption Model
• Remote API calls: Use cl_http_client (released) or Destination Service; never hard-code URLs
• Side Effects: Declare sideEffects in behavior definition to trigger UI refresh

Verification

This skill is complete ONLY when ALL of the following are true:

• All referenced SAP objects verified as released (C0 or C1) in ADT or API Business Hub
• ATC run with Cloud Readiness check variant — zero findings of severity Error or Warning
• No forbidden SQL patterns (SELECT *, EXEC SQL, direct DDIC table access without CDS)
• RAP EML used for all transactional operations — no direct DML on application tables
• Service binding published and tested via Fiori Preview or Postman (for Web API)

Evidence required: ATC results screenshot / export showing clean run; service binding URL confirmed active.

Next Skill

After completing ABAP Cloud development, invoke: verification-before-completion For deployment to BTP, invoke: btp For API exposure and management, invoke: integration-suite

Related Skills

• btp — BTP environment setup, CAP, HANA Cloud
• integration-suite — Exposing and consuming APIs
• code-review — General code quality review
• troubleshooting — Debugging runtime errors

Complete RAP Example

Full travel entity showing CDS → Behavior → Service → Binding:

* 1. CDS Interface View
define root view entity ZI_Travel
  as select from /dmo/travel as travel
{
  key travel_id    as TravelID,
  agency_id        as AgencyID,
  customer_id      as CustomerID,
  begin_date       as BeginDate,
  end_date         as EndDate,
  booking_fee      as BookingFee,
  total_price      as TotalPrice,
  currency_code    as CurrencyCode,
  status           as Status
}

* 2. CDS Projection View
@AccessControl.authorizationCheck: #CHECK
define root view entity ZC_Travel
  provider contract transactional_query
  as projection on ZI_Travel
{
  key TravelID,
  AgencyID,
  CustomerID,
  BeginDate,
  EndDate,
  BookingFee,
  TotalPrice,
  CurrencyCode,
  Status
}

* 3. Behavior Definition
managed implementation in class zbp_i_travel unique;
strict ( 2 );

define behavior for ZI_Travel alias Travel
persistent table /dmo/travel
lock master
etag master LastChangedAt
{
  create;
  update;
  delete;
  field ( readonly ) TravelID, Status;
  validation validateDates on save { create; field BeginDate, EndDate; }
  action acceptTravel result [1] $self;
  determination calculateTotalPrice on save { create; update; }
}

* 4. Service Definition
define service ZUI_TravelService {
  expose ZC_Travel as Travel;
}

* 5. Service Binding: OData V4 UI

EML (Entity Manipulation Language) Patterns

* Read
READ ENTITIES OF ZI_Travel
  ENTITY Travel FIELDS ( TravelID BeginDate )
  WITH VALUE #( ( TravelID = '001' ) )
  RESULT DATA(lt_travel)
  FAILED DATA(ls_failed)
  REPORTED DATA(ls_reported).

* Modify
MODIFY ENTITIES OF ZI_Travel
  ENTITY Travel
  UPDATE FIELDS ( Status )
  WITH VALUE #( ( TravelID = '001' Status = 'A' ) )
  FAILED ls_failed
  REPORTED ls_reported.

* Execute Action
MODIFY ENTITIES OF ZI_Travel
  ENTITY Travel EXECUTE acceptTravel
  FROM VALUE #( ( TravelID = '001' ) )
  RESULT DATA(lt_result).

Restricted Syntax Reference

ATC Cloud Readiness Workflow

1. Download remote ATC config — SAP Note 1935048, fetch check variant ABAP_CLOUD_DEVELOPMENT_DEFAULT
2. Run ATC — Select objects, execute with cloud variant (tcode: ATC or ADT)
3. Categorize findings — Errors block cloud usage; warnings should be remediated; info is advisory
4. Remediate by category:
   • Use released API (preferred)
   • Move to on-stack classic (if cloud not required)
   • Refactor to side-by-side on BTP
5. Exemption handling — For known exceptions, add exemption with business justification and reviewer approval

Released API Discovery Methods

1. Query I_APIBusinessObject CDS view — SELECT * FROM I_APIBusinessObject WHERE ReleaseState = 'RELEASED'
2. ADT Properties panel — Right-click object → Properties → shows API state (released/deprecated/not released)
3. SAP API Business Hub — Online search at api.sap.com
4. ATC Cloud Readiness — Flags unreleased API usage automatically
5. Object annotations — @ObjectModel.api annotation visible in CDS source

Common Pitfalls

• Using USE_IN_CLOUD_DEVELOPMENT APIs in on-stack code — Wrong context; check release state matches use case
• Assuming all I_ views are released — Many interface views remain internal (C0 contract); verify state
• Mixing ABAP Cloud with RAP draft patterns — Draft requires additional draft table; incompatible with simple scenarios
• Missing strict(2) in behavior definitions — Older strict(1) allows more permissive syntax but misses modern checks
• Missing EML error handling — Always check FAILED and REPORTED structures for failures