RAP_CDS_ODATAintermediate
Managed RAP
Master managed RAP where the framework owns the transactional buffer and standard persistence for custom business objects. Learn CRUD, numbering, locking, validations, determinations, actions, draft options and the limits of direct managed persistence.
Overview
Master managed RAP where the framework owns the transactional buffer and standard persistence for custom business objects. Learn CRUD, numbering, locking, validations, determinations, actions, draft options and the limits of direct managed persistence.
Lessons in this topic
- Managed RAP Part 1: Tables, CDS Data Model and Your First Behavior DefinitionBuild the foundation of a managed RAP business object step by step: persistence tables, a root/child CDS data model, and a managed behavior definition — and understand exactly what the framework does for you.
- Managed RAP Part 2: Numbering, Locking, ETags and AuthorizationAdd the transactional controls to the Purchase Request object: a technical UUID plus a readable request number, pessimistic locks, optimistic ETag concurrency, and global and instance authorization.
- Managed RAP Part 3: Determinations, Validations, Actions and Feature ControlGive the Purchase Request real business behavior: default and calculated values with determinations, error checks with validations, a Submit/Approve/Reject workflow with actions, and state-based feature control.
- Managed RAP Part 4: Compositions, Create-by-Association and DraftUnderstand the composition tree behind a RAP business object, create items through their parent with create-by-association and %cid_ref, and enable draft so users can edit requests over a longer session safely.
- Managed RAP Part 5: Projection Layer, Testing, Performance and Clean CoreTake the Purchase Request object to production: build the projection layer that services consume, write ABAP Unit tests with EML, avoid the common performance traps in handlers, and keep the design clean-core compliant.
Interview questions covered
- Walk me through the layers of a RAP application, from the database table to the Fiori app. What is the job of each layer?
- In managed RAP, what exactly does the framework do for you, and why must a behavior implementation never contain COMMIT WORK or direct INSERT/UPDATE statements on its own tables?
- Two users open the same purchase request. User B saves a change first; user A saves later from a stale screen. Which RAP mechanisms prevent A from overwriting B, and how do locks and ETags differ?
- Design the numbering for a purchase request business object: users need a readable, sequential request number, but drafts are often abandoned. Which RAP numbering options exist and which would you choose?
- Classify each requirement as a determination, validation, action, feature control or authorization: (1) status is New when a request is created, (2) description is mandatory, (3) manager clicks Approve, (4) Approve is only possible when status is Submitted, (5) only buyers may create requests. Explain why.
- Implement a Submit/Approve/Reject workflow in a managed RAP object. What do you declare in the BDEF, and how does the approve action implementation look in principle?
- What is the difference between a composition and an association in a RAP business object, and how do you create a header with items in one EML call?
- After enabling draft on a working managed RAP object, one determination fails and the object page behaves oddly. What do you check?
- A mass approval of 2,000 purchase requests through OData times out, although single approvals are fast. How do you analyze and fix it?
- You inherit a managed RAP business object before a go-live. What would you review, and which findings would block production?