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

Lesson 3 of 5

Activation and security

10 min

Listen to this lesson

0:00 / 8:53

Building a service is not enough; it must be activated so that requests reach it, and secured so that only the right callers, with the right authorizations, can use it. Activation and security failures are among the most common reasons an OData test fails in a new system or after a client copy, so testers need to recognize them quickly.

Activating OData V2 services

OData V2 services are activated with Activate and Maintain Services (/IWFND/MAINT_SERVICE). The upper part of the screen lists registered services (the service catalog); the lower part shows the selected service's ICF nodes and system aliases. To register a service you add it with a system alias, usually LOCAL when SAP Gateway runs in the same system as the back end, which is the common setup for SAP S/4HANA.

SAP's documentation says activation creates three things: a service repository object, which controls authorizations through authorization object S_SERVICE, external name mapping and transport; an object group assigned to the system alias; and an ICF node, which controls authentication and whether the service is active. A green ICF node means active. From the same screen you can open the SAP Gateway Client or call the service in a browser.

  1. Register the serviceAdd it in /IWFND/MAINT_SERVICE with system alias LOCAL
  2. Repository object createdCarries the S_SERVICE start authorization and transport information
  3. System alias assignedRoutes requests to the back end that implements the service
  4. ICF node activeThe service URL answers; authentication is handled here
  5. Test callCall $metadata from the Gateway Client and check for an error-free response
Activation of an OData V2 service and what each step creates.
The Sign-Off Table · thesignofftable.com/academy/sap-int-202

Publishing OData V4 services

OData V4 services are organized in service groups and published with /IWFND/V4_ADMIN: you choose to publish service groups, enter the system alias, fetch the available groups and publish the one you need. SAP's tutorial notes that system aliases for V4 service groups must be created manually and that the exact steps depend on your landscape. Once a group is published, its services are addressable.

StepOData V2OData V4
Admin transaction/IWFND/MAINT_SERVICE/IWFND/V4_ADMIN
Unit of activationIndividual service and versionService group
RoutingSystem alias on the serviceSystem alias on the service group
RAP servicesV2 bindings: publish from ADT or register hereV4 bindings: publish from ADT or publish the group here
Typical "not found" causeService not registered or ICF node inactiveService group not published
Activating V2 and V4 services. Confirm the exact path for your release and deployment.
The Sign-Off Table · thesignofftable.com/academy/sap-int-202

Security layers

Transport securityHTTPS; certificates trusted by the caller
AuthenticationWho is calling: user and password, certificate or a token issued by an identity provider, configured on the ICF node or the front door
CSRF protectionModifying requests must carry a CSRF token fetched with a prior GET
Start authorizationS_SERVICE for the service, granted through a PFCG role
Business authorizationNormal authorization checks and CDS access controls, for example by sales organization
Security layers an OData request passes. Each layer has its own error and its own test.
The Sign-Off Table · thesignofftable.com/academy/sap-int-202

The start authorization decides whether a user may call the service at all. In a PFCG role you add the service, and the system generates the S_SERVICE entry from a hash of the service name. The business authorization then decides which data the user sees or changes, exactly as in a Fiori app or SAP GUI. A user with the start authorization but no sales organization authorization gets an empty list, not an error, which surprises testers who expect a 403.

A FleetLink request passes several gates in order, and each failure looks different: a 401, a 403, or an empty but successful list.
The Sign-Off Table · thesignofftable.com/academy/sap-int-202

SAP Gateway protects modifying requests against cross-site request forgery. The client first sends a GET with the header X-CSRF-Token: Fetch; the server returns a token and a matching cookie. Every POST, PATCH or DELETE must send that token back. If it is missing or invalid, the server answers 403 Forbidden. Integration clients must handle this, and so must automated API tests.

The CSRF handshake: fetch a token with a GET, then send it back with every modifying call, or SAP Gateway answers 403.
The Sign-Off Table · thesignofftable.com/academy/sap-int-202

What would you do?

After a client copy into the training client 200, every FleetLink call returns 403 for the technical user, while the same calls work in CMQ client 100. What should the team check first?

Key points
  • Activate V2 services in /IWFND/MAINT_SERVICE; publish V4 service groups in /IWFND/V4_ADMIN.
  • Activation creates a repository object (S_SERVICE), an object group with system alias and an ICF node.
  • Users need a start authorization (S_SERVICE) and business authorizations; missing data can mean missing business authorization.
  • Modifying calls need a CSRF token; check the Gateway error logs when calls fail.

Check your understanding · not graded

Lesson check

  1. 1. Which authorization object controls whether a user may start an OData service?

  2. 2. A V4 service returns "not found" in a new system. What is a typical cause?

  3. 3. A user with the start authorization gets an empty order list instead of an error. What is the likely reason?

  4. 4. What must a client send with a POST to an SAP Gateway OData service?