ARCHITECTAdvanced
RAP Basics
Master ABAP RAP fundamentals with CDS root views, behavior definitions, managed and unmanaged scenarios, actions, determinations, validations, EML, draft, locking, authorization and service binding.
Overview
Master ABAP RAP fundamentals with CDS root views, behavior definitions, managed and unmanaged scenarios, actions, determinations, validations, EML, draft, locking, authorization and service binding.
Lessons in this topic
- RAP Build-Along Part 1: Build a Managed RAP App End to EndBuild a draft-enabled managed RAP Travel application from persistence tables to CDS business object, behavior, Fiori Elements service, EML tests, authorization, debugging and transport—while understanding why every artifact exists.
- RAP Build-Along Part 2: Persistence Tables, Root and Child CDS ViewsPart 2 of the RAP Bootcamp builds the data foundation of the Travel + Booking app: active and draft tables, UUID keys with readable business IDs, audit fields, and the CDS root and child view entities connected by composition and parent association — with a working activation order and a checkpoint.
- RAP Build-Along Part 3: Behavior Definition — Managed, Draft, Locking and ETagsPart 3 of the RAP Bootcamp turns the Travel + Booking data model into a transactional business object: a managed, draft-enabled behavior definition with persistent and draft table mapping, CRUD and create-by-association, lock and authorization master/dependent, local and total ETag, managed UUID numbering and field control.
- RAP Build-Along Part 4: Behavior Implementation — Validations, Determinations and ActionsPart 4 of the RAP Bootcamp implements the business rules declared in Part 3: initial status and total-price determinations, date and child validations, Accept/Reject actions, FAILED/REPORTED with %tky, %msg and %element, instance feature control and authorization — all with bulk-safe EML IN LOCAL MODE and no COMMIT WORK.
- RAP Build-Along Part 5: Projection Views and Fiori Elements UI AnnotationsPart 5 of the RAP Bootcamp builds the consumer layer of the Travel + Booking app: projection views with redirected composition and parent association, a projection behavior that exposes only intended operations and actions, and metadata extensions that produce a Fiori Elements List Report and Object Page with a Booking table.
- RAP Build-Along Part 6: OData V4 Service Binding and EML TestingPart 6 of the RAP Bootcamp exposes the Travel + Booking BO through a service definition and OData V4 UI service binding, validates $metadata, and tests the BO end to end with EML — read, modify, create by association, actions, MAPPED/FAILED/REPORTED, COMMIT ENTITIES at the outer boundary — plus how to tell BO failures from exposure or UI failures.
- RAP Build-Along Part 7: Clean Core, Security, Performance and TransportPart 7 of the RAP Bootcamp hardens the Travel + Booking app for production: DCL read access versus RAP modify authorization, released APIs and clean core, ATC, bulk and N+1 performance, draft/lock/concurrency and authorization negative tests, DEV→QAS→PRD transport and service-binding checks, production troubleshooting, a managed vs unmanaged decision table, and a capstone checklist.
- RAP Build-Along Part 8: Managed vs Unmanaged — Choosing the Transaction Model for Your Travel AppChoose the right RAP implementation type for your Travel app and future projects: managed, managed with additional or unmanaged save, or unmanaged — with a decision checklist and the BDEF headers for each.
- RAP Build-Along Part 9: Production Troubleshooting — Metadata, Behavior, Messages and SaveTroubleshoot the Travel app layer by layer: missing fields or actions (metadata), disabled buttons (feature control vs authorization), messages that do not appear, and save failures — with a checklist and the right tools.
- RAP Basics Part 1: RAP Architecture — Layers, Artifacts and When RAP FitsThe architect's map of the ABAP RESTful Application Programming Model: the data model (CDS), behavior (BDEF + behavior pool), projection, service definition and service binding, how a Fiori request flows through them, and when RAP is the right choice versus SEGW or classic development.
- RAP Basics Part 2: Data Model Design — Tables, Keys, Administrative Fields and Interface ViewsDesign the persistence and interface layer of a RAP BO: UUID versus semantic keys, the administrative fields RAP needs for ETags and draft (created/changed by/at, local and total last changed), client handling, and building the interface root view entity on top of the table.
- RAP Basics Part 3: Projection Layer and Metadata ExtensionsBuild the projection layer of a RAP BO: projection view entities (ZC_*), provider contract transactional_query, redirecting compositions, value helps, search and text annotations, and moving UI annotations into metadata extensions so one BO can serve several apps.
- RAP Basics Part 4: Implementation Types — Managed, Unmanaged, Additional Save and Unmanaged SaveChoose the transactional model of a RAP BO: managed (framework does CRUD and save), unmanaged (you implement everything, typically wrapping legacy BAPIs), and the two hybrids — managed with additional save and managed with unmanaged save — with decision criteria for greenfield and brownfield projects.
- RAP Basics Part 5: Root Entity, Child Entity and CompositionModel multi-level RAP business objects: root and child entities, composition versus association, the to-parent association, lock master and lock dependent, authorization master and dependent, create-by-association, and how the composition tree defines the BO boundary.
- RAP Basics Part 6: Behavior Definition — CRUD, Field Control and FeaturesControl what a RAP BO allows with the behavior definition: CRUD operations, static field properties (readonly, mandatory, readonly:update), dynamic field and operation control via features: instance, global features, field mapping, and strict mode.
- RAP Basics Part 7: Actions, Determinations and Validations — Design DecisionsDecide where each piece of business logic belongs in a RAP BO: validations (check on save, reject with messages), determinations (derive values on modify or on save), actions (explicit user or API operations, instance, static and factory), side effects for Fiori, and the trigger conditions that keep logic efficient.
- RAP Basics Part 8: Service Definition, Service Binding and OData ExposureExpose a RAP BO: service definition (which projections, with aliases), service binding types (OData V2/V4, UI/Web API), publishing locally or via transport, the Fiori Elements preview, released APIs, and why UI and API consumers get separate services.
- RAP Basics Part 9: Behavior Implementation — Handler and Saver ClassesImplement RAP business logic in the behavior pool: the ZBP_* global class, local handler classes (cl_abap_behavior_handler) with FOR VALIDATE, FOR DETERMINE, FOR MODIFY and FOR INSTANCE FEATURES methods, the saver class (cl_abap_behavior_saver), derived types, %tky, failed and reported, and IN LOCAL MODE.
- RAP Basics Part 10: EML — Entity Manipulation LanguageUse EML to read and change RAP business objects from ABAP: READ ENTITIES, MODIFY ENTITIES (create, update, delete, create by association, execute action), the response parameters mapped/failed/reported, COMMIT ENTITIES and its rules, and when EML is used inside versus outside the BO.
- RAP Basics Part 11: Draft, Locking and AuthorizationMake a RAP BO safe for real multi-user use: draft handling (draft tables, Edit/Activate/Discard/Resume/Prepare, total ETag), pessimistic locking (lock master) and optimistic concurrency (ETags), and authorization at two levels — read access via CDS DCL and modify access via authorization master (global/instance).
Interview questions covered
- How does RAP fit S/4HANA Clean Core?
- What is a determination?
- How do you expose a RAP service to Fiori?
- What is the difference between action, determination and validation in RAP?
- How would you design a RAP business object with header and items?
- What is the role of behavior definition in RAP?
- What is RAP in SAP ABAP?
- Explain the difference between managed and unmanaged RAP business objects.
- Why should direct database updates be avoided for RAP business objects?
- Your team must decide between managed and unmanaged RAP for a new requirement. Which questions do you ask?
- An approve action for expense claims reads each selected claim with a separate SELECT SINGLE in a loop and raises a message when one fails, but the other claims still get approved without any explanation for the failed one. How do you improve the implementation?
- In a travel app, the total price is calculated in a determination on save. Users entering bookings in the Fiori object page see a total of zero until they press Save and think the app is broken. What do you change?
- A batch program called MODIFY ENTITIES to create orders and immediately reported success, but nothing appeared in the database and some records were never explained. What is wrong?
- An expense app put defaulting, validation and status transitions all into one big determination on save. Users get no immediate feedback, and wrong amounts are silently corrected. How would you restructure the logic?
- A new approval app on custom tables needs standard CRUD, draft, and in addition must write change documents and an application log entry whenever an approval request is saved. Which RAP implementation type do you choose and where does the extra logic go?
- Your team designed a draft-enabled RAP BO for trade promotions with the promotion number (from a number range) as the table key, drawn in early numbering. Auditors now complain about large gaps in promotion numbers. What went wrong and how would you redesign the keys?
- A Fiori app hid the Approve button for approved or foreign-region requests, but an integration partner using the OData API was still able to approve such requests. Where should this rule have been implemented?
- A RAP-based Fiori app suddenly shows an empty list after a transport. How do you localize the problem?
- What key design decisions do you make when starting a new RAP business object?
- Explain RAP feature control for operations and fields, and how to troubleshoot it.