OData · SAP Gateway

SAP OData Interview Questions

OData interviews split candidates into two groups fast: those who have only consumed a service from a Fiori app, and those who have built and debugged one. The questions below are drawn from ERPClimb's reviewed bank and are written for the second group — but they are exactly what the first group gets asked.

Expect the mechanics first: entity types and entity sets, the metadata document, query options like $filter and $expand, and how CRUD maps to the generated provider classes. Then the scenarios: a service that returns 500 with no message, a breakpoint that never stops, a list service that dies on real data volumes, a key that cannot find a material that obviously exists.

Every answer keeps the order that works in a real interview — what you would check, in which tool, and what that result would tell you next. Naming the right error log without being prompted is worth more than any definition.

What interviewers actually probe

Error analysis under pressure

The classic scenario is a failing call with a useless message. Interviewers listen for the frontend versus backend error logs, replaying the request, and checking service registration before touching code.

Performance on real volumes

A list service that is fast in testing and slow in production is a near-guaranteed scenario. Server-side paging, selective fields, and pushing filters to the database are the expected direction.

Why your breakpoint does not stop

Gateway calls do not run in your dialog session. Being able to explain external breakpoints and runtime users separates candidates who have debugged a live service from those who have not.

Conversion exits and keys

The 'material exists but the service says not found' question tests whether you remember that keys arrive in external format and need conversion before the SELECT.

14 questions with full answers

Ordered from foundational to advanced. No sign-in required.

easyOData Gateway

1. What is OData?

First, I would define OData as an OASIS standard for building RESTful HTTP APIs, especially in SAP where it is commonly used to expose business data in a consistent way. The key starting point is the metadata document, $metadata, because it describes the service structure, entity types and available operations so consumers can understand the API without bespoke documentation. What makes it strong is the standard HTTP-based approach with CRUD verbs and query options such as $filter, $select and $expand, which let clients read only the data they need and navigate related data efficiently. A strong candidate would also mention that OData improves interoperability because the same conventions are understood by different clients and tools.
easyOData Gateway

2. What is SEGW?

SEGW is the SAP Gateway Service Builder transaction used to model an OData service and generate the related runtime artefacts. A good first step is to define the service structure, entities and relationships there, because that determines how the service will be exposed and consumed. It also generates the framework objects needed for implementation, including the data provider extension class, where CRUDQ logic is typically coded. A strong candidate adds that SEGW is mainly for design-time modelling and initial implementation support, while the actual business data handling is implemented in the generated extension class.
mediumOData Gateway

3. How do you implement $filter on an entity set?

First, redefine the entity set’s GET_ENTITYSET method and inspect io_tech_request_context->get_filter( ) to see what the consumer actually sent. This is important because $filter is only effective if you translate the filter tree correctly into your data selection logic. In a simple case, you can map the conditions into WHERE clauses and select only the matching records; alternatively, if the entity set is backed by a CDS view, you can pass the filtering down to the CDS-based retrieval. After that, fill et_entityset with the filtered result set and make sure the response reflects only the requested rows. A strong candidate also mentions handling complex filter expressions consistently and keeping the implementation efficient by pushing filtering down as far as possible.
mediumOData Gateway

4. A Fiori app calls your OData service but your breakpoint is not stopping. What would you check?

First, I would confirm I am using an external breakpoint, because a normal session breakpoint will not stop an OData request coming from the browser. Then I would verify the breakpoint is set for the actual runtime user that the Fiori app is using, since the technical or dialog user may differ from the user I am logged in with. I would also check that the request really reaches the backend system and that the service is registered correctly, because an issue in the front-end, gateway, or service activation can prevent the code from being hit at all. Finally, I would make sure I am debugging the correct DPC_EXT method, as the request may be handled in a different read, create, update, delete, or query implementation than expected. A strong candidate also checks the browser request and gateway error logs to confirm the exact call path.
mediumOData Gateway

5. An OData list service is slow and returns thousands of records. How would you improve it?

First I would check the service call pattern to see whether the consumer is requesting too much data, then apply paging with $top and $skip so the backend only returns a manageable result set. I would map the available filters properly and, if the business allows it, enforce mandatory filters to avoid unbounded reads. I would also use $select to return only the fields really needed, because reducing the payload improves response time and network load. The key performance point is to push filtering down into Open SQL instead of reading everything into ABAP and filtering there. A strong candidate would also mention avoiding huge payloads altogether and validating the service with realistic test volumes.
easyOData Gateway

6. What is the difference between entity type and entity set in OData?

First check the OData model definition in SEGW: an entity type describes the structure of one business object, for example Customer with properties such as CustomerId and Name. It is the blueprint for the data. An entity set is the addressable collection of that entity type, such as CustomerSet, and is what the service exposes for reading or changing multiple records. The key distinction is that the type defines what one record looks like, while the set defines where that record can be accessed in the service. A strong candidate also mentions that entity sets are used in requests and navigation, whereas the entity type is the underlying model definition.
mediumOData Gateway

7. What is a deep insert?

A deep insert is a single POST request that sends a parent object together with its related child items in one JSON payload. The first thing to check is that the service is designed for nested data and that the backend can interpret the structure correctly. In implementation, GET_ENTITY and CREATE_DEEP_ENTITY must be able to process the payload and create the related records as one logical unit. This matters because the entire operation should behave transactionally, so either all parts are saved successfully or the request is rejected. A strong candidate adds that deep insert reduces multiple round trips and is useful when header and item data belong together.
hardOData Gateway

8. A material detail service returns not found for material 12345, but the material exists in SAP. What could be wrong?

First check the key that comes from IT_KEY_TAB and compare it with the format stored in SAP. A very common reason for a material detail service returning not found is that the external material number 12345 is being used directly, while the database stores the value in internal format with leading zeros. The service should convert the key before the SELECT, using the proper conversion exit such as ALPHA_INPUT or the standard material conversion logic. This matters because a direct database read with the external value will not match any record even though the material exists. A strong candidate would also mention checking whether the service implementation reads the right key field and whether the conversion is applied consistently before any lookup.
hardOData Gateway

9. How do you design a maintainable SEGW OData service?

First I keep the SEGW entity model as simple and stable as possible, with clear relationships and only the fields the consumer really needs. I then implement the DPC_EXT methods in a clean, focused way and avoid putting heavy business logic there. Instead, I move reusable processing into service classes so the OData layer stays thin and easier to test and enhance. I also make sure filters and paging are supported properly, because that keeps the service performant and predictable for large data volumes. Strong candidates also handle errors with Gateway exceptions so consumers get controlled messages, check authorisation early, and avoid direct updates to standard tables for business documents, using the proper application logic instead.
mediumOData Gateway

10. Where do you check errors for a failing OData service?

First I would identify whether the failure is happening in the Gateway front end or in the backend, because that tells me where to start tracing the issue. For front-end or hub-related errors I check /IWFND/ERROR_LOG, and for backend processing issues I check /IWBEP/ERROR_LOG. If I need to validate the payload or reproduce the call, I use /IWFND/GW_CLIENT to replay the request. I also check ST22 for short dumps, SU53 for authorization problems, and confirm the service is correctly registered in /IWFND/MAINT_SERVICE. A strong candidate adds that they correlate the logs with the exact request time and understand whether the issue is configuration, authorisation, or application logic.
mediumOData Gateway

11. OData call returns 500 error with no useful message. What do you check?

First I check the runtime logs in both places: /IWFND/ERROR_LOG on the frontend and /IWBEP/ERROR_LOG on the backend, because they usually reveal the actual exception and stack trace behind a generic 500. If that is still not enough, I switch on /IWFND/TRACES to capture the full request and response flow and see where the failure occurs. I also confirm the OData service is activated correctly in /IWFND/MAINT_SERVICE and in the hub setup, since an inactive or inconsistently activated service can surface as a 500 with little detail. A strong candidate also checks whether the error is reproducible with the same user and payload, so the root cause can be isolated faster.
hardOData Gateway

12. External partner requires OAuth2 on OData. Approach?

First check whether the OData service is exposed directly in SAP Gateway or through API Management, because that decides where authentication is enforced. For a direct Gateway setup, enable and secure the relevant SICF node, then configure OAuth2 in the Gateway so the external partner authenticates with a client and token flow rather than basic user credentials. The key is to align OAuth2 scopes with the Gateway user roles so the token only allows the intended business access. If API Management is in the landscape, it can terminate or mediate the OAuth2 flow before forwarding to Gateway. A strong candidate also mentions rotating client secrets on a regular schedule and monitoring token issuance and usage with /IWFND/STATS to spot authentication or consumption issues early.
hardOData Gateway

13. OData service is slow for large lists. Options?

First check where the time is spent: payload size, database access, or UI round-trips. For large lists, enable server-side paging with $top and $skip so the backend returns only the requested slice, which reduces processing and network load. If the list needs totals or grouping, push aggregation into CDS with parameters so the database does the work instead of ABAP. Also cache metadata because repeated metadata fetches add avoidable latency. A strong candidate would also avoid $expand on high-cardinality navigations, as it can multiply the result set, and use $batch for related requests to reduce round-trips while keeping the response manageable.
hardOData Gateway

14. When would you pick RAP over SEGW?

I would pick RAP first on S/4HANA when the underlying data model can be expressed cleanly with CDS. I would check whether the requirement fits a standard CRUD-style service with managed semantics, because RAP gives you V4 semantics, less boilerplate, and a cleaner development model. That also makes it a stronger choice for native cloud scenarios. I would keep SEGW for ECC, or for cases where the service must expose complex non-CDS logic that does not map well to CDS-based design. A strong candidate also adds that the choice is driven by fit to the data model and runtime semantics, not just personal preference.

Practise by experience level

Fresher1-3 years4-7 years8-12 years

The questions above are tagged by the experience levels they are normally asked at, so the same page works for a first interview and for a lead-developer round.

SAP OData Interview Questions FAQ

What is the difference between V2 and V4 OData in SAP?

V2 is the SAP Gateway generation exposed through SEGW with hand-implemented provider methods; V4 is the standard-aligned generation that RAP services produce. V4 tightens the protocol — cleaner expand and filter semantics, leaner metadata — and, in SAP terms, signals that the service comes from a behaviour definition rather than a legacy project.

An OData call returns 500 with no useful message. What do you check?

The error logs before the code: the frontend Gateway error log for requests that never reached the backend, the backend error log for ones that did, then replay the request in the Gateway client to reproduce it under your own control. Only after that do breakpoints and dumps earn their place.

How do you make a slow list service faster?

Move work to the database and shrink the payload: server-side paging with $top and $skip, $select for only the fields the UI shows, filters translated into the underlying selection instead of applied in ABAP afterwards, and care with $expand on high-cardinality associations.

What is a deep insert and when is it used?

A single create call whose payload contains a header and its items together, so the consumer creates a document in one request. The backend must handle the nested structure in one logical unit of work — interviewers probe whether you understand the consistency requirement, not just the payload shape.

Why does a service return not found for a material that exists?

Almost always a conversion-exit problem: the key arrives in external format while the database stores the internal one, so the selection misses. The fix is converting the incoming key — the debugging skill is recognising the symptom before rewriting the query.

Next practice step

Related SAP interview topics

ERP Climb is an independent educational platform and is not affiliated with SAP SE.