Draft, Locking and Authorization in RAP

Explanation

Draft handling allows users to save incomplete work before final activation. This is important for complex Fiori object pages where users may fill data in multiple steps. Locking prevents conflicting updates. Authorization ensures only permitted users can see or change business objects. RAP supports managed locking and authorization concepts, but the developer must design them properly. A production-ready RAP app cannot ignore these concerns. Draft is powerful but should be used when the business process actually needs temporary saved state.

Code example

define behavior for ZI_Request alias Requestpersistent table zrequestlock masterauthorization master ( instance )draft table zrequest_d{ create; update; delete;  draft action Edit; draft action Activate; draft action Discard; draft action Resume;  action approve result [1] $self;} * Draft table stores temporary draft data.* Lock master prevents conflicting changes.* Authorization master means instance-level authorization can be checked.

Real project scenario

A procurement request app used draft because users often saved incomplete requests and completed them later. Authorization restricted approval actions to specific approver roles.

Common mistakes

- Enabling draft when process does not need it. - Ignoring lock behavior. - Not designing authorization for actions. - Assuming UI role security is enough.

Best practices

- Use draft for multi-step/incomplete-save scenarios. - Design lock strategy early. - Implement instance authorization where needed. - Test with multiple users.

Interview angle

A strong answer should explain draft as temporary saved state, plus lock and authorization importance.