RAP Basics Part 11: Draft, Locking and Authorization

📌 KEY POINTS
✅ Draft lets users save incomplete work on the server: changes live in a draft table until Activate copies them to the active table.
✅ Locking: lock master takes an exclusive lock on the active instance (for draft: when editing starts); ETags detect that the data changed since it was read.
✅ Draft needs a total ETag (lock master total etag LastChangedAt) to detect changes to the active instance while a draft exists.
✅ Authorization has two parts: read = CDS access control (DCL); create/update/delete/actions = authorization master in the BDEF (global and/or instance methods).
⚠️ A BO with DCL but no authorization master lets every user who can open the app change every record they can see.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Final part: making the BO ready for many users working at the same time.

━━━━━━━━━━━━━━━━━━━━
▶ 1. DRAFT

• BDEF header: with draft; entity: draft table ztravel_d (generated via quick fix).
• Draft actions: Edit, Activate optimized, Discard, Resume, Prepare.
• Children: association _Booking { create; with draft; }.
• %is_draft in %tky distinguishes draft and active instances.

━━━━━━━━━━━━━━━━━━━━
▶ 2. LOCKING

• Pessimistic: lock master on root, lock dependent by _Travel on children.
• Managed BO: framework sets the enqueue lock; unmanaged: implement lock method.
• With draft the lock is held from Edit until Activate/Discard (draft lifetime).

━━━━━━━━━━━━━━━━━━━━
▶ 3. ETAGS (OPTIMISTIC)

• etag master LocalLastChangedAt — instance ETag in OData (If-Match header).
• total etag LastChangedAt — for draft; checked on Resume/Activate.
• Outdated ETag → HTTP 412 / "data changed by another user".

━━━━━━━━━━━━━━━━━━━━
▶ 4. AUTHORIZATION — READ

• @AccessControl.authorizationCheck: #CHECK + DCL role with pfcg_auth mapping.
• Restricts which rows a user can see (Part 8 of CDS Views).

━━━━━━━━━━━━━━━━━━━━
▶ 5. AUTHORIZATION — MODIFY

• authorization master ( global, instance ) on the root; children authorization dependent.
• get_global_authorizations: may the user create at all?
• get_instance_authorizations: may the user update/delete/accept this record (e.g. by agency)?
• Use AUTHORITY-CHECK on your own authorization object.

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP

1. Add with draft; and create draft tables via quick fix.
2. Add total etag and draft actions, include Prepare validations.
3. Add authorization master ( global, instance ) and implement both methods.
4. Create a DCL role for read access.
5. Test with two users: edit the same travel, and a user without authorization.

✅ CHECKPOINT: user B sees "locked by user A" while A edits, and a user without the auth object cannot create travels.

After go-live of a draft-enabled promotion BO, planners complained that their changes "disappeared". Analysis showed two planners editing the same promotion: the BO had an instance ETag but no total ETag, and the draft of planner A was activated over changes planner B had activated minutes earlier. Adding lock master total etag LastChangedAt made Resume/Activate detect the conflict and show "data changed by another user". A second finding in the same audit: the BO had a DCL restricting read by sales org but no authorization master — any user who could see a promotion could also approve it. Instance authorization with AUTHORITY-CHECK on a custom object closed the gap.

• Draft-enabled BO without total ETag, so concurrent activations overwrite each other.
• Relying on DCL alone and forgetting authorization master for modify operations.
• Designing draft tables by hand instead of generating them from the BDEF.
• Forgetting "with draft" on create-by-association for children.
• Testing only with a developer user who has SAP_ALL-like authorizations.

• Use draft with total ETag for all new Fiori transactional apps.
• Combine DCL (read) and authorization master (modify) — always both.
• Use a custom authorization object with the business field (agency, sales org) for instance checks.
• Test locking and authorization with at least two restricted test users.
• Keep draft lifetime and cleanup (draft expiry) in mind for operations.

Questions: "How does draft work in RAP?", "Difference between locking and ETag?", "How do you implement authorization in RAP?"
Strong answer: draft stores work in progress in a draft table until Activate; lock master sets an exclusive lock, ETags detect concurrent changes (instance ETag via If-Match, total ETag for draft). Authorization is split: CDS DCL restricts read access; authorization master with global and instance methods controls create, update, delete and actions. Senior answers describe testing with restricted users and the risk of DCL without modify authorization.