SAP OData Beta

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, applications, and devices through HTTP.

The Fivetran SAP OData connector connects to your SAP system and extracts data from the SAP OData API for loading 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

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

You must have an Enterprise or Business Critical plan to use the SAP OData connector.

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.

When available, we combine data from the primary artifact entity and its associated DeltaLinksOf entity into a single destination table, providing 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.

After the initial sync, we perform incremental updates by syncing only changed data from the SAP OData API, minimizing the load on your SAP system.

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

SAP ODP commonly exposes entities using standard naming prefixes. We use these prefixes to identify SAP ODP artifact types and to help detect whether an entity has SAP-provided delta tracking support.

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

Entities can still be discovered and synced even if they don't follow these naming prefixes (for example, custom or renamed entities). However, incremental (delta) sync depends on SAP delta tracking support. If SAP does not expose the required DeltaLinksOf entity for an artifact, we perform a full sync for that entity.

For best results, follow SAP's standard ODP artifact naming conventions and ensure delta tracking is enabled and exposed by SAP for the relevant entities. Without delta tracking, we perform a full sync for the affected entities.

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.
Incremental sync depends on SAP delta tracking – Entities can be discovered and synced even if they don't follow the standard ODP artifact naming prefixes. However, incremental sync depends on SAP exposing a DeltaLinksOf entity for the artifact. If delta tracking is not available, we perform a full sync for that entity. 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 re-sync 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.

When available, 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.