SEGW OData Modeling versus CDS-Based Service Exposure

SEGW is the Service Builder transaction where a developer models an OData service by hand: entity types, entity sets, associations, drawn manually, then generated into a model provider class and a data provider class. Fetch and transform logic is written as ABAP inside DPC_EXT redefinitions, usually calling BAPIs or reading tables directly. CDS-based exposure works the other way round: an existing CDS view entity carries annotations, either the older @OData.publish flag or a RAP service definition activated through a service binding, and the framework generates the service automatically from the view's fields and associations, with no data provider class needed for read scenarios. The one structural fact that explains most confusion: SEGW puts the mapping logic in imperative ABAP inside generated classes, while CDS exposure puts that logic in declarative metadata on the view itself. SEGW services take longer to build but tolerate arbitrary logic; CDS exposure is fast but is only as expressive as the view and its annotations.

Default to CDS-based exposure for any new development, especially list report and object page scenarios, because a service definition and binding plus a RAP behavior definition give read and write with very little handwritten code. Use SEGW only when maintaining an existing service already deployed on a system that predates RAP, when a consumer contractually depends on an already-shipped classic OData V2 service with no CDS equivalent, or on an ECC landscape without RAP tooling. Building a new SEGW service on a current S/4HANA system is almost always a mistake: it duplicates what a CDS view and behavior definition express more concisely, and it is the pattern explicitly discouraged under clean core guidance. If business logic genuinely cannot be expressed declaratively — heavy cross-system orchestration, unusual locking, mid-request calls to remote systems — the answer is normally an unmanaged RAP business object behind the CDS exposure, not a fallback to SEGW.

Below SEGW sit BAPIs, function modules or direct table reads invoked from DPC_EXT redefinitions. Below CDS-based exposure sit CDS view entities with their associations, plus a RAP behavior definition and implementation for anything beyond read. Above both sits the OData protocol layer — V2 only for SEGW-generated services, V2 or V4 for CDS-based ones — and then a Fiori Elements or freestyle UI consuming the service. SEGW services are registered through the IWBEP model and runtime and the service catalog. CDS-based services are registered through a service definition bound to a chosen OData protocol version in a service binding, generated straight from the annotated view. CDS-based exposure with RAP is the object model that supersedes SEGW for anything transactional going forward; SEGW is not receiving new capability and is treated as the legacy path in current landscapes.

A consultant needs a read-only list of purchase requisitions, header plus items, for a Fiori list report. With SEGW: model an entity type in the Service Builder matching a custom structure, generate the runtime artifacts, then write a GET_ENTITYSET redefinition in the DPC_EXT class that selects from the requisition tables, applies the filters arriving as OData query options, and maps the result field by field into the generated structure. With CDS-based exposure: build a CDS view entity selecting from the requisition header table with an association to items, then either annotate it with @OData.publish: true or, in RAP style, expose it through a service definition and activate that definition for OData V2 or V4 in a service binding. Filtering, sorting and paging on exposed fields work without any handwritten ABAP, because the generated service delegates straight to the view's SQL. The CDS route produces a working service in a fraction of the lines; the only logic written is inside the view definition itself — associations, access conditions — rather than inside a data provider class.

On S/4HANA, CDS-based exposure through RAP is the recommended path and, for extensibility purposes, effectively the only sanctioned one for new service development. SEGW still runs and existing generated services keep functioning, but building new SEGW services is discouraged under clean core principles, since the generated data provider classes sit outside the released API surface and complicate future upgrades. Moving an existing SEGW service to CDS-based exposure is not a mechanical conversion: it usually means re-modeling the entity as a CDS view and, for anything beyond read, building a RAP behavior definition and implementation from scratch, then repointing the consuming UI's service binding at the new service.

This is primarily a build-time developer decision, but an architect should set a landscape-wide standard so individual developers are not each re-deciding SEGW versus CDS project by project. Functional consultants get pulled in when annotations need to carry business semantics such as currency conversion, unit handling or value help. A handover should record the service definition or SEGW service name, the OData protocol version, and which underlying tables or CDS views back it.

Read service-definition-and-service-binding-in-rap for the mechanics of the CDS-based activation path that supersedes SEGW's model provider class. Read cds-view-entities-versus-classic-cds-ddic-views for the modeling choice sitting underneath any CDS-based service. Read odata-v2-versus-odata-v4-for-sap-developers since SEGW is fixed to V2 while CDS-based exposure can target either. Read rap-managed-versus-unmanaged-scenarios to understand what replaces hand-written DPC create and update logic. Read cds-annotations-and-where-they-take-effect for how @OData.publish and related annotations actually drive generation.