---
title: "SAP S/4HANA"
slug: "sap-s4-hana"
description: "Connect SAP S/4HANA to Dataddo and sync its data to any dashboard, database, AI system, or data warehouse. SAP 3255746 Note Compliant"
updated: 2026-07-15T06:03:40Z
published: 2026-07-15T06:03:40Z
canonical: "docs.dataddo.com/sap-s4-hana"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dataddo.com/llms.txt
> Use this file to discover all available pages before exploring further.

# SAP S/4HANA

The SAP S/4HANA connector lets you extract data from your SAP S/4HANA system into Dataddo and sync it to any dashboard, database, or data warehouse. It reads data through SAP's standard OData services, so no RFC connection is needed.

## Prerequisites

Before you can list or extract any data, your SAP administrator must deploy the Dataddo ABAP scripts to the SAP S/4HANA system. The scripts define:

- An **extraction catalog** service (`Z_C_EXTRACTION_CATALOG`). The connector calls it to discover which CDS views are available and by which method.
- **CDS views** for each table you want to extract, published as OData query services.
- For change data capture, **ODP-enabled CDS views** exposed through SEGW ODP Extraction OData services, registered in `/IWFND/MAINT_SERVICE`.

You also need:

- A technical SAP user with authorization to read the deployed OData services. Ask your Basis team to verify the user's roles.
- Network access from Dataddo to your SAP Gateway over HTTPS.

Change data capture requires SAP S/4HANA 1909 FPS01 or later (SAP S/4HANA Cloud 1905 or later).

## Architecture

The connector has two parts:

- **In your SAP system**: the Dataddo ABAP scripts. They define the extraction catalog, the CDS views, and (for change data capture) the ODP providers. Your SAP team deploys, reviews, and activates them, so you keep full control over what is exposed. All of it runs inside SAP's standard OData stack.
- **In Dataddo**: the connector. It only sends read-only HTTPS requests to the OData services on your SAP Gateway. It never connects to the HANA database directly and never uses RFC.

### How each method loads your database

**The CDS Views method is a plain read.** Each sync runs an OData query against the view, filtered to the configured time window. All load happens at sync time. The cost grows with the window size and with the view's joins and derived columns, like any database query. Nothing is installed on the base table, and no state remains in SAP between syncs.

**The ODP method is trigger-based.** Activating the ODP view creates database triggers on the base table. From then on, every insert, update, and delete also writes a compact change record into the Operational Delta Queue (ODQ). A sync only drains that queue from the last delta token; after the initial load, SAP never re-reads the base table. The cost is a small, constant overhead on every transaction that writes to the table, plus queue storage until the changes are consumed.

|  | CDS Views | ODP (True CDC) |
| --- | --- | --- |
| When the load occurs | At sync time, as a query | Continuously, as a small overhead on each write, plus a cheap read at sync time |
| Read cost per sync | Grows with the window size and view complexity | Grows with the number of changes only, regardless of table size |
| Write overhead on SAP transactions | None | Small, on every insert, update, and delete of the base table |
| Objects created in SAP | CDS views and OData services only | Additionally database triggers and ODQ storage |
| Initial load | Not needed; query any window at any time | One full table read to arm the subscription |
| State between syncs | None | Delta subscription and queued changes, managed in ODQMON |

In short: the CDS method has the smaller footprint and is the safer first step. The ODP method pays a small continuous cost so that syncs stay cheap on large tables, and it is the only method that captures hard deletes.

### Compliance with SAP Note 3255746

SAP Note 3255746 does not permit customer or third-party applications to use the RFC modules of the ODP Data Replication API (ODP-RFC), and SAP is rolling out a security patch that actively blocks such calls. This connector is **not affected** and remains compliant:

- The ODP (True CDC) method consumes the ODP framework exclusively through its official, externally available **OData API** on SAP Gateway. This is the interface the note directs customer and third-party applications to use.
- The CDS Views method does not use the ODP framework at all. It reads published CDS view OData services.
- The connector never uses RFC, for anything.

If you are replacing an ODP-RFC based extraction tool because of this note, both methods of this connector are compliant successors.

## Authorize Connection to SAP S/4HANA

1. In Dataddo, go to **Authorizers** and click **Authorize New Service**.
2. Select **SAP S/4HANA**.
3. Fill in the connection details:

| Field | Details |
| --- | --- |
| Label | A name for this authorizer in Dataddo. |
| Server IP or Hostname | Public hostname of your SAP S/4HANA system without protocol, e.g. `myserver.company.com`. |
| Username | Username for HTTP Basic authentication. |
| Password | Password for HTTP Basic authentication. |

The connector authenticates to the OData services with HTTP Basic authentication over HTTPS.

## Data Coverage

The connector offers two datasets. Both extract from CDS views deployed in your system, so the available tables and columns are dynamic: they depend on which Dataddo ABAP views your administrator has activated.

| Dataset | Description | Example fields | Date range |
| --- | --- | --- | --- |
| CDS Views | Extract new and updated rows from a published CDS view OData service by tracking a timestamp column. Best for master data and snapshot-style tables. | Dynamic (from your SAP system) | Yes |
| ODP (True CDC) | Change data capture via SAP Operational Data Provisioning. Captures inserts, updates and hard deletes through delta tokens. Best for high-volume or delete-sensitive tables. | Dynamic (from your SAP system) | No |

## Choosing an Extraction Method

|  | CDS Views | ODP (True CDC) |
| --- | --- | --- |
| New rows | Yes | Yes |
| Updated rows | Yes | Yes |
| Hard deletes | No (soft-delete flags only, where the view exposes one) | Yes (`ODQ_CHANGEMODE = 'D'`) |
| Change tracking | Timestamp column, filtered per run | Delta token in SAP's Operational Delta Queue |
| Load on SAP | Query with an interval filter | Trigger-based change capture on the base table |
| Best for | Master data, snapshots, low-footprint onboarding | High-volume or delete-sensitive tables |

Both methods poll on your source's sync schedule. Neither is a push stream, so data freshness equals your sync interval.

## How Data Extraction Works

### CDS Views

When you create the source, you pick a CDS view, the columns, and a **Change Tracking Column**. This is a timestamp column, such as the last-changed date, that SAP exposes as an interval filter.

Each run reads a *relative* time window (for example "1 day ago") against the current date, so the window slides forward over time. A run today with a "1 day ago" range pulls yesterday's changes; the same source pulls the new day tomorrow. Each run replaces the window's data, it does not accumulate older history. To load data from before the window, run a full data re-sync with a wider range. See [Data Backfilling](/docs/data-backfilling).

To maintain a complete replica of the table, combine the sliding window with the `dataddo_hash` metadata column and an **upsert** write mode. New and updated rows are then merged into your destination by key.

If you leave the Change Tracking Column empty, every run extracts the full table for the configured window instead.

### ODP (True CDC)

The first sync performs a **full initial load** and arms change tracking in SAP's Operational Delta Queue (ODQ). Every following sync asks SAP for a **delta**: only the rows inserted, updated, or deleted since the previous sync.

Every extracted row carries the `ODQ_CHANGEMODE` change indicator. Dataddo always extracts this column, even if you do not select it:

| ODQ_CHANGEMODE | Meaning | Notes |
| --- | --- | --- |
| `C` | Created | Full row values. |
| `U` | Updated | Full row values after the change. |
| `D` | Deleted | Key fields only; other columns are empty. |

Recommended setup: schedule the source regularly and write with **upsert** on `dataddo_hash`, then handle rows with `ODQ_CHANGEMODE = 'D'` as deletions in your downstream model. A key can appear more than once in one delta; the last change for a key is the current state.

A few things to know about the delta state:

- The delta position lives in SAP's Operational Delta Queue, not in Dataddo. You can inspect it in transaction **ODQMON**.
- Data previews in Dataddo never start or advance the delta subscription. Only scheduled or manual syncs do.
- Consume the delta regularly (for example daily). The queue retains changes until they are consumed.
- To force a new full initial load, terminate the subscription in ODQMON. The next sync then detects that no delta token exists and reloads the table in full.
- If a delta token expires because the queue was cleaned up, the sync fails. Reset the subscription in ODQMON to trigger a full reload.

## Metadata Columns

You can add two optional Dataddo metadata columns to either dataset:

- `dataddo_hash`: a fingerprint of each record's key fields, a natural key. Ideal for upserts.
- `dataddo_extraction_timestamp`: the time of extraction. Use it for slowly changing dimensions.

## How to Create a SAP S/4HANA Data Source

1. In Dataddo, go to **Sources** and click **Create Source**.
2. Select the **SAP S/4HANA** connector.
3. Choose the extraction method: **CDS Views** or **ODP (True CDC)**.
4. Select your SAP S/4HANA authorizer.
5. Name the data source.
6. Pick the entity:
  - CDS Views: select a **CDS View** from the list of published query services.
  - ODP (True CDC): select an **ODP Provider** from the list of extraction-enabled views.
7. Select the **Columns** to extract.
8. For CDS Views only: select the **Change Tracking Column** and a date range. Leave the column empty for a full extraction on every run.
9. Click **Test Data** to preview the extraction.
10. Click **Save**.

## Troubleshooting

### No CDS views or ODP providers are listed

The Dataddo ABAP scripts are not deployed, or the services are not activated:

- Verify the extraction catalog service (`Z_C_EXTRACTION_CATALOG_CDS`) is registered in `/IWFND/MAINT_SERVICE`.
- For ODP providers, verify the view is registered for ODP data extraction and its SEGW ODP Extraction service is activated. Providers without a registered service are not listed.
- Verify the technical user is authorized for the services.

### The ODP sync fails with a delta token error

The Operational Delta Queue was reset or cleaned up, so the stored delta position is no longer valid. Terminate the subscription in transaction **ODQMON**; the next sync performs a full initial load and re-arms change tracking.

### Deleted rows show mostly empty columns

This is expected. SAP reports a deletion as a key-only row with `ODQ_CHANGEMODE = 'D'`. Use the key columns to remove the row downstream.

### Data Preview Unavailable

No data preview when you click on **Test Data** might be caused by an issue with your ***source*** configuration. The most common causes are:

- **Date range**: Try a smaller date range. You can load the rest of your data afterward via [manual data load](https://docs.dataddo.com/docs/data-backfilling).
- **Insufficient permissions**: Please make sure your authorized account has at least admin-level permissions.

## Related Articles

Now that you have successfully created a ***data source***, see how you can connect your data to a dashboarding app or a data storage.

**Sending Data to Dashboarding Apps**

- [Simple Data Integration to Dashboards](https://docs.dataddo.com/docs/simple-data-integration-to-dashboards)
- [Data Backfilling to Dashboarding Apps](https://docs.dataddo.com/docs/data-backfilling-to-dashboarding-apps)

**Sending Data to Data Storages**

- [Batch Ingestion to Data Warehouses](https://docs.dataddo.com/docs/ingestion-to-data-warehouses)
- [Data Backfilling to Storages](https://docs.dataddo.com/docs/data-backfilling-to-storages)

**Other Resources**

- [Troubleshooting](https://docs.dataddo.com/docs/troubleshooting)
- [Extraction Logs](https://docs.dataddo.com/docs/extraction-logs)
- [Data Duplication](https://docs.dataddo.com/docs/data-duplication)