Service Binding (RAP)

A service binding is the last step in the RAP chain from data model to consumable service:

1. CDS view entities and a behavior definition form the business object.
2. Projection views shape what one service needs.
3. A service definition lists the entities the service exposes.
4. The service binding decides how that scope is exposed: which protocol, which consumption type and which version.

Its parameters are the service name, identical to the binding name; the binding type; the service version; and the publishing status. Because protocol and scope are separate objects, several bindings can sit on one service definition: Alder Manufacturing could expose the same purchase requisition scope once as an OData V4 UI service for its SAP Fiori app and once as an OData V4 Web API for a supplier portal of Cedar Office Supply. A service binding is therefore where a RAP service becomes a concrete, addressable endpoint.

SAP's current documentation lists four protocols and two consumption categories:

The category matters as much as the protocol. UI services carry UI annotations in their metadata, value helps, side effects and feature control, and offer the SAP Fiori elements preview. Web APIs contain no UI-specific information and are meant for unknown consumers, and they can be extended. SAP recommends OData V4 wherever possible for transactional services, and notes that full SAP Fiori elements support on OData V4 is granted only for draft-enabled scenarios. Check which binding types your release offers in its RAP documentation. Decision criterion: bind as UI when an SAP Fiori app consumes the service, and as Web API for everything else.

• Publishing: the binding must be active, and the Publish button in the service binding editor runs the task lists that enable the endpoint. SAP stresses that publishing enables the service only in the current system; it does not make the service reachable from other systems.
• After transport (on-premise and Private Edition): SAP documents that the service binding only enables the service locally in the development system; in quality and production systems the service is activated with the Gateway tools, OData V4 services as service groups in /IWFND/V4_ADMIN and OData V2 services in /IWFND/MAINT_SERVICE.
• ABAP environment (SAP BTP and Public Edition developer extensibility): a Web API reaches external callers through the inbound service generated by the binding, added to a published communication scenario, and then a communication arrangement that an administrator creates.
• Versioning: adding another service definition to an existing binding creates the next service version, so changes reach new consumers without breaking existing ones.

A published service binding is a local endpoint; exposure to other systems is a separate configuration step.

1. Binding an SAP Fiori app to a Web API. The app loads but shows empty tables or default layouts, because Web API metadata contains no UI annotations. Create a UI binding.
2. Choosing OData V4 for a non-draft transactional app. SAP Fiori elements support on V4 is complete only with draft; enable draft or plan for gaps.
3. Changing a released service in place. Consumers break silently. Add a service version instead.
4. Assuming Publish means reachable. A remote caller still needs communication setup, and on-premise users need authorizations for the service.
5. Debugging the UI first. When a preview fails, check that the binding is active and published before touching annotations.

Most service binding problems come from choosing the wrong category or skipping a publishing step, not from the business object behind it.