Now accepting guest editorial from SAP, Oracle, Workday and ServiceNow practitioners.Pitch a guide
The Sign-Off Table

Lesson 2 of 5

Creating services

10 min

Listen to this lesson

0:00 / 7:13

An OData service in SAP S/4HANA comes from one of three places: SAP delivers it as a released API or as the back end of an SAP Fiori app; a developer builds it with the older model-based approach; or a developer builds it with the ABAP RESTful Application Programming Model (RAP). Knowing which kind you are dealing with tells you how it was built, how it is activated and what can break.

  1. ClassicSAP Gateway Service Builder (SEGW)Model the entities, generate runtime classes, implement read and write methods in ABAP; OData V2
  2. TransitionalCDS views with the OData publish annotationA CDS view exposed directly as a V2 service; used in the earlier programming model for SAP Fiori
  3. CurrentRAPCDS data model, behavior definition, service definition and service binding; V2 or V4, recommended for new development
How OData services have been built on the ABAP platform. All three exist side by side in a converted system.
The Sign-Off Table · thesignofftable.com/academy/sap-int-202

Model-based services with SEGW

In the classic approach a developer creates a project in the SAP Gateway Service Builder (SEGW), defines entity types and entity sets, and generates runtime artifacts: a model provider class that publishes the metadata and a data provider class whose methods read and write data. The developer implements those methods, for example the method that returns the entity set, in ABAP. A converted system like Contoso's carries many such services from ECC, and they still work. They need careful regression testing because their hand-written logic often reads tables whose structure changed in SAP S/4HANA.

A SEGW service is a model plus generated classes; the custom ABAP lives in the data provider extension class, which is what a conversion can break.
The Sign-Off Table · thesignofftable.com/academy/sap-int-202

RAP: the current model

RAP builds a service in layers, each a separate development object in ABAP Development Tools (ADT) for Eclipse:

Data model (CDS)CDS view entities define the business object: a root entity such as a fleet contract, with child entities
Behavior definitionWhat the object can do: create, update, delete, actions, validations, determinations, draft; managed or unmanaged
ProjectionA use-case-specific view on the business object, for example only what the portal may see
Service definitionLists which entities are exposed and under which names
Service bindingBinds the service definition to a protocol and purpose: OData V2 or V4, UI or Web API
The RAP stack. The service binding is where a business object becomes an OData service.
The Sign-Off Table · thesignofftable.com/academy/sap-int-202

The binding type matters. A UI binding (for example OData V4 - UI) carries UI annotations for SAP Fiori elements apps. A Web API binding (for example OData V4 - Web API) is meant for system-to-system consumption without UI metadata. The same service definition can be bound more than once, so one business object can serve a Fiori app and an external API.

One RAP business object, one service definition, two bindings: a UI binding for a Fiori elements app and a Web API binding for FleetLink.
The Sign-Off Table · thesignofftable.com/academy/sap-int-202

SAP's RAP tutorials show a generator in ADT that creates the full stack from a database table: CDS entities, behavior implementation classes, a draft table, a service definition and a service binding of type OData V4 - UI. In the binding editor you publish the local service endpoint and then open a preview of the generated Fiori elements app. In some on-premise and Private Edition setups, the tutorials publish the service group in /IWFND/V4_ADMIN instead; check which applies to your system.

  1. Define CDS data modelRoot entity ZI_FleetContract with child entity for covered vehicles
  2. Define behaviorManaged implementation with validation: contract end date after start date
  3. Project for the use casePortal projection exposes contract number, customer, dates and status only
  4. Service definitionExposes FleetContract and CoveredVehicle
  5. Service bindingOData V4 - Web API for FleetLink; publish; test
Kenji's RAP service for a new Contoso fleet contract object, from data model to binding.
The Sign-Off Table · thesignofftable.com/academy/sap-int-202

What would you do?

The portal team asks Kenji to expose a new service for fleet contracts by publishing a CDS view directly with the old publish annotation, "because it is quicker". What should Kenji do?

Key points
  • Services come from SAP (released APIs, Fiori back ends), SEGW model-based development, or RAP.
  • RAP layers: CDS data model, behavior definition, projection, service definition, service binding.
  • The binding type decides the protocol (V2 or V4) and purpose (UI or Web API).
  • Old custom services carry custom logic into SAP S/4HANA and belong in regression scope.

Check your understanding · not graded

Lesson check

  1. 1. Which RAP object turns a service definition into an OData V2 or V4 service?

  2. 2. Which binding type suits a system-to-system integration without SAP Fiori UI annotations?

  3. 3. Why do custom SEGW services from ECC need regression testing after a conversion?