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. It's compatible with SAP S/4HANA, SAP ECC, and SAP BW systems that expose data through the ODP API.

Features

Supported deployment models

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

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 ODQ-prefixed metadata fields that track the extraction process. These fields are essential for incremental data extraction, but we don't sync them to the destination.

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. The connector follows SAP __next pagination links automatically — we fetch all pages transparently, with no action required on your part.

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:

• Service – all selected services load into the single destination schema you configure during setup; services are not represented as separate schemas
• Entity corresponds to a table
• Property corresponds to a column
• Key corresponds to the primary key (PK)

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.

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. To view and manage existing ODP subscriptions on your SAP system, use SAP transaction ODQMON.
• HTTPS required – Connections to your SAP system must use HTTPS.
• SSO not supported – We don't support SSO. You must use basic authentication with a username and password.
• 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.
• Re-enabled columns require a re-sync – Newly added or removed columns in the OData service metadata are detected automatically on the next sync. If a column was previously excluded and you re-enable it, a re-sync is required to backfill data missed during the exclusion period. You can trigger a re-sync from your Fivetran dashboard by selecting the affected tables and clicking Re-sync.
• Response-size limits – By default, page size is server-controlled: SAP decides how many rows to return per request. If SAP returns a string-size error, we automatically fall back to a lower default page size to complete the sync.

Schema information

Fivetran replicates data from the selected OData services into the destination schema you configured during setup. For how OData concepts map to destination objects, see SAP OData metadata mapping. For schema constraints such as entity name uniqueness, 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 system columns to each destination table:

• _fivetran_synced (UTC TIMESTAMP) — the time when Fivetran last successfully synced the row. Present in all tables.
• _fivetran_deleted (BOOLEAN) — TRUE if the row has been deleted in the source. Present in tables using soft delete mode.
• _fivetran_start (UTC TIMESTAMP) — the time when this version of the row became active. Present in tables using history mode.
• _fivetran_end (UTC TIMESTAMP) — the time when this version was superseded. Present in tables using history mode.
• _fivetran_active (BOOLEAN) — TRUE if this is the current version of the row. Present in tables using history mode.

Soft delete mode

When soft delete mode is enabled for a table, Fivetran tracks deleted records using a _fivetran_deleted (BOOLEAN) column. When a row is deleted in the source, Fivetran sets _fivetran_deleted = TRUE rather than removing it from the destination. Rows are never physically removed.

For entities with SAP delta tracking enabled, Fivetran detects deletes incrementally during normal syncs: rows with ODQ_CHANGEMODE = D in the delta response are processed as deletes without requiring a full re-sync. For entities without delta support, Fivetran identifies deletes during a full re-sync: if a primary key that was previously synced no longer appears in the source data, it's marked as deleted.

History mode

When history mode is enabled for a table, Fivetran preserves a full record of every row version rather than overwriting rows on update. Each version of a row is stored as a separate entry in the destination, with the following additional columns:

• _fivetran_start (UTC TIMESTAMP) — the time when this version of the row became active.
• _fivetran_end (UTC TIMESTAMP) — the time when this version was superseded. For the current active version, this is set to a destination-specific maximum timestamp (9999-12-31 for most destinations, 2038-01-19 for MySQL).
• _fivetran_active (BOOLEAN) — TRUE if this is the current version of the row.

To use history mode, delta tracking must be available for the entity — no other SAP configuration is required. Entities without delta support perform a full re-import each sync, which history mode also captures correctly.

The _fivetran_deleted column is not present in history mode tables. Instead, deleted rows are marked with _fivetran_active = FALSE.

Type transformations and 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: