Service Definitions Part 1: What a Service Definition Does

📌 KEY POINTS
✅ A service definition lists WHICH entities a service exposes: define service … { expose … as …; }.
✅ It contains no logic and no protocol — the binding decides OData V2/V4, UI or API.
✅ Expose projection views (ZC_/ZA_), not base R_ views or tables.
⚠️ Entities not exposed are invisible to consumers — including navigation targets.

━━━━━━━━━━━━━━━━━━━━
▶ WHAT THIS SERIES COVERS

• Part 1 — what a service definition does (this lesson)
• Part 2 — exposing projections as a business service
• Part 3 — API boundary, naming and versioning
• Part 4 — troubleshooting activation and exposure gaps
• Part 5 — UI vs integration APIs: one service or two?
• Part 6 — exposing multiple entities, navigation and value helps

Next topic after this series: Service Bindings.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE IT SITS
Table → CDS base view (ZR_) + BDEF → projection (ZC_) + projection BDEF → SERVICE DEFINITION → service binding → OData service → Fiori app / API client.
The service definition is the first object that answers the consumer's question: "what can I access in this service?"

━━━━━━━━━━━━━━━━━━━━
▶ WHAT IT CONTAINS
define service ZUI_PURCHREQ {
expose ZC_PurchReq as PurchaseRequest;
expose ZC_PurchReqItem as PurchaseRequestItem;
}

• "expose <CDS entity> as <alias>" — each exposed entity becomes an entity set in OData.
• The alias is the name consumers see — choose business names.
• Optional header annotations like @EndUserText.label.

━━━━━━━━━━━━━━━━━━━━
▶ WHAT IT DOES NOT CONTAIN

• No behavior — operations come from the projection BDEF.
• No UI — layout comes from annotations/metadata extensions.
• No protocol or URL — that is the service binding (OData V2/V4, UI/Web API).
• No authorization — handled by the BO, CDS access control and roles.

━━━━━━━━━━━━━━━━━━━━
▶ WHY IT IS A SEPARATE OBJECT
One service definition can be bound several times (e.g. V4 UI and V4 Web API bindings), and several service definitions can reuse the same projections. Keeping "what" (definition) and "how" (binding) separate lets you change the protocol without touching the content.

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

1. In ADT, right-click ZC_PurchReq → New → Service Definition.
2. Name: ZUI_PURCHREQ, description "Purchase Request UI service".
3. Expose the root and item projections with business aliases (code example).
4. Activate. Next step: create the binding (Service Bindings Part 2).

✅ CHECKPOINT: you can write a service definition and explain its role in one sentence: it defines the content of a service, nothing else.

A new team member was asked to "add OData V2 for the old UI5 app" and started copying the whole service definition, projections included. The lead explained that the service definition only describes content; the protocol is a binding property.
He created a second binding (OData V2 – UI) on the existing ZUI_PURCHREQ definition — ten minutes of work, no duplicated objects, and both apps received exactly the same entities.

• Exposing base R_ views instead of projections.
• Expecting the service definition to control operations or UI.
• Copying service definitions just to change the protocol.
• Technical aliases (ZC_PURCHREQ) instead of business names.
• Forgetting to expose child or navigation target entities.

• One service definition per business service and consumer type.
• Expose only projections, with business aliases.
• Keep protocol decisions in bindings.
• Label the service definition with @EndUserText.label.
• Name consistently: ZUI_… for UI services, ZAPI_… for APIs.

Questions: "What is a service definition?", "Service definition vs binding?", "What can be exposed?"
Strong answer: a service definition lists the CDS entities (projections) exposed by a service, with aliases; it has no behavior, UI or protocol — the binding defines protocol (OData V2/V4) and type (UI/Web API). One definition can have several bindings. Base views and tables should not be exposed.