Introducing the ABAP Cloud SDK for Azure: a native, secure path from SAP ABAP Cloud to Azure
Overview The ABAP Cloud SDK for Azure is now available as open source. It gives developers building on SAP Business AI Platform, ABAP environment and S/4HANA Cloud a first-class way to call Azure REST APIs — through a layered HTTP pipeline, pluggable Microsoft Entra ID credentials, typed exceptions, and strongly typed service clients — instead of hand-rolling if_web_http_client calls. SAP runs some of the largest enterprise workloads on Azure, and teams regularly ask for "better together" integrations — archiving documents to Storage, managing Compute, or querying their resource estate. Until now, doing this from ABAP Cloud (the restricted, released-API-only model behind SAP Business AI Platform, ABAP environment and S/4HANA Cloud) meant reinventing HTTP, authentication, and parsing in every program. This SDK closes that gap with a reusable, secure, and testable runtime, so developers can focus on their scenario instead of the plumbing. The first release ships three service clients — Azure Storage (Blob), Compute, and Resource Graph — backed by ABAP Unit tests, runnable demos, and full Microsoft open-source governance. Why it matters Accelerate SAP-on-Azure integration — give ABAP Cloud developers a native, low-friction way to call Azure REST APIs, cutting boilerplate and time to value. Bring Azure SDK patterns to ABAP — offer the same pipeline, credential, and typed-client model as the official Azure SDKs, so SAP teams feel at home quickly. Advance the Azure and SAP partnership — deepen Azure's value for the large SAP customer base and enable "better together" scenarios across storage, compute, and resource management. ABAP Cloud compliance — provide a released, cloud-ready SDK that complements the classic on-premises ABAP SDK for Azure for modern SAP Business AI Platform, ABAP environment and S/4HANA Cloud environments. Security-forward by default — encourage Microsoft Entra ID–based authentication, with a User Delegation SAS as the recommended path over account keys. Community-driven — ship an open-source MVP to gather feedback, validate demand, and shape the roadmap together with SAP and Azure customers. Relationship to the classic ABAP SDK for Azure This SDK is the ABAP Cloud counterpart to the established ABAP SDK for Azure. The classic SDK targets classic and on-premises ABAP; the new one is written entirely in ABAP for Cloud Development using only released APIs, so it activates cleanly on SAP Business AI Platform, ABAP environment and S/4HANA Cloud. Whichever platform your team runs on, there is a fitting option. Authentication: Microsoft Entra ID first Security is a design constraint here, not an afterthought. Authentication is built around Microsoft Entra ID (formerly Azure Active Directory). Every credential implements a single interface, zif_az_token_credential: a client-secret (service principal) credential, a managed-identity credential, and a default credential that resolves whatever is available in the environment. A token cache avoids re-fetching tokens that are still valid. For Storage Blob data-plane access, the SDK documents — and its demos and tests follow — a recommended order of authentication: prefer a User Delegation SAS (a short-lived SAS signed by a Microsoft Entra ID identity, with no account key involved), then a direct Microsoft Entra ID credential. Plain SAS and Shared Key (the storage account key) remain supported for compatibility, but are the least-recommended options. The guidance is simple and identity-first: prefer an Entra ID identity (ideally signing a User Delegation SAS); fall back to account keys only when no identity is available. DATA(lo_credential) = NEW zcl_az_client_secret_cred( " a Microsoft Entra ID identity iv_client_id = '<client-id>' iv_client_secret = '<client-secret>' iv_tenant_id = '<tenant-id>' ). DATA(lo_udk) = NEW zcl_az_blob_udk_sas( iv_account_name = '<storage-account>' io_credential = lo_credential ). " Entra ID identity signs the SAS DATA(lo_blob) = lo_udk->create_blob_client( iv_container = '<container>' iv_permissions = 'rl' " read + list iv_start = '2026-07-24T00:00:00Z' iv_expiry = '2026-07-25T00:00:00Z' ). DATA(lo_result) = lo_blob->list_blobs( iv_container = '<container>' ). " no account key Architecture at a glance The SDK is layered so each concern is isolated, testable, and reused across every service client. HTTP pipeline (zcl_az_http_pipeline) — a request flows through an ordered chain of policies before it hits the wire. Shipped policies cover retry, authentication, logging, and the transport itself. Credentials — everything authenticates through zif_az_token_credential, so any credential type plugs into any client. Typed exceptions (zcx_az_*) — callers handle meaningful SDK errors with context, not raw HTTP status codes. Typed models — responses deserialize into ABAP structures and result objects, so consumers work with fields, not strings. Injection seam — every client and credential constructor accepts an optional transport, so unit tests can substitute a double and run without a network. A service client stays thin — build a typed request, hand it to the pipeline, map the typed response back — while retry, auth, logging, and error translation are shared infrastructure. Anyone who has used the Azure SDKs for .NET or Java will recognize the shape immediately. Implemented services (first release) Service Client What you get Storage Blob zcl_az_blob_client Four convenient typed methods — list_containers, list_blobs, download_blob, upload_blob — with typed models and XML deserialization, plus the full generated REST surface (containers, leases, blocks, pages, append, service operations). Binary-safe for images and arbitrary bytes. Compute zcl_az_compute_client The Virtual Machines / Scale Sets / Images / Hosts surface with typed responses, path and query building, body serialization, and action endpoints such as start, deallocate, and restart. Resource Graph zcl_az_resourcegraph_client A streamlined query_resources interface (primitives in, object result out), plus the typed resources( body ) request/response and operations_list. Getting started Prerequisites An SAP Business AI Platform, ABAP environment or S/4HANA Cloud system with ABAP for Cloud Development. A Microsoft Entra ID identity (for example a service principal: client ID, client secret, tenant ID) with appropriate Azure RBAC roles for the resources you intend to access. The target Azure resources (a storage account and container, a subscription, etc.). Import Clone the repository and import the ABAP objects into your system (for example via abapGit). The objects are organized under a clean package hierarchy rooted at ZABAP_SDK_AZURE, with sub-packages for the core runtime, identity, services, tests, and demos. On import, assign the root package to your target parent package. A guided walkthrough 1. Blob access with a direct Entra ID credential Pass an Entra ID credential straight to the blob client. The identity needs a Storage Blob Data RBAC role on the account. DATA(lo_blob) = NEW zcl_az_blob_client( iv_account_name = '<storage-account>' io_credential = lo_credential ). " Microsoft Entra ID bearer token DATA(lo_result) = lo_blob->list_blobs( iv_container = '<container>' ). LOOP AT lo_result->mt_blobs INTO DATA(ls_blob). " ls_blob-name / ls_blob-content_type / ls_blob-content_length ... ENDLOOP. 2. Uploading a document to Blob storage A frequent SAP-to-Azure scenario is archiving a generated document into a storage container. With upload_blob, that is a single typed call: provide the container, blob name, content bytes, and content type, and the SDK handles the request, auth, and response mapping. The bundled blob demo shows this end to end — say, a PDF invoice upload (see below). 3. Running a Resource Graph query Query your Azure resource estate with KQL and get a typed result back: DATA(lo_rg) = NEW zcl_az_resourcegraph_client( io_credential = lo_credential ). DATA(lo_result) = lo_rg->query_resources( iv_query = `Resources | project name, type, location | limit 5` it_subscriptions = VALUE #( ( '<subscription-id>' ) ) ). Try it in minutes: the bundled demos The ZABAP_AZ_DEMO package contains three ready-to-run, self-contained example classes — one per service. Each is an if_oo_adt_classrun class, so you run it directly from ABAP Development Tools with F9 (Run As → ABAP Application (Console)). Demo class Service What it does zcl_az_demo_blob_ops Storage Blob Document upload: builds an in-memory PDF "invoice", uploads it to a container, lists blobs, and downloads it back. Demonstrates all auth modes and defaults to User Delegation SAS. zcl_az_demo_compute_vm Compute Lists the VMs in a resource group and deallocates a VM. zcl_az_demo_rg_quer Resource Graph Runs a KQL query three ways: the ergonomic facade, the typed resources( body ), and operations_list. Before running, replace the <YOUR_...> placeholder constants with your own environment values (storage account, container, subscription, resource group, VM name, and the Entra ID client ID / tenant ID / client secret). The demos ship with placeholders only — never commit real credentials, account names, or SAS tokens. Tested by design The SDK ships with ABAP Unit test methods, all RISK LEVEL HARMLESS DURATION SHORT, plus self-skipping integration tests for optional live verification. Because every client and credential accepts an optional transport, tests substitute a double and assert on the exact request that would go on the wire — URL, headers, body — and on how a canned response is parsed, all offline and deterministic. The runtime core (pipeline, policies, credentials, crypto, HTTP helpers) and each service client are covered. Open source and governance The project follows Microsoft open-source practice and is developed in the open under the Azure organization: License: MIT. Security: please report vulnerabilities privately per SECURITY.md (MSRC), not via public issues. Code of Conduct and Contributing guidelines are in the repository. This is an initial release This is a first / MVP release, published deliberately early so the community can use it, test it against real scenarios, and help steer it. APIs may evolve based on what we hear. What's next is community-driven. The same runtime — pipeline, credentials, typed exceptions, and models — is designed to be extended to additional Azure services beyond the initial three. Which services come next will be prioritized by what practitioners actually need, so early feedback has the most influence. Get involved Feedback and participation happen in the open on GitHub: Browse the code and docs: https://github.com/Azure/ABAP-Cloud-SDK-for-Azure Report a bug or request a feature: open a GitHub Issue. Ask questions, share scenarios, discuss ideas: start a thread in GitHub Discussions. Whether it is a bug, a missing operation, an awkward API, or a service you wish were covered — please tell us. Early, specific feedback is the fastest way to make this SDK genuinely useful for SAP-on-Azure integration. Get the SDK https://github.com/Azure/ABAP-Cloud-SDK-for-Azure Import it, run a demo, and let us know what you think.