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.
2. 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."

3. 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."

4. 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."

5. 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."

6. 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."

7. 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."

8. 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.

4. Supported CDS object types

This skill recommends and generates these CDS object types:

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

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.

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.
2. Annotations on the interface view — @AccessControl, @AbapCatalog.viewEnhancementCategory, @Metadata.allowExtensions, @Semantics.*, @Search.*.
3. CDS projection view (R_… / C_…) — exposed subset, computed fields, @UI.*, @Consumption.*.
4. Behavior definition — managed, with draft, lock master, field controls, vali