ERPClimb logoERPClimb
Login
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.

24 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. A CustomerSet entity was created by importing KNA1 directly, exposing 180 technical fields like KUNNR and LAND1. What is wrong with this design and how would you model it?

The service contract now mirrors a database table: clients depend on technical names, receive far more data than needed, and any table change leaks into the API. An OData entity should model the business object the consumer needs. I would create a DDIC structure (or CDS view) with the 10–15 fields the app needs, give business property names (Customer, CustomerName, Country), mark the key, import it as entity type Customer with entity set CustomerSet, regenerate, and put mapping in DPC_EXT. Changes to KNA1 then no longer break consumers.
easyOData Gateway

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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

12. 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.
mediumOData Gateway

13. A service works in /IWFND/GW_CLIENT on the backend but fails from the Fiori launchpad on the frontend server with "No system alias found". What is happening?

This is a hub deployment problem, not a code problem. The service is registered on the frontend server, but the registration has no (or the wrong) system alias pointing to the backend RFC destination. The backend test works because it runs locally. I would open /IWFND/MAINT_SERVICE on the frontend, check the service's system alias assignment, verify the RFC destination in SM59 (trusted, so the user's identity passes to the backend) and check S_SERVICE for the users. I document aliases per tier so transports do not repeat the issue.
mediumOData Gateway

14. A sales order service uses MESSAGE e001(zsales) for validation in DPC_EXT. Fiori users get a short dump or a generic error. How do you fix error handling?

MESSAGE type E in an HTTP request is not a UI dialog — it terminates processing and the client gets a technical error. Business validation must raise /IWBEP/CX_MGW_BUSI_EXCEPTION with the message container. I would add the T100 message with lo_msg->add_message( iv_msg_type = 'E' iv_msg_id = 'ZSALES' iv_msg_number = '001' ), pass BAPI RETURN tables via add_messages_from_bapi, raise the busi exception (HTTP 400, leading message plus errordetails), keep technical exceptions for real technical failures, and send success messages in the sap-message header.
mediumOData Gateway

15. A stable SEGW OData V2 API is used by three external partners. A new architect wants to rewrite it in RAP "because SEGW is old". How do you evaluate this?

SEGW remains supported; a working partner API has real value and every rewrite risks breaking consumers (property names, formats, error structures, V2 vs V4 differences). I would only rewrite with a business reason — major new functionality, a move to ABAP Cloud, or unfixable limits. Before any change I inventory consumers and contract details. My recommendation would be: keep the SEGW API, build new apps and APIs in RAP, and if a RAP version is needed later, run both in parallel with a migration window for partners.
mediumOData Gateway

16. A Fiori list shows customers correctly, but the object page is empty for every customer. The list returns Customer = '12345'. What is likely wrong?

A key format mismatch between list and single read. KNA1-KUNNR is stored with leading zeros ('0000012345'); the list mapping applied an output conversion, so it returns '12345', and GET_ENTITY selects KUNNR = '12345', which does not exist. Fix: return keys in internal format (let the UI format them) and in GET_ENTITY apply CONVERSION_EXIT_ALPHA_INPUT or use get_converted_keys; share one mapping method for list and single reads; return 404 (resource_not_found) instead of an empty 200 when nothing is found.
mediumOData Gateway

17. A developer proposes adding @OData.publish: true to a CDS view to quickly expose it. What do you advise on a current S/4HANA system?

@OData.publish was an early shortcut that generates a service from a CDS view; it is considered obsolete and offers limited control (read-only without BOPF, older V2 generation). On current S/4HANA releases I would use RAP instead: the CDS view entity as data model, a service definition exposing it and a service binding (OData V2 or V4, UI or Web API). That gives framework-handled filter, paging, $count and $expand, a clean path to transactional behavior later, and alignment with SAP's strategic model. On old releases where RAP is not available, SEGW with a referenced CDS data source is the alternative.
mediumOData Gateway

18. A service works when you test it in the Gateway client, but fails when called from the Fiori app. How do you find the difference?

I capture the exact request the app sends: browser F12 network tab or /IWFND/TRACES payload trace for the user. Differences are usually in the URL (filters, key format, $expand), headers or payload, or the user (authorizations, different roles). Then I check /IWFND/ERROR_LOG and /IWBEP/ERROR_LOG, replay the captured request in the Gateway client as the same user, and set an external breakpoint in the relevant DPC_EXT method for that user in the backend. After the fix I switch the trace off.
mediumOData Gateway

19. A Fiori order-entry app makes 12 sequential calls to create one order (header, then each item, then texts). Saves are slow and sometimes leave half-created orders. How would you redesign the service?

Two problems: many round trips and no atomicity. I would support deep insert: an association SalesOrder → ToItems (and texts), a deep type in MPC_EXT with components named like the navigation properties, and CREATE_DEEP_ENTITY reading the whole payload and calling one BAPI for header and items, with rollback on any error. The UI then sends one POST. Where several independent changes must go together, they go into one $batch changeset, which succeeds or fails as a unit — without COMMIT WORK in my code inside the changeset. Result: one round trip and no partial orders.
mediumOData Gateway

20. A customer portal's CREATE_ENTITY inserts sales order data directly into VBAK and VBAP. What are the risks and what should it do instead?

Direct inserts into SAP standard tables bypass all business logic: no pricing, availability, credit, partner determination, number ranges, change documents, status or follow-on integration — data becomes inconsistent and unsupported by SAP. CREATE_ENTITY must read the payload with read_entry_data, validate, then call the released API (BAPI_SALESORDER_CREATEFROMDAT2 or a released RAP API), check RETURN, commit with BAPI_TRANSACTION_COMMIT outside changesets or roll back, and return the created entity with the new number. Logic should sit in a reusable class, keeping DPC_EXT thin.
mediumOData Gateway

21. After transporting a changed OData service to QA, the Fiori app fails with "Property DeliveryDate not found" although the code is correct. What do you check?

First I open $metadata in QA: if DeliveryDate is missing, the model is outdated there. Typical causes: stale metadata caches on backend and frontend, the transport missing the regenerated MPC, or the frontend registration not transported/activated. I clean caches with /IWBEP/CACHE_CLEANUP and /IWFND/CACHE_CLEANUP (or Cleanup Cache in MAINT_SERVICE), check that MPC/MPC_EXT versions match DEV, verify the service registration and ICF node, then retest with saved Gateway client test cases. I add cache cleanup to the post-transport checklist.
hardOData Gateway

22. 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

23. An invoice list service returns every billing document when no filter is sent and times out in Fiori. How do you fix it?

The service reads without scope and pages in memory. I would push filters into the database (ranges from it_filter_select_options in WHERE), apply ORDER BY with the key plus UP TO top+skip ROWS, and return inlinecount via COUNT(*) with the same WHERE. Additionally I require a meaningful scope: e.g. a mandatory date or company code filter in the UI (selection field required) and a server-side rule that rejects or defaults unscoped requests. Filters are never concatenated from raw filter strings into SQL.
hardOData Gateway

24. Users scrolling a Fiori list see some orders twice and others never. The service implements $top/$skip. What is the cause?

Paging without a deterministic sort. Each page is a separate request with a different $skip; if the SELECT has no ORDER BY (or orders by a non-unique field like date), the database may return rows in a different order per request, so pages overlap or skip rows. Fix: always ORDER BY the requested $orderby fields plus the full key as tie-breaker, apply the sort before cutting the page (in the database), and never sort in memory after UP TO has already limited rows.

Practise by experience level

Fresher1-3 years4-7 years8-12 yearsArchitect

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

Practise these questions with Interview AITake a mock test

Related SAP interview topics

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