ERPClimb logoERPClimb
RAP · RESTful ABAP

SAP RAP Interview Questions

RAP questions arrive in almost every modern ABAP interview now, and they expose a specific gap: candidates who have read about the RESTful Application Programming Model but cannot reason about why it is shaped the way it is. Interviewers are not checking whether you can recite the layers; they are checking whether you know which layer owns which decision.

The questions on this page come from ERPClimb's reviewed question bank and move from the model's building blocks — behaviour definitions, projections, service definitions and bindings — into the judgement calls: managed versus unmanaged implementation, when a legacy application should keep its own persistence, and how RAP relates to the CDS model underneath it.

Each answer is written to be said out loud in an interview: the decision first, the reason second, and the trade-off the interviewer is waiting for last. If you can explain why a greenfield object goes managed without hesitating, you are ahead of most of the field.

What interviewers actually probe

Managed versus unmanaged

The single most common RAP question. Expect to justify the choice from who owns persistence and who owns the transactional buffer — not from which one is newer.

What the behaviour definition actually controls

Interviewers probe whether you understand that the behaviour definition declares the business object's contract — operations, validations, determinations, locks — rather than containing the logic itself.

Projections and service exposure

A frequent practical line: how a single data model serves multiple apps through projection layers and service bindings, and what V4 exposure buys you over a hand-built service.

RAP versus what it replaces

Strong candidates can place RAP against SEGW services, classic reports and BOPF-era thinking, and say honestly when the older technique is still the right one.

11 questions with full answers

Ordered from foundational to advanced. No sign-in required.

easyRAP Basics

1. Difference between managed and unmanaged.

First I would check whether the scenario needs the RAP framework to own the database save logic or whether an existing business API must remain in control. In managed RAP, the framework provides the persistence handling, so you mainly model the CDS view and behaviour definition and let RAP take care of create, update, delete and save sequence. In unmanaged RAP, you implement the CRUDQ handlers yourself, typically by calling existing BAPIs or other application logic, and you manage the persistence explicitly. A strong candidate also adds that managed is faster to build when the data model fits RAP cleanly, while unmanaged is chosen when legacy logic or special processing must be preserved.
easyRAP Basics

2. What is RAP?

RAP, or the ABAP RESTful Application Programming Model, is SAP’s framework for building transactional OData services and Fiori apps in a declarative way on S/4HANA and BTP. First, I would explain that the model centres on CDS for the data definition and behaviour definitions for the business logic, rather than relying on a lot of procedural coding. This matters because it gives a consistent, service-oriented approach, fits cleanly with modern Fiori development, and supports transactional processing. A strong candidate would also add that RAP is designed to simplify end-to-end app development by combining data modelling, behaviour, and exposure as services in a structured ABAP approach.
mediumRAP Basics

3. What is a determination?

A determination is a behaviour that runs automatically at defined trigger points such as create, update or save to derive and populate fields without manual user input. The first thing to check is which trigger point is appropriate for the business rule and what data the determination depends on, because it should only run when the required context is available. It is used to keep values consistent, for example automatically filling the reviewer based on the department when a request is created. A strong candidate also adds that determinations should be deterministic, lightweight, and focused on deriving data rather than performing unrelated processing, so the saved business object is complete and consistent.
mediumRAP Basics

4. How do you expose a RAP service to Fiori?

First create the service definition and list only the RAP entities you want to expose, because that controls the service contract and avoids publishing unnecessary data. Then create a service binding of type OData V4 UI and publish the binding so the runtime can generate the service endpoint. After that, register or activate the binding in /IWFND/V4_ADMIN, which makes the service available for consumption. In a strong answer, add that Fiori Elements can then consume the service directly, typically as a list report or object page, provided the CDS/RAP model is designed for those UI patterns and the exposed entities support the required navigation and annotations.
mediumRAP Basics

5. What is the difference between action, determination and validation in RAP?

First, I would separate them by when they run and whether they are triggered by the consumer. An action is an explicit operation the user or consumer invokes, such as approve or submit, so it is used for business steps that are not simple field updates. A determination runs automatically during modify or save to derive or adjust values, so it is ideal for defaulting, recalculating, or keeping data consistent without user intervention. A validation also runs automatically, but its purpose is to check business rules and stop the save with errors if the data is not acceptable. A strong candidate adds that action changes are intentional, determination is corrective or derivative, and validation is purely control and quality enforcement.
mediumRAP Basics

6. RAP action returns 'business logic disabled'. Why?

First check whether the action is actually enabled for the instance at runtime, because this message usually means RAP has suppressed the action before execution. Review the feature definition and confirm features : instance is set where required, especially if the action depends on the current state of the object. If the action is meant to work in draft processing, ensure the entity is draft-enabled, otherwise RAP can block it as business logic disabled. Then verify the access path: DCL restrictions and any global authorisation implementation can still prevent the action from being offered or executed. A strong candidate would also test the same action with a fully authorised user and compare behaviour between active and draft instances to isolate whether the issue is configuration, authorisation, or runtime feature control.
hardRAP Basics

7. How would you design a RAP business object with header and items?

I would create a root entity for the header and child entity for items using composition. The child would have an association to parent. Behavior definition would be defined for the root and child depending on allowed operations. I would use determinations and validations for business rules, and expose projection/consumption entities through a service definition and binding.
mediumRAP Basics

8. When would you choose managed RAP and when would you choose unmanaged RAP?

I would choose managed RAP when the business object uses standard persistence and the framework can handle CRUD and save behavior. I would choose unmanaged RAP when save logic must be controlled manually, such as when calling BAPIs, legacy function modules, existing APIs or complex custom update logic.
hardRAP Basics

9. How does RAP fit S/4HANA Clean Core?

First, I would say RAP fits S/4HANA Clean Core by moving custom development into released, upgrade-safe extension points. It relies on released CDS views for the data model and BDEF for transactional behaviour, so business logic sits in the extension layer rather than in core modifications. That makes it fully cloud-eligible and aligned to the Clean Core principle of keeping the standard stable. Compared with classic SEGW and modification-based approaches, RAP is the preferred way to add transactional apps and logic without changing the SAP core. A strong candidate also highlights that RAP supports maintainability, clearer separation of custom code, and safer upgrades because the custom build uses released artefacts only.
hardRAP Basics

10. App needs offline capability. Approach?

First, check whether the app really needs full offline use or only short connection loss tolerance, because the design changes the synchronisation model. In SAP Fiori offline scenarios, the usual approach is to use OData $batch together with a local store so the app can continue to read and queue changes while disconnected. A key point is that keys must be generated on the client, typically with a client UUID, so new records can be created before the backend is reachable. On the backend, entities should have stable keys and RAP determinations can translate the client key to the backend UUID during save. A strong candidate also adds clear sync-on-reconnect logic, conflict handling, and validation of what data must be cached locally.
hardRAP Basics

11. How do you migrate a classic transaction to RAP?

First check whether the classic transaction can be wrapped or needs partial redesign, then model the RAP layers: interface, composite, and consumption CDS views. After that define the behaviour, usually in an unmanaged implementation that wraps the existing BAPIs so the legacy logic is reused without changing proven processing. Expose the consumption model through a service definition and service binding, then build the Fiori Elements pages on top. A strong candidate also mentions running the old transaction and the RAP app in parallel for acceptance, validating business parity, and only retiring the classic transaction once users have signed off.

Practise by experience level

Fresher1-3 years4-7 years8-12 years

The questions above are tagged by the experience levels they are normally asked at, so the same page works for a first interview and for a lead-developer round.

SAP RAP Interview Questions FAQ

When would you choose a managed over an unmanaged RAP implementation?

Managed when the object is new and the framework can own persistence and the transactional buffer — that is the greenfield default on S/4HANA. Unmanaged when existing code already owns the database tables and the save sequence, because RAP then delegates those phases to your implementation instead of replacing working logic.

What is a behaviour definition in RAP?

It is the declared contract of a business object: which operations exist, which fields are read-only, where validations and determinations run, and how locking works. The implementation lives in the behaviour pool class; the definition is what consumers and the framework rely on.

How does a CDS model become an OData service in RAP?

Through three thin layers: the CDS views model the data, a projection view adapts it for a specific app, and a service definition plus binding exposes it as OData — V4 with RAP. The point interviewers look for is that no hand-written DPC class is involved.

What is the difference between a validation and a determination?

A validation checks consistency and can reject the save; a determination derives or fills values during the transactional phase. The expected answer includes when each runs — determinations modify, validations guard — and that both are declared in the behaviour definition and triggered by the framework, not called directly.

Is RAP only for S/4HANA cloud?

No — RAP is available on S/4HANA on-premise and in the ABAP environment on BTP as well. What changes with the cloud is which release of the model and which language version restrictions apply, which is itself a question interviewers ask to test whether you have actually built with it.

Next practice step

Practise these questions with Interview AITake a mock test

Related SAP interview topics

ERP Climb is an independent educational platform and is not affiliated with SAP SE.