Explain OData Services in SAP in SAP

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 the protocol between almost every Fiori app and its backend. It is REST with a standard query language and a machine-readable schema.

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

The vocabulary.

    entity           one record, like a table row
    entity set       a collection, like a table
    navigation       a link to related entities
    $metadata        the full schema, as a document

$metadata is what makes generic tooling possible. A client fetches it and learns every entity, field, type and relationship. SAPUI5 uses this to build tables and forms without being told the structure — which is exactly how Fiori Elements generates a screen.

$metadata

A hand-written REST API has no equivalent, which is why every client of one needs bespoke code.

Query options do the work you would otherwise write endpoints for.

    /SalesOrders?$filter=Status eq 'OPEN'
                &$select=OrderId,CustomerName
                &$expand=Items
                &$orderby=CreatedAt desc
                &$top=20&$skip=40

One service answers all of these. Without them you would be building /orders/open/by-customer/sorted?page=3 and a new endpoint for each variation.

/orders/open/by-customer/sorted?page=3

Two generations of building them in SAP.Classic Gateway (SEGW). You model the entities in Service Builder, and it generates a class with methods to redefine:

SEGW

    GET_ENTITYSET    read a list
    GET_ENTITY       read one
    CREATE_ENTITY    create

You write the retrieval yourself, often calling a BAPI or Open SQL. Full control, and a lot of code for a standard case.

CDS and RAP. The service is generated from annotations and a service binding. No handler class for ordinary scenarios:

    CDS view + annotations -> service definition -> service binding -> OData

This is the S/4HANA approach, and the contrast between the two is a common question.

V2 against V4. V4 is the current OASIS standard, with better batching, delta support and standardised errors, and it is what RAP exposes by default. V2 is still everywhere, because Gateway generated it for years and many Fiori Elements apps consume it.

The operational transaction. /IWFND/MAINT_SERVICE registers and activates a service on the Gateway hub. A service that exists in the backend and was never activated there returns 404, and that is the first thing to check when an app reports that its service cannot be found. The Gateway error log (/IWFND/ERROR_LOG) carries the real message behind most others.

/IWFND/MAINT_SERVICE/IWFND/ERROR_LOG

What the interviewer is probing.1. "How would you build an OData service today?" Probing: currency. Stalls: "With SEGW." Moves up: from a CDS view with RAP or OData annotations; SEGW with DPC classes is the legacy path.

2. "What is the difference between V2 and V4?" Probing: the detail. Stalls: "The version." Moves up: V4 is leaner with better batch, deltas and a richer query language — and Fiori elements V4 apps require it.

3. "Why does $expand matter for performance?" Probing: the practical point. Stalls: "Nothing." Moves up: it fetches related entities in one round trip instead of many, which is what makes a list-plus-detail screen fast.

4. "How do you debug a slow OData call?" Probing: the method. Stalls: "Read the code." Moves up: the gateway trace and performance trace in /IWFND/TRACES, then the underlying CDS or SQL — usually the data provider, not the protocol.