Service Definition, Service Binding and OData Exposure

Explanation

After a RAP business object is modeled and behavior is defined, it can be exposed through a service definition and service binding. The service definition selects which entities are exposed. The service binding publishes the service using protocol such as OData V2 or OData V4 depending on system support. This is how RAP applications are consumed by Fiori elements or external clients. Developers should expose only required entities and avoid exposing internal helper views.

Code example

@EndUserText.label: 'Travel Service Definition'define service ZUI_TRAVEL { expose ZC_Travel as Travel; expose ZC_TravelItem as TravelItem;} * After service definition:* 1. Create service binding.* 2. Choose OData protocol supported by system.* 3. Publish binding.* 4. Test metadata and entity operations. * Key point:* Service definition controls what is exposed.* Do not expose internal technical views unnecessarily.

Real project scenario

A custom travel request RAP object was exposed as OData V4 service and consumed by a Fiori elements app without writing custom UI CRUD code.

Common mistakes

- Exposing basic/internal views directly. - Publishing service before behavior is tested. - Exposing unnecessary child/helper entities. - Not testing metadata and authorization.

Best practices

- Expose consumption/projection entities. - Keep service surface minimal. - Test metadata and CRUD behavior. - Check authorization before release.

Interview angle

A good answer should explain service definition vs service binding and how RAP becomes OData.