OData

OData describes business data as entity sets that clients address through URLs, with standard HTTP verbs for each operation:

• GET reads an entity set or a single entity, for example the purchase orders of Cedar Office Supply.
• POST, PATCH/PUT and DELETE create, change and remove entities.
• System query options such as $filter, $select, $expand, $orderby, $top and $skip let the client ask the server to filter, sort and page the data.
• `$metadata` returns the service's data model: entity types, properties, keys, associations and annotations.
• `$batch` bundles several requests into one HTTP call.

Because the model and the operations are standardized, a generic client such as the SAPUI5 OData model can bind controls to any compliant service without custom request code. OData is therefore a contract about how data is exposed, not a piece of business logic.

Once the SAP Fiori Launchpad has resolved a tile and started the app, data access follows the same path for every SAPUI5 or SAP Fiori elements app:

1. The app starts. The app descriptor names the OData service the app uses as its data source.
2. The app calls the service. The SAPUI5 OData model sends requests, often grouped in a $batch, to the service URL. On SAP S/4HANA, SAP Gateway checks that the user may start the service (authorization object S_SERVICE) and routes the request.
3. Business logic runs. The service implementation — CDS views, RAP behavior or SEGW-based code — applies validations and data authorizations.
4. The record is read or written. The response returns the data, or the change is saved to the business document, which can trigger follow-on processing such as a workflow.

A broken step shows up differently: a missing start authorization appears in SU53, while a service-side error appears in /IWFND/ERROR_LOG or /IWBEP/ERROR_LOG on-premise. Every data-driven SAP Fiori screen is, underneath, a sequence of OData requests.

Both versions coexist in SAP landscapes, and the version decides which tools and models apply:

RAP can expose the same business object as OData V2 or V4, and some newer SAP Fiori elements features are evaluated only with OData V4, while many delivered apps continue to run on V2. Choosing an OData version is a decision about tooling and app support, not only about protocol features.

SAP offers several ways to create an OData service, depending on platform and age of the codebase:

• RAP (ABAP RESTful Application Programming Model): a service definition selects CDS entities, and a service binding publishes them as OData V2 or V4, with category UI (carries UI annotations for SAP Fiori elements) or Web API (no UI-specific metadata).
• SEGW projects: the SAP Gateway Service Builder models entities and generates runtime classes for hand-written ABAP; common in older custom apps.
• CDS with `@OData.publish: true`: generates an OData V2 service from a CDS view; still documented for on-premise and Private Edition, while RAP service bindings are the newer approach.
• CAP on SAP BTP: service definitions in CDS served as OData, with V4 as the default and V2 available through an adapter.

The protocol on the wire is the same; the programming model behind it determines how logic, drafts and extensions are handled. A new OData service is best started in the programming model the target platform currently recommends.

• On-premise and Private Edition: administrators register and activate OData services on SAP Gateway, assign system aliases and maintain ICF nodes. The full set of Gateway transactions and logs is available.
• Public Edition: SAP operates the services behind the delivered SAP Fiori apps. Access to administration and monitoring tools is controlled rather than open as on-premise; external consumers call released APIs through communication arrangements, and custom services come from developer or key user extensibility.
• SAP BTP: apps call OData services on SAP BTP directly or reach on-premise services through destinations and the SAP Cloud Connector.

The OData protocol behaves the same everywhere; what changes is who activates the service and how a caller reaches it.

1. Treating a UI service as an integration API. A service built for one SAP Fiori app can change with the app. Integrations belong on released APIs or on services designed as Web APIs.
2. Over-fetching. Lists without $select or with deep $expand move far more data than the screen shows; check the requests in the browser developer tools.
3. Ignoring `$batch` when debugging. The browser shows one batch call; the failing operation is inside its response body.
4. Mixing versions in one app design. V2 and V4 use different SAPUI5 models and SAP Fiori elements stacks, so components rarely move between them unchanged.
5. Blaming the UI for authorization gaps. An empty list can be a data authorization filter in the service, not a frontend bug.

Most OData problems in SAP Fiori projects are design or authorization problems that only surface as protocol errors.