ABAP RESTful Application Programming Model (RAP)

A RAP application is assembled from layers, each a separate repository object:

1. Data model: CDS view entities over database tables. A root entity and its child entities, linked by compositions, form the business object, for example a purchase request with its items.
2. Behavior definition (BDEF): declares what the business object can do: create, update, delete, actions, validations, determinations, locking, concurrency control and draft.
3. Behavior pool: an ABAP class that implements the custom parts the behavior definition declares, such as a validation that rejects requests above a limit.
4. Projection layer: projection views and a projection behavior definition that expose only what a given service needs.
5. Service definition: lists the entities a service exposes.
6. Service binding: chooses the protocol (OData V2, OData V4 or InA) and the category, UI or Web API, and publishes the service. A preview shows the result as a SAP Fiori elements app.

Each layer has one job, which is how RAP keeps data model, behavior and exposure separate in one ABAP business object.

The implementation type in the behavior definition decides who writes the transactional code:

• Managed: the RAP framework handles standard create, update and delete operations, the transactional buffer and saving to the persistent tables. Developers add only business logic: validations, determinations and actions.
• Unmanaged: developers implement every operation and the save sequence themselves, typically by calling existing application code that already handles persistence.

A third variant exists for older code: business objects built with the predecessor ABAP Programming Model for SAP Fiori (BOPF) can be migrated to BOPF-based RAP business objects. SAP notes these are not native RAP business objects and are not enabled for ABAP Cloud.

Decision criterion: choose managed when the business object owns its tables, such as a new custom application at Alder Manufacturing; choose unmanaged when proven legacy logic must be reused rather than rewritten. Managed RAP reduces code; unmanaged RAP protects existing investments.

RAP grew release by release, so availability depends on the feature, not only on the model:

SAP S/4HANA Cloud Public Edition receives features with the cloud cadence, and Private Edition follows the on-premise release it runs on. SAP ERP (ECC) does not include RAP: the ABAP Platform releases that carry it, from 7.53 on, ship only with SAP S/4HANA. SAP's RAP BDL feature tables list the release of every language element, and checking them for the target release is the first step of any RAP design.

ABAP Cloud is SAP's development model for cloud-ready, upgrade-stable ABAP: released APIs only, a restricted language version and Eclipse-based tools. RAP is the programming model ABAP Cloud uses for transactional applications and services.

• In the SAP BTP ABAP environment and in developer extensibility of SAP S/4HANA Cloud Public Edition, RAP is the way to build transactional apps and APIs.
• In Private Edition and on-premise, RAP can be used with ABAP Cloud rules, available from SAP S/4HANA 2022 (ABAP 7.57), or in classic ABAP. The choice decides which SAP objects the code may use.
• Strict mode in a behavior definition enforces current best practices, such as using CDS view entities as data sources.

RAP is therefore not tied to SAP BTP: the same model runs inside SAP S/4HANA. ABAP Cloud adds the rules; RAP provides the structure.

RAP's strengths are real. One model runs from the database to the SAP Fiori elements UI; locking, concurrency control and draft come from the framework instead of hand-written code; services stay upgrade-stable when built on released APIs; and the same business object can serve a UI and an API.

Its boundaries follow from where it runs:

• ABAP only. RAP needs ABAP skills, ABAP Development Tools and an ABAP system; teams without them face a real learning curve.
• One system. A RAP business object is transactional inside one ABAP system. Processes spanning several systems need integration or events on top.
• Release-bound. A feature documented for the cloud may arrive on-premise only with a later release.
• UI flexibility through annotations. Apps generated with SAP Fiori elements are as flexible as the floorplans and their extension points.

RAP is the strongest option when logic and data belong in the ABAP system; it is not designed for cross-system orchestration.

1. Exposing the base layer directly. Without a projection layer, every service change touches the core business object.
2. Choosing unmanaged out of habit. Unmanaged makes sense when legacy logic is reused; for new tables, managed saves most of the code.
3. Binding a SAP Fiori app to a Web API service. Web API bindings carry no UI metadata, so the app shows empty tables or default layouts. Use a UI binding.
4. Building on DDIC-based CDS views. They are obsolete, and strict mode expects view entities.
5. Ignoring the feature tables. Code copied from a cloud tutorial can fail to activate on an older on-premise release.

Most RAP problems are layering and release decisions made too early, not coding errors.