SAP Data Extraction · Solution

One product gets your SAP data out, compliantly, and in real time.

Simplement Roundhouse™ delivers a live, analytics-ready copy of your SAP data to the warehouse, lake, or AI agent of your choice, without the unsupported interfaces that break at the next audit.

Supported interfaces only· Real-time CDC· Built for SAP Note 3255746

Simplement Roundhouse™: built for SAP, ready for everything downstream

Getting data out of SAP has always meant choosing among eight imperfect methods, each trading off compliance, latency, and engineering effort. Roundhouse™ replaces that decision: it extracts through SAP's supported application layer, streams changes in real time, and lands clean, analytics-ready data wherever you need it: Snowflake, Databricks, BigQuery, Azure Synapse, Redshift, Kafka, or a Fabric lakehouse.

01

Compliant by design

Reads SAP's application layer, not ODP/RFC. No interface that SAP can deprecate out from under you.

02

Real-time CDC

Change data capture streams inserts, updates, and deletes as they happen, not nightly batch.

03

Decoded, not raw

Resolves SAP's pool/cluster tables, data types, and deltas into business-ready columns.

04

Any target

One pipeline to your warehouse, lake, streaming bus, or AI layer, on ECC or S/4HANA.

As a technology partner in each ecosystem, Roundhouse™ lands SAP data natively in your platform of choice. See it in depth on the SAP to Snowflake, SAP to Databricks, and SAP to Microsoft Fabric pages.

AI-agent integrations

Live SAP data your AI agents can actually trust

Roundhouse™ lands current, governed SAP data in your own platform, so AI agents and copilots query the real thing instead of stale extracts. Point an agent at live finance, supply chain, or order data, built on a foundation that stays compliant as SAP evolves.

SAP Note 3255746: keeping your Snowflake, Databricks, and Fabric pipelines running

SAP has restricted third-party tools from using Operational Data Provisioning (ODP) APIs and unauthorized RFC calls for external extraction. If your pipeline to Snowflake, Databricks, or Microsoft Fabric pulls data from ECC, S/4HANA, or RISE through an ODP-based connector, that path is the one under scrutiny, and it's the reason many teams are re-architecting now.

Why Roundhouse™ is unaffected

Roundhouse™ extracts through SAP's supported application layer, not the ODP/ODQ frameworks or background RFC table readers that Note 3255746 addresses. Because extraction runs inside the application layer, SAP's own security profiles, authorizations, and business logic stay intact, and there's no ODP interface for a future SAP change to remove from under you.

01 · Trigger

A change posts in SAP

A transaction updates a table such as BSEG or VBAK in ECC or S/4HANA.

02 · Process

Captured in-app

Roundhouse™, installed via SAINT, captures the delta at the application layer, without ODP.

03 · Transport

Streamed to target

The change is streamed securely to your destination as it happens, no intermediate staging DB required.

04 · Landing

Analytics-ready

Decoded, typed data lands in Snowflake, Databricks, or Fabric, ready for dbt, Snowpark, or Power BI.

The 8 extraction methods, and how Roundhouse™ handles each

Here's the full landscape of ways to get data out of SAP, rated on a 5-star compliance scale. For each, you'll see a real SAP example and how Roundhouse™ either replaces it or does the same job without the risk.

★★★★★ Fully compliant ★★★☆☆ Mixed / conditional ☆☆☆☆☆ Blocked / at risk
Method 01

ODP / ODQ via RFC

The default for many legacy connectors, and the one on borrowed time.
At risk
☆☆☆☆☆Not a supported third-party extraction interface
The question isn't if they break. It's when.

Operational Data Provisioning over RFC exposes extractors and CDS-based ODP sources to outside tools. SAP has been explicit that using ODP/ODQ for non-SAP extraction is not licensed or supported, leaving these pipelines one upgrade or audit away from failure.

SAP example A connector pulling the 2LIS_11_VAITM sales-order extractor (or a 0FI_GL_* finance DataSource) through the RODPS_REPL_* / ODQ RFC function modules. Common in older Theobald, SLT-to-ODP, and generic-connector setups.
How Roundhouse™ handles it: captures the same business objects (sales orders, GL line items) through the supported application layer instead, so you keep the data and drop the compliance exposure.
Method 02

SAP Datasphere

SAP's cloud answer: compliant, but inside SAP's walls and pricing.
Conditional
★★★☆☆Compliant within the SAP ecosystem

Datasphere (formerly Data Warehouse Cloud) federates and replicates SAP data inside SAP BTP. It's governed by design, but adds Capacity Unit costs, keeps semantics in SAP's model, and limits how freely data moves to non-SAP targets.

SAP example Replicating S/4HANA I_SalesDocumentItem CDS views into a Datasphere space via the Replication Flow / Premium Outbound Integration, then trying to push that out to Snowflake.
How Roundhouse™ handles it: delivers the same S/4HANA objects straight to your own warehouse, with no BTP intermediary and no Capacity Unit metering on outbound data.
Simplement's approach
Method 03 · Application Layer

Application-Layer Extraction with Simplement Roundhouse™

Reads through SAP's own application layer: supported, real-time, and yours.
Fully compliant
★★★★★Supported interface · real-time CDC

Roundhouse™ runs inside SAP at the application layer, where it sees data exactly as SAP intends it: decoded, typed, and authorization-aware. It captures changes in real time and streams them to your target with no ODP dependency to break.

SAP example Streaming live changes from BSEG/BKPF (finance documents), VBAK/VBAP (sales), MSEG (material movements), and even cluster tables like RFBLG, fully decoded, into Snowflake or Kafka as they post in ECC or S/4HANA.
The whole point: one supported pipeline that does what Methods 01–08 each do partially, without the compliance gaps, the decoding work, or the batch latency.
Method 04

CDS Views

Modern and semantically rich, if your release exposes what you need.
Compliant
★★★★☆Supported · coverage varies by release

Core Data Services views expose business-meaningful, S/4HANA-aligned data and are a supported, future-facing interface. The catch is coverage and consumption: not every object is released for external use, and extraction still needs an interface (OData, RFC, or ODP) to pull it.

SAP example Consuming C_SalesDocumentItemDEX or an I_* interface view via OData in S/4HANA. Clean semantics, but bounded by what's been released and by API throughput limits.
How Roundhouse™ handles it: uses SAP's released semantics where they help, but isn't limited to what CDS exposes, so coverage gaps don't become blind spots in your warehouse.
Method 05

Database Log Reading

Low latency, but it goes around SAP rather than through it.
Use with caution
★★☆☆☆Bypasses the application layer

Reading the database redo/transaction log (e.g. trigger-based or log-based CDC straight off HANA or an underlying DB) captures changes fast, but it sidesteps SAP's application logic, security, and support boundary, and you inherit the job of decoding raw structures yourself.

SAP example A log-based CDC tool tailing HANA changes to ACDOCA (the Universal Journal), then having to reconstruct currency, unit, and pool/cluster logic that the application layer would have applied.
How Roundhouse™ handles it: delivers comparable low latency via supported application-layer CDC, with SAP's own decoding intact, so ACDOCA arrives correct, not raw.
Method 06

SAP BW / BW4HANA

Battle-tested for reporting, heavy for modern data movement.
Conditional
★★★☆☆Supported · operationally heavy

BW is a known, compliant quantity for traditional analytics, but it adds a full modeling layer (InfoProviders, DTPs, transformations) and is itself often fed by the same extractors now under ODP scrutiny. Justifying it purely to land data in a lake is hard.

SAP example Loading the 0FI_AR_4 accounts-receivable extractor into an aDSO in BW/4HANA, then exporting via Open Hub to a downstream warehouse. Multiple hops, nightly cadence.
How Roundhouse™ handles it: goes direct to the source objects in real time, so you skip the BW modeling and Open Hub round-trip when the goal is simply a clean copy downstream.
Method 07

Custom ABAP

Total control, and total ownership of the maintenance.
Compliant
★★★★☆Supported · you own the upkeep

Hand-written ABAP extractors stay inside supported boundaries and pull exactly what you specify. The trade is engineering: every object, delta logic, and S/4 conversion (e.g. classic AR/AP tables folding into ACDOCA) becomes your team's permanent backlog.

SAP example A custom RFC-enabled function module that reads LIPS (delivery items) with bespoke delta pointers. Works, until an upgrade changes the table or someone who wrote it leaves.
How Roundhouse™ handles it: gives you the same supported, in-SAP extraction as a configured product, not custom code, with no per-object development and no upgrade firefighting.
Method 08

Generic ETL / iPaaS Tools

Familiar tooling, but most lean on the interface that's at risk.
Depends on connector
★★★☆☆Only as compliant as its SAP connector

General-purpose platforms are convenient and well-integrated downstream, but their SAP connectors frequently call ODP/RFC or BAPIs under the hood, so they quietly inherit Method 01's risk, and rarely decode SAP's trickier structures correctly.

SAP example Fivetran, Azure Data Factory, Informatica, or SAP Data Services configured with an "SAP ODP" source. Convenient in the UI, but tied to the same unsupported extraction path.
How Roundhouse™ handles it: sits upstream of your ETL/iPaaS as the compliant SAP source, then feeds your existing tools the clean data. You keep your stack, you lose the ODP dependency.

Same SAP source, every modern platform

Roundhouse™ extracts SAP data once, through the supported application layer, and lands it in the destination your team already runs on. The compliance model doesn't change with the target: the same BSEG, VBAK, and ACDOCA data streams to Snowflake, Databricks, or Microsoft Fabric without ODP.

Target · Databricks

SAP to Databricks Lakehouse

Delta-tracked SAP tables straight into Delta Lake and Unity Catalog.
No ODP dependency

Lakehouse teams want clean, delta-tracked SAP data in Delta Lake without standing up intermediate cloud storage first. Roundhouse™ streams changes from the SAP application layer directly into Delta tables, with the metadata Databricks needs to plug straight into Delta Live Tables and Unity Catalog governance.

SAP example Streaming BSEG/BKPF (finance) and VBAK/VBAP (sales) into Delta Lake in real time, decoded and typed, ready for ML feature pipelines, rather than nightly batch loads into a staging bucket.
Why it matters: the extraction stays inside SAP's supported application layer, so the pipeline avoids the ODP/RFC path under SAP Note 3255746 while feeding Databricks clean data.
Target · Microsoft Fabric

SAP to Microsoft Fabric OneLake

SAP data in OneLake without an Azure Data Factory ODP pipeline.
No ODP dependency

Azure-centric teams often reach for Azure Data Factory to move SAP data, but ADF's SAP path typically leans on ODP extractors, the same interface under scrutiny in Note 3255746, and adds staging and pipeline overhead. Roundhouse™ streams SAP changes directly into Fabric OneLake in Delta format, skipping the intermediate ADLS staging layer.

SAP example Landing ACDOCA (Universal Journal) and MSEG (material movements) into OneLake as decoded Delta tables, queryable in Power BI Direct Lake mode, without an ADF ODP connector in the middle.
Why it matters: you stay inside the Microsoft ecosystem and land data in Fabric directly, without building or maintaining an ODP-based ADF pipeline that Note 3255746 puts at risk.

Find out which method you're on, and the compliant way off it

We've helped teams migrate off ODP in weeks, not quarters.

Tell us what you're running today, whether Theobald, SLT, BODS, a homegrown ABAP extractor, anything, and we'll tell you plainly whether you're at risk and what Roundhouse™ would replace it with.

Talk to an expert