Microsoft ABAP SDK for Azure: What It Covers, What It Doesn't, and What You Need to Build on Top

In 2023, Microsoft quietly published a GitHub repository called abap-sdk-for-azure. It received almost no marketing attention. There was no Azure blog announcement. No Ignite keynote mention. It appeared in the Microsoft GitHub organisation, accumulated a few hundred stars, and became a reference implementation that most SAP teams have never heard of.

That is a mistake worth correcting — because in the context of the June 2026 ODP-RFC ban, the Microsoft ABAP SDK for Azure is one of the most practically important open-source repositories in the SAP data integration space right now.

It is also incomplete in ways that matter for production analytics pipelines. This post is a technical review: what the SDK covers, how each module works, what is missing, and what you need to build on top of it for a production-grade SAP-to-Azure data integration architecture.

---

What the SDK Is

The Microsoft ABAP SDK for Azure is an open-source collection of ABAP classes that enable SAP NetWeaver ABAP systems to communicate with Azure services over HTTPS. It uses the ICM outbound channel — CL_HTTP_CLIENT — and implements the Azure REST APIs for each supported service. It ships as SAP transport files (.cofile and .datafile) that you import into your SAP system via transaction STMS.

The code is maintained by Microsoft's SAP on Azure engineering team. It is licensed under MIT. The GitHub repository is at github.com/microsoft/abap-sdk-for-azure.

It is not a Microsoft product in the sense that comes with support SLAs. It is a reference implementation with solid code quality, reasonable documentation, and active maintenance from Microsoft engineers who work on SAP Azure integrations. Using it in production is a legitimate choice — the same way using any well-maintained open-source library is a legitimate choice.

The SDK targets the Z namespace (customer namespace) in the SAP system, meaning all classes are prefixed ZCL_AZ_ and all function modules follow the Z_AZ_* convention. This means it does not require a registered SAP development namespace, which lowers the barrier to entry significantly.

---

What It Covers: Module by Module

Azure Event Hubs (`ZCL_AZ_EH_*)

The Event Hubs module is the most mature and most frequently used component. It implements the Event Hubs REST API — specifically the Send Event operation — and handles:

• HTTPS transport via CL_HTTP_CLIENT to the Event Hubs namespace endpoint
• Shared Access Signature (SAS) authentication — generating the time-limited SAS token that Event Hubs requires for REST API calls
• Batch event publishing — sending multiple events in a single HTTPS request, which is critical for throughput
• Partition key support — allowing the calling code to control which partition events land on, enabling ordering guarantees

For near-real-time CDC scenarios — ABAP code detecting changes in CDHDR/CDPOS and publishing change events — the Event Hubs module works correctly out of the box. It is what you use when you need SAP data in Azure Stream Analytics, Fabric Real-Time Intelligence, or any Kafka-compatible consumer within seconds of a SAP transaction completing.

What it does not cover: Consumer groups, checkpoint management, or event replay. The SDK sends events — it does not consume them. Partition assignment strategy for high-volume scenarios requires additional wrapper logic.

Azure Service Bus (`ZCL_AZ_SB_*)

The Service Bus module implements the REST API for queue and topic message operations:

• Send message to a queue or topic
• Receive and delete — pull a message from a queue
• SAS token generation for authentication
• Message properties — setting custom headers that downstream consumers can route on

The primary SAP use case is event-driven push: a sales order confirmation, a goods issue posting, or a payment clearing triggers an IDoc or a BAdI, which calls the Service Bus module to deliver a structured message to Azure. Logic Apps, Azure Functions, or Power Automate pick it up within seconds.

What it does not cover: Dead-letter queue management, scheduled messages, or session-based message ordering from ABAP. These require additional wrapper classes.

Azure Blob Storage (`ZCL_AZ_BS_*)

This is a foundational module and is where a significant gap appears for analytics pipelines — but more on that in the gap section. The Blob Storage module covers:

• Upload blob — writing a file or data payload to a Blob container
• Download blob — reading a blob back into ABAP
• Delete blob — removing an object
• List blobs — enumerating container contents
• Shared Key authentication — using the storage account name and key (or SAS token) for authentication

For simple scenarios — ABAP pushing a CSV extract to a Blob container, or reading a configuration file from Blob — this works well. The authentication implementation is correct, and the HTTP wrapper handles chunked encoding for large payloads.

The gap: This module targets Azure Blob Storage (blob.core.windows.net). It does not implement the Azure Data Lake Storage Gen2 REST API (dfs.core.windows.net). These are different APIs. ADLS2 supports hierarchical namespaces, directory-level ACLs, and atomic rename operations — capabilities that Blob Storage lacks and that analytics pipelines (specifically Delta Lake / Parquet landing zones on Fabric and Synapse) depend on. A pipeline that writes to blob.core.windows.net with a flat namespace is not the same as a pipeline that writes to a governed Delta Lake landing zone on ADLS2.

Azure Key Vault (`ZCL_AZ_KV_*)

The Key Vault module enables ABAP code to retrieve secrets from Azure Key Vault at runtime, rather than hardcoding credentials or storing them in SAP configuration tables. It implements:

• Get secret — retrieve a secret value by name
• OAuth 2.0 client credentials authentication to Key Vault (using an Azure App Registration with Key Vault Secrets User role)
• Secret version management — access specific versions of a secret

This is a security best practice module. Instead of storing your Event Hubs SAS key or ADLS2 storage account key in a SAP Z-table, you store a reference to the Key Vault secret name, and the ABAP code retrieves the live secret at runtime. Secret rotation in Key Vault propagates automatically — no SAP configuration changes required.

For production use: Combine Key Vault with ABAP session-level caching. Retrieving a secret is an HTTPS round-trip — you do not want this on every record. Cache the secret value for the duration of a background job run.

Microsoft Entra ID (`ZCL_AZ_AUTH_*)

This is the authentication foundation that the other modules build on. It implements the OAuth 2.0 client credentials grant — the standard service-to-service authentication flow where the SAP system authenticates as an Azure App Registration:

• Token acquisition — POST to login.microsoftonline.com/{tenant-id}/oauth2/v2.0/token
• Token caching — store the bearer token in memory and reuse until near-expiry
• Scope handling — correctly formatting the scope parameter for different Azure services

Every other module that uses OAuth 2.0 (as opposed to SAS tokens) delegates authentication to this module. If you are building custom extensions on top of the SDK, you use this module for all token management rather than reimplementing it.

Azure OpenAI (`ZCL_AZ_OPENAI_*)

This is the newest module in the SDK and the one that reflects where Microsoft's SAP engineering focus has shifted in 2025–2026. It implements:

• Chat completion — calling the Azure OpenAI chat completions endpoint with a prompt and receiving a structured response
• Embeddings — generating vector embeddings from SAP text data (product descriptions, customer notes, material text)
• Token counting — approximate token usage estimation before sending (relevant for cost control)

The practical SAP use cases are: ABAP code that calls Azure OpenAI to classify a customer complaint, enrich a vendor description, summarise a change document history, or generate a structured output from unstructured text in SAP custom fields.

What it does not cover: Streaming responses, function calling (tool use), multi-turn conversation management, or the Azure OpenAI Assistants API. For simple single-turn inference in ABAP, the module works. For complex agentic patterns, additional wrapper logic is needed.

---

What Is Missing: The Production Gap

The SDK covers six Azure services with solid implementations. For a development team writing their first ABAP push programmes, it removes weeks of work on authentication, HTTP transport, and Azure API semantics. That is genuine value.

But there are six gaps that matter for production SAP-to-Azure analytics pipelines — gaps that the SDK's current scope does not address.

Gap 1 — Azure Data Lake Storage Gen2

This is the most consequential gap for teams replacing ODP-RFC with ABAP Push.

ADF's SAP CDC connector wrote to ADLS2 — specifically the hierarchical namespace API (dfs.core.windows.net) that supports directory semantics, ACL-based access control, and the atomic directory rename that Delta Lake depends on. The SDK's Blob Storage module writes to the flat Blob API. These are different endpoints with different capabilities.

A production Delta Lake landing zone on Fabric or Synapse Analytics requires ADLS2 with hierarchical namespace. Writing to flat Blob Storage and calling it a data lake landing zone is a technical compromise that creates problems downstream: no atomic Delta commits, no directory-level security, no ACL inheritance for data zone boundaries.

The ADLS2 REST API is well-documented and implementable in ABAP — it uses OAuth 2.0 (which the SDK's Auth module handles) and standard HTTPS PUT/PATCH requests with specific headers (x-ms-hns-enabled: true, x-ms-version: 2020-02-10). It is simply not implemented in the current SDK.

Gap 2 — Microsoft Fabric Integration

Microsoft Fabric is the analytics platform that most SAP-on-Azure shops are consolidating toward in 2025–2027. Fabric's lakehouse uses ADLS2 with OneLake as the storage layer. Writing SAP data to a Fabric lakehouse from ABAP requires:

• ADLS2 API for the actual data write (Gap 1 above)
• Delta Lake format for compatible table writes (Parquet files + _delta_log transaction log)
• Fabric shortcut or workspace registration to make the data queryable

None of these are in the current SDK. Writing SAP data to Fabric in a way that Fabric can query as a Delta table without additional transformation requires a governance layer on top of the raw HTTPS transport.

Gap 3 — Governance and Audit Logging

The SDK has no built-in logging. Every push operation — success or failure, row count, bytes transferred, timestamp, target endpoint — disappears into the void unless the calling code implements its own logging.

For production analytics pipelines, this is not acceptable. When an auditor asks "how many records from BSEG were pushed to the data lake in March 2026, and were any rejected?", you need an answer. When a data quality issue surfaces in a Fabric report and the root cause investigation points to a SAP extraction, you need a traceable log of every push event.

A production governance logging table for ABAP Push needs at minimum: source table name, push timestamp, record count, byte count, target endpoint, HTTP response code, error message if applicable, watermark value used, and the background job number that triggered the run. None of this is provided by the SDK.

Gap 4 — PII Classification and Field-Level Masking

The SDK pushes whatever data you tell it to push. There is no concept of data sensitivity, no field classification, no masking or tokenisation layer.

For SAP ECC systems, this is a significant compliance risk. Tables like KNA1 (customer master) contain names, addresses, phone numbers, and VAT IDs. LFA1 (vendor master) contains similar PII. PA0002 (HR personal data) in HCM landscapes contains highly sensitive personal information. BSEC (one-time account data) in FI contains bank details and personal identification numbers.

A governed ABAP Push architecture needs to classify each field before it leaves the SAP trust boundary — masking direct identifiers, tokenising quasi-identifiers, and blocking or encrypting regulated fields based on the target data zone. The SDK provides no mechanism for this. The calling code is responsible for knowing what it is pushing, which in practice means each developer decides independently, with no systematic enforcement.

Gap 5 — Change-Data-Capture Patterns

The SDK implements the Azure-side transport. It says nothing about the SAP-side change detection. How do you know which records changed since the last push? How do you manage the watermark? What happens when a background job fails halfway through — does the watermark advance or stay at the last successful position?

The three ABAP Push scenarios described in our previous post — Batch Full Load, CDC via CDHDR/CDPOS, and Event-Driven IDoc Push — each require different SAP-side implementation patterns that are entirely outside the SDK's scope. The SDK assumes you know what data to push and when. The hard problem of detecting what changed and resuming safely after failure is left to the implementing team.

This is where most bespoke ABAP Push implementations accumulate technical debt. Watermark logic implemented inconsistently across five tables by five developers produces five subtly different failure modes. A structured CDC pattern library — with a standardised watermark table, failure recovery semantics, and duplicate-event handling — is the infrastructure that ABAP Push needs to be reliable at scale.

Gap 6 — Telemetry to Azure Monitor

The SDK does not emit metrics. There is no integration with Azure Monitor, Application Insights, or any observability platform. For a production data pipeline that runs every 15 minutes and pushes to a governed data lake, you need to know: is the pipeline running? What is the current lag (time since last push)? Is the data volume normal, or did something change? Did the last run fail?

An ABAP-native telemetry layer — one that streams custom metrics (push volume, latency, error count, data freshness) to Azure Monitor as custom metrics — transforms ABAP Push from a scheduled background job into a monitored data pipeline with the same observability as a native Azure pipeline.

---

The Gap Summary

---

How to Use the SDK Effectively

Given this gap analysis, the right approach is to treat the Microsoft ABAP SDK for Azure as what it is: a transport layer, not a complete data integration solution.

The SDK solves the hardest low-level problems: OAuth 2.0 client credentials flow in ABAP (non-trivial to implement correctly), SAS token generation for Event Hubs and Service Bus, and the HTTP request construction for each Azure service. Implementing these from scratch takes a competent ABAP developer approximately three weeks and produces code that still needs peer review for security correctness. The SDK eliminates that work.

What you build on top of it:

An ADLS2 module. Implement ZCL_SKYN_ADLS2 (or equivalent in your namespace) using the ADLS2 Data Lake REST API (dfs.core.windows.net). The Auth module from the SDK handles token acquisition. The HTTP transport is the same CL_HTTP_CLIENT pattern. The difference is the endpoint and the required headers for hierarchical namespace operations.

A governance logger. Create a custom table (ZSKYN_PUSH_LOG or equivalent) and a logger class that every push operation writes to — source table, timestamp, record count, bytes, target path, HTTP response code, error text, watermark. Index on timestamp and source table for fast audit queries.

A PII classification layer. Maintain a field classification table that maps SAP table/field combinations to sensitivity levels (public, internal, PII, regulated). Every push operation consults this table before serialising data and applies the appropriate transformation (mask, tokenise, exclude) at the field level.

A CDC library. Implement a watermark manager — a standardised pattern for reading CDHDR/CDPOS deltas, advancing the watermark only after successful push, and handling partial failures with a retry queue. Make this reusable across all tables that need CDC.

A telemetry emitter. After each push operation, emit a structured metric to Azure Monitor using the Custom Metrics REST API: push count, byte count, latency, watermark lag. Dashboard these in Azure Monitor Workbooks or Fabric Real-Time Analytics.

---

Where the Skynome ABAP Azure SDK Fits

The Skynome ABAP Azure SDK — currently in specification, planned for open-core release — is designed to fill exactly these gaps. It builds on top of the Microsoft SDK's transport layer and adds:

• /SKYN/CL_ADLS2 — ADLS2 hierarchical namespace write module, designed for Delta Lake–compatible landing zones on Fabric and Synapse
• /SKYN/CL_LOGGER — Structured governance audit log with indexed query support and retention management
• /SKYN/CL_PII — Field-level PII classifier using a maintained classification table, with mask, tokenise, and exclude actions per field
• /SKYN/CL_CDC — CDC watermark manager: CDHDR/CDPOS delta reader, watermark table (/SKYN/PUSH_WM), failure recovery, duplicate handling
• /SKYN/CL_METER — Telemetry emitter streaming push metrics to Azure Monitor as custom metrics

The Microsoft SDK provides the foundation. The Skynome SDK adds the governance layer on top. The combination is a complete ABAP Push architecture: transport-reliable, Delta Lake–compatible, PII-governed, audit-logged, and observable.

The Skynome SDK will be distributed as SAP transport files in the /SKYN/ registered namespace. Community Edition will be open-source. Professional Edition will add the PII classification engine and pre-built extraction templates for the most common ECC tables (BKPF/BSEG, VBAK/VBAP, MKPF/MSEG, KNA1, LFA1, MARA).

---

How to Get Started

Step 1 — Clone or download the SDK. The repository is at github.com/microsoft/abap-sdk-for-azure. The Transports folder contains the .cofile and .datafile pairs for each release.

Step 2 — Import to a development system. Use transaction STMS to import the transport files. Apply them in order: cofile first, then datafile. The SDK targets the Z namespace and requires no registered SAP development namespace.

Step 3 — Configure authentication. Create an Azure App Registration in your Entra ID tenant. Assign it the minimum required roles for the services you plan to use (Storage Blob Data Contributor for Blob, Azure Event Hubs Data Sender for Event Hubs). Store the client ID, client secret, and tenant ID in SAP Secure Store (SSFR transaction) or a custom encrypted configuration table.

Step 4 — Test the Auth module. Before building anything else, validate that ZCL_AZ_AUTH can successfully acquire a bearer token from your Entra ID tenant. A failing authentication setup breaks every downstream module — validate it first in isolation.

Step 5 — Build your first push. Start with Event Hubs or Blob Storage — the simpler modules. Push a test payload from a background job. Confirm it arrives in Azure. Add logging around the push operation even at this stage.

Step 6 — Plan your gap coverage. Decide which of the six gaps you need to address for your specific requirements. If you are targeting Fabric, ADLS2 is non-negotiable. If you are handling customer or employee data, PII classification is non-negotiable. Plan the build order and effort before you start production work.

If you are working through this process and need architectural guidance on the SAP side or the Azure side, contact us. The ABAP Push Architecture review is one of the primary engagement types Skynome offers for teams replacing ODP-RFC pipelines.

---

This review is based on the Microsoft ABAP SDK for Azure as available on GitHub as of August 2026. The SDK is an evolving open-source project — module coverage may expand over time. Skynome is independent of Microsoft and has no affiliation with the Microsoft ABAP SDK for Azure project. The Skynome ABAP Azure SDK is a separate, independently developed product that builds on the Microsoft SDK's transport layer. SAP namespace /SKYN/ registration is in process.