SAP Architect OData Gateway Interview Questions

OData Gateway is a standard block in SAP Architect interviews. It is rarely asked as a definition; it is asked as a situation you have to talk your way through.

Master SAP Gateway OData with SEGW, service registration, metadata, CRUD, filters, paging, deep entity, batch, debugging, error handling and Fiori integration.

This page carries 14 reviewed SAP Architect odata gateway interview questions, each with a complete written answer and no sign-in required. The set breaks down into 3 foundational, 6 mid-level and 5 advanced questions, so you can start at the top for a first interview or skip ahead to the scenario-based items for a senior round.

Treat the answers as a starting structure, not a script. Interviewers in SAP Architect rounds follow up on whatever you sound least certain about, so the value is in being able to keep going after the first answer.

14 OData Gateway questions with answers

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.

Related lesson

GET_ENTITY and Key Handling

Related topics

Next practice step