OData Query Options and Server Side Paging

OData query options are standard URL parameters ($top, $skip, $filter, $select, $expand, $orderby, $count or $inlinecount) that let a client shape a result set without a bespoke API for every list variant. The one structural fact that explains most confusion: whether these options are handled automatically depends entirely on whether the exposing business object is managed or unmanaged. For a managed RAP business object built on a CDS view entity, the framework translates $top/$skip/$filter/$orderby into a real database select, pushing offset and fetch to the database engine. For an unmanaged business object, the READ operation implementation receives the requested paging and filter information as part of the incoming request and has to apply it itself against whatever internal table or legacy call it is wrapping, including working out and returning the total count if $count was requested. Server side paging simply means a default page size applies when the client does not send an explicit $top, so an unbounded select never happens by accident, but that default is set independently at several layers.

Query option handling is not optional; it happens on essentially every list-returning OData operation, so the real decision is how much of it is built in versus hand coded. Rely on the framework's automatic handling whenever the underlying data comes from a CDS view entity a managed RAP business object can select from directly. Implement paging logic explicitly when building an unmanaged business object around legacy code, a remote-enabled function module, or a BAPI that returns a full internal table with no native offset concept. The wrong reflex is disabling or bypassing server side paging, or forcing an artificially large $top, to make a list report 'show everything' - that just moves the unbounded select into application memory and shifts the failure from a paginator glitch to a timeout or dump. Equally wrong is writing custom paging logic inside a managed business object; the framework already does this and a hand rolled version will conflict with it or simply be ignored.

Above this layer sits the OData consumer: a Fiori Elements list report deciding its growing threshold, or a freestyle UI5 list binding, both of which translate scroll or page-size settings into $top and $skip on the request. Below it sits the persistence: for managed RAP, the generated service adaptation layer converts the query options into a select against the CDS view entity, including pushing WHERE conditions from $filter and OFFSET/FETCH from $top/$skip to the database. For unmanaged RAP, that translation step does not exist and the developer's ABAP code stands in for it. This structure supersedes classic Gateway service implementation classes, where every entity set's paging, filtering and counting logic had to be written by hand in the DPC/MPC redefinition; CDS based exposure gets equivalent behavior generated for standard read and CRUD operations, leaving hand written logic only for genuinely non-standard sources.

A managed RAP business object exposes a read-only list report over sales order items via a CDS view entity. The UI, after the user scrolls, requests $top=30&$skip=60 with a filter and $count=true. Nothing is coded for paging on the managed side: the framework builds a select against the view with the filter turned into a WHERE clause, applies offset and fetch for the skip and top, and issues a separate count select to satisfy $count. Contrast the same business object built unmanaged, wrapping an existing function module that returns a full internal table. The READ operation implementation now has to read the paging information supplied on the request (offset and page size), slice the internal table returned by the function module accordingly, and if a count was requested and has not already been produced, run separate logic to determine the full count and set it explicitly on the response data. Skipping that last step is exactly why a UI paginator ends up showing an unknown or incorrect total - the OData layer only reports what the READ implementation tells it, nothing more.

On S/4HANA, exposing data through managed RAP business objects on CDS view entities is the supported, clean-core-aligned way to get correct query option and paging behavior without writing it by hand. Hand written paging logic in an unmanaged business object, or in a classic Gateway service implementation class, still works technically but is discouraged for anything a customer will extend or that needs to survive upgrades cleanly, because that logic lives outside the generated framework and has to be maintained manually release after release. Where an unmanaged wrapper around existing RFC-based logic cannot be avoided in the short term, the resulting paging and counting code should be tracked explicitly as technical debt rather than assumed to behave the same as a managed object.

The developer implements and tests paging and count logic, especially in unmanaged scenarios, and is responsible for verifying behavior at realistic data volumes, not just in a dev system with sample records. The architect decides managed versus unmanaged exposure and whether filter pushdown to the database is achievable given the underlying persistence. Functional consultants should specify expected list sizes during test planning so paging problems surface before go live rather than after.

Read rap-managed-versus-unmanaged-scenarios first to understand why the same query option behaves differently depending on the business object type. odata-v2-versus-odata-v4-for-sap-developers covers the $count versus $inlinecount and $expand differences referenced above in more depth. performance-of-nested-cds-views is directly relevant when $expand interacts badly with paging. fiori-elements-list-report-and-object-page explains the UI side that actually generates the $top and $skip values being discussed here.