All topics
52 / 65
Integrationbeginner

OData Services in SAP

The REST-based protocol SAP standardized on for exposing business data to Fiori, mobile apps, and external consumers.

OData is unavoidable in any modern SAP interview because it's the connective tissue between virtually every Fiori app and its backend, and interviewers ask about it to confirm a candidate understands both the protocol basics and how SAP-specific tooling (Gateway, RAP service bindings) generates and exposes these services in practice.

OData is like a restaurant menu with a standardized, universally understood ordering format ($filter, $select, $expand) that any customer (client app) can use to request exactly the dish variations they want, rather than every restaurant inventing its own completely custom ordering language that a hungry customer has to learn from scratch each time.

Key Concepts

1
OData (Open Data Protocol) is a REST-based protocol standardizing how to expose and consume queryable, CRUD-capable data over HTTP, built on top of familiar concepts (entities, resembling a table row; entity sets, resembling a table; associations/navigation properties linking related entities) with a service document listing available entity sets and a metadata document ($metadata) describing the full schema, letting generic client tooling (like SAPUI5) introspect the service and build appropriate UI without hardcoded knowledge of its structure. Standard query options are a big part of what makes OData genuinely useful over a plain custom REST API - $filter for conditions, $select for choosing specific fields, $expand for pulling in related entities in one round trip, $top/$skip for pagination, and $orderby for sorting - all supported generically by any compliant OData service without custom endpoint code for each variation.
$metadata$filter$select$expand$top
2
On the SAP implementation side, classic OData services (V2) are built via SAP Gateway using a Service Builder (transaction SEGW) that generates a model class with redefinable methods (GET_ENTITY, GET_ENTITYSET, CREATE_ENTITY, and so on) where a developer implements the actual data retrieval/manipulation logic, often by calling existing BAPIs or direct Open SQL. In S/4HANA, the more modern approach generates OData services directly and largely automatically from CDS view annotations and RAP business object service definitions/service bindings (discussed in the CDS and RAP topics), meaning far less manual Gateway-class coding is needed for standard scenarios - a good candidate should be able to contrast the two generations clearly.
SEGWGET_ENTITYGET_ENTITYSETCREATE_ENTITY
3
A senior-level answer covers OData V2 versus V4 differences (V4 is the current OASIS standard with richer capabilities like better batch/delta support and more standardized error handling, and is the version RAP services expose by default, while V2 remains extremely common for older or SAP GUI-Gateway-generated services and is still what many Fiori Elements apps consume), and mentions the /IWFND/MAINT_SERVICE transaction (activating and maintaining OData service registration/ICF nodes on the Gateway hub) as the everyday operational transaction for troubleshooting why a service isn't reachable.
/IWFND/MAINT_SERVICE
Use cases:odatagatewayrest-apifiori-backend