SAP OData Private Preview

OData (Open Data Protocol) is a standardized protocol developed by Microsoft and widely adopted by SAP for secure, scalable, and efficient data exchange across SAP systems and various other platforms, applications, or devices through HTTP. The OData protocol enables data integration, allowing you to use SAP data within broader ecosystems.

The Fivetran SAP OData connector integrates your SAP system as a data source with a focus on read operations. It extracts data from the SAP OData API and loads it into your destination, providing access to SAP ERP data, including:

Core Data Services (CDS) views - Modern analytical views that provide direct access to SAP business data
Business Warehouse (BW) extractors - Traditional data extraction objects exposed through the SAP Operational Data Provisioning (ODP) API
Key business processes data - Critical operational data representing your organization's core workflows

The connector uses SAP's standardized OData services for efficient data retrieval, making it easier to analyze ERP data across diverse applications and systems.

Features

Feature Name	Supported	Notes
Capture deletes		Extraction objects with delta enabled.
History mode
Custom data
Data blocking		Column (property) level, table (view) level, and schema (service) level.
Column hashing		Column level
Re-sync		Connection level and table (entity) level.
Row filtering
API configurable
Priority-first sync
Fivetran data models
Private networking		AWS PrivateLink with self-configuration support Azure Private Link with self-configuration support Proxy Agent with self-configuration support
Authorization via API

Supported deployment models

We support the SaaS and Hybrid deployment models for the connector.

You must have an Enterprise or Business Critical plan to use the Hybrid Deployment model.

Setup guide

Follow our step-by-step SAP OData setup guide to connect SAP OData to your destination using the Fivetran connector.

Sync overview

Fivetran uses the SAP OData API to extract data from your SAP environment. This RESTful interface provides standardized access to your SAP OData resources, including both Core Data Services (CDS) views and traditional BW extractors that have been exposed. To ensure a successful sync, all extraction objects (CDS views and BW extractors) must be correctly published to the SAP OData API and enhanced with the required SAP annotations in their definitions:

@Analytics.dataExtraction.enabled: true - Enables data extraction. You can wrap an extractor (for example, based on a table or extractor logic) into a CDS view and annotate it for extraction.
@Analytics.dataExtraction.delta.changeDataCapture.automatic: true - Enables automatic delta data extraction, which tracks changes (inserts, deletions, updates) for incremental data loads. This reduces the need for full data extractions during reporting or re-sync operations.

Fivetran uses specific SAP artifacts and delta tracking mechanisms to optimize data synchronization:

SAP artifacts (for example, FactsOf or EntityOf) define the relationships between entities within an object. These artifacts enable comprehensive and context-aware data extraction.
DeltaLinks track incremental changes since the last sync, optimizing resource usage and ensuring only updated records are captured in each sync cycle.

Fivetran replicates both entities into a single table in your destination, combining the artifact and delta entities to provide a comprehensive view of your SAP data. We also retrieve metadata fields to track the data extraction process (ODQ-prefixed columns). These fields are essential for incremental data extraction but are not synced to the destination.

For more information, see the SAP Analytics Annotations documentation.

Not all BW extractors are directly compatible with the OData API. In many cases, intermediate staging, such as CDS or ABAP, is required. Delta handling for BW extractors can be complex. While Fivetran uses the OData API to access data, the underlying implementation depends on how each extractor is designed and configured.

Fivetran syncs only change data from the SAP OData API, minimizing the load on your SAP system while providing efficient access to your business data.

SAP OData metadata mapping

The SAP OData API, based on the OData protocol, uses a set of conventions for building and consuming RESTful APIs. The API is structured around the concept of services, entities, properties, and keys, which map to the following elements in your destination:

Entity corresponds to a table
Property corresponds to a column
Key corresponds to the primary key (PK)

Entities from every OData service you select load into the same destination schema that you configure during setup. Services themselves are not represented as separate schemas in the destination.

Because all services share a single destination schema, entity names must be unique across the services you select. If two services expose an entity with the same name, the later-synced entity overwrites the earlier one.

SAP artifact naming conventions

We support extraction only from SAP artifacts that follow specific naming conventions. For successful integration, ensure your extraction objects follow these specific prefix conventions:

Prefix	Purpose	Description
`FactsOf<ODP name>`	Fact data	Entity set for a fact ODP containing measurable business data
`AttrOf<ODP name>`	Attributes	Entity set for an ODP containing descriptive attributes
`TimeDepAOf<ODP name>`	Time-dependent attributes	Entity set for an ODP containing attributes that change over time
`TextsOf<ODP name>`	Text data	Entity set for an ODP containing text descriptions and labels
`EntityOf<ODP name>`	Generic entities	Entity set for an ODP without specific semantic classification

Only SAP artifacts that strictly follow these naming conventions will be discoverable and extractable through our connector.

When creating or modifying SAP objects intended for extraction, coordinate with your SAP development team to follow these naming patterns. Non-compliant artifacts will not be exposed for extraction.

Limitations

The following limitations apply when you use SAP OData as a source:

Single destination schema – All OData services selected within a connection load into the destination schema you choose during setup. Entity names must be unique across services; if two services expose an entity with the same name, the later-synced entity overwrites the earlier one. To sync services with overlapping entity names, create a separate connection for each service.
ODP subscriptions are unique per service and user – SAP ODP tracks delta subscriptions by the combination of OData service and SAP user. Only one active subscription can exist for a given service-and-user pair; starting a new sync with the same pair cancels the existing subscription and resets its delta state. When you run multiple SAP OData connections, such as one per environment or destination, give each connection its own SAP user and its own set of OData services — reusing either across connections can overwrite delta state and cause sync failures.
HTTPS required – Connections to your SAP system must use HTTPS.
Primary key required – Each entity must expose at least one key property. Entities without a key aren't supported.
Artifact naming conventions – Only artifacts whose names follow the supported prefixes (FactsOf, AttrOf, TimeDepAOf, TextsOf, EntityOf) are discoverable. For more information, see SAP artifact naming conventions.
No server-side filtering or expansion – We don't use the $filter or $expand OData query options. All rows from the selected entities are replicated.
Metadata changes require a re-sync – Changes to an OData service's metadata, such as added, removed, or re-enabled columns, require a resync of the affected tables.

Type transformation mapping

Fivetran maps SAP OData data types (EDM) to Fivetran-supported types. Our system attempts to infer the types of any columns with data types that are not recognized.

The following table illustrates how Fivetran transforms your SAP data types (based on the OData primitive types) into Fivetran-supported types:

Edm Primitive Type	Fivetran Type	Fivetran Supported
Edm.Binary	BINARY	True
Edm.Boolean	BOOLEAN	True
Edm.Byte	BINARY	True
Edm.DateTime	LOCALDATETIME*	True
Edm.Decimal	BIGDECIMAL**	True
Edm.Double	DOUBLE	True
Edm.Guid	STRING	True
Edm.Int16	SHORT	True
Edm.Int32	INTEGER	True
Edm.Int64	LONG	True
Edm.SByte	BINARY	True
Edm.Single	FLOAT	True
Edm.String	STRING	True
Edm.Time	STRING	True
Edm.DateTimeOffset	INSTANT	True

*The LOCALDATETIME type is used to represent date and time values using the Gregorian calendar. For dates before 1582-10-15, there may be discrepancies in the representation of dates due to the switch from the Julian to the Gregorian calendar.

**The BIGDECIMAL type uses the provided precision and scale values from the SAP source. Depending on the mapping, both precision and scale can be 0, even though there can be valid non-zero BigDecimal data in that column. In such cases, we default the precision to 38 and scale to 8.

When you have invalid values in SAP for the chosen Edm type in OData, Fivetran will not be able to load the data due to an error related to SAP Note 1797736. For additional details about data types, see the OData documentation.

Schema information

Fivetran replicates the selected OData services and their underlying entities from your SAP source into the destination schema you configured during setup. Each entity maps to a table, and each property becomes a column. Entities from all selected services share the same destination schema. For more information, see Limitations.

We retrieve and combine data from both the primary artifact entities and their associated DeltaLinksOf entities into a single destination table per entity.

Fivetran-generated columns

Fivetran adds one extra system column to each destination table to provide insight into sync progress and timing:

_fivetran_synced (UTC TIMESTAMP) indicates the time when Fivetran last successfully synced the row.

Deleting data

Fivetran tracks deleted records for all tables.
Tables have a _fivetran_deleted column in the destination. After each re-import, we mark any row that no longer exists in the source table as deleted in the destination.