Lesson 1 of 5
RAP architecture: data model, behavior and service
10 min
Listen to this lesson
The ABAP RESTful Application Programming Model (RAP) is SAP's programming model for transactional apps and APIs in ABAP Cloud. If CDS answers "what is the data", RAP answers "what can you do with it, and how is it exposed". SAP Learning summarizes RAP as built on CDS, a service model infrastructure and ABAP-based application services, producing SAP HANA-optimized OData services for Fiori apps and Web APIs. Every SAP Fiori elements app you build on SAP S/4HANA with ABAP Cloud follows this structure, so testers who understand it can read a defect and know which layer to look at.
The RAP business object
A RAP business object (BO) represents a real-world entity with its data and behavior. Its data is a tree of CDS entities: one root entity, defined with define root view entity, and child entities linked by compositions. Its behavior is declared in a behavior definition (BDEF), which by convention has the same name as the root entity, and implemented in an ABAP behavior pool, a special class pool typically prefixed BP_, whose handler code sits in the Local Types section in ADT. Consumers read and change the BO through the Entity Manipulation Language (EML) in ABAP, or through OData from a UI.
Contoso’s first RAP app
Maria's order-to-cash team maintains core return agreements today with an old maintenance screen that came across in the conversion. Kenji's team will replace it with a RAP app in the ABAP Cloud software component ZCMC_CLOUD: a Fiori elements list and object page where key users create and change agreements, add items, and close an agreement when the fleet customer ends the program. Following SAP's naming guide, the objects are named as in the table below.
| Object | Name | Role |
|---|---|---|
| Root view entity | ZR_CMC_CoreAgreement | Agreement header over ZCMC_CORE_AGR |
| Child view entity | ZR_CMC_CoreAgreementItem | Agreement items over ZCMC_CORE_AGI |
| Behavior definition | ZR_CMC_CoreAgreement | Same name as the root entity |
| Behavior pool | ZBP_R_CMC_COREAGREEMENT | Validations, determinations, actions |
| Projection views and BDEF | ZC_CMC_CoreAgreement, ZC_CMC_CoreAgreementItem | Shape the BO for the UI service |
| Service definition | ZUI_CMC_COREAGREEMENT | Exposes the projections |
| Service binding | ZUI_CMC_COREAGREEMENT_O4 | OData V4, UI |
Contoso’s core return agreement app (illustrative names following SAP’s RAP naming conventions).
- User saves in the Fiori appOData V4 request to the published service
- RAP runtimeRoutes the request to the BO through the projection
- Interaction phaseCreate or update lands in the transactional buffer; on modify determinations run
- Save sequenceOn save determinations and validations run; any failure rejects the whole buffer
- PersistManaged BO writes ZCMC_CORE_AGR and ZCMC_CORE_AGI
- ResponseMessages and the saved data return to the UI
Two phases you must understand
RAP separates the interaction phase, in which operations change data in the transactional buffer, from the save sequence, in which the buffer is checked and written to the database. SAP's cheat sheet stresses the consequence: when a validation rejects inconsistent data, the entire transactional buffer is rejected, including instances without errors. That all-or-nothing rule is what keeps data consistent, and it is also why a tester sometimes sees a save fail because of an item they did not touch.
EML deserves a sentence of its own because tests use it constantly. READ ENTITIES and MODIFY ENTITIES read and change BO instances in the transactional buffer; COMMIT ENTITIES triggers the save sequence; ROLLBACK ENTITIES discards the buffer. Each call returns response structures: mapped for keys of new instances, failed for instances that could not be processed and reported for messages. In a Fiori app the RAP runtime issues the commit for you; in an ABAP program or a test you call it yourself.
What would you do?
During CMQ testing, Maria saves an agreement with three items. Item 2 has a deposit of zero, which a validation forbids. What should she expect, and what should Priya's team record?
- RAP layers: persistence, CDS data model, behavior, projection, business service.
- A RAP BO has one root entity and child entities linked by compositions.
- The BDEF declares behavior; the ABAP behavior pool (BP_) implements it.
- Changes go to the transactional buffer, then the save sequence checks and persists them.
- A failed validation rejects the whole buffer: all or nothing.
Check your understanding · not graded
Lesson check
1. Which statement defines the top entity of a RAP business object?
2. Where is a RAP BO’s behavior implemented?
3. What happens to error-free instances when a validation rejects one instance during save?
4. Which artifact decides whether a service is exposed as OData V2 or V4?