ABAP & Clean Core Glossary
The vocabulary of the move from classic ABAP to ABAP Cloud, RAP and a clean core — explained the way the Dojo teaches: what it is, why it matters for upgrade-stability, and the one mistake to avoid. Tap any term for the full entry; many link straight into the lesson that teaches it.
52 terms
Clean Core
The principles, tiers and discipline behind upgrade-safe SAP.
- Clean CoreSAP's principle that the digital core (S/4HANA) is kept standard and upgrade-stable: customisation happens through released extension points and side-by-side apps, never by modifying SAP objects. It spans not just code but data, processes, integration and operations.Read
- Modification vs. EnhancementA modification changes SAP's own delivered objects (a repair); an enhancement adds your logic at SAP-provided extension points (BAdIs, enhancement spots) without touching the original. Clean Core forbids the former and governs the latter.Read
- Tier 1 / 2 / 3 ExtensibilitySAP's three-tier model for how cleanly an extension is coupled to the core. Tier 1 = on-stack developer extensibility using only released APIs (ABAP Cloud). Tier 2 = on-stack 'cloud API enablement' / classic extensibility kept within guardrails. Tier 3 = side-by-side on SAP BTP, fully decoupled.Read
- Upgrade StabilityThe property that your custom code and configuration keep working unchanged across SAP releases and updates. It's the outcome Clean Core is designed to produce.Read
ABAP Cloud
The restricted, released-API-only language scope and runtime.
- ABAP CloudSAP's restricted ABAP programming model and language scope for building upgrade-stable, cloud-ready apps. You may use only released APIs and the ABAP-for-Cloud language version; the compiler enforces it. It runs on the ABAP Environment (BTP), in S/4HANA Cloud, and on-stack in S/4HANA via developer extensibility.Read
- ABAP Environment (Steampunk)The standalone ABAP runtime on SAP BTP — historically nicknamed 'Steampunk'. A fully managed ABAP Cloud platform with no S/4HANA underneath; you build side-by-side ABAP apps that connect to S/4HANA over released APIs and events.Read
- ABAP Language VersionA per-object setting (Standard / ABAP for Key Users / ABAP for Cloud Development) that fixes which language constructs and APIs an object may use. 'ABAP for Cloud Development' is the strictest and is what ABAP Cloud requires.Read
- Embedded Steampunk (Developer Extensibility)Developer extensibility inside S/4HANA itself: writing ABAP Cloud code on-stack, in the same system as the standard core, using only released APIs. 'Embedded Steampunk' is the informal name for this on-stack ABAP Cloud.Read
- Release Contract (C0 / C1 / C2)The stability promise attached to a released object. C1 = use by customer/partner cloud development (the one developers care about). C0 = SAP-internal. C2 = extend (e.g. extension includes). The contract defines what SAP may and may not change.Read
- Released APIC1An SAP object (CDS view, class, interface, function, table type…) that SAP has formally released for use in cloud development with a stability contract — the C1 release contract. In ADT its API state shows 'Released'. Only released APIs are callable from ABAP Cloud code.Read
- Released vs. Unreleased ObjectsReleased objects carry a stability contract and are callable from ABAP Cloud; unreleased objects (most classic tables, BAPIs, function modules) carry no contract and are blocked by the Cloud Development language version.Read
RAP
The RESTful Application Programming model and its building blocks.
- Action (RAP)A non-standard operation on a RAP business object beyond create/update/delete — e.g. 'Approve', 'Release', 'Copy'. Declared in the BDEF and exposed as an OData function/action; it can change the BO and return a result.Read
- Behavior Definition (BDEF)BDEFThe DDL artefact (object type BDEF) that declares a RAP business object's behavior: which operations it supports (create/update/delete), its determinations, validations, actions, draft enablement, locking and field controls. The matching behavior implementation (ABAP class) holds the logic.Read
- Business Object (RAP BO)In RAP, the self-contained transactional entity: a root CDS entity (optionally with child entities via compositions) plus its behavior. It owns its data, behavior, draft state and authorisation as one unit.Read
- DeterminationA RAP behavior that automatically derives or fills data when a trigger condition occurs (e.g. on create, or when a field changes). Declared in the BDEF, implemented in the behavior pool. Think 'derived value', not 'validation'.Read
- Draft (RAP Draft Handling)RAP's built-in mechanism for saving incomplete, work-in-progress data so a user can leave and resume an edit, with the active (saved) and draft versions kept side by side. Enabled declaratively in the BDEF; RAP generates the draft tables and lifecycle.Read
- EML (Entity Manipulation Language)EMLThe ABAP language extension for reading and changing RAP business objects from code: `READ ENTITIES`, `MODIFY ENTITIES`, `COMMIT ENTITIES`. It's how you invoke a BO's behavior programmatically instead of touching its tables.Read
- ETag / Optimistic ConcurrencyA version token RAP attaches to an entity so a save is rejected if someone else changed the record since you read it. Declared in the BDEF (`etag master`), it implements optimistic locking over OData.Read
- Locking (RAP managed locks)RAP's declarative locking: you mark a `lock master` (and dependent locks down the composition) in the BDEF, and the framework acquires the right locks during a change — replacing hand-written ENQUEUE/DEQUEUE for the BO.Read
- Managed vs. Unmanaged BOTwo RAP implementation types. A managed BO lets RAP handle persistence (create/update/delete to the DB) for you — ideal for greenfield. An unmanaged BO delegates persistence to your existing code (legacy tables, function modules) — for wrapping a brownfield application.Read
- RAP (RESTful Application Programming Model)RAPSAP's standard framework for building transactional, OData-based services and Fiori apps in ABAP. You declaratively model a business object (CDS data model + behavior definition + behavior implementation) and RAP generates the OData service, draft handling, locking and ETag handling.Read
- Side Effect (RAP)A BDEF declaration that tells the UI which fields/entities to re-fetch after a change, so the Fiori app refreshes derived data immediately. Pure UI-freshness metadata — it doesn't change data itself.Read
- Validation (RAP)A RAP behavior that checks data and raises messages without changing it. Declared in the BDEF with its trigger (on save, on modify), it can block the save and attach failed-state messages to specific fields.Read
CDS & data modelling
Core Data Services view entities, annotations and projections.
- AMDP (ABAP Managed Database Procedure)AMDPAn ABAP method whose body is SQLScript executed directly in HANA, managed by the ABAP layer. Used for set-based logic too complex for CDS but that you still want pushed down to the database.Read
- Annotation (CDS)Metadata attached to a CDS entity or field (`@UI`, `@Semantics`, `@ObjectModel`, `@OData`…) that downstream consumers read — Fiori Elements builds the UI, OData exposes semantics, analytics interprets measures. Declarative, not procedural.Read
- Association (CDS)A declared, navigable relationship between CDS entities (like a join you can follow by name) that the framework resolves lazily — only when the path is used. Compositions are a special, ownership-implying kind of association used by RAP for parent/child.Read
- CDS (Core Data Services)CDSSAP's data-modelling language for defining semantically rich views, associations and annotations on top of the database — evaluated by HANA close to the data. ABAP CDS is the in-stack flavour used for S/4HANA data models and RAP.Read
- CDS View EntityThe modern form of an ABAP CDS view: a single DDL object (`DEFINE VIEW ENTITY`) with no separate generated SQL view and no `sqlViewName`. It's the only CDS view form allowed in ABAP Cloud and the data-modelling foundation for RAP.Read
- Code PushdownThe principle of doing data-intensive work in the database (via CDS/AMDP/open SQL) instead of pulling rows into ABAP and looping. 'Let HANA do the heavy lifting close to the data.'Read
- Composition (CDS / RAP)A special CDS association expressing ownership: the child entity is part of the parent and has no life of its own. RAP uses compositions to define a business object's hierarchy (root → child), driving cascading create/delete and draft.Read
- Metadata Extension (MDE)A separate DDLX object that carries a CDS view's UI annotations outside the view definition, so layout metadata can be changed and layered (e.g. by extension) without editing the view itself.Read
- Projection View vs. Interface ViewRAP's two-layer CDS pattern. The interface view (the 'engine', I_*) holds the reusable data model; the projection view (the 'consumption' / C_*) exposes a tailored, annotated subset for one service. RAP behavior projections mirror this for behavior.Read
Extensibility
The three-tier extension model — key-user, developer, side-by-side.
- BAdI (Business Add-In)An SAP-provided, object-oriented enhancement point you implement to inject custom logic into a standard process — without modifying SAP code. In ABAP Cloud / S/4HANA, released BAdIs (and the key-user Custom Logic app) are the sanctioned hook.Read
- Extensibility Model (Key-user / Developer / Side-by-side)The three places you can extend S/4HANA cleanly: key-user (in-app, no-code adaptations), developer (on-stack ABAP Cloud with released APIs), and side-by-side (separate apps on SAP BTP). Each consumes the core only through released, contract-stable interfaces.Read
- Key-User ExtensibilityIn-app, no-/low-code extension done by a business key user through Fiori tools: custom fields, custom logic (BAdIs via the Custom Logic app), custom CDS views, and UI adaptation. No transport, no developer.Read
- Side-by-Side ExtensionAn extension that runs as its own application on SAP BTP (in ABAP Cloud, CAP/Node.js or Java) and talks to S/4HANA only over released APIs and events. The core stays untouched; the extension has its own lifecycle.Read
Tooling & quality
ADT, ATC, abaplint and the checks that keep code clean-core-ready.
- ABAP CleanerAn open-source ADT plugin that automatically reformats and modernises ABAP source toward the Clean ABAP style guide — one keystroke to apply dozens of clean-up rules to a file.Read
- abaplintAn open-source, system-independent ABAP linter and parser. It runs from CI or an editor against your source files (no SAP system needed) to enforce naming, style and many cleanliness rules early.Read
- ADT (ABAP Development Tools)ADTThe Eclipse-based ABAP IDE — 'ABAP in Eclipse'. CDS, RAP, behavior definitions, and the API-state/released-object views only exist in ADT, not in classic SE80.Read
- ATC (ABAP Test Cockpit)ATCSAP's static-analysis framework that runs check variants over your code. The `ABAP_CLOUD_DEVELOPMENT_DEFAULT` variant is the authoritative gate for cloud/Clean-Core readiness — it flags every unreleased dependency and disallowed construct.Read
- Clean ABAPSAP's open-source style guide for readable, maintainable ABAP (the ABAP take on 'Clean Code'). It covers naming, method size, error handling, and modern syntax preferences.Read
- Custom Code MigrationThe structured process of getting existing custom ABAP cloud-ready: run the ABAP cloud-readiness ATC variant (often via the Custom Code Migration Fiori app / ATC on a central checks system), triage findings, and remediate to released APIs and allowed syntax.Read
- XCO LibraryThe eXtension Components library — a released, fluent ABAP API for things classic code did with unreleased helpers: string/JSON/CSV handling, time/UUID generation, metadata reads, and more. The go-to replacement when a classic utility isn't released.Read
Platform
SAP BTP and the landscape the clean core runs alongside.
- CAP (Cloud Application Programming Model)CAPSAP's framework for building services and apps in Node.js or Java on BTP, using CDS (the same modelling language family) for data and service definitions. The non-ABAP counterpart to RAP for side-by-side apps.Read
- Fiori ElementsA framework that generates a complete SAPUI5 Fiori app (list report, object page, etc.) from an OData service and its CDS @UI annotations — no hand-written UI code for the standard floorplans.Read
- JouleSAP's generative-AI copilot, embedded across SAP applications. It reaches business processes and (increasingly) custom logic through the same released, well-annotated interfaces that Clean Core promotes.Read
- ODataThe REST-based protocol SAP uses to expose business data and operations to UIs and integrations. RAP business objects are published as OData (V2 or V4) services; Fiori apps consume them.Read
- RISE with SAPSAP's bundled offering for moving to and running S/4HANA Cloud (private or public edition) as a managed subscription. It assumes — and rewards — a clean core so SAP can deliver continuous updates.Read
- S/4HANASAP's current-generation ERP suite, built on HANA, delivered on-premise or as S/4HANA Cloud (private/public edition). The 'digital core' that Clean Core keeps clean.Read
- SAP BTP (Business Technology Platform)BTPSAP's platform-as-a-service for building, integrating and extending SAP and non-SAP systems — it hosts the ABAP Environment, CAP runtimes, integration, AI and analytics. The home of side-by-side extensions.Read
- SAP HANASAP's in-memory, columnar database and the foundation of S/4HANA. Its speed for set-based and analytical queries is what makes code-pushdown (CDS, AMDP) the right pattern.Read
- Service Definition & Service BindingThe two RAP artefacts that publish a business object as a consumable service. The service definition lists which entities are exposed; the service binding binds that to a protocol (OData V2/V4 UI, OData API) and creates the service URL.Read