OData V4 Part 2: Publishing a RAP Service with an OData V4 Binding

📌 KEY POINTS
✅ Binding type decides the consumer: OData V4 – UI (Fiori) or OData V4 – Web API (integrations).
✅ Activate + Publish is required; the binding shows the service URL.
✅ Every write request needs a CSRF token (fetched with a GET) — except in some API setups with other protection.
⚠️ 403 on POST is usually a missing CSRF token, not missing authorization.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Part 1 explained the contract. Now you make the service available and call it. (Service Bindings Part 2 covers the binding object in ADT; this lesson focuses on the OData V4 side and first calls.)

━━━━━━━━━━━━━━━━━━━━
▶ 1. CREATE AND PUBLISH THE BINDING

• Right-click the service definition ZUI_PURCHREQ → New Service Binding.
• Name ZUI_PURCHREQ_O4, binding type "OData V4 – UI".
• Activate, then click Publish (on-premise, this publishes the service locally; in cloud systems publishing is part of the binding lifecycle).
• The binding shows the service URL, the service versions and the entity sets with a Preview button.

━━━━━━━━━━━━━━━━━━━━
▶ 2. URL ANATOMY
/sap/opu/odata4/sap/zui_purchreq_o4/srvd/sap/zui_purchreq/0001/

• /sap/opu/odata4 — OData V4 handler
• zui_purchreq_o4 — binding (lower case)
• srvd — UI binding path segment (Web API bindings use srvd_a2x)
• zui_purchreq/0001 — service definition and version

━━━━━━━━━━━━━━━━━━━━
▶ 3. SERVICE VERSIONS
A V4 binding can contain several versions (0001, 0002) based on different service definitions. Use a new version for breaking changes (Service Definitions Part 3).

━━━━━━━━━━━━━━━━━━━━
▶ 4. FIRST CALLS FROM A REST CLIENT
Tools: browser (GET only), Postman/Insomnia, VS Code REST Client, or the ADT HTTP client.

• GET the service root with basic authentication or your SSO setup.
• For writes, first GET with header "X-CSRF-Token: Fetch"; the response returns a token and a session cookie.
• Send POST/PATCH/DELETE with "X-CSRF-Token: <token>" and the same cookies.
• Content-Type: application/json.

━━━━━━━━━━━━━━━━━━━━
▶ 5. DRAFT-ENABLED UI SERVICES
In a UI service with draft, a POST to the entity set creates a DRAFT (IsActiveEntity=false). To get active data you must call Activate (Part 4). For integrations, use a Web API service without draft (Service Definitions Part 5).

━━━━━━━━━━━━━━━━━━━━
▶ 6. AUTHORIZATION
The user needs a role with the service (start authorization for the OData service, typically via the IAM app/catalog in cloud or roles with S_SERVICE on-premise) plus the BO's own authorization objects.

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

1. Create and publish ZUI_PURCHREQ_O4.
2. Copy the URL; GET $metadata in the browser.
3. In a REST client: fetch CSRF token, create a request (code example), read it back.
4. Try the same POST without token → 403; add token → 201.

✅ CHECKPOINT: you can publish a V4 service and call it with any HTTP client. Part 3 goes deeper into CRUD payloads.

An integration developer reported "403 Forbidden" for every POST to a new RAP service and requested more authorizations. The basis team added roles twice without effect. GET requests worked fine.
The response body actually said "CSRF token validation failed". The client never fetched a token. After adding the token fetch (GET with X-CSRF-Token: Fetch, then reuse token and cookies), all writes succeeded. The team documented the difference between a CSRF 403 and an authorization 403 in their integration guide.

• Activating the binding but not publishing it.
• Using the UI binding for integrations and getting drafts instead of active data.
• Sending writes without CSRF token or without the session cookie.
• Misreading a CSRF 403 as missing authorization.
• Wrong URL segment (srvd vs srvd_a2x) or version.
• Testing only in the browser, which cannot send writes.

• One binding per consumer type: V4 UI for Fiori, V4 Web API for integrations.
• Document the service URL, version and authentication for consumers.
• Always implement CSRF handling in custom clients.
• Test with a REST client and keep request collections in the repository.
• Check the response body before changing authorizations.

Questions: "How do you publish a RAP OData V4 service?", "What does the service URL consist of?", "Why do POST requests fail with 403?"
Strong answer: create a service binding (V4 UI or Web API) on the service definition, activate and publish; the URL contains the V4 handler path, binding, service definition and version (srvd for UI, srvd_a2x for Web API). Writes need a CSRF token fetched via GET with X-CSRF-Token: Fetch and sent back with cookies; distinguish CSRF 403 from authorization 403 via the response body. UI services with draft create drafts on POST.