Managed vs Unmanaged RAP Scenarios

Explanation

Managed RAP is suitable when the framework can handle standard create, update, delete, locking and save behavior for a persistent table. It is faster to build and ideal for many custom transactional apps. Unmanaged RAP is used when the developer must control the save sequence manually, usually because the business object is backed by legacy function modules, BAPIs, existing APIs or complex custom logic. The decision is important. Choosing unmanaged unnecessarily increases code and complexity. Choosing managed when the persistence/save logic is not standard can create design problems.

Code example

managed implementation in class zbp_i_travel unique;strict ( 2 ); define behavior for ZI_Travel alias Travelpersistent table ztravellock masterauthorization master ( instance ){ create; update; delete;  field ( readonly ) TravelId, CreatedBy;} * Managed RAP:* Framework handles standard persistence.* Use this when CRUD maps cleanly to your table. * Unmanaged RAP:* Developer controls save manually.* Use this when you must call BAPI/API/legacy logic.

Real project scenario

A travel approval Fiori app was built in one sprint using managed RAP because it used custom transparent tables and standard CRUD. A sales order wrapper used unmanaged RAP because save had to call BAPI_SALESORDER_CHANGE.

Common mistakes

- Using unmanaged RAP for simple custom table CRUD. - Using managed RAP when save must call legacy API. - Not understanding persistence ownership. - Ignoring lock and authorization design.

Best practices

- Prefer managed RAP for clean custom persistence. - Use unmanaged RAP for legacy/BAPI-backed scenarios. - Do not over-engineer simple CRUD. - Document why unmanaged was chosen.

Interview angle

Interviewers often ask managed vs unmanaged. A strong answer gives decision criteria and real examples.