ERPClimb logoERPClimb

SAP Architect RAP Basics Interview Questions

In SAP Architect rounds, rap basics questions are where configuration knowledge meets day-to-day behaviour — what a setting does, and what breaks in a live system when it is wrong.

Master ABAP RAP fundamentals with CDS root views, behavior definitions, managed and unmanaged scenarios, actions, determinations, validations, EML, draft, locking, authorization and service binding.

This page carries 11 reviewed SAP Architect rap basics interview questions, each with a complete written answer and no sign-in required. The set breaks down into 2 foundational, 5 mid-level and 4 advanced questions, so you can start at the top for a first interview or skip ahead to the scenario-based items for a senior round.

Rehearse these out loud rather than reading them. If you can explain each answer in your own words, including one realistic way it goes wrong on a project, you are covering what a normal SAP Architect round on rap basics expects.

Read the full guide: SAP RAP Interview Questions

11 RAP Basics questions with answers

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.

Related lesson

Behavior Implementation and Behavior Pool

Related topics

Cross-Module Integration and Non-Functional ArchitectureABAP CoreOData GatewayCDS ViewsDebuggingInternal TablesS/4HANA Clean CoreOpen SQL

Next practice step

Practice with Interview AITake a mock test