OData Source

The OData Source tool lets you connect Neptune DXP - SAP Edition apps to OData services, whether they run on the same SAP system or on remote systems. This page explains the key concepts behind OData Source configuration, so you can make informed decisions before creating or modifying an OData Source entry.

For detailed step-by-step instructions, see OData Source: How-to guides. For a full dialog field reference, see OData Source configuration reference.

What OData Source is and what problem it solves

Open Data Protocol (OData) is a standardized REST-based protocol for exposing and consuming structured data over HTTP. It provides a uniform way to query, create, update, and delete resources through well-defined endpoints.

The OData Source tool manages the connection details for an OData service (host, authentication, proxy behavior, and protocol version) in one reusable configuration object. Apps built in the App Designer reference an OData Source by name rather than hard-coding service URLs or credentials directly. This separation keeps apps portable across development, QA, and production landscapes and centralizes credential management.

OData V2 vs V4

Neptune DXP - SAP Edition supports both OData V2 (available since the initial release) and OData V4 (introduced in version 24.10.0000).

OData V4 is the current standard and offers a richer query language, improved metadata representation, and better alignment with modern REST conventions. OData V2 remains widely used in SAP on-premise landscapes, particularly for classic SAP Gateway services.

Choose V2 when connecting to legacy SAP Gateway or older ABAP-based OData services.

Choose V4 for newer RAP-based services, third-party APIs, or any service that explicitly advertises OData V4.
OData V4 support requires Proxy Version 2. If you select OData V4, the proxy version is effectively fixed.

Proxy configuration

No proxy (same-system calls)

When Neptune DXP - SAP Edition and the OData service run on the same ABAP system, no proxy is needed. The application server calls the service directly without crossing a domain boundary, so there is no risk of Cross-Origin Resource Sharing (CORS) errors.

Use the no-proxy configuration for:

  • SAP Gateway services on the same system

  • RAP OData services on the same system

Proxy (cross-domain calls)

When the OData service resides on a different host (for example, a remote SAP system, SAP BTP, or any external API), the browser would normally block the request due to CORS restrictions. Neptune DXP’s proxy server acts as a server-side relay: the app calls the Neptune proxy, which forwards the request to the target system and returns the response.

Use the proxy configuration for:

  • Remote SAP systems (connected via SM59)

  • SAP BTP services

  • Third-party REST/OData APIs

Proxy Version 1 vs Version 2

The following proxy implementations exist for backward compatibility reasons.

Version 1 was the original implementation and is retained solely to avoid breaking existing OData Source entries created before Neptune DXP - SAP Edition 24.

Do not use Version 1 for new OData Source entries. It lacks OData V4 support, has no update support for OData V2 sources, and does not handle SAP session cookies.

Version 2 is the current implementation, introduced with Neptune DXP - SAP Edition 24.

All new OData Source entries should use Version 2. It adds:

  • OData V4 support

  • Improved CSRF handling

  • URL query string pass-through

  • Session-less operation on SAP on-premise and SAP Rise

  • Compatibility with SAP and non-SAP systems

  • Extensibility via custom proxy classes

Authentication approaches

The proxy supports the following authentication modes:

No Authentication: The target service is publicly accessible or authentication is handled by the network layer. Use this for open APIs such as the Northwind demo service.

HTTP Destination (recommended): Credentials and connection parameters (host, port, protocol, logon data) are stored in an SM59 entry of connection type G (HTTP Connection to External Server).

This is the recommended approach for any remote system because:

  • Credentials are managed in the ABAP system and never exposed to front-end code.

  • The same SM59 entry can be reused across multiple OData Source entries.

  • The SM59 entry must be maintained separately in each system landscape (development, QA, production), which aligns with standard ABAP transport practices.

  • SAML2 and OIDC enforcement by the target system can be bypassed in favor of the SM59 basic credentials, when required.

Basic Authentication: A username and password are stored directly in the OData Source record. This is convenient for quick prototyping but is not recommended for productive use because credentials are stored in the Neptune configuration rather than in the secure SM59 store.

The value help in Service URL is only active when the destination is fully defined. Either the proxy is disabled (same-system) or the Authentication Type is set to HTTP Destination. This allows Neptune to browse the target system’s OData catalog and present matching services.

OData Source in a system landscape

Apps in the App Designer reference an OData Source by name. Connection details (host, authentication, proxy behavior) are resolved at runtime from the OData Source record and are not embedded in the app itself.

When an app is deployed across development, QA, and production landscapes, the OData Source configuration is maintained separately in each system, typically pointing to the appropriate SM59 destination for that landscape. The app remains unchanged across deployments.

The configuration options described on this page (proxy, version, authentication type) determine how that runtime resolution works for a given target system and network topology.

Related topics