ODP-RFC Is Now Technically Blocked: The Complete Reference for June 2026
On June 9, 2026, SAP activated the ODP-RFC security block. Azure Data Factory's SAP CDC connector, Fivetran, Qlik Replicate, Talend, and Informatica are all broken. Here is the complete reference: what is banned, what still works, and the three compliant architectures that replace ODP-RFC.
This is not a future risk. ODP-RFC is technically blocked as of June 9, 2026. If your pipelines are still running, you are on SAP's temporary fallback mechanism — which expires December 2026. After that, there is no grace period and no supported path back. This post is the complete technical reference for what happened, what it means, and what you build next.
On June 9, 2026, SAP activated the security enforcement behind Note 3255746. It was not announced with fanfare. There was no press release. SAP delivered it as a Support Package, the way it delivers everything significant — quietly, in the maintenance stream, with the full expectation that enterprises would absorb it during their next scheduled system update.
The consequence is not quiet at all.
Azure Data Factory's SAP CDC connector is broken. Fivetran's SAP NetWeaver connector is broken. Qlik Replicate, Talend, and Informatica — any tool that extracted SAP data via the ODP replication API over RFC — is broken. This is the single largest forced migration event in SAP data integration history, affecting the primary extraction method of the majority of the SAP installed base.
This post is the complete technical reference. It covers exactly what is blocked, what is not, the December 2026 deadline, and the three compliant architectures that replace ODP-RFC. Every claim is traceable to SAP's own notes.
The Four Numbers That Define the Crisis
What SAP Note 3255746 Actually Says
SAP Note 3255746 reached Version 11 in April 2026. The position it articulates is unambiguous:
The ODP RFC modules are exclusively designed for data transfer between SAP applications. Any use of ODP-RFC by customer or third-party applications to access SAP ABAP systems — on-premises or in private cloud — is prohibited.
The June 2026 security patch delivered the technical enforcement mechanism behind that policy. Before the patch, the restriction was compliance-based: you were operating outside SAP's certified architecture, but the system would not stop you. After the patch, it is technically enforced: the SAP system actively blocks ODP-RFC calls from non-authorised consumers.
SAP also published Note 3439624 alongside this enforcement — a self-assessment tool that scans your SAP system and produces a report of every active ODP-RFC subscriber, every tool using it, and every volume of data extracted through it. Run this note before anything else. It gives you the complete picture of your exposure in under an hour.
Run SAP Note 3439624 today. Log in to your SAP Support Portal, download the correction, and execute the self-assessment report. The output tells you exactly which tools are using ODP-RFC in your system and how much data they have extracted. Without this baseline, you are remediating blind.
The Complete Reference: What Is Banned vs. What Works
This is the most important clarification in this post, and the one most teams are getting wrong.
SAP Note 3255746 bans ODP via RFC. It does not ban RFC as a protocol. Standard RFC table reads, BAPI calls, DeltaQ, and custom function modules over RFC remain fully permitted. Only the ODP replication API functions — the RODPS_REPL_* function module family — are blocked.
What is banned
RODPS_REPL_* function module familyWhat still works
| Extraction Method | Since | Notes |
|---|---|---|
| RFC Table Read | Always | RFC_READ_TABLE or custom function modules. Fully SAP-compliant. ADF SAP Table connector, Theobald XtractTable. |
| BAPI calls via RFC | Always | Business API layer. SAP-endorsed for transactional and read scenarios. Any RFC-capable tool. |
| DeltaQ (BW Extractors) | Always | Native SAP BW extractor framework. Full and delta loads. ADF SAP BW, Theobald DeltaQ. |
| ODP via OData (HTTP REST) | Note 3255746 | SAP's own recommended ODP-RFC replacement. HTTP-based, not RFC. Requires Netweaver Gateway. |
| ABAP CDS Views via OData | S/4HANA 1511+ | Standard S/4HANA extraction. Semantic views with delta. ADF OData connector. |
| ABAP Push to Cloud | Always | ABAP inside SAP pushes via cl_http_client. Microsoft ABAP SDK for Azure, Google ABAP SDK. |
| SLT Replication | Always | SAP-licensed and SAP-certified. Requires a dedicated SLT server and licence. |
| ABAP Add-on for Copy Jobs | 2025 | SAP-certified add-on installed in SAP system. Pushes directly to Microsoft Fabric. |
| SAP Business Data Cloud | 2025 | Premium SAP product connecting to Databricks. High licence cost. |
The Clarification Most Teams Miss
ODP-RFC is banned. RFC as a protocol is not. These are two different things, and conflating them is causing unnecessary panic — and unnecessary pipeline rebuilds — across the industry.
What stopped working: ODP via RFC
The specific RFC function modules used by the ODP framework to replicate data to third-party tools are now blocked. These modules — RODPS_REPL_INIT, RODPS_REPL_DELTA, and the broader RODPS_REPL_* family — were never public, documented API. SAP tolerated third-party use of them for years because demand existed and enforcement was absent. Note 3255746 ended the tolerance. The June 2026 patch ended the access.
Who is directly impacted:
- Azure Data Factory's SAP CDC connector (uses ODP-RFC for all SAP source types)
- Fivetran SAP NetWeaver connector
- Qlik Replicate SAP ABAP source
- Talend SAP source components using ODP
- Informatica Intelligent Cloud Services SAP connectors
- Any custom ABAP or third-party code that called
RODPS_REPL_*functions from non-SAP contexts
What still works: RFC as a protocol
RFC remains the backbone of SAP integration and is completely unaffected by Note 3255746. What you can still do over RFC, today, with no compliance concern:
- Read any SAP database table using
RFC_READ_TABLEor custom function modules - Call any BAPI for transactional reads and updates
- Use DeltaQ to extract BW extractor data with full delta support
- Execute any custom ABAP function module exposed via RFC
- Use ADF's SAP Table connector — this uses RFC table reads, not ODP, and is unaffected
If your tool is using RFC to read tables or call BAPIs, you are not affected by this note. If it is using RFC to call ODP replication functions, you are.
The Three Compliant Architectures
With ODP-RFC eliminated, three architectural patterns replace it. They serve different scenarios. The right choice depends on your SAP system version, data volume, delta requirements, and cloud target.
Architecture 1 — Table RFC Pull (Immediate, No Migration)
External Tool
│
├─ RFC (port 3300) ─────────────────────────────────────────► SAP System
│ │
│ RFC_READ_TABLE / Custom FM / ADF SAP Table connector ▼
│ Database Tables
│◄────────────────────────────────────────────────── Result set (rows)
│
▼
Cloud Target (ADLS2, Synapse, Databricks, Snowflake)
Best for: Full load scenarios, master data, reference data, reporting extracts. Tools: ADF SAP Table connector (unaffected), Theobald XtractTable, any RFC client. Limitation: No built-in delta tracking. Must implement watermark or full reload logic. Compliance: Fully SAP-compliant. No ODP involved.
Architecture 2 — ODP via OData (SAP's Recommended Replacement)
External Tool / Azure Data Factory OData connector
│
├─ HTTPS (port 443) ──────────────────────────────────────► SAP System
│ │
│ OData service URL: /sap/opu/odata/sap/[SERVICE_NAME] ▼
│ ODP Framework (HTTP)
│◄────────────────────────────────────────────────── JSON/Atom response
│
▼
Cloud Target
Best for: Scenarios that previously used ODP-RFC for delta extraction. ODP via OData exposes the same ODP sources — DataSources, CDS views, BW InfoProviders — but over HTTP instead of RFC. Tools: ADF OData connector, SAP-native OData services, custom REST clients. Limitation: Requires SAP Netweaver Gateway configuration. Performance is lower than RFC for very high volumes. Compliance: SAP's own recommended replacement. Explicitly endorsed in Note 3255746.
Architecture 3 — ABAP Push to Cloud (The Future-Proof Pattern)
SAP System (ECC or S/4HANA)
│
├─ ABAP program / scheduled job ──────────────────────────────────────────┐
│ │
│ cl_http_client / cl_web_http_client_manager │
│ → HTTPS outbound via ICM (port 443) │
│ → OAuth 2.0 token to Azure Entra ID ▼
│
├───────────────────────────────────────────► Azure Data Lake Gen2 (HDFS)
│ │
│ ├── Microsoft Fabric Lakehouse
│ ├── Azure Databricks / HDInsight
│ └── Azure Synapse Analytics
│
└───────────────────────────────────────────► Azure Event Hubs (streaming CDC)
│
└── Azure Stream Analytics → Fabric
Best for: Legacy ECC customers who cannot upgrade, high-volume scenarios, real-time CDC via streaming. Tools: Microsoft ABAP SDK for Azure (open source, MIT license) — covers Event Hubs, Service Bus, Blob Storage, Key Vault, Azure OpenAI, and more. Key advantage: ABAP code runs inside SAP and pushes data out. There is no external tool pulling — no RFC port exposure, no ODP dependency, no certification requirement. Works on SAP ECC 6.0 EhP5+ (BASIS 702+) with no OS upgrade. Compliance: Fully compliant. This is the same pattern Google uses for its ABAP SDK for Google Cloud, which has pushed data to BigQuery from SAP for years without any SAP Note concerns.
Microsoft has already published an open-source ABAP SDK for Azure at github.com/microsoft/abap-sdk-for-azure. It covers Event Hubs, Service Bus, Blob Storage, Key Vault, and Azure OpenAI. If you have an ABAP developer on your team, this is the fastest path to a compliant, ODP-free architecture — without purchasing any new SAP licence or replacing your extraction infrastructure.
What to Do in the Next 30 Days
The temporary fallback mechanism gives you a window. It is not large, and it does not renew.
Week 1 — Know your exposure: Run SAP Note 3439624. Export the full report of ODP-RFC subscribers in your system. For each subscriber, record the tool, the ODP provider type, the extraction frequency, and the downstream business impact.
Week 2 — Classify and prioritise: Separate your pipelines into three tiers: (A) production-critical feeds powering live dashboards or financial processes, (B) operational reporting and analytics, (C) archive, development, and non-production extracts. Tier A must be migrated first. Tier C can wait.
Week 3 — Choose your replacement architecture per pipeline:
- If your tool has an OData connector (most modern tools do): switch to ODP via OData. This is the lowest-effort migration for tools that support it.
- If you are using ADF's SAP CDC connector: replace it with ADF's SAP Table connector for full loads, and evaluate the ODP OData approach for delta scenarios.
- If you are on legacy ECC with no upgrade path: evaluate the ABAP push architecture via the Microsoft ABAP SDK for Azure.
Week 4 — Migrate Tier A, activate governance: Begin migration of your Tier A pipelines. Simultaneously, establish extraction governance: know which extraction methods are in use, which are SAP-certified, and which carry remaining risk. This is the layer that most organisations have never had.
Do not apply the June 2026 SAP Support Package until your migration plan is in place. Once you apply it, the fallback mechanism is removed from your system and ODP-RFC calls will fail immediately. Time your Support Package application to coincide with completed pipeline migration — not before.
The Governance Layer That Nobody Has
The harder lesson of Note 3255746 is not about the extraction tools. It is about governance.
Every enterprise affected by this note had a compliance gap long before June 2026. They were running extraction architectures that were not SAP-certified, not tracked in any compliance register, and not governed by any SLO or audit framework. They discovered the problem when the pipelines broke — not before.
That pattern repeats. The organisations that emerge from the ODP-RFC crisis with the least damage are the ones that invest in extraction governance: knowing what extraction methods are in use, which are certified, what the compliance posture of each pipeline is, and what the remediation path looks like before the next SAP Note changes the rules again.
The Governance Readiness Score (GRS) Domain 9 measures your data extraction compliance posture across nine questions — covering extraction method certification, Datasphere cost governance, pipeline observability, and DR readiness. If your score in Domain 9 is in the Critical or Developing band, you are one Support Package away from a production crisis.
The Governance Readiness Score measures exactly where you stand. Start there.
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