ABAP Cloud
Clean Core
RAP
Cloud Native

ABAP Cloud Environment

SAP BTP's managed ABAP runtime — the bridge between classic ABAP expertise and cloud-native development. Build clean core-compliant extensions using RAP, released APIs, and ABAP Cloud rules.

ABAP Cloud Environment Architecture
Rendering diagram…

Executive Summary

The ABAP Cloud Environment is a fully managed ABAP-as-a-Service on SAP BTP. It allows ABAP developers to build cloud-native extensions using the same language they know, but constrained to the ABAP Cloud programming model: released APIs only (C1/C2 classification), no direct database table access, no classic ABAP syntax (CALL TRANSACTION, RFC calls, etc.).

It is the ideal landing zone for ABAP teams transitioning to the cloud. The runtime is fully managed by SAP — no OS, database, or ABAP system administration required. Development uses ADT (Eclipse) or the BAS ABAP Dev Space. Deployment follows a three-tier flow: local unit test → cloud integration → production, using software component transport via gCTS.

ABAP Cloud Architecture Concepts

Managed ABAP SystemFully managed by SAP — no OS, DB, or kernel administration. You interact only with ABAP objects and BTP services. Provisioned via BTP Cockpit.
ADT / BAS Dev SpaceDevelopment via ABAP Development Tools (Eclipse plugin) or the dedicated ABAP Dev Space in SAP Business Application Studio.
ABAP Cloud RulesEnforced via ABAP Test Cockpit (ATC): only released APIs (C1/C2), no SYST, no CALL TRANSACTION, no classic DB access. Violations block transport.
RAP (Restful Application Programming Model)The only supported model for OData V4 services. Combines CDS Views (data model), Behavior Definitions (CRUD/actions), and Service Bindings (exposure).
CDS ViewsCore Data Services views define the data model, access control (@AccessControl.authorizationCheck), and field annotations for Fiori UI rendering.
Communication ArrangementsCloud-native equivalent of SM59 + RFC destinations. Declare inbound and outbound API connections. Credentials managed in BTP Credential Store.
Identity & AccessManaged via SAP IAS. No SAP GUI users — all access via Fiori Launchpad and OData APIs. Business Roles assigned via IAM app in BTP Cockpit.
PersistenceHANA Cloud shared or dedicated schema. Access only via CDS abstract entities and RAP managed persistence — no direct OPEN SQL on DDIC cluster tables.
gCTS TransportSoftware component transport via Git-enabled Change and Transport System. Promotes code from DEV → TEST → PROD ABAP Cloud systems via Git branches.

RAP Entity + Behavior Definition Example

Clean Core CDS Pattern
This example shows a RAP root entity extending the released I_BusinessPartner API. Note the use of released annotations, virtual elements for calculated fields, and a managed behavior with explicit table mapping. No classic ABAP DB access is involved.
ZDEWA_I_BUSPARTNER.cds + ZDEWA_I_BUSPARTNER.bdef
1" CDS Entity — Business Partner extension
2@AccessControl.authorizationCheck: #CHECK
3@EndUserText.label: 'Enhanced Business Partner'
4define root view entity ZDEWA_I_BUSPARTNER
5  as select from I_BusinessPartner
6{
7  key BusinessPartner,
8      BusinessPartnerFullName,
9      BusinessPartnerIsBlocked,
10      " Virtual element for calculated field
11      @ObjectModel.virtualElement: true
12      @ObjectModel.virtualElementCalculatedBy: 'ABAP:ZDEWA_BP_CALC'
13      cast( '' as dewa_partner_tier ) as PartnerTier,
14      CreatedByUser,
15      CreationDate
16}
17
18" RAP Behavior Definition
19managed implementation in class zbp_dewa_buspartner unique;
20strict;
21
22define behavior for ZDEWA_I_BUSPARTNER alias BusinessPartner
23persistent table zdewa_bp_ext
24lock master
25authorization master ( instance )
26{
27  create;
28  update;
29  delete;
30  field ( readonly ) BusinessPartner;
31
32  action updateTier result [1] $self;
33
34  mapping for zdewa_bp_ext
35  {
36    BusinessPartner = business_partner;
37    PartnerTier = partner_tier;
38  }
39}

Clean Core Compliance: Released API Classification

ClassificationMeaningABAP Cloud Allowed
C1 — Use System-InternallyReleased for use within the same software component onlyNo
C2 — Use in Key User AppsReleased for key user extensibility scenarios (BAdIs, CDS extensions)Yes
C0 — Released for CloudFully released for ABAP Cloud custom code — stable API contract guaranteedYes
No classificationInternal implementation detail — no stability guaranteeNo

Enterprise Example: DEWA Meter-to-Cash Extensions

DEWA ABAP Cloud Configuration
DEWA's ABAP team (100+ ABAP developers) uses ABAP Cloud Environment to build S/4HANA extensions for their meter-to-cash process. RAP services expose OData V4 endpoints consumed by Fiori apps. Communication Arrangements connect back to on-premise S/4HANA for reading master data via released APIs. Clean core compliance is maintained — no custom Z-table modifications to the S/4HANA system. ATC checks run in every CI pipeline stage.

Best Practices

Enable ABAP Test Cockpit from day 1

ATC enforces clean core rules automatically. Enable it in CI/CD pipelines to catch violations before they reach the ABAP Cloud system.

Use Communication Arrangements

Configure external system connections via Communication Arrangements — the cloud-native equivalent of SM59 RFC destinations. No hardcoded credentials.

Model all OData services via RAP

Never use old-style ABAP Gateway (SEGW). RAP + CDS is the only supported pattern for new OData V4 services in ABAP Cloud.

Version RAP entities from the start

Plan API versioning for all RAP-exposed entities. Breaking changes require new entity versions — retrofitting versioning is painful.

Separate ABAP Cloud systems per environment

ABAP Cloud uses software component transport (gCTS), not classic ABAP transport requests. Maintain distinct DEV/TEST/PROD systems.

Common Pitfalls

Using classic ABAP syntax in ABAP Cloud
CALL TRANSACTION, SYST, CALL FUNCTION (RFC), and direct DDIC table access all fail ATC checks. Only released APIs (C1/C2) are permitted.
Replicating Z-table approach from on-premise
ABAP Cloud disallows direct database table manipulation. Custom persistence must use RAP managed scenario with explicit table definitions.
Not configuring IAM / Business Catalogs
Without Business Catalogs assigned to Business Roles, users cannot access Fiori tiles. IAM configuration is required for every exposed service.
Skipping Communication Arrangement setup
Hardcoding destination URLs in ABAP Cloud code is not possible — all outbound connections require Communication Arrangements.
Not enabling ABAP Test Cockpit
Clean core violations accumulate silently without ATC. By the time violations are found, refactoring is expensive.

Security Considerations

ABAP Cloud Environment uses IAS for user authentication — no direct SAP system users. Configure role-based authorization via Business Role assignments in the IAM app (equivalent to PFCG). Use Communication Users (technical users) for system-to-system communication via Communication Arrangements — never use personal named users for API access. Enable audit logging for all inbound and outbound Communications to meet compliance requirements.