Now accepting guest editorial from SAP, Oracle, Workday and ServiceNow practitioners.Pitch a guide
The Sign-Off Table

Lesson 4 of 5

Service exposure: definitions, bindings and OData V4

10 min

Listen to this lesson

0:00 / 9:06

A RAP BO is not usable from a browser until it is exposed as a business service. That takes two objects. The service definition says which entities are exposed, usually the projection views, and under which names. The service binding binds that definition to a protocol and a purpose. SAP's RAP documentation stresses the separation: one service definition can be bound several times, for example as a UI service and as a Web API, without re-implementing anything.

  1. Projection viewsZC_CMC_CoreAgreement and ZC_CMC_CoreAgreementItem, provider contract for transactional queries
  2. Projection BDEFuse create, update, action closeAgreement; no delete
  3. Service definitionZUI_CMC_COREAGREEMENT exposes ZC_CMC_CoreAgreement as CoreReturnAgreement and the item projection as CoreReturnItem
  4. Service bindingZUI_CMC_COREAGREEMENT_O4: binding type OData V4 - UI
  5. Activate and publishPublish the local service endpoint in the binding editor
  6. Preview and consumeFiori elements preview; later an app in the launchpad
Exposing Contoso’s core return BO as a Fiori UI service.
The Sign-Off Table · thesignofftable.com/academy/sap-abp-202

Projection views first

Before the service definition comes the projection. A CDS projection view is a special view entity based on another view entity; SAP's RAP guide describes projections as the ABAP-native way to adapt a data model for one business service. Contoso's ZC_CMC_CoreAgreement projects the root view, keeps only the fields Maria's team works with, redirects the composition to the item projection, and carries the UI annotations through its metadata extension. A second projection for a future integration could expose a different field set over the same BO, with its own projection BDEF, without touching the behavior pool. For testers, the projection is where "why is this field missing in the app" questions are usually answered.

Binding types

SAP documents OData version 2 and version 4 bindings for transactional and read-only services, InA for analytical data models with live access, and SQL for published SQL access. Each OData binding is either a UI service, whose metadata carries UI annotations for Fiori elements, or a Web API, which carries no UI-specific information and is meant for other consumers. SAP advises using OData V4 wherever possible for transactional services, and notes that full Fiori elements support for OData V4 UI services is only granted for draft-enabled scenarios. That is one reason Contoso's BDEF includes with draft.

One service definition can be bound more than once: a UI binding for Fiori elements and a Web API binding for other consumers, without new behavior code.
The Sign-Off Table · thesignofftable.com/academy/sap-abp-202
Feature (SAP’s comparison)Web APIUI service
UI annotations in metadataNoYes
Value helpNot availableAvailable
Side effectsNot availableAvailable
Feature controlNot exposedExposed
Typical consumerAnother system or appA Fiori elements app

How Web API and UI bindings differ, summarized from SAP’s OData exposure comparison.

Publishing, URLs and versions

A binding must be active before it can be published. Publishing the local service endpoint, with the Publish button in the binding editor, runs the steps that make the service consumable, and SAP notes it enables the service for the current system only. The binding editor shows the service URL: for an OData V4 binding such as Contoso's ZUI_CMC_COREAGREEMENT_O4 it starts with /sap/opu/odata4/ (OData V2 bindings use /sap/opu/odata/), followed by the binding path. The editor also offers a Fiori elements preview straight from the system. The service binding is a normal repository object, so it travels with the transport; how the published service is activated in follow-on systems such as CMQ and CMP depends on your release and landscape, so agree the steps with Basis early. For changes to an API's contract, SAP supports versions: adding a further service definition to a binding exposes a new version.

Publishing in CMD enables the service there only; the binding moves by transport, and the follow-on activation steps are agreed with Basis.
The Sign-Off Table · thesignofftable.com/academy/sap-abp-202
Internal UI serviceOData V4 UI binding; change with the app.
Internal integrationOData V4 Web API for a known partner system; version on breaking change.
UI with many users and rolesUI binding, draft enabled, careful feature control.
External or released APIWeb API with versioning; SAP lists C2 for released remote APIs.
Choosing a binding by who consumes the service and how stable it must be.
The Sign-Off Table · thesignofftable.com/academy/sap-abp-202

What would you do?

Grace's integration team wants the fleet portal to create core return agreements automatically. Kenji suggests adding a second binding to the existing service definition. What is the best binding choice?

Key points
  • A service definition says what is exposed; a service binding says how.
  • OData V2 and V4, InA and SQL are binding types; OData bindings are UI or Web API.
  • Use OData V4 for transactional services; full Fiori elements V4 support needs draft.
  • Publish the active binding; preview the Fiori elements app from the binding editor.
  • Version services when their contract changes.

Check your understanding · not graded

Lesson check

  1. 1. What does a service definition specify?

  2. 2. What does SAP note about full Fiori elements support for OData V4 UI services?

  3. 3. What must be true before a service binding can be published?

  4. 4. Which binding fits a known system that creates agreements automatically?