ADF SAP CDC Connector Is Broken. Here Are Your Three Options.
Azure Data Factory's SAP CDC connector used ODP via RFC — the exact mechanism SAP blocked on June 9, 2026. If you rely on ADF to extract SAP data into Azure Data Lake, Fabric, or Synapse, your pipeline is running on a temporary fallback that expires December 2026. Here are the three architecturally sound replacements.
Your ADF SAP CDC pipeline is running on a fallback that expires December 2026. The Azure Data Factory SAP CDC connector used ODP via RFC — the exact extraction method SAP permanently blocked on June 9, 2026. If it is still working today, you are on SAP's temporary fallback mechanism. When that fallback expires, it stops with no warning and no recovery path. This post covers the three architecturally correct replacements.
Azure Data Factory's SAP CDC connector was one of the most widely deployed SAP-to-Azure data pipelines in the market. Its promise was compelling: near-real-time delta extraction from SAP ECC or S/4HANA directly into Azure Data Lake Gen2, Azure Synapse, or Microsoft Fabric — with change tracking built in. Microsoft built it, SAP tolerated it, and thousands of Azure-first SAP customers adopted it as their standard extraction layer.
On June 9, 2026, it broke.
Not because Microsoft made a mistake. Not because Azure changed anything. It broke because SAP activated the technical enforcement behind Note 3255746 — the note that designates the ODP replication API over RFC as exclusively for SAP-to-SAP data transfer. ADF's SAP CDC connector used RODPS_REPL_* function modules, which are exactly what Note 3255746 prohibits. The June 2026 security patch delivered the mechanism that enforces that prohibition at the ABAP system level.
If your pipelines are still running, you have not applied SAP's June 2026 Support Package, and you are on the temporary fallback. That fallback expires December 2026.
This is not speculation. Run SAP Note 3439624 on your system right now — it will show you every active ODP-RFC subscriber, including your ADF connection, the last extraction timestamp, and the data volumes flowing through it. That output is your migration scope document.
Why the SAP CDC Connector Specifically Broke
It helps to understand the mechanics, because the fix depends on understanding what ADF's CDC connector was actually doing.
The SAP CDC connector in ADF worked by registering as an ODP subscriber in the connected SAP system. ODP — the Operational Data Provisioning framework — is SAP's internal delta-tracking mechanism. It maintains watermarks, queues delta records, and manages subscriber state. When ADF polled for new data, it called the ODP replication API via RFC (the RODPS_REPL_* function module family) to retrieve those delta records.
SAP Note 3255746 states this clearly: ODP replication via RFC is for SAP-to-SAP communication only. Third-party tools — including ADF — were never certified for this usage. SAP tolerated it for years because it drove Azure adoption. They ended the tolerance in June 2026.
The important clarification is that RFC as a protocol is not banned. Table reads via RFC, BAPI calls via RFC, custom function module calls via RFC — all of these are still fully compliant. Only the ODP replication API function modules over RFC are prohibited.
This distinction matters because your migration options depend on it.
The Three Options
Option 1 — ADF SAP Table Connector (RFC Table Read)
What it does: ADF's SAP Table connector uses RFC Table Read (RFC_READ_TABLE or equivalent custom function modules) to pull data directly from SAP transparent tables. It does not use ODP at all — no subscriber registration, no delta queue, no ODP-RFC calls. It is fully compliant with SAP Note 3255746.
The limitation: There is no native delta mechanism. You are pulling the full table every run, or you are implementing your own delta logic — typically using a date field (like AEDAT, ERDAT) or a change indicator. For small to medium tables, this is viable. For BSEG, ACDOCA, or VBAP at enterprise scale, full-table loads become a performance and cost problem quickly.
When to use it:
- Tables under ~50 million rows
- Batch-acceptable latency (daily or weekly)
- Data where a date field provides reliable delta
- Quick migration with minimal SAP-side changes required
Option 2 — ODP via OData (SAP's Recommended Replacement)
What it does: SAP published this as the explicit replacement for ODP-RFC. Instead of connecting to the ODP framework via RFC, you consume ODP via HTTP REST — SAP exposes the same ODP extractors (BW DataSources, CDS views, custom extractors) through an OData service layer. The delta mechanism is preserved. The extractor registration is preserved. Only the transport protocol changes: from RFC (now prohibited) to HTTP (always allowed).
This is the path SAP officially recommends. It uses the SAP Gateway framework (transaction /IWFND/MAINT_SERVICE) to expose ODP extractors as OData services, and you consume those services via ADF's OData connector or any HTTP-capable pipeline tool.
The limitation: This requires S/4HANA 1511 or later, or a supported BW system. It does not work on ECC without additional configuration. SAP Gateway must be active and configured. For large delta volumes, OData throughput is lower than a direct RFC call — this is a genuine architectural trade-off.
When to use it:
- S/4HANA systems (on-premise or RISE)
- Scenarios where you had BW DataSources or CDS view extractions
- When you need certified delta with minimal pipeline refactoring
- When SAP certification matters for your compliance posture
Option 3 — ABAP Push Architecture (The Long-Term Answer)
What it does: Instead of an external tool pulling data from SAP, ABAP code running inside SAP detects changes and pushes them outbound via HTTPS REST to Azure — Azure Data Lake Gen2, Event Hubs, or Microsoft Fabric. There is no external tool polling the SAP system. There is no ODP. There is no RFC replication. The SAP system becomes the producer; Azure becomes the consumer.
This uses SAP's Internet Communication Manager (ICM) for outbound HTTPS — an always-available, always-compliant channel built into every SAP NetWeaver system since BASIS 7.02. It is the same pattern Google's ABAP SDK uses to push data to BigQuery, and it is the pattern the Skynome ABAP Azure SDK is designed to implement for the Microsoft stack.
The trade-off: This requires ABAP development inside the SAP system. That means BASIS involvement, transport management, SAP change management approval, and ABAP development resources. The build timeline is weeks, not days. But the result is an architecture with no external dependency, no SAP certification risk, and no exposure to future SAP policy changes about third-party tool access.
When to use it:
- ECC systems where OData is not available
- High-volume scenarios where full-table RFC loads are too slow
- Near-real-time requirements (push on commit, not batch polling)
- When you want an architecture that is structurally immune to future SAP policy changes
- When governance and auditability of the extraction layer matter
Side-by-Side Comparison
| | SAP Table Connector | ODP via OData | ABAP Push | |---|---|---|---| | Compliant with Note 3255746 | ✓ Yes | ✓ Yes | ✓ Yes | | Works on ECC | ✓ Yes | Partial | ✓ Yes | | Native delta | ✗ No | ✓ Yes | ✓ (custom) | | Near-real-time | ✗ No | Partial | ✓ Yes | | SAP-side development | None | Low | Medium–High | | Tool dependency | ADF still required | ADF or HTTP client | None external | | Migration speed | Fast (days) | Medium (weeks) | Slower (weeks–months) | | Architecture longevity | Medium | High | Highest | | Large table performance | Limited | Limited | High |
How to Choose
If your landscape is S/4HANA and you had BW DataSource or CDS extraction: Start with ODP via OData. It preserves your delta mechanism, requires the least rearchitecting, and is SAP's own recommended path. The ADF OData connector handles the consumption side.
If your landscape is ECC and your tables are medium-sized: ADF SAP Table connector is your fastest migration path. Implement a date-field delta or use ADF's built-in incremental copy with a watermark. Accept the trade-off on delta granularity.
If your landscape is ECC with large tables, or you need near-real-time delta, or you are building for the next five years: ABAP Push is the right answer. It is more investment upfront, but it solves the problem permanently and gives you a data integration architecture that SAP cannot break with a future support note.
Many teams will use a combination of all three. OData for S/4HANA semantic layer extractions, RFC Table Read for small reference data, and ABAP Push for the high-volume transactional tables (BSEG, ACDOCA, VBAK) where performance actually matters.
The Timeline You Cannot Ignore
The December 2026 fallback expiry is not like a software end-of-life date that gets extended because enough customers complain. SAP has structured this as a security enforcement — the same framing they use for cryptographic deprecations and vulnerability remediations. There is no precedent for reversing this kind of decision. The only organisations that will still have working SAP data extraction in January 2027 are the ones that migrated before December 2026.
Working backward from December:
- August: Run Note 3439624, classify all active ODP-RFC consumers, select your replacement architecture per pipeline
- September: Build and test replacements in non-production
- October: Migrate production pipelines, one by one, starting with Tier 1 (critical and high-volume)
- November: Complete all Tier 2 migrations, decommission ODP subscriber registrations
- December: System clean — no active ODP-RFC subscribers, fallback mechanism irrelevant
This is a five-month programme if you start today. It is a two-month panic if you start in October.
Where Skynome Fits
If you are an ADF-centric SAP on Azure shop and you are looking at your Note 3439624 output for the first time, the Skynome engagement model is designed for exactly this moment:
ODP Compliance Review — A focused 2-4 week engagement. We review your Note 3439624 output, map your active ODP-RFC consumers, assess your ECC/S4 landscape, and recommend the correct replacement architecture per pipeline. You receive a migration roadmap, a GRS Domain 7 compliance score, and a board-ready assessment of your ODP risk. Starting from $15,000.
ABAP Push Architecture build — If your assessment points to ABAP Push as the right answer, we partner with ABAP development resources to build the push patterns for your specific tables and target (ADLS2, Event Hubs, or Fabric). Built on the Skynome ABAP Azure SDK.
Contact us or start with a Governance Readiness Score assessment to see where your current extraction compliance stands across all nine governance domains.
The pipeline is broken. The deadline is December. Start the work now.
This post reflects Skynome's analysis of SAP Note 3255746 (Version 11, April 2026), SAP Note 3439624, and observed pipeline behaviour in Azure Data Factory post-June 2026 enforcement. Microsoft has acknowledged the impact of the ODP-RFC restriction on the SAP CDC connector. Skynome is independent of both SAP and Microsoft.
How governed is your SAP estate?
The Governance Readiness Score measures your SAP on Azure environment across 9 domains — from AI sovereignty to data extraction compliance. Get your score.
Start Crisis Assessment