RAP Architecture: CDS, Behavior and Service Exposure

Explanation

RAP applications are built using a layered architecture. CDS views define the data model. Behavior definitions describe what operations are allowed on that model, such as create, update, delete, actions, validations and determinations. Behavior implementations contain custom ABAP logic when required. Service definitions expose selected entities, and service bindings publish the service as OData for Fiori or external consumption. This is different from classic SEGW where developers manually coded most CRUD operations. In RAP, the framework understands the business object model and generates much of the runtime behavior when designed correctly.

Code example

@EndUserText.label: 'Travel Root Entity'define root view entity ZI_Travel as select from ztravel{ key travel_id as TravelId, agency_id as AgencyId, customer_id as CustomerId, status as Status, created_by as CreatedBy} * RAP building blocks:* 1. CDS root entity models the business object.* 2. Behavior definition controls allowed operations.* 3. Behavior implementation contains custom logic.* 4. Service definition exposes entities.* 5. Service binding publishes OData service.

Real project scenario

A travel approval app was built using one root CDS entity for travel request, child entity for items, a behavior definition for create/update/approve actions and an OData V4 service binding for Fiori elements.

Common mistakes

- Starting from service binding before designing the business object. - Mixing database table design and UI design without RAP layers. - Not understanding which artifact owns which responsibility. - Trying to write old SEGW-style CRUD code in RAP.

Best practices

- Model business object first. - Keep CDS, behavior and service responsibilities separate. - Use Fiori elements annotations at the right layer. - Test behavior before publishing service.

Interview angle

A good answer should explain RAP as CDS plus behavior plus service exposure, not just as another OData generator.