Service Bindings Part 1: From Business Object to OData Service

📌 KEY POINTS
✅ Chain: BO → projection → service definition → service binding → OData service.
✅ Service definition = WHAT is exposed; binding = HOW (protocol, UI/API).
✅ Expose projections (ZC_/ZA_), never base R_ views.
⚠️ One binding per protocol and consumer type.

▶ WHAT THIS SERIES COVERS
This series exposes the Purchase Request business object built in the Managed RAP series as an OData V4 service and a Fiori Elements app. You can follow it with any RAP business object, but the examples use ZR_PurchReq and its projection ZC_PurchReq (Managed RAP Part 5).

• Part 1 — the exposure chain and what a binding is
• Part 2 — create, activate, publish and test a binding in ADT
• Part 3 — moving bindings through DEV, QAS and PRD
• Part 4 — UI vs Web API bindings, OData V2 vs V4
• Part 5 — troubleshooting 404, 403, metadata and cache problems
• Part 6 — preview, metadata and Fiori Elements annotations

━━━━━━━━━━━━━━━━━━━━
▶ THE PROBLEM A SERVICE BINDING SOLVES
A RAP business object is ABAP: CDS views, a behavior definition and classes. A browser, a Fiori app or another system cannot call ABAP directly — they speak HTTP and OData. Something must decide which entities are visible, which protocol is used, and at which URL. That is the job of the last two objects in the RAP stack.

━━━━━━━━━━━━━━━━━━━━
▶ THE EXPOSURE CHAIN — FOUR OBJECTS, FOUR DECISIONS

1. Business object (ZR_PurchReq + BDEF) — WHAT the data is and what can happen to it. Built once, reused by all consumers.
2. Projection (ZC_PurchReq + projection BDEF) — WHICH fields and operations one consumer gets, plus UI annotations.
3. Service definition (ZUI_PURCHREQ) — WHICH entities form one service, and under which names. It is protocol-neutral: it lists "expose ZC_PurchReq as PurchaseRequest" and nothing about OData.
4. Service binding (ZUI_PURCHREQ_O4) — HOW and for WHOM the service is offered: the protocol (OData V2 or V4, and some other types), the purpose (UI or Web API), and the runtime registration that produces a URL.

The chain is one-directional: a binding points to exactly one service definition; one service definition can have several bindings (e.g. a V4 UI binding and a V2 UI binding during a migration).

━━━━━━━━━━━━━━━━━━━━
▶ WHAT THE SERVICE DEFINITION DOES

• Groups the root and child projections into one service. Everything the consumer navigates to must be exposed here — if ZC_PurchReqItem is not exposed, the Items navigation will not work.
• Gives each entity its external name (the entity set name in OData). Choose business-readable names; they appear in URLs and in client code.
• Contains no logic and no protocol settings.

━━━━━━━━━━━━━━━━━━━━
▶ WHAT THE SERVICE BINDING DOES

• Binds the service definition to a protocol and binding type.
• After activation, shows in ADT: the service version, the entity sets and their associations, and a Preview button per entity.
• After publishing (Part 2), registers the service in the OData runtime (SAP Gateway) so it gets a real URL, e.g. …/sap/opu/odata4/sap/zui_purchreq_o4/srvd/sap/zui_purchreq/0001/. Always copy the URL from the binding editor rather than typing it.

━━━━━━━━━━━━━━━━━━━━
▶ BINDING TYPES

• OData V4 – UI: for Fiori Elements and SAPUI5 apps. Includes UI annotations and supports draft. The default choice for new transactional apps.
• OData V4 – Web API: for system-to-system integration. No UI annotations; meant for stable programmatic contracts.
• OData V2 – UI and OData V2 – Web API: the older protocol version. Use only when a consumer requires V2 (older apps, some tools, some integration adapters).
• Some releases offer further types (for example InA for analytical queries or SQL for SQL-based access); they are outside this series.

Part 4 explains the choice in detail.

━━━━━━━━━━━━━━━━━━━━
▶ NAMING CONVENTION
A consistent pattern avoids confusion later:

• Service definition: ZUI_<object> for UI services, ZAPI_<object> for APIs.
• Service binding: the service definition name plus a suffix for protocol: _O4 (OData V4) or _O2 (OData V2). Example: ZUI_PURCHREQ_O4.

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP

1. Make sure the projection ZC_PurchReq, ZC_PurchReqItem and the projection BDEF are active (Managed RAP Part 5).
2. Right-click ZC_PurchReq → New → Service Definition. Name ZUI_PURCHREQ. Add both entities as in the code example. Activate.
3. Right-click ZUI_PURCHREQ → New Service Binding. Name ZUI_PURCHREQ_O4, binding type OData V4 – UI. Activate.
4. Look at the editor: the service version 0001, entity sets PurchaseRequest and PurchaseRequestItem, and the navigation between them. You will publish and test it in Part 2.

━━━━━━━━━━━━━━━━━━━━
▶ WHAT YOU HAVE AFTER PART 1
A clear mental model of the four layers and an active service definition and binding. Activation alone does not make the service callable in an on-premise system — that is the publish step in Part 2.

A developer finished a RAP business object and created a service definition that exposed only the root projection ZC_PurchReq. The binding activated without error, and the list page worked in preview. But the object page showed no Items section, and adding an item failed. The team spent a day checking the behavior definition and draft tables.
The cause was one missing line: ZC_PurchReqItem was not exposed in the service definition, so the _Item navigation had no target entity set in the service. Adding "expose ZC_PurchReqItem as PurchaseRequestItem;" and reactivating the definition and binding fixed it immediately.
Afterwards the team added a checklist item: every entity reachable through a composition must be exposed in the service definition.

• Thinking the service binding contains logic — it only publishes; behavior lives in the BDEF, fields in the projection.
• Exposing ZR_ base views instead of ZC_ projections.
• Forgetting to expose child entities, which breaks navigation and create-by-association.
• Using technical or cryptic external names in the service definition — they become part of every URL and client.
• Choosing OData V2 for a new app out of habit when V4 is the current standard.
• Assuming "activated" means "callable" — in on-premise systems the binding must also be published.

• Keep the chain clean: tables → ZR_ BO → ZC_ projection → service definition → binding.
• One service definition per use case (one app or one API), not one giant service for everything.
• Expose every entity of the composition tree the consumer needs.
• Use business names in the service definition and a consistent binding naming pattern (_O4 / _O2).
• Default to OData V4 – UI for new Fiori Elements apps; use Web API bindings for integrations.
• Copy the service URL from the binding editor instead of constructing it by hand.

Very common question: "What is the difference between a service definition and a service binding?" Answer: the service definition decides which projected entities form a service and their external names, independent of protocol; the service binding binds that definition to a protocol and purpose (OData V2/V4, UI or Web API) and registers it so it gets an endpoint. One definition can have several bindings.
Follow-ups: "What are the RAP layers from table to app?" (tables, BO, projection, service definition, service binding, consumer), and "Which binding type for a Fiori Elements app?" (OData V4 – UI, because it supports draft and UI annotations). Mentioning that activation and publishing are separate steps on-premise shows hands-on experience.