sap-rap-dev

SAP RAP Development Skill

Status: draft. All reference files are populated with substantive

guidance and examples. Mark this skill released only after a human

RAP expert reviews the references against the current SAP Help Portal

for the target ABAP release.

1. Scope guardrails (read first, every time)

Before doing anything, classify the request:

1. **Is this RAP on ABAP Cloud / S/4HANA Cloud / BTP ABAP Environment / S/4

on-premise?** → proceed.

1. Is this SAP CAP (Node.js or Java)? → refuse:

> "This skill is SAP RAP only. For CAP, use the sap-cap-nodejs-dev > skill (Node.js) or the equivalent CAP-Java skill."

1. **Is this a classic ABAP framework (BOPF, FPM, Web Dynpro, FPM/UIBB,

SAP GUI)?** → refuse: > "RAP replaces those frameworks. This skill does not maintain BOPF / > FPM / Web Dynpro / SAP GUI code."

1. Is this generic ABAP unrelated to RAP (DDIC reports, BAPIs, customer

user-exits, function-module-only work)? → refuse: > "This skill is RAP-scoped. For generic ABAP, please use a general > ABAP skill."

1. Is this frontend code (UI5 controllers, freestyle UI5, React, Vue,

plain HTML/CSS/JS)? → refuse: > "CDS-side @UI. / @Search. / @Consumption.* annotations and > metadata extensions are in scope. Writing the UI application itself > is not — please use a Fiori / UI5 skill."

1. Is this a non-SAP backend (Spring, Express, NestJS, FastAPI, etc.)?

→ refuse: > "This skill is SAP RAP only. Non-SAP backends are out of scope."

1. **Is this BTP cockpit / Cloud Foundry / Kyma / Kubernetes / identity-

provider configuration?** → refuse: > "This skill covers RAP code only. Cloud-platform operations live in > a different skill family."

1. **Does the request use an unreleased / NOT_TO_BE_RELEASED /

Use_System_Internally / deprecated API?** → refuse and propose the released alternative. If none exists, say so and stop.

When in doubt, ask the user to confirm the request fits the RAP scope before writing code. Never silently extend the scope based on what the user pasted — if the pasted content seems to be a non-RAP framework, the correct action is to flag it and refuse.

2. OData version default — V4 only

• Default: every CDS projection, service definition, service binding,

and example produced by this skill is OData V4 (OData V4 — UI for Fiori, OData V4 — Web API for APIs).

• OData V2 is produced only when the user has explicitly asked for

V2 in the current request (e.g. "create a V2 binding", "we need V2 for legacy Fiori app X"). In that case, generate the V2 binding plus a short one-line note explaining that V2 is opt-in and V4 is the strategic default.

• Never default to V2. Never mix V2 and V4 in the same output

silently. Never assume V2 from indirect hints — require an explicit request.

3. Released-API rule

• Only use CDS views, behavior definitions, service definitions, and ABAP

classes whose CDS annotations or release-state metadata document them as Released for use in customer extensions / cloud development.

• Never recommend NOT_RELEASED, NOT_TO_BE_RELEASED, or

Use_System_Internally artifacts to consumers.

• Never use ABAP statements flagged as obsolete by the ABAP Cloud

development model (e.g. classic dynpros, EXEC SQL, CALL FUNCTION ... STARTING NEW TASK without RAP equivalents, INSERT REPORT, dynamic generation of ABAP source).

• If the released surface can't do what the user wants, say so — do not

fall back to internal classes.

Full guidance: [references/released-apis.md](references/released-apis.md).

4. Supported CDS object types

This skill recommends and generates these CDS object types:

| Object | Used for | |---------------------------------------------------|------------------------------------------------------------------------------------| | define table (DDIC database table) | RAP-owned persistent table for a managed BO. See [cds-table-entity.md](references/cds-table-entity.md). | | define table entity (CDS table entity) | Modern CDS-native persistence. Same role as DDIC table; preferred long-term. | | define root view entity (interface, root) | The BO's root interface view (I_…). See [cds-view-entity.md](references/cds-view-entity.md). | | define view entity (interface, child or reuse) | Composition children or stand-alone reuse views. | | define root view entity … as projection on … | The BO's exposed shape for a service (R_… / C_…). See [cds-projection-view.md](references/cds-projection-view.md). | | define view entity … with parameters | Parameterized views — usually reuse / value-help / analytics. Not for transactional BOs. | | define table function | Calculations the DB cannot push down — exceptional use. | | define hierarchy | Hierarchical reuse data. | | annotate entity (metadata extension) | Annotation-only extension of an existing view. See [metadata-extension.md](references/metadata-extension.md). | | extend view entity / append view | Structural extension — adds fields to a delivered view (subject to the enhancement category). | | define behavior for | Behavior definition (managed / unmanaged / projection / extension). See [behavior-definition.md](references/behavior-definition.md). | | define service | CDS service definition listing exposed entities. See [service-definition.md](references/service-definition.md). |

Not used by this skill (out of date / classic / not for new RAP code):

| Object | Why excluded | |---------------------------------------------|------------------------------------------------------------------------------------| | define view (classic DDL view) | Legacy. Always prefer define view entity. | | define structure (classic structures) | DDIC-classic; RAP uses CDS structures and CDS types instead. | | define type | Allowed but rarely needed for RAP BOs — only when the BDEF needs a custom type. | | annotation definition | Used by SAP / advanced framework code; not generated by this skill. |

5. Managed vs. unmanaged decision

Greenfield BO, RAP can own the table?            → MANAGED              (default)
Greenfield BO, need outbox / event emission?     → MANAGED + saver hook
Wrap a BAPI / legacy FM, want drafts?            → MANAGED WITH UNMANAGED SAVE
Wrap an external system (no ABAP persistence)?   → UNMANAGED
Need full control of COMMIT timing?              → UNMANAGED
Behavior on top of an existing BO?               → PROJECTION (delegating via `use`)

When in doubt, choose managed. Detailed comparison and code samples: [references/managed-vs-unmanaged.md](references/managed-vs-unmanaged.md).

6. Domain-first decision order

When adding a new behavior, drop to the next step only if the previous one cannot express it:

1. CDS interface view (I_…) — keys, types, associations, compositions,

aspects.

1. Annotations on the interface view — @AccessControl,

@AbapCatalog.viewEnhancementCategory, @Metadata.allowExtensions, @Semantics., @Search..

1. CDS projection view (R_… / C_…) — exposed subset, computed

fields, @UI., @Consumption..

1. Behavior definition — managed, with draft, lock master,

field controls, vali