Managed RAP Part 1: Tables, CDS Data Model and Your First Behavior Definition

📌 KEY POINTS
✅ A managed BO needs: tables → CDS root/child views → behavior definition → behavior pool.
✅ Use UUID keys with numbering : managed; add a readable RequestID for users.
✅ Composition + association to parent connect header and items.
⚠️ Admin fields only update automatically with the correct @Semantics annotations.

▶ WHAT YOU WILL BUILD IN THIS SERIES
Across these five parts you build one complete business object: a Purchase Request with a header and items. Each part adds one layer to the same object, so keep the objects you create:

• Part 1 — tables, CDS data model, first behavior definition (CRUD works with zero code)
• Part 2 — numbering, locking, ETag concurrency and authorization
• Part 3 — determinations, validations, actions and feature control (Submit / Approve / Reject)
• Part 4 — composition (header + items), create-by-association and draft
• Part 5 — projection layer, testing, performance and clean-core rules

After Part 5, continue with the Service Bindings series to expose the same object as a Fiori Elements app.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE MANAGED RAP SITS
The RESTful ABAP Programming Model (RAP) builds a transactional app in layers:

1. Database tables — where the data is stored.
2. CDS data model (view entities) — the business shape of the data: a root entity, child entities and their relationships.
3. Behavior definition (BDEF) — what may happen to the data: create, update, delete, actions, validations, locks.
4. Behavior implementation (an ABAP class called the behavior pool) — code for the non-standard parts.
5. Projection, service definition and service binding — what is exposed to a UI or an API.

"Managed" is a decision about layers 3 and 4. It means the RAP framework itself implements the standard transactional work. You write code only for business-specific logic.

━━━━━━━━━━━━━━━━━━━━
▶ WHAT THE FRAMEWORK OWNS VS WHAT YOU OWN
The framework owns: standard create/update/delete; the transactional buffer (changes are held in memory until save); locking; ETag comparison; filling administrative fields (created by/at, changed by/at); writing to the database and committing; the draft tables if draft is enabled.
You own: the data model (tables, keys, CDS); the behavior definition; the numbering strategy if you do not use UUIDs; determinations, validations and actions; authorization and feature control; messages.

━━━━━━━━━━━━━━━━━━━━
▶ THE TWO PHASES OF EVERY RAP REQUEST
Interaction phase: the consumer sends create, update or action requests. RAP runs the standard operations and calls your handler methods. All changes land in the transactional buffer — nothing is written to the database yet.
Save sequence: when the consumer commits (a user clicks Save, or code calls COMMIT ENTITIES), RAP runs on-save determinations, then validations, then writes to the database and commits. If a validation fails, nothing is written.
This is why a managed behavior class must never contain COMMIT WORK, ROLLBACK WORK or direct INSERT/UPDATE statements on its own tables: the framework owns the transaction (the LUW).

━━━━━━━━━━━━━━━━━━━━
▶ STEP 1 — CREATE THE PERSISTENCE TABLES
In ADT create two database tables: ZPR_HEAD (request header) and ZPR_ITEM (request items). Use UUID keys of type sysuuid_x16 — managed RAP can generate them. Add the administrative fields using the standard data elements shown in the code example (abp_creation_user, abp_creation_tstmpl, abp_locinst_lastchange_user, abp_locinst_lastchange_tstmpl, abp_lastchange_tstmpl). ZPR_ITEM carries parent_uuid, the foreign key to its header.

━━━━━━━━━━━━━━━━━━━━
▶ STEP 2 — CREATE THE CDS DATA MODEL
ZR_PurchReq is the root view entity ("define root view entity"). It declares "composition [0..*] of ZR_PurchReqItem as _Item": items belong to the request and cannot exist without it. ZR_PurchReqItem declares "association to parent ZR_PurchReq as _Request". Rename columns to readable CamelCase names — these become the business object field names and later the OData property names.
The @Semantics annotations on the admin fields tell RAP which field means "created by", "last changed at" and so on. Managed RAP fills them automatically on every change.

━━━━━━━━━━━━━━━━━━━━
▶ STEP 3 — CREATE THE BEHAVIOR DEFINITION
Right-click ZR_PurchReq, choose New Behavior Definition, implementation type Managed. Read each line:

• managed implementation in class zbp_r_purchreq unique — the behavior pool that will hold your code.
• strict ( 2 ) — the strictest syntax checks. Always use it for new development.
• persistent table zpr_head — tells the framework where to write.
• lock master / lock dependent by _Request — the root is locked, items are locked through the root.
• authorization master ( global, instance ) — authorization is checked on the root and inherited by items. Strict mode requires it to be declared; you implement it in Part 2.
• etag master LocalLastChangedAt — optimistic concurrency (Part 2).
• create; update; delete; and association _Item { create; } — the allowed operations. Items can only be created through their parent.
• field ( readonly, numbering : managed ) RequestUUID — RAP generates the UUID key on create.
• mapping for zpr_head — maps CDS names (RequestUUID) to table columns (request_uuid). Without it the framework cannot write CamelCase fields into snake_case columns.

━━━━━━━━━━━━━━━━━━━━
▶ STEP 4 — GENERATE THE BEHAVIOR POOL
Use the ADT quick fix (Ctrl+1) on the class name to generate ZBP_R_PURCHREQ. It contains a local handler class (lhc_…) with empty authorization methods. For Part 1 you write no further code: create, update and delete already work.

━━━━━━━━━━━━━━━━━━━━
▶ STEP 5 — TEST WITHOUT A UI
Create a class that implements if_oo_adt_classrun and run the EML snippet at the end of the code example with F9. EML (Entity Manipulation Language) is how ABAP code talks to a RAP business object. Outside the business object you call COMMIT ENTITIES to trigger the save sequence; inside handler methods you never do.

━━━━━━━━━━━━━━━━━━━━
▶ WHAT YOU HAVE AFTER PART 1
A working business object that creates, changes and deletes purchase requests and items, with keys and admin fields maintained automatically — and zero lines of CRUD code. Part 2 adds a readable request number, locking behaviour, concurrency control and authorization.

A team migrating a custom requisition transaction to RAP built an "unmanaged-style" managed BO: every handler method issued its own INSERT or UPDATE on the custom table, and one method called COMMIT WORK. Users saw half-saved requests when a later validation failed, and created/changed timestamps were inconsistent because some code paths forgot to set them.
The data mapped cleanly to two custom tables, so the fix was to let the framework do its job: declare persistent table and mapping in the BDEF, annotate the admin fields with @Semantics, delete the hand-written CRUD and the COMMIT WORK, and keep only real business logic (numbering, validations, the approval action). About 60% of the behavior class disappeared, and the half-save problem stopped because nothing reached the database until every validation passed.

• Writing INSERT/UPDATE/MODIFY statements on the persistent table inside handler methods — the framework already does this at save time, and doing it yourself bypasses the buffer and validations.
• Calling COMMIT WORK or ROLLBACK WORK in a behavior class. The framework owns the LUW; a manual commit can persist half-validated data.
• Forgetting the mapping block when CDS names differ from column names, then wondering why fields are not saved.
• Declaring the child entity as a normal association instead of "composition" / "association to parent" — then it is not part of the business object and cannot share locks, ETags or draft.
• Omitting the @Semantics annotations on admin fields, so CreatedBy/LastChangedAt stay empty.
• Leaving strict ( 2 ) out, which hides syntax problems that surface later during upgrades.

• Start every new table-based business object as managed; move to unmanaged or unmanaged save only for a proven persistence reason (see the Unmanaged RAP series).
• Use UUID technical keys with numbering : managed, plus a separate human-readable number (Part 2).
• Always use strict ( 2 ) and the standard abp_* data elements for administrative fields.
• Name layers consistently: ZR_ for the base business object views, ZC_ for projections (Part 5), ZBP_ for behavior pools.
• Keep persistence tables free of UI-only fields; UI concerns belong in the projection layer.
• Test the BO with EML in a console class before building any UI — it isolates backend problems from UI problems.

Typical questions: "What is the difference between managed and unmanaged RAP?", "What does the framework do for you in managed RAP?", "Why can't you use COMMIT WORK in a behavior implementation?"
A strong answer: in managed RAP the framework implements standard CRUD, the transactional buffer, locking, ETag handling, admin fields and the save sequence; the developer declares the contract in the BDEF and implements only business logic. Explain the two phases (interaction phase into the buffer, save sequence to the database) and that the framework owns the LUW, so a manual commit would break atomicity. Senior candidates add when they would not choose managed: when an existing API must own persistence, which leads to unmanaged or managed with unmanaged save.