Abap cloud
Skill vigneshbarani24/sap-superpowers/skills/modules/abap-cloud
The SAP consultant's AI operating system - enforced workflows, checklists, and hard gates for Claude Code. Debugging, estimation, and go-live readiness.
npx -y skills add vigneshbarani24/sap-superpowers --skill abap-cloudAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 5 stars5 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Use when writing, reviewing, or troubleshooting ABAP Cloud code, RAP business objects, CDS views, released APIs, or any ABAP development in S/4HANA Public Cloud or BTP ABAP Environment.
SKILL.md
11.9 KB, as published. Nobody here has run it
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
| Topic | Section |
|---|---|
| Released API verification | Iron Laws + Released API Patterns |
| RAP development | RAP Overview |
| CDS views | CDS View Patterns |
| Syntax restrictions | Restricted Syntax Reference |
| Service exposure | Service Binding Patterns |
Iron Laws
- 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. - ALWAYS CHECK RELEASE STATUS BEFORE CODING. Run transaction
ABAPDOCor check the object in ADT "Released Objects" view before referencing any SAP object. Checking after writing is too late — rewrites are expensive. - NEVER USE CLASSIC STATEMENTS EXCLUDED FROM RESTRICTED SYNTAX. Forbidden:
SELECT * INTO TABLEwithout field list,EXEC SQL,CALL FUNCTION(useCALL METHODof a released function group), direct table access to DDIC tables without CDS. Restricted syntax is not a suggestion. - 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. - 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
| Agent Will Try To... | Why It Seems Reasonable | Why It Fails | Counter |
|---|---|---|---|
| Use a classic BAPI directly | "BAPIs are stable SAP interfaces" | Most BAPIs are not released for ABAP Cloud; they will be blocked at activation | Check BAPI release status in SE37 → "Where-Used" → Cloud Release state before any BAPI reference |
Access MARA, BKPF, EKKO directly | "These are standard SAP tables, always available" | Direct table access is forbidden in Cloud; use released CDS views (e.g., I_MaterialDocumentItem) | Replace with the corresponding released CDS VDM view; see SAP API Business Hub for equivalents |
| Skip ATC because "it's just a small change" | "ATC takes time, it's a minor fix" | A one-line change using a non-released type fails upgrade validation. All changes require ATC. | Iron Law 5: ATC is always required. No exceptions for size. |
| Use CALL FUNCTION for utility logic | "Function modules work fine in on-prem" | Classic function module calls are restricted in Cloud; use class-based calls or released APIs | Refactor to ABAP OO; use released utility classes from CL_* namespace |
| Write SQL without CDS views | "OpenSQL still works" | Direct table SELECT bypasses authorizations built into CDS; creates maintenance debt | Define a CDS view with @AccessControl.authorizationCheck: #CHECK and query through it |
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_JournalEntryCDS.
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
| Tool | Purpose |
|---|---|
| ADT (Eclipse) | Primary dev environment for Cloud |
ABAPDOC | Released API documentation |
| ATC (ABAP Test Cockpit) | Code quality + Cloud readiness |
SE80 | Not available in Cloud — use ADT |
SEGW | OData v2 service — prefer RAP for new dev |
/IWFND/MAINT_SERVICE | Activate OData services (classic) |
Key CDS View Patterns (Released VDM)
| Domain | Released CDS View |
|---|---|
| Journal entries | I_JournalEntry, I_JournalEntryItem |
| Material documents | I_MaterialDocumentItem |
| Purchase orders | I_PurchaseOrder, I_PurchaseOrderItem |
| Sales orders | I_SalesOrder, I_SalesOrderItem |
| Business partner | I_BusinessPartner |
| Cost center | I_CostCenter |
| Profit center | I_ProfitCenter |
RAP Development Checklist
- Define root CDS view — annotate
@AbapCatalog.viewEnhancementCategory, adddefine root view entity - Define behavior definition — specify
managedorunmanaged; declare operations (create,update,delete, actions, determinations, validations) - Generate behavior implementation class — implement handler and saver methods
- Add validations — use
FAILED,REPORTEDstructures; report to field level - Define service definition — expose root + compositions
- 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
sideEffectsin 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 Cloudintegration-suite— Exposing and consuming APIscode-review— General code quality reviewtroubleshooting— 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
| Allowed (Cloud) | Forbidden (Cloud) | Why |
|---|---|---|
SELECT FROM ZC_Travel | SELECT FROM /dmo/travel | Must use CDS/released view |
cl_abap_context_info=>get_user_technical_name( ) | SY-UNAME | Context abstraction required |
| Field symbols with structures | EXEC SQL | Native SQL not allowed |
VALUE #(...), inline declarations | COMPUTE, obsolete statements | Modern ABAP only |
| Released Function Modules only | Unreleased FMs | API release state check |
Released classes (cl_abap_*) | Internal classes | Upgrade safety |
ATC Cloud Readiness Workflow
- Download remote ATC config — SAP Note 1935048, fetch check variant ABAP_CLOUD_DEVELOPMENT_DEFAULT
- Run ATC — Select objects, execute with cloud variant (tcode: ATC or ADT)
- Categorize findings — Errors block cloud usage; warnings should be remediated; info is advisory
- Remediate by category:
- Use released API (preferred)
- Move to on-stack classic (if cloud not required)
- Refactor to side-by-side on BTP
- Exemption handling — For known exceptions, add exemption with business justification and reviewer approval
Released API Discovery Methods
- Query I_APIBusinessObject CDS view —
SELECT * FROM I_APIBusinessObject WHERE ReleaseState = 'RELEASED' - ADT Properties panel — Right-click object → Properties → shows API state (released/deprecated/not released)
- SAP API Business Hub — Online search at api.sap.com
- ATC Cloud Readiness — Flags unreleased API usage automatically
- Object annotations —
@ObjectModel.apiannotation 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 (
C0contract); 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