The ABAP Push Architecture: Why SAP Code Should Send Data, Not Receive It

There is a framing problem in how the SAP data integration industry talks about the ODP ban.

Most of the conversation is about replacement pull mechanisms — what tool can I substitute for ADF's SAP CDC connector, which other extraction method is compliant, how do I restructure my pipeline so an external system can still read SAP data over the network. The question being asked is: what pulls instead of ODP?

The ABAP Push Architecture asks a different question entirely: why is something external pulling at all?

The data is in SAP. The authority over that data — when it changes, what it means, what rules govern it — is in SAP. The business logic that determines what constitutes a delta is in SAP. And yet the conventional integration architecture requires an external tool to reach across the network, authenticate, call function modules, and retrieve data on a schedule — all while SAP's security posture is tightening around exactly those mechanisms.

The ABAP Push Architecture reverses the direction. ABAP code running inside SAP detects data changes and initiates an outbound HTTPS call to Azure. The SAP system is the producer. Azure is the consumer. The data moves out from the inside — authenticated, structured, governed, and fully compliant with SAP Note 3255746 — without any external tool needing to touch the SAP system at all.

This is not a new idea. It is what Google's ABAP SDK for Google Cloud has been doing since 2022. It is what Microsoft's ABAP SDK for Azure implements for Event Hubs and Blob. What has changed is the urgency. In June 2026, ODP-RFC was technically blocked. The pull model's most capable tool is gone. The push model is no longer a forward-looking option — it is the migration target.

---

The Core Insight: ICM Is Always On

Every SAP NetWeaver system since BASIS 7.02 has an Internet Communication Manager. The ICM is the component that handles all HTTP and HTTPS communication in both directions — inbound requests to the SAP system and outbound requests from ABAP code to external services.

The outbound channel is the key. When ABAP code calls CL_HTTP_CLIENT=>CREATE_BY_URL, it is using the ICM to make a standard HTTPS request to any URL the system can reach — including Azure REST APIs. This requires:

• The ICM to be running (it is, by default, in every production system)
• An SSL certificate bundle that includes Azure's root CA (standard configuration)
• A network path from the SAP system to Azure endpoints (outbound HTTPS on port 443)
• An ABAP user with authorisation to create HTTP sessions

This is categorically different from an external tool using RFC on port 3300. RFC requires an SAP-side open port, SAP system credentials, and registration in the SAP router table. Port 3300 is what SAP Note 3255746 is effectively locking down by prohibiting the ODP API that sat on top of it. Port 443, outbound from SAP, has no such restriction. It is the same channel SAP uses for Update Manager downloads, SOAP web service calls, and SAP Business Connector traffic.

---

What Changes Architecturally

The conventional pull model looks like this:

External tool
  → authenticate via RFC (port 3300)
  → call ODP replication API (RODPS_REPL_* — now blocked)
  → receive delta records
  → write to Azure Data Lake / Synapse / Fabric

The ABAP Push model looks like this:

ABAP program (inside SAP)
  → detect data change (batch schedule / change pointer / IDoc)
  → serialize records to JSON
  → acquire OAuth 2.0 token from Azure Entra ID (outbound HTTPS)
  → POST to Azure Data Lake Gen2 / Event Hubs / Service Bus (outbound HTTPS)

There is no external tool touching the SAP system. There is no open RFC port. There is no ODP subscriber registration. There is nothing for SAP Note 3255746 to prohibit, because the ABAP code is not using ODP at all. The data movement is initiated from inside the SAP trust boundary, authenticated using Azure's standard OAuth 2.0 client credentials flow, and delivered directly to the Azure service.

The SAP system needs one outbound network path: HTTPS on port 443 to Azure endpoints. In most corporate landscapes, this is already open — the same path used for SAP SOAP web services and BTP Cloud Connector traffic.

---

The Three Push Scenarios

Not all SAP data has the same latency, volume, or change-detection requirements. The ABAP Push Architecture addresses this with three distinct patterns, each suited to different data characteristics.

Scenario 1 — Batch Full Load

When to use it: Reference data, master data, configuration tables. Data that changes infrequently and can tolerate a daily or weekly full refresh. Tables like T001 (company codes), LFA1 (vendor master), KNA1 (customer master), MARA (material master).

How it works: A scheduled ABAP programme (via SM36 background job) reads the target table using a SELECT statement, serialises each record to a JSON array, and POSTs the payload to Azure Data Lake Gen2 using a structured path convention:

/raw/{sap-sid}/{table-name}/{YYYY}/{MM}/{DD}/full_{timestamp}.json

The ABAP code uses CL_HTTP_CLIENT for the HTTPS transport and the Azure Blob REST API or ADLS2 PUT endpoint for the write. Authentication uses an OAuth 2.0 client credentials grant — the ABAP code requests a bearer token from Azure Entra ID's token endpoint, caches it in memory for the session, and attaches it as an Authorization: Bearer header to every Azure API call.

Delta strategy: Date field watermark. For tables with AEDAT (changed-on date) or ERDAT (created-on date), the programme filters to records changed since the last run. This is not change-data-capture — it is a scoped full load of changed rows. For tables without date fields, a periodic full table scan is acceptable for small reference tables.

Volume ceiling: Practical limit is roughly 50 million rows per run at ~1–2 million rows per minute over HTTPS from an E-series ABAP system. For larger tables, partition by date range across multiple background job steps.

Scenario 2 — Near-Real-Time CDC via Change Documents

When to use it: Transactional tables where delta tracking matters and where SAP has change document logging enabled. Suitable for FI postings, SD order changes, MM goods movements. Tables: BKPF/BSEG (FI documents), VBAK/VBAP (SD orders), MKPF/MSEG (goods movements).

How it works: SAP maintains a change document log in CDHDR (change document header) and CDPOS (change document item). Every change to a business object with change document logging active creates entries in these tables with the object key, changed field, old value, new value, and timestamp.

The ABAP Push programme runs on a short cycle (every 5–15 minutes via a self-scheduling background job) and does the following:

1. Reads CDHDR for records created since the last watermark timestamp
2. Joins to CDPOS for field-level change details
3. Reads the current state of the changed objects from the source table using the object keys from CDHDR
4. Serialises the change events — object key, timestamp, changed fields, current state — to JSON
5. POSTs each batch to Azure Event Hubs as a stream of events (one event per changed object)
6. Updates the watermark in a custom Z-table (ZSKYN_PUSH_WM) to the last processed timestamp

Azure Event Hubs receives a stream of structured change events, retains them for up to 7 days (or longer with dedicated clusters), and makes them available to downstream consumers — Azure Stream Analytics, Fabric Real-Time Intelligence, or custom consumers via the Kafka-compatible endpoint.

Change document coverage: Not all SAP tables have change document logging. The tables that matter most for analytics (FI/CO/SD/MM) generally do. Custom tables require change document classes (SCDO transaction) — a one-time BASIS configuration step.

Scenario 3 — Event-Driven Push via IDoc Ports

When to use it: Business event-driven scenarios where you want to trigger downstream processing the moment a specific transaction completes — GR/GI posting, sales order confirmation, invoice posting, payment clearing. Latency target: seconds, not minutes.

How it works: SAP's IDoc framework supports custom port types. You can define an HTTP port that delivers IDocs to an external endpoint instead of a file or RFC connection. Combined with a custom NACHN user exit or a BAdI on the relevant transaction, you can configure SAP to deliver a structured IDoc to an Azure Service Bus endpoint the moment the business event completes.

The ABAP Push pattern here uses a custom IDoc port class that:

1. Receives the outbound IDoc from SAP's standard outbound processing
2. Serialises the IDoc segments to JSON (or leaves them in the IDoc XML format)
3. Acquires an OAuth 2.0 token from Azure Entra ID
4. POSTs the payload to Azure Service Bus using the REST API

Service Bus receives each business event as a message, guarantees at-least-once delivery, and makes it available to downstream consumers — Logic Apps, Azure Functions, Fabric pipelines, or custom event processors.

Ordering and deduplication: Service Bus sessions can preserve ordering per document number. Idempotency keys (IDoc number + change sequence) allow downstream consumers to handle at-least-once delivery without duplicating records.

---

ECC Compatibility: The Critical Detail

The ABAP Push Architecture is compatible with SAP ECC 6.0 EhP5+ (BASIS 702 and above). This covers the vast majority of the approximately 17,000 ECC customers still running on-premise or hosted infrastructure.

The three core ABAP classes required are:

| Class | Availability | Purpose | |---|---|---| | CL_HTTP_CLIENT | BASIS 702+ | HTTP/HTTPS client factory | | CL_HTTP_ENTITY | BASIS 702+ | Request/response body manipulation | | CL_ABAP_CONV_OUT_CE | BASIS 702+ | UTF-8 encoding of request body |

No BTP. No Cloud Connector. No S/4HANA upgrade. No new SAP licence. The ICM outbound channel has been available since BASIS 7.02, which shipped with ECC 6.0 EhP4 — released in 2011. If you are running ECC 6.0 with a support package stack from the last five years, you have everything you need.

The one infrastructure prerequisite is outbound HTTPS access from the SAP application server to Azure endpoints (*.blob.core.windows.net, *.servicebus.windows.net, *.eventhub.windows.net). In most landscapes this is already open. Where it is not, a single firewall rule change opens it — far simpler than opening RFC port 3300 bidirectionally, which is what the pull model required.

---

The OAuth 2.0 Flow in ABAP

The authentication pattern is the same across all three push scenarios. ABAP code requests a bearer token from Azure Entra ID using the client credentials grant — a service-to-service OAuth flow where the SAP system authenticates as an Azure App Registration using a client ID and client secret.

The flow in ABAP:

" Step 1: Build the token request
DATA(lo_http) = CL_HTTP_CLIENT=>CREATE_BY_URL(
  url    = 'https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/token'
  scheme = IF_HTTP_CLIENT=>CO_ENABLED ).

lo_http->request->set_method( IF_HTTP_REQUEST=>CO_REQUEST_METHOD_POST ).
lo_http->request->set_header_field(
  name  = 'Content-Type'
  value = 'application/x-www-form-urlencoded' ).

DATA(lv_body) = 'grant_type=client_credentials'
  && '&client_id=' && lv_client_id
  && '&client_secret=' && lv_client_secret
  && '&scope=https%3A%2F%2Fstorage.azure.com%2F.default'.

lo_http->request->set_cdata( lv_body ).
lo_http->send( ).
lo_http->receive( ).

" Step 2: Parse the token from the JSON response
" (Use ABAP JSON library or string parsing on lv_response)
" Store token in class attribute for session reuse

" Step 3: Use the token for every Azure API call
DATA(lo_adls) = CL_HTTP_CLIENT=>CREATE_BY_URL(
  url    = 'https://{account}.dfs.core.windows.net/{container}/{path}'
  scheme = IF_HTTP_CLIENT=>CO_ENABLED ).

lo_adls->request->set_method( IF_HTTP_REQUEST=>CO_REQUEST_METHOD_PUT ).
lo_adls->request->set_header_field(
  name  = 'Authorization'
  value = 'Bearer ' && lv_access_token ).
lo_adls->request->set_header_field(
  name  = 'Content-Type'
  value = 'application/json' ).
lo_adls->request->set_cdata( lv_json_payload ).
lo_adls->send( ).

The token has a 1-hour expiry. A well-implemented push module caches the token and only requests a new one when the expiry is approaching — reducing authentication overhead for high-frequency push scenarios.

The client ID and client secret are stored in the SAP Secure Store (SSFR transaction) or in a custom configuration table with field-level encryption — never in hardcoded ABAP. The Azure App Registration is granted only the minimum required roles: Storage Blob Data Contributor for ADLS2, Azure Event Hubs Data Sender for Event Hubs, Azure Service Bus Data Sender for Service Bus.

---

Why This Architecture Is Structurally Immune to Future SAP Policy Changes

The pull model's vulnerability is that it depends on SAP-side APIs that SAP controls. ODP-RFC was tolerated for years as a de-facto interface. SAP Note 3255746 withdrew that tolerance with a security patch. The same pattern — SAP tolerating third-party use of internal APIs, then withdrawing it — could repeat with any other RFC-based extraction mechanism.

The ABAP Push model has no such exposure. It does not use any SAP-controlled API for the data extraction. The ABAP programme reads data using SELECT statements on the application's own tables — the same mechanism that every ABAP developer uses in every ABAP programme. SAP cannot prohibit ABAP programmes from reading their own data. And the delivery mechanism — HTTPS from the ICM to Azure — uses Azure's APIs, which Azure controls, not SAP's.

SAP can change its RFC security posture. It cannot change the behaviour of Azure's REST API.

There is a second dimension to this immunity. The ABAP code that implements the push logic is a customer transport — it lives in the customer namespace (Z- or /SKYN/ namespace), travels through the customer's CTS, and is subject to the customer's change management. SAP patches do not touch customer transports. A future Support Package that changes SAP's internal function module surface cannot break customer ABAP code that does not call those function modules.

---

The Governance Layer

Raw ABAP code that pushes data to Azure is a starting point, not a finished architecture. In production, the push layer needs:

Audit logging. Every push event — table name, row count, bytes transmitted, timestamp, success/failure, target endpoint — should be written to a custom log table (ZSKYN_PUSH_LOG). This table provides the audit trail that compliance teams and data governance reviews require.

Error handling and retry. Azure APIs return HTTP 429 (rate limited) and 5xx (transient errors). The ABAP code must handle these gracefully — exponential backoff, dead-letter queue for permanently failed records, alert on repeated failures.

PII classification. Before any data leaves the SAP system, fields containing personal data (customer names, addresses, bank details, employee data) should be classified and either masked, tokenised, or excluded based on the target data zone (raw, curated, consumer-ready). This is governance that external pull tools cannot implement — they receive whatever the SAP system exposes. ABAP Push can enforce field-level policy before the data crosses the system boundary.

Telemetry. Push volume, latency, error rate, and data freshness should stream to Azure Monitor as custom metrics. This gives you end-to-end observability: from the moment the ABAP programme fires, through the Azure Event Hubs ingestion, to the Fabric or Synapse consumer processing.

This governance layer is what the Skynome ABAP Azure SDK adds on top of the base push pattern — a structured /SKYN/ namespace implementation that includes logging, error handling, PII classification, and telemetry as first-class capabilities alongside the core HTTP transport.

---

How to Start

The fastest path to ABAP Push in production is:

Week 1. Run SAP Note 3439624 to get your complete ODP-RFC exposure list. Identify the Tier 1 tables (high-volume, production-critical) that need to migrate first.

Week 2. Validate ICM outbound connectivity. From the SAP system, use transaction SMICM to verify the ICM is running, and test a simple outbound HTTPS call using CL_HTTP_CLIENT to a public endpoint. Confirm port 443 is open outbound from the app server IP.

Week 3. Build the authentication module. Implement the OAuth 2.0 client credentials flow in a reusable ABAP class. Test against your Azure Entra ID tenant. Store the client secret in SAP Secure Store.

Week 4. Implement Scenario 1 (Batch Full Load) for your first Tier 1 table. Schedule it as a background job. Verify data arrives in ADLS2. Compare row counts against the source. Decommission the equivalent ODP-RFC pipeline.

Weeks 5–8. Implement Scenario 2 (CDC) for high-value transactional tables. Add the governance layer (logging, error handling, PII classification). Connect Azure Event Hubs to your downstream consumer (Fabric Real-Time Intelligence, Stream Analytics, or Azure Functions).

The complete implementation — authentication, ADLS2 push, Event Hubs push, logging, error handling — is approximately 1,500–2,500 lines of ABAP across 6–8 classes. An experienced ABAP developer can build and test this in 4–6 weeks for a focused scope. The Skynome ABAP Azure SDK packages this as transportable objects, reducing the build from weeks to days for the core transport modules.

---

Where Skynome Fits

The ABAP Push Architecture is not something you hire Skynome to build for you entirely. The ABAP development sits with your BASIS and ABAP team (or an ABAP partner). What Skynome provides:

Architecture design. Which tables use Batch Full Load, which use CDC, which use IDoc ports. Data zone design for ADLS2. Event schema design for Event Hubs. This is the work that takes three weeks to do well and six months to redo badly.

Governance framework. The logging, PII classification, telemetry, and error handling that turn raw ABAP HTTP calls into a governed data movement layer. This is what the Skynome ABAP Azure SDK implements in the /SKYN/ namespace.

GRS Domain 7 assessment. After your push architecture is live, a Governance Readiness Score assessment validates your extraction compliance posture against the 8 questions in Domain 7 — including the June 2026 enforcement and December 2026 deadline.

If you are scoping a migration from ODP-RFC to ABAP Push, contact us or start with the GRS assessment to understand your current compliance posture.

The direction of SAP data integration has changed. The tools that pull from SAP are being restricted, one by one. The architecture that pushes from SAP is unrestricted by design, compliant by default, and built on the same mechanisms SAP uses for its own cloud integrations.

---

Technical details in this post reflect observed behaviour on SAP ECC 6.0 EhP5+ systems with BASIS 7.02 and above. ABAP code patterns are illustrative — production implementations require ABAP developer review, security assessment, and appropriate change management. Microsoft ABAP SDK for Azure is an open-source project maintained by Microsoft. Skynome is independent of SAP and Microsoft.