Service Definition and Service Binding in RAP

A service definition is a DDLS source object listing 'expose' statements: a root CDS entity given an alias, plus optionally its children reached via association, all bundled as one addressable service. It contains no protocol information at all. A service binding is a separate SRVB object that takes one service definition, attaches a binding type (OData V2 UI, OData V4 UI, Web API, or an analytical binding), assigns a version, and, once activated and published, registers the resulting service with the ICF node and the OData framework so it can actually be called. The structural fact that causes most confusion: editing the service definition never automatically updates a binding that already exists against it. Activation of the definition and publishing of the binding are two independent lifecycle events, and a stale binding will keep serving the old metadata until someone republishes it, even though the underlying CDS and behavior definition look correct in the IDE.

Use a service definition and binding whenever a RAP business object, or a read-only CDS projection, needs to be consumed externally, whether by a Fiori elements app, a custom SAPUI5 app, or an external system calling an OData Web API. They are the standard, and now the only supported, way to expose CDS-based business logic as OData in RAP. They are the wrong tool when the requirement is purely internal ABAP-to-ABAP consumption; in that case call the CDS entity or the EML interface directly and skip the service layer entirely. They are also unnecessary for a CDS view that only feeds an analytical query or a table function consumed inside another view, where no HTTP endpoint is required. Do not create a binding just to 'test' a business object during early development if there is no consumer yet; the extra published artifact adds housekeeping (versioning, transport, catalog assignment) with no payoff until a UI or integration actually needs it.

Below the service definition sits the projection CDS view entity, usually with its own behavior definition, which itself sits on top of an interface CDS entity and a behavior implementation class. Above the service binding sits the actual protocol runtime: OData V4 UI bindings feed Fiori elements object pages and list reports directly, OData V2 UI bindings feed classic and transitional Fiori apps, and Web API bindings feed external integrations without a UI layer. INA bindings feed analytical consumers. The service definition and binding together replace the SEGW project plus its generated model classes from the classic OData V2 stack; there is no manual model class, no runtime artifact generation step, and no separate DPC/MPC implementation to maintain. Nothing sits between the binding and the transport layer other than the standard gateway registration.

A managed RAP business object for sales quotations has an interface CDS entity, a projection view with a UI-facing alias, and a behavior definition implementing create, update and an action to convert the quotation to an order. A service definition is created exposing the projection entity as the root entity set, with its association to quotation items exposed as a dependent entity set so the object page can show line items in a table. A first service binding is created against this definition with an OData V4 UI type, version 0001; it is activated and published, and immediately available for preview, generating a working Fiori elements object page with a create form, an editable item table and the conversion action as a button. Later, a second binding is created against the same service definition with a Web API type so an external procurement system can create quotations programmatically without pulling in any UI annotations. Both bindings share the same underlying behavior logic; they differ only in protocol and consumer.

Service definitions and bindings are the standard extensibility artifact in S/4HANA and are fully aligned with clean core: they belong in the customer namespace, are transportable, and do not touch SAP-delivered objects. They are the recommended replacement for SEGW-based OData V2 projects, which are discouraged for new development on S/4HANA regardless of whether the underlying data source is a RAP business object or a plain CDS view. In key user or developer extensibility scenarios, a service definition can only expose entities released for extension, so the choice of binding type and exposed fields is constrained by the release contract of the underlying CDS views, not by what happens to compile locally.

This is developer and architect territory. The developer authors the service definition and binding as part of the business object; the architect decides protocol choice, versioning policy and whether UI and integration traffic share a definition. Handover to functional or Fiori configuration teams should include the published binding name, version, entity set names and the associated app or launchpad tile, not just the underlying CDS entity names.

Read rap-behaviour-definition-and-behaviour-implementation and rap-managed-versus-unmanaged-scenarios first, since the service definition only exposes what the behavior layer already implements. odata-v2-versus-odata-v4-for-sap-developers and segw-versus-cds-based-service-exposure explain the protocol and legacy-replacement decisions referenced in the guidance section above. fiori-elements-list-report-and-object-page covers what the published binding actually drives once a UI consumer is attached.