SAP OData Authorization Requirements

Applies to: S/4HANA Private Cloud Edition, OData V2 and V4, Basic authentication over HTTPS

This topic is intended for SAP Basis and IT administrators. It describes the authorization requirements for Process Runner to call an SAP OData service on a user's behalf using basic authentication over HTTPS.

Note: This guide does not apply to S/4HANA Public Cloud Edition, which uses Communication Arrangements and does not permit customer PFCG editing.

Authorization model

For Process Runner to call an SAP OData service, the SAP user requires authorizations at three layers. The following table describes each layer for OData V2 and V4.

Supported SAP user types

Process Runner supports all SAP user types, subject to the authorization restrictions imposed by your organization.

OData V2 authorization — S_SERVICE fields

SRV_NAME is a hash, not the service name. Populate S_SERVICE by adding the service to a PFCG role via the role menu as a TADIR Service. Profile Generator computes the hash from table USOBHASH automatically.

OData V4 authorization — S_START fields

OData V4 uses S_START (repository-object based) instead of S_SERVICE. AUTHOBJNAM is the service group name.

Examples

Example A — OData V2: API_PURCHASEORDER_PROCESS_SRV

URL: /sap/opu/odata/sap/API_PURCHASEORDER_PROCESS_SRV/ | System alias: LOCAL (embedded)

Note: This V2 service is deprecated as of S/4HANA (SAP KBA 3502308) and is shown for illustration only.

Example B — OData V4: API_PURCHASEORDER_2

URL: /sap/opu/odata4/sap/api_purchaseorder_2/srvd_a2x/sap/purchaseorder/0001/ | Service group: API_PURCHASEORDER_2

Identify authorization objects for any OData service

Use transaction SU24 as the source of truth for any OData service not covered by the examples above.

1. Open transaction SU24 (customer view) or SU22 (SAP proposals).
2. Set Type of Application to IWSV for OData V2 or G4BA for OData V4.
3. Enter the service or service group name in the Object Name field. V4 names carry a version suffix, for example, _0001.
4. Select Execute. The proposal lists the start object and every application authorization object the service checks, along with field defaults.
5. If SU24 returns no results after an upgrade, run SU25 and, if needed, program SU24_AUTO_REPAIR.

Note: An OData service enforces the same application authorization objects as the underlying transaction or BAPI, since both use the same ABAP code. OData only adds the start gate authorization.

Service activation prerequisites

The following prerequisites are owned by the Basis team and must be completed before Process Runner can connect to the OData service.

HTTPS/HTTP and basic authentication

Important: Verify the ICF node Logon Data settings before assuming basic authentication is enabled. Do not assume it is active by default.

• Basic authentication is accepted on /sap/opu/odata/ and /sap/opu/odata4/ provided the ICF node is active and its Logon Data (SICF > Logon Data tab) permits credential-based logon — "Standard" or "Alternative Logon Procedure" (SAP KBA 3564503).
• OData V4 has a single SICF node (/sap/opu/odata4/). Per-service stored credentials via SICF are not available for V4 the way they are for V2.
• HTTPS is required. A valid CA-signed server certificate must be installed on the SAP Web Dispatcher or ICM, TLS 1.2 or higher must be configured, and the Process Runner client must trust the server certificate chain.
• IMPORTANT: Process Runner currently supports basic authentication only. SAP recommends OAuth 2.0 as the more secure option; basic authentication is fully functional for S/4HANA Private Cloud Edition.

S/4HANA Private Cloud Edition (RISE) boundary

The following table describes what the customer and SAP Enterprise Cloud Services (ECS) each own in an S/4HANA Private Cloud Edition environment.

Note: This guide does not apply to S/4HANA Public Cloud Edition, which uses Communication Arrangements and does not permit customer PFCG editing.

End-to-end validation checklist

1. User: In SU01, confirm the user type, that the password is valid, that roles are assigned, and that the account is not locked. Use SU56 to view the authorization buffer.
2. Service reachable in SAP: Run /n/IWFND/GW_CLIENT, enter the request URI, and select Execute. Expect HTTP 200 with metadata or entity data.
3. Service reachable from Process Runner: Call /sap/opu/odata/sap/<service>/$metadata or /sap/opu/odata4/<group>/$metadata from Process Runner over HTTPS. Expect HTTP 200 XML.
4. Business action test: Perform the smallest real operation, for example, GET one purchase order. If the operation fails with HTTP 403, see Troubleshooting authorization failures below.

Troubleshooting authorization failures

All transactions listed below are run by Basis or Security teams using SAP GUI. The end user only needs to supply the failing user ID and the timestamp of the failure.

Symptoms, likely causes, and where to look

Transaction reference

Standard fix workflow

1. Capture the user ID and exact timestamp of the failing call.
2. Run SU53 as that user, or select SU53 > Goto > Other User.
3. If SU53 is not helpful, run STAUTHTRACE filtered on that user, reproduce the issue, and select Evaluate.
4. Cross-check /IWFND/ERROR_LOG for the same timestamp.
5. If a hash was shown, resolve it using USOBHASH (see Transaction reference above).
6. Add the missing authorization object or field values to the PFCG role, regenerate the profile, run User Comparison, and retest.