SAP Community - SAP BTP Security

Agentic AI on BTP: a Multi‑Agent App with Pydantic AI

2026-05-03T14:04:10.563000+02:00

Introduction

In the previous post I built btp-agent: a single LangGraph agent in a CAP app that wires up five BTP MCP servers (Cloud Integration, AI Core, BTP Core, Audit Log, Cloud Foundry V3) and lets users chat with their full BTP landscape. It worked, but it hit some limitations. With all five MCP servers plugged in, the model saw well over a hundred tools on every turn. Latency climbed, the model reached number of tool limits and the single orchestrator prompt got asked to be an expert in integration flows, AI deployments, audit events and CF applications all at once. For a live demo that is survivable. For anything that wants to scale, it isn’t.

So I took the agent apart.

Why

The natural cut line is the MCP server: each server already represents a bounded domain (CI, AI Core, BTP Core, etc.), and each one has its own vocabulary of tools. If every MCP server gets its own specialist agent, each agent’s prompt becomes short and focused, each agent’s tool list becomes small and the model can actually reason about which tool to call. An orchestrator agent on top then decides which specialist(s) to delegate to for a given question and stitches the answers together.

I switched the stack from CAP/TypeScript to Python with Pydantic AI for this step. Pydantic AI gives me typed agents, typed tool calls and first‑class MCP client support, which means each specialist is about thirty lines of code. It also made it natural to treat delegation as just another tool on the orchestrator, which is a pattern that maps cleanly onto how LLMs already think about tool use.

How

btp-multiagent-app keeps the same philosophy as before, everything runs on BTP, everything reuses the user’s identity but the internals are rearranged. A chat entry point (app.py) receives the user’s message and hands it to the orchestrator. The orchestrator (agents/orchestrator.py) has no tools of its own other than a set of delegation tools pointing at the specialists:

Figure 1 — btp-multiagent-app solution diagram (L2). Editable .drawio version included with this post.

Figure 2 — Screenshot of the chat UI delegating across specialists (placeholder — replace before publishing).

Cloud Foundry specialist: operations against CF V3 via its MCP server
BTP specialist: BTP Core Services via its MCP server
Audit log specialist: scaffolded and disabled while I iterate on scopes

Each specialist wraps an MCP client that speaks Streamable HTTP to its MCP server, authorised with OAuth 2.1. A small shared module (agents/shared.py) centralises the AI Core GenAI Hub model setup, the MCP client factory and the OAuth flow, so every specialist is stamped from the same template. A legacy agent.py sits next to the new agents/ package as a reference to the single‑agent design from the previous post, useful when explaining the migration.

Key configuration patterns

The app supports two credential layouts for AI Core so it runs comfortably both locally and on CF:

Individual environment variables — AICORE_AUTH_URL, AICORE_CLIENT_ID, AICORE_CLIENT_SECRET, AICORE_BASE_URL, AICORE_RESOURCE_GROUP.
A single AICORE_SERVICE_KEY JSON — the whole service key dropped in as one variable, handy on CF where a service binding gives you exactly that shape.

MCP server URLs are injected the same way: MCP_CLOUDFOUNDRY_URL, MCP_BTP_URL and MCP_AUDITLOG_URL. Locally you get them by running the MCP servers on 127.0.0.1; on CF the mta.yaml descriptor wires them to the deployed hosts. The AI Core binding is attached automatically so you don’t have to ship credentials into the image.

What the orchestrator actually does

The orchestrator is deliberately small. Its prompt tells it: you are a BTP operations assistant; you have the following specialists available; when a user asks a question, decide which specialist(s) can answer, call them, and combine their output into a single response. Under the hood, each delegation tool invokes the corresponding specialist agent with a sub‑prompt, collects the result and returns it to the orchestrator. That lets the model reason at two levels (routing at the top, tool selection inside each specialist) which is exactly what the single‑agent design was trying and failing to do in one go.

The outcome is measurable. Tool lists per agent drop from "well over a hundred" to "a dozen or two", token usage per turn drops with them and the agent stops hallucinating tool names because each specialist only knows the tools that actually make sense for its domain. Debugging also gets easier: when something goes wrong, you can tell whether the orchestrator mis‑routed or the specialist mis‑used a tool, just by reading the trace.

What I learned (and the OAuth honesty section)

The multi‑agent pattern pays for itself instantly. Tool lists per agent drop from "well over a hundred" to "a dozen or two", token usage per turn drops with them, no tool-overload and the model stops hallucinating tool names because each specialist only sees the tools that make sense for its domain. OAuth 2.1 against the MCP servers also works fine once deployed, Pydantic AI ships a web client that handles the consent flow inside the running app, so the same code path that works locally works on Cloud Foundry.

What this iteration did make obvious is that the list of specialists is still compiled into the code. Add a sixth MCP server and you have to edit the application, rebuild and redeploy. Fine while the list is short, not a pattern that scales to something like an AI Data Enabler exposing dozens of APIs to LLMs, which is where the next post goes.

Solution & references

Build & deploy

This one is a Python FastAPI app with a Node.js approuter in front of it. Prerequisites: Python 3.11+, Node.js 20+ (for the approuter), mbt and the Cloud Foundry CLI with the MultiApps plugin.

Local development:

git clone https://github.com/lemaiwo/btp-multiagent-app.git
cd btp-multiagent-app
python -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt
# point the app at your AI Core + MCP servers
export AICORE_SERVICE_KEY='{"clientid":"...","clientsecret":"...","url":"...","serviceurls":{"AI_API_URL":"..."}}'
export MCP_CLOUDFOUNDRY_URL=https://<your-cf-mcp>.cfapps.<region>.hana.ondemand.com/mcp
export MCP_BTP_URL=https://<your-btp-mcp>.cfapps.<region>.hana.ondemand.com/mcp
python -m uvicorn app:app --host 127.0.0.1 --port 7932

On first chat, each MCP client triggers the OAuth 2.1 browser flow against localhost:3000/callback. Tokens are cached afterwards.

Build and deploy to BTP Cloud Foundry:

mbt build                                        # -> mta_archives/*.mtar
cf login -a <api-endpoint> -o <org> -s <space>
cf deploy mta_archives/<name>.mtar

The MTA contains two modules, the Python FastAPI app (pydantic-agent, started as python -m uvicorn app:app --host 0.0.0.0 --port $PORT) and the approuter which binds xsuaa (application plan) plus AI Core (extended plan). MCP server URLs are injected as env vars per module. Reminder: production CF cannot use the localhost OAuth2 callback; switch to client-credentials or pre-provisioned tokens before you promote the deployment.

Code: github.com/lemaiwo/btp-multiagent-app

Previous post: Building a BTP Agent with LangGraph

Next up: making the set of specialists dynamic, so new agents can be created through an admin UI without redeploying the app: https://community.sap.com/t5/technology-blog-posts-by-members/agentic-ai-on-btp-dynamic-multi-agent-on-demand-with-pydantic-ai/ba-p/14388032#M178664

Agentic AI on BTP: Dynamic Multi‑Agent on Demand with Pydantic AI

2026-05-03T14:10:16.444000+02:00

Introduction

Post one introduced the OData MCP Proxy and gave us five BTP MCP servers by configuration. Post two took those MCP servers and wrapped them in a Pydantic AI multi‑agent application: an orchestrator on top, one specialist per MCP server below. That fixed the tool‑overload problem the original single‑agent design had hit. But it left one uncomfortable property in place: the list of specialists was still hard‑coded. Adding another MCP server meant editing the repo and redeploying. For my own BTP management experiments that is acceptable. For a broader scenario (say, an AI Data Enabler that wants to expose many, many APIs to LLMs safely) it very clearly isn’t.

So in this final iteration I made the agents themselves first‑class, dynamic objects: created, edited, deleted and reloaded without ever restarting the app.

Why

Two forces push you towards this design. The first is scale. If every domain, every data product, every API surface deserves its own specialist agent, you don’t want to ship a new release every time someone publishes a new API. You want the platform to accept an agent definition the same way a data platform accepts a new table. The second is governance. Treating agent configurations as data (rather than code) means you can export them, version them, review them, diff them and re‑import them. It also gives you a natural place to attach role‑based access: who can create agents, who can only consume them, who can re‑load the orchestrator.

btp-dynamic-multiagent-app takes those two ideas seriously. Every agent lives as a row in a database. A small admin UI lets an authorised user create, edit and disable agents and a Reload button rebuilds the orchestrator in memory without restarting the container.

How

The request path is straightforward. A user hits the approuter, the approuter terminates XSUAA authentication and forwards the request to a FastAPI app. Inside FastAPI there are two logical surfaces: /chat, served by the dynamic orchestrator, and /admin, served by a CRUD API plus a small HTML admin page. Both sit behind the same JWT; the admin routes additionally require an admin scope so the UI can only be used by users with the right role collection.

Figure 1 — btp-dynamic-multiagent-app solution diagram (L2). Editable .drawio version included with this post.

Figure 2 — Screenshot of the admin UI adding a new agent (placeholder — replace before publishing).

The pieces that make it dynamic:

agents/db.py: SQLAlchemy models for the agent configuration (name, description, instructions, MCP URL, enabled flag). PostgreSQL in production, SQLite locally so you can iterate without infra.
agents/registry.py: a builder that reads the current set of enabled agent records, constructs Pydantic AI agents from them on the fly, and produces a fresh orchestrator with delegation tools pointing at each specialist.
agents/admin.py: a REST API for CRUD plus a Reload endpoint that calls into the registry to swap in the newly built orchestrator.
agents/auth.py: XSUAA JWT validation and a contextvar‑bound token forwarder so every MCP call made during a request carries the original user’s identity.
agents/chat_app.py: a dynamic ASGI wrapper for the chat interface so the underlying agents can be swapped at runtime.
templates/admin.html + agents.seed.json: the admin UI and a bootstrap configuration for cold starts.

How an operator adds a new agent

In the admin UI an operator clicks "+ New agent", fills in a name, a short description, the system instructions for that specialist and the URL of its MCP server. Saving writes a row. Clicking "Reload agents" asks the registry to rebuild the orchestrator; the new specialist appears in the delegation tool set from the very next chat message. No redeploy. No CF restart (although there is an optional Restart‑app button that can trigger one, if you have a technical‑user service binding to the CF API and you actually want that).

On top of the live CRUD you get export and import of the full agent set as a JSON snapshot. That is small but it is what turns agent definitions from "config in a live DB somewhere" into "versionable artefact you can put in Git". It is also how you seed a new environment from a known‑good baseline rather than clicking your way through twenty entries.

Security and identity propagation

Because everything runs on BTP behind the approuter, identity is not something this app invents. Every request already arrives with a validated XSUAA JWT; agents/auth.py pins it into a contextvar for the duration of the request. When a delegated specialist calls its MCP server, the middleware grabs that token and forwards it as a bearer credential. The MCP server authorises using the caller’s actual permissions, not a shared service account. The admin surface is gated by a dedicated "Pydantic Agent Administrator" role collection, so only authorised users can create or modify agents. Normal chat users never see the admin UI.

Why this matters for the AI Data Enabler

This is the design I want for any serious "expose‑your‑APIs‑to‑LLMs" story. A centralised MCP server that tries to host tools for every API in the organisation becomes a hot mess very quickly: the tool list explodes, governance becomes all‑or‑nothing, and a single team ends up owning everything. A dynamic multi‑agent app inverts that. Each API surface can publish its own MCP server, owned by its own team, registered as an agent in the platform by its owner and consumed through the same orchestrator. The orchestrator sees a small, stable set of specialists; specialists see small, focused tool lists; identity flows through on every call. You can scale the number of exposed APIs without scaling the complexity of any single component.

Lessons learned

Treating agent definitions as data is a much bigger win than it sounds like. Export/import, diffing, code review, all of it becomes free once the definition lives in a row instead of in a module.
Reloading an agent graph in place is subtle. The trick was to keep the chat ASGI wrapper thin and always resolve the current orchestrator lazily, so swapping the instance is atomic from the request’s point of view.
Role‑based admin access from day one avoids retrofits later. If the platform can edit agents, it needs a scope for it, full stop.
Using SQLite locally and PostgreSQL on CF kept the inner loop fast without forcing a separate "dev" code path.

Solution & references

Build & deploy

Same FastAPI + approuter shape as btp-multiagent-app, with a PostgreSQL service added for the agent registry. Prerequisites: Python 3.11+, Node.js 20+, mbt, and the Cloud Foundry CLI with the MultiApps plugin.

Local development:

git clone https://github.com/lemaiwo/btp-dynamic-multiagent-app.git
cd btp-dynamic-multiagent-app
python -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt
# local uses SQLite automatically — no Postgres needed to iterate
export AICORE_SERVICE_KEY='{"clientid":"...","clientsecret":"...","url":"...","serviceurls":{"AI_API_URL":"..."}}'
python -m uvicorn app:app --host 127.0.0.1 --port 7932
# then open http://127.0.0.1:7932/admin to seed agents from agents.seed.json

Build and deploy to BTP Cloud Foundry:

mbt build                                        # -> mta_archives/*.mtar
cf login -a <api-endpoint> -o <org> -s <space>
cf deploy mta_archives/<name>.mtar

The MTA contains the same pydantic-agent Python module and pydantic-agent-approuter Node.js module, and adds a PostgreSQL (postgresql-db, standard plan) resource for the agent registry alongside xsuaa and AI Core. After the first deploy: assign the "Pydantic Agent Administrator" role collection to the users who should be able to create or modify agents, then open /admin to import your agents.seed.json baseline.

Code: github.com/lemaiwo/btp-dynamic-multiagent-app

Editable diagram: 03-btp-dynamic-multiagent-architecture.drawio (shipped alongside this post).

Previous posts in the series: OData MCP Proxy Introduction, btp-agent, btp-multiagent-app.

With this iteration the loop closes: any OData service can become an MCP server with a config file; any MCP server can become a specialist agent with a row in a database and the orchestrator keeps the user experience to a single conversation.

Application Vulnerability Report: Now Scanning Your Applications Beyond EU Landscapes

2026-05-11T15:27:59.030000+02:00

The threat landscape does not respect regional boundaries. Vulnerabilities in your deployed applications are equally critical whether your workloads run in Frankfurt, the US, or Tokyo. Since launching the AVR beta on EU-10, we have heard consistent feedback from customers operating across multiple BTP landscapes: "We need visibility into our non-EU deployments too."

At the same time, the current security climate has made it clear that waiting for a full multi-region rollout would leave too many applications without coverage. We decided to act.

What We Have Done: Cross-Region Scanning

Application Vulnerability Report is currently available as a beta on EU-10. While the service is not yet subscribable in other landscapes, we have significantly expanded our scanning scope. AVR now scans applications deployed across 42 Cloud Foundry landscapes globally - including US, Asia-Pacific, Japan, Brazil, and additional EU landscapes beyond the original EU-10.

Think of this as a bridge solution: we are extending our scanning reach now, while native service availability in additional regions remains on our roadmap.

How It Works

Our scanning infrastructure - including the vulnerability scanner, the databases, and all processing logic - operates from our central EU datacenters. From there, AVR reaches out to all supported landscapes, collects the relevant application dependency information, and performs the vulnerability analysis centrally.

The results - your security findings and vulnerability data - are stored in our EU-based infrastructure and made available to you through the BTP Cockpit integration you already know from the beta.

Covered Landscapes

The following Cloud Foundry landscapes are now included in AVR scanning:

EU: eu01, eu02, eu10, eu10-002, eu10-003, eu10-004, eu10-005, eu11, eu13, eu20, eu20-001, eu20-002, eu22, eu30, eu31
US: us01, us02, us10, us10-001, us10-002, us11, us20, us21, us21-001, us22, us30, us32
Asia-Pacific: ap01, ap10, ap11, ap12, ap20, ap21, ap30, ap31
Japan: jp01, jp10, jp20, jp30, jp31
Brazil: br10, br20, br30
Other: ch20, uk20

Excluded landscapes: Due to regulatory and compliance constraints, the following landscapes are excluded from scanning: ae01 (United Arab Emirates), ca10 and ca20 (Canada), cn01, cn10, cn20, and cn40 (China).

Important: Data Residency Considerations

Please note: Because the scanner and all databases operate in the EU, vulnerability and security findings for applications deployed in any landscape will be stored in EU datacenters.

This is relevant if your organization requires security data to remain in the same region where your applications are deployed. Specifically:

All vulnerability findings - regardless of the landscape your application runs in - are transmitted to and stored in EU.
No scanning infrastructure is deployed locally in non-EU regions at this time.

We want to be fully transparent about this so you can make an informed decision.

What is on the Roadmap

This cross-region scanning capability is our interim response to an urgent need. Looking ahead, our roadmap includes:

Full landscape-native subscriptions in additional regions, where both scanning and data storage operate locally in the respective region.
Integration with SAP Cloud ALM - enabling you to manage vulnerability findings alongside your broader application lifecycle management.
General availability of Application Vulnerability Report as a commercially subscribable service.

We will keep you updated as these milestones progress.

Try It Out

If you are already part of the AVR beta, cross-region scanning is available to you automatically - no action required on your side. If you have not joined the beta yet, there has never been a better time - especially if you have workloads running across multiple BTP landscapes.

Automate Extraction – Project Users Maintained as Cloud Foundry Org/Space Members

2026-05-11T16:23:58.128000+02:00

Introduction

While reviewing SAP BTP Cloud Foundry access, I ran into a common operational challenge: users who were no longer part of a project were still maintained as Cloud Foundry org or space members.

Checking this manually across multiple SAP BTP subaccounts is time-consuming. Each subaccount may have a Cloud Foundry org, multiple spaces, and different user role assignments. If the landscape spans multiple Cloud Foundry API endpoints, the effort increases further.

In this blog, I am sharing an automation approach I used to extract Cloud Foundry org and space membership details across SAP BTP subaccounts and consolidate the results into CSV reports for review.

Problem Statement

Cloud Foundry access in SAP BTP is maintained at different levels:

Organization level
Space level

Users may be assigned roles such as:

Org Manager
Org Auditor
Org User
Space Manager
Space Developer
Space Auditor
Space Supporter

When project teams change, some users may no longer need access. However, if project offboarding does not include Cloud Foundry org and space membership cleanup, stale access can remain.

Manually validating this from the SAP BTP cockpit requires going through each subaccount, org, and space one by one. In my case, this could take close to a full business day.

Tools Used

I used the following command-line tools:

SAP BTP CLI -The SAP BTP CLI is used for SAP BTP account administration, including working with global accounts, subaccounts, and environment instances.
Cloud Foundry CLI - The Cloud Foundry CLI is used to interact with the SAP BTP Cloud Foundry runtime, including orgs, spaces, applications, services, and users.

High-Level Approach

The automation was split into two steps.

Step 1: Identify Cloud Foundry API Endpoints - First, I used the SAP BTP CLI to list subaccounts and environment instances. Then, for each subaccount, lists environment instances of a subaccount, such as Cloud Foundry orgs or Kyma clusters.

From this output, I identified the Cloud Foundry API endpoints used in the global account.

Example endpoints:

https://api.cf.eu10-004.hana.ondemand.com
https://api.cf.us10-001.hana.ondemand.com
https://api.cf.us20.hana.ondemand.com
https://api.cf.us21.hana.ondemand.com

Step 2: Extract Org and Space Members - After collecting the API endpoints, I used the Cloud Foundry CLI to log in to each endpoint and extract:

Organizations
Spaces
Org-level role assignments
Space-level role assignments
User details
Role details

The script loops through each endpoint, retrieves all orgs, then retrieves spaces and role assignments for each org.

Why Include Both Org and Space Roles?

Initially, I focused only on org members. However, that did not give the complete access picture.
A user may not have a high-privilege org role but may still be assigned as a Space Developer or Space Manager in one or more spaces. For access review purposes, both org-level and space-level assignments are important.

Conclusion

Automating Cloud Foundry org and space membership extraction helped reduce a repetitive manual review process from almost a full business day to a few minutes.
The consolidated CSV output provides a clear view of users maintained at org and space levels across multiple SAP BTP Cloud Foundry endpoints. This makes access review faster, more consistent, and easier to repeat.
For teams managing multiple SAP BTP subaccounts, this type of automation can be a useful starting point for improving visibility into Cloud Foundry access.

How to Run the Automation

This section explains the practical steps to run the automation and generate the final Cloud Foundry org/space membership report.

Prerequisites
Before running the scripts, ensure the following tools are installed and accessible from PowerShell:

SAP BTP CLI
Cloud Foundry CLI
PowerShell
Access to the SAP BTP global account/subaccounts
Access to Cloud Foundry endpoints through SSO

Validate the CLI installations:

btp --version
cf version

If btp or cf is not recognized, add the CLI installation folder to the system/user PATH or call the executable using the full path.

$env:Path += ";C:\BTP"

Step 1: Log in to SAP BTP CLI
Log in to the SAP BTP global account:

btp login

Confirm the current BTP target:

btp target

The target should point to the intended global account before continuing.

Step 2: Extract Cloud Foundry API Endpoints
Run the endpoint discovery script:

cd C:\BTP
.\get-all-cf-api-endpoints.ps1

This script identifies Cloud Foundry-enabled subaccounts and generates two output files:

C:\BTP\btp-cf-api-endpoints-by-subaccount.csv
C:\BTP\btp-cf-api-endpoints-unique.txt

The detailed CSV contains subaccount-level details, while the unique text file contains the distinct Cloud Foundry API endpoints.

Step 3: Update the Endpoint List in the Extraction Script(export-org-and-space-members-multiple-endpoints.ps1)
Open the org/space member extraction script:

notepad C:\BTP\export-org-and-space-members-multiple-endpoints.ps1

Update the $Endpoints array with the API endpoints identified in Step 2.

Example:

$Endpoints = @(
    "https://api.cf.eu10-004.hana.ondemand.com",
    "https://api.cf.us10-001.hana.ondemand.com",
    "https://api.cf.us20.hana.ondemand.com",
    "https://api.cf.us21.hana.ondemand.com"
)

Step 4: Run the Org and Space Membership Extraction
Run the script:

cd C:\BTP
.\export-org-and-space-members-multiple-endpoints.ps1

For each endpoint, the script will display a passcode URL similar to:

https://login.cf.us21.hana.ondemand.com/passcode

Open the displayed URL in a browser, copy the temporary SSO passcode, paste it into the PowerShell prompt, and press Enter.
The script repeats this process for each Cloud Foundry API endpoint.

Step 5: Review the Output File
After the script completes, it generates a consolidated CSV report:

C:\BTP\all-cf-endpoint-org-space-members.csv

============================================================================
get-all-cf-api-endpoints.ps1 Source Code
============================================================================

# ============================================================
# Get all Cloud Foundry API endpoints from all BTP subaccounts
# Output:
#   C:\BTP\btp-cf-api-endpoints-by-subaccount.csv
#   C:\BTP\btp-cf-api-endpoints-unique.txt
#
# Prerequisite:
#   Already logged in using: btp login
# ============================================================

$DetailOutFile = "C:\BTP\btp-cf-api-endpoints-by-subaccount.csv"
$UniqueOutFile = "C:\BTP\btp-cf-api-endpoints-unique.txt"

$Results = @()

function Get-JsonArray {
    param($JsonObject)

    if ($null -eq $JsonObject) {
        return @()
    }

    if ($JsonObject -is [System.Array]) {
        return @($JsonObject)
    }

    foreach ($prop in @("value", "items", "content", "subaccounts", "environmentInstances", "resources")) {
        if ($JsonObject.PSObject.Properties.Name -contains $prop) {
            return @($JsonObject.$prop)
        }
    }

    return @($JsonObject)
}

function Get-FirstPropertyValue {
    param(
        $Object,
        [string[]]$PropertyNames
    )

    if ($null -eq $Object) {
        return $null
    }

    foreach ($name in $PropertyNames) {
        if ($Object.PSObject.Properties.Name -contains $name) {
            $value = $Object.$name
            if ($null -ne $value -and "$value".Trim() -ne "") {
                return "$value"
            }
        }
    }

    return $null
}

function Get-CfApiEndpointFromObject {
    param(
        $EnvObject,
        [string]$SubaccountRegion
    )

    # 1. Try to find a full API endpoint directly in the JSON.
    $jsonText = $EnvObject | ConvertTo-Json -Depth 30 -Compress

    if ($jsonText -match "https://api\.cf\.[a-zA-Z0-9-]+\.hana\.ondemand\.com") {
        return $Matches[0]
    }

    # 2. Try to derive from landscape label or region.
    $candidateValues = @()

    $landscape = Get-FirstPropertyValue $EnvObject @(
        "landscapeLabel",
        "landscape",
        "landscape_label",
        "platformId",
        "platform_id",
        "region"
    )

    if ($landscape) {
        $candidateValues += $landscape
    }

    if ($SubaccountRegion) {
        $candidateValues += $SubaccountRegion
    }

    foreach ($candidate in $candidateValues) {
        if (-not $candidate) {
            continue
        }

        $value = "$candidate".Trim()

        # Examples:
        # cf-us21        -> us21
        # cf-us21-001    -> us21
        # us21           -> us21
        # us21-001       -> us21
        if ($value -match "^cf[-_](?<region>[a-z]{2}[0-9]{2})(?:[-_][0-9]+)?$") {
            return "https://api.cf.$($Matches.region).hana.ondemand.com"
        }

        if ($value -match "^(?<region>[a-z]{2}[0-9]{2})(?:[-_][0-9]+)?$") {
            return "https://api.cf.$($Matches.region).hana.ondemand.com"
        }
    }

    return $null
}

Write-Host "Getting subaccounts from current BTP global account..." -ForegroundColor Cyan

$subRaw = btp --format json list accounts/subaccount

if ($LASTEXITCODE -ne 0) {
    Write-Host "Failed to list subaccounts. Confirm you are logged in with btp login." -ForegroundColor Red
    exit 1
}

$subJson = $subRaw | ConvertFrom-Json
$subaccounts = Get-JsonArray $subJson

Write-Host "Found $($subaccounts.Count) subaccount record(s)." -ForegroundColor Green

foreach ($sub in $subaccounts) {
    $subaccountId = Get-FirstPropertyValue $sub @(
        "guid",
        "id",
        "subaccountId",
        "subaccountGuid",
        "subaccountGUID",
        "subaccount id"
    )

    $subaccountName = Get-FirstPropertyValue $sub @(
        "displayName",
        "display name",
        "name"
    )

    $subdomain = Get-FirstPropertyValue $sub @(
        "subdomain"
    )

    $region = Get-FirstPropertyValue $sub @(
        "region"
    )

    if (-not $subaccountId) {
        Write-Host "Skipping subaccount record because no subaccount ID was found." -ForegroundColor Yellow
        continue
    }

    Write-Host "`nChecking subaccount: $subaccountName [$subaccountId]" -ForegroundColor Yellow

    try {
        $envRaw = btp --format json list accounts/environment-instance --subaccount $subaccountId

        if ($LASTEXITCODE -ne 0) {
            $Results += [PSCustomObject]@{
                SubaccountName = $subaccountName
                SubaccountId   = $subaccountId
                Subdomain      = $subdomain
                Region         = $region
                Environment    = ""
                EnvironmentId  = ""
                CfApiEndpoint  = ""
                Status         = "Error listing environment instances"
            }

            continue
        }

        $envJson = $envRaw | ConvertFrom-Json
        $envInstances = Get-JsonArray $envJson

        if (-not $envInstances -or $envInstances.Count -eq 0) {
            $Results += [PSCustomObject]@{
                SubaccountName = $subaccountName
                SubaccountId   = $subaccountId
                Subdomain      = $subdomain
                Region         = $region
                Environment    = ""
                EnvironmentId  = ""
                CfApiEndpoint  = ""
                Status         = "No environment instances"
            }

            continue
        }

        foreach ($env in $envInstances) {
            $envText = ($env | ConvertTo-Json -Depth 30 -Compress)

            $isCloudFoundry =
                $envText -match "cloudfoundry" -or
                $envText -match "Cloud Foundry" -or
                $envText -match "cloud foundry"

            if (-not $isCloudFoundry) {
                continue
            }

            $envName = Get-FirstPropertyValue $env @(
                "name",
                "displayName",
                "environment",
                "environmentType",
                "serviceName",
                "service"
            )

            $envId = Get-FirstPropertyValue $env @(
                "id",
                "guid",
                "environmentInstanceId"
            )

            $endpoint = Get-CfApiEndpointFromObject -EnvObject $env -SubaccountRegion $region

            $Results += [PSCustomObject]@{
                SubaccountName = $subaccountName
                SubaccountId   = $subaccountId
                Subdomain      = $subdomain
                Region         = $region
                Environment    = $envName
                EnvironmentId  = $envId
                CfApiEndpoint  = $endpoint
                Status         = if ($endpoint) { "Found" } else { "Cloud Foundry found, endpoint not derived" }
            }
        }
    }
    catch {
        $Results += [PSCustomObject]@{
            SubaccountName = $subaccountName
            SubaccountId   = $subaccountId
            Subdomain      = $subdomain
            Region         = $region
            Environment    = ""
            EnvironmentId  = ""
            CfApiEndpoint  = ""
            Status         = "Error: $($_.Exception.Message)"
        }
    }
}

$Results |
    Sort-Object SubaccountName, CfApiEndpoint |
    Export-Csv -Path $DetailOutFile -NoTypeInformation

$Results |
    Where-Object { $_.CfApiEndpoint -and $_.CfApiEndpoint.Trim() -ne "" } |
    Select-Object -ExpandProperty CfApiEndpoint -Unique |
    Sort-Object |
    Set-Content -Path $UniqueOutFile

Write-Host "`nDone." -ForegroundColor Green
Write-Host "Detailed output: $DetailOutFile" -ForegroundColor Green
Write-Host "Unique endpoints: $UniqueOutFile" -ForegroundColor Green

============================================================================
export-org-and-space-members-multiple-endpoints.ps1 Source Code
============================================================================

# ============================================================
# Export Cloud Foundry org + space members from multiple endpoints
# Output: C:\BTP\all-cf-endpoint-org-space-members.csv
#
# Safety:
#   READ-ONLY against Cloud Foundry.
#   Uses cf login and cf curl GET requests only.
# ============================================================

$OutFile = "C:\BTP\all-cf-endpoint-org-space-members.csv"

$Endpoints = @(
    "https://api.cf.eu10-004.hana.ondemand.com",
    "https://api.cf.us10-001.hana.ondemand.com",
    "https://api.cf.us20.hana.ondemand.com",
    "https://api.cf.us21.hana.ondemand.com"
)

$Results = @()

function Get-LoginHostFromApiEndpoint {
    param([string]$Endpoint)
    return ($Endpoint -replace "^https://api\.", "https://login.") + "/passcode"
}

function Invoke-CfGetPaged {
    param([string]$Path)

    $AllResources = @()
    $AllIncludedUsers = @()
    $NextPath = $Path

    while ($NextPath) {
        $Raw = cf curl $NextPath

        if ($LASTEXITCODE -ne 0) {
            throw "cf curl failed for path: $NextPath"
        }

        $Json = $Raw | ConvertFrom-Json

        if ($Json.resources) {
            $AllResources += $Json.resources
        }

        if ($Json.included -and $Json.included.users) {
            $AllIncludedUsers += $Json.included.users
        }

        if ($Json.pagination -and $Json.pagination.next -and $Json.pagination.next.href) {
            $NextHref = $Json.pagination.next.href

            if ($NextHref -like "http*") {
                $Uri = [System.Uri]$NextHref
                $NextPath = $Uri.PathAndQuery
            }
            else {
                $NextPath = $NextHref
            }
        }
        else {
            $NextPath = $null
        }
    }

    return [PSCustomObject]@{
        Resources = $AllResources
        Users     = $AllIncludedUsers
    }
}

function Convert-CfRoleName {
    param([string]$Role)

    switch ($Role) {
        "organization_manager"         { return "Org Manager" }
        "organization_auditor"         { return "Org Auditor" }
        "organization_user"            { return "Org User" }
        "organization_billing_manager" { return "Billing Manager" }
        "space_manager"                { return "Space Manager" }
        "space_developer"              { return "Space Developer" }
        "space_auditor"                { return "Space Auditor" }
        "space_supporter"              { return "Space Supporter" }
        default                        { return $Role }
    }
}

function Get-UserDetailsFromRoleResponse {
    param(
        $RoleResponse
    )

    $UsersByGuid = @{}

    foreach ($User in $RoleResponse.Users) {
        if ($User.guid -and -not $UsersByGuid.ContainsKey($User.guid)) {
            $UsersByGuid[$User.guid] = $User
        }
    }

    return $UsersByGuid
}

function Get-UserGuidFromRole {
    param($Role)

    if ($Role.relationships -and
        $Role.relationships.user -and
        $Role.relationships.user.data -and
        $Role.relationships.user.data.guid) {
        return $Role.relationships.user.data.guid
    }

    return $null
}

Write-Host "SCRIPT STARTED: Export org + space members from multiple CF endpoints" -ForegroundColor Cyan
Write-Host "Output file: $OutFile" -ForegroundColor Cyan

foreach ($Endpoint in $Endpoints) {
    Write-Host "`n============================================================" -ForegroundColor Cyan
    Write-Host "Processing endpoint: $Endpoint" -ForegroundColor Cyan
    Write-Host "============================================================" -ForegroundColor Cyan

    $PasscodeUrl = Get-LoginHostFromApiEndpoint -Endpoint $Endpoint

    Write-Host "`nOpen this URL in browser and copy a fresh SSO passcode:" -ForegroundColor Yellow
    Write-Host $PasscodeUrl -ForegroundColor White

    $Passcode = Read-Host "Enter SSO passcode for $Endpoint"

    if ([string]::IsNullOrWhiteSpace($Passcode)) {
        Write-Host "No passcode entered. Skipping endpoint: $Endpoint" -ForegroundColor Red

        $Results += [PSCustomObject]@{
            Endpoint   = $Endpoint
            OrgName    = ""
            OrgGuid    = ""
            SpaceName  = ""
            SpaceGuid  = ""
            Email      = ""
            Origin     = ""
            OrgRoles   = ""
            SpaceRoles = ""
            Status     = "Skipped - no SSO passcode entered"
        }

        continue
    }

    Write-Host "Logging in to $Endpoint ..." -ForegroundColor Cyan
    cf login -a $Endpoint --sso-passcode $Passcode

    if ($LASTEXITCODE -ne 0) {
        Write-Host "Login failed for endpoint: $Endpoint" -ForegroundColor Red

        $Results += [PSCustomObject]@{
            Endpoint   = $Endpoint
            OrgName    = ""
            OrgGuid    = ""
            SpaceName  = ""
            SpaceGuid  = ""
            Email      = ""
            Origin     = ""
            OrgRoles   = ""
            SpaceRoles = ""
            Status     = "Login failed"
        }

        continue
    }

    try {
        Write-Host "Getting organizations from $Endpoint ..." -ForegroundColor Cyan
        $OrgResponse = Invoke-CfGetPaged "/v3/organizations?per_page=5000"
        $Orgs = $OrgResponse.Resources

        if (-not $Orgs -or $Orgs.Count -eq 0) {
            $Results += [PSCustomObject]@{
                Endpoint   = $Endpoint
                OrgName    = ""
                OrgGuid    = ""
                SpaceName  = ""
                SpaceGuid  = ""
                Email      = ""
                Origin     = ""
                OrgRoles   = ""
                SpaceRoles = ""
                Status     = "No orgs found or no org access"
            }

            continue
        }

        foreach ($Org in $Orgs) {
            $OrgName = $Org.name
            $OrgGuid = $Org.guid

            Write-Host "`nProcessing org: $OrgName" -ForegroundColor Yellow

            # ------------------------------------------------------------
            # 1. Get org-level members and roles
            # ------------------------------------------------------------

            $OrgUserRoleMap = @{}
            $OrgUserOriginMap = @{}

            try {
                $OrgRoleResponse = Invoke-CfGetPaged "/v3/roles?organization_guids=$OrgGuid&include=user&per_page=5000"
                $OrgRoles = $OrgRoleResponse.Resources
                $OrgUsersByGuid = Get-UserDetailsFromRoleResponse -RoleResponse $OrgRoleResponse

                foreach ($Role in $OrgRoles) {
                    if ($Role.type -notlike "organization_*") {
                        continue
                    }

                    $UserGuid = Get-UserGuidFromRole -Role $Role

                    if (-not $UserGuid) {
                        continue
                    }

                    $UserObj = $OrgUsersByGuid[$UserGuid]

                    if ($UserObj) {
                        $Email = $UserObj.username
                        $Origin = $UserObj.origin
                    }
                    else {
                        $Email = $UserGuid
                        $Origin = "User details not included"
                    }

                    if (-not $OrgUserRoleMap.ContainsKey($Email)) {
                        $OrgUserRoleMap[$Email] = @()
                    }

                    $OrgUserRoleMap[$Email] += Convert-CfRoleName $Role.type
                    $OrgUserOriginMap[$Email] = $Origin
                }
            }
            catch {
                $Results += [PSCustomObject]@{
                    Endpoint   = $Endpoint
                    OrgName    = $OrgName
                    OrgGuid    = $OrgGuid
                    SpaceName  = ""
                    SpaceGuid  = ""
                    Email      = ""
                    Origin     = ""
                    OrgRoles   = ""
                    SpaceRoles = ""
                    Status     = "Error getting org roles: $($_.Exception.Message)"
                }
            }

            # Add org-level rows where no specific space is attached
            foreach ($Email in $OrgUserRoleMap.Keys) {
                $OrgRolesText = ($OrgUserRoleMap[$Email] | Sort-Object -Unique) -join ", "

                $Results += [PSCustomObject]@{
                    Endpoint   = $Endpoint
                    OrgName    = $OrgName
                    OrgGuid    = $OrgGuid
                    SpaceName  = ""
                    SpaceGuid  = ""
                    Email      = $Email
                    Origin     = $OrgUserOriginMap[$Email]
                    OrgRoles   = $OrgRolesText
                    SpaceRoles = ""
                    Status     = "Org-level member"
                }
            }

            # ------------------------------------------------------------
            # 2. Get spaces under this org
            # ------------------------------------------------------------

            try {
                $SpacesResponse = Invoke-CfGetPaged "/v3/spaces?organization_guids=$OrgGuid&per_page=5000"
                $Spaces = $SpacesResponse.Resources

                if (-not $Spaces -or $Spaces.Count -eq 0) {
                    continue
                }

                foreach ($Space in $Spaces) {
                    $SpaceName = $Space.name
                    $SpaceGuid = $Space.guid

                    Write-Host "Processing space members: $OrgName / $SpaceName" -ForegroundColor Gray

                    try {
                        $SpaceRoleResponse = Invoke-CfGetPaged "/v3/roles?space_guids=$SpaceGuid&include=user&per_page=5000"
                        $SpaceRoles = $SpaceRoleResponse.Resources
                        $SpaceUsersByGuid = Get-UserDetailsFromRoleResponse -RoleResponse $SpaceRoleResponse

                        if (-not $SpaceRoles -or $SpaceRoles.Count -eq 0) {
                            $Results += [PSCustomObject]@{
                                Endpoint   = $Endpoint
                                OrgName    = $OrgName
                                OrgGuid    = $OrgGuid
                                SpaceName  = $SpaceName
                                SpaceGuid  = $SpaceGuid
                                Email      = ""
                                Origin     = ""
                                OrgRoles   = ""
                                SpaceRoles = ""
                                Status     = "No space members found"
                            }

                            continue
                        }

                        $SpaceUserRoleMap = @{}
                        $SpaceUserOriginMap = @{}

                        foreach ($Role in $SpaceRoles) {
                            if ($Role.type -notlike "space_*") {
                                continue
                            }

                            $UserGuid = Get-UserGuidFromRole -Role $Role

                            if (-not $UserGuid) {
                                continue
                            }

                            $UserObj = $SpaceUsersByGuid[$UserGuid]

                            if ($UserObj) {
                                $Email = $UserObj.username
                                $Origin = $UserObj.origin
                            }
                            else {
                                $Email = $UserGuid
                                $Origin = "User details not included"
                            }

                            if (-not $SpaceUserRoleMap.ContainsKey($Email)) {
                                $SpaceUserRoleMap[$Email] = @()
                            }

                            $SpaceUserRoleMap[$Email] += Convert-CfRoleName $Role.type
                            $SpaceUserOriginMap[$Email] = $Origin
                        }

                        foreach ($Email in $SpaceUserRoleMap.Keys) {
                            $SpaceRolesText = ($SpaceUserRoleMap[$Email] | Sort-Object -Unique) -join ", "

                            $OrgRolesText = ""
                            if ($OrgUserRoleMap.ContainsKey($Email)) {
                                $OrgRolesText = ($OrgUserRoleMap[$Email] | Sort-Object -Unique) -join ", "
                            }

                            $Origin = $SpaceUserOriginMap[$Email]
                            if (-not $Origin -and $OrgUserOriginMap.ContainsKey($Email)) {
                                $Origin = $OrgUserOriginMap[$Email]
                            }

                            $Results += [PSCustomObject]@{
                                Endpoint   = $Endpoint
                                OrgName    = $OrgName
                                OrgGuid    = $OrgGuid
                                SpaceName  = $SpaceName
                                SpaceGuid  = $SpaceGuid
                                Email      = $Email
                                Origin     = $Origin
                                OrgRoles   = $OrgRolesText
                                SpaceRoles = $SpaceRolesText
                                Status     = "Space-level member"
                            }
                        }
                    }
                    catch {
                        $Results += [PSCustomObject]@{
                            Endpoint   = $Endpoint
                            OrgName    = $OrgName
                            OrgGuid    = $OrgGuid
                            SpaceName  = $SpaceName
                            SpaceGuid  = $SpaceGuid
                            Email      = ""
                            Origin     = ""
                            OrgRoles   = ""
                            SpaceRoles = ""
                            Status     = "Error getting space members: $($_.Exception.Message)"
                        }
                    }
                }
            }
            catch {
                $Results += [PSCustomObject]@{
                    Endpoint   = $Endpoint
                    OrgName    = $OrgName
                    OrgGuid    = $OrgGuid
                    SpaceName  = ""
                    SpaceGuid  = ""
                    Email      = ""
                    Origin     = ""
                    OrgRoles   = ""
                    SpaceRoles = ""
                    Status     = "Error getting spaces: $($_.Exception.Message)"
                }
            }
        }
    }
    catch {
        $Results += [PSCustomObject]@{
            Endpoint   = $Endpoint
            OrgName    = ""
            OrgGuid    = ""
            SpaceName  = ""
            SpaceGuid  = ""
            Email      = ""
            Origin     = ""
            OrgRoles   = ""
            SpaceRoles = ""
            Status     = "Error getting orgs: $($_.Exception.Message)"
        }
    }
}

$Results |
    Sort-Object Endpoint, OrgName, SpaceName, Email |
    Export-Csv -Path $OutFile -NoTypeInformation

Write-Host "`nExport completed." -ForegroundColor Green
Write-Host "File created: $OutFile" -ForegroundColor Green
Write-Host "Open with:" -ForegroundColor Cyan
Write-Host "notepad $OutFile" -ForegroundColor White

New Course Announcement: Getting Started with SAP Enterprise Consent and Preference Management

2026-05-13T18:51:35.377000+02:00

We’re excited to introduce a new course in the SAP Customer Data Cloud learning portfolio:

Getting Started with SAP Enterprise Consent and Preference Management

This course is the next step in your journey after completing
Mastering SAP Customer Identity and Access Management

Together, these courses form part of a comprehensive learning experience designed to guide you through the full implementation of SAP Customer Data Cloud.

Part of a Complete Learning Journey

This course is part of a broader enablement plan for SAP Customer Data Cloud.

⚠️Note: This course will soon be officially included in this Learning Journey.

Once fully released, the learning journey will contain four new complementary courses, covering the complete scope of the instructor-led training (ILT):

SAP Customer Data Cloud Implementation

These courses collectively guide you through identity, access, consent, and advanced configuration topics—providing a complete end-to-end learning experience.

Who Should Take This Course?

This course is designed for:

Customer data professionals (intermediate level)
Consultants and practitioners working with customer data platforms
Professionals responsible for privacy, compliance, and consent management

If you’re already familiar with identity and access management concepts, this course will help you extend your expertise into privacy and preference management.

What You’ll Learn

In today’s privacy-first world, managing consent is critical. This course provides a practical, hands-on introduction to SAP Enterprise Consent and Preference Management capabilities.

By the end of the course, you’ll be able to:

Understand global privacy regulations (e.g., GDPR, CCPA) and their impact
Configure and manage customer consent using SAP Customer Consent
Apply version control to ensure valid and up-to-date consent records
Use the Consent Vault to track, audit, and report consent activity
Set up and customize a Self-Service Preference Center for end users [
Define and manage communication channels and topics to personalize user preferences

Ultimately, you’ll gain the skills to implement enterprise-grade consent strategies that support compliance while enabling trusted customer engagement.

Course Highlights

The course is structured into three practical units:

1. Foundations of Customer Consent Management

Key regulations and compliance requirements
Core principles of consent and user rights

2. Managing Consent with SAP Customer Data Cloud

SAP Customer Consent capabilities
Version control and consent lifecycle
Consent Vault for auditing and reporting
Self-Service Preference Center configuration

3. Communication Preferences and Personalization

Communication channels and topics
Subscription management and user choice

🔗Prerequisite Course

Before taking this course, we strongly recommend completing:

Mastering SAP Customer Identity and Access Management
This foundational course introduces identity concepts and prepares you to fully understand consent and preference management within SAP Customer Data Cloud.

Why This Course Matters

As organizations operate across global markets, compliance with privacy regulations is no longer optional. Customers expect transparency, control, and trust.

With SAP Enterprise Consent and Preference Management, you can:

Ensure regulatory compliance
Build trust-based digital relationships
Deliver personalized yet privacy-aware experiences

This course equips you with the knowledge and practical skills to make that happen.

Start Learning Today

Enroll now:
Getting Started with SAP Enterprise Consent and Preference Management

Stay tuned—more CIAM courses are coming soon.

Secure by Design: How SAP and NVIDIA Are Redefining Agent Execution

2026-06-01T07:50:00.019000+02:00

I am still reveling in the excitement of SAP Sapphire Orlando, May 11 to May 13, 2026. It started with the SAP keynote , highlighting our future direction. A personal moment of pride filled the screens around minute 42, when the CEO of NVIDIA Jensen Huang introduced how SAP and NVIDIA are making enterprise software more powerful and security.

On Wednesday, I hosted a strategy talk between Sebastian Mahr, Chief Development Architect, SAP SE and Shahriar Hooshmand, GenAI Technical Lead, NVIDIA. Today, I am sharing more details about their discussion for redefining agent execution. The AI first experience for building happens in Joule Studio and Joule Studio runtime with NVIDIA makes it easy to deploy and secure for enterprise scale.

AI agents are moving from conversation to action. They are beginning to execute tasks, invoke tools, cross system boundaries, and operate inside the business processes where decisions are made and value is created. For enterprises, this changes the trust equation. A chatbot can suggest; an agent can act. And once agents can engage with systems of record across finance, procurement, supply chain, manufacturing, and customer operations, the question becomes much sharper: how do we safely deploy autonomous AI? SAP and NVIDIA’s collaboration is designed to answer exactly that question. The SAP Business AI Platform uses the NVIDIA OpenShell secure runtime to make agents safe, governable, and auditable by design. Joule Studio acts as an "agent harness" that combines Large Language Model intelligence with business data and domain expertise.

Autonomy, Intelligence, and Security

Every enterprise agent sits in a tension between Autonomy, Intelligence, and Security. Highly autonomous agents can move fast, intelligent agents can reason through complex business contexts, and secure agents can operate within clear technical and business boundaries. In real-world enterprise environments, you cannot simply maximize all three at once. A loan-processing agent, a production-line response agent, and a strategic planning agent should not run with the same level of freedom, the same approval model, or the same risk posture. The more autonomous the agent, the more important it becomes to define what it can see, what it can do, who approves its actions, and how those actions are traced.

Responsibility and secure execution must become the layer around agentic enterprise AI. Security is about container isolation, credentials, networks, APIs and risk management for unauthorized spending, compliance violations, reputational damage, liability, and audit readiness. Enterprises need a way to choose the right balance for each workload:

Autonomous and secure for repeatable tasks,
Intelligent and secure for high-context work with human oversight, or
Autonomous and intelligent only in tightly controlled development and testing environments.

Responsibility defines who decides the operating mode, who bears the risk, and how the system adapts as the workload becomes more capable or more sensitive.

In Joule Studio runtime, NVIDIA OpenShell provides the secure runtime foundation for agent execution, including isolated environments, filesystem and network policy enforcement, and runtime-level containment to limit impact if agent logic fails. SAP brings the enterprise context: roles, skills, identity, lifecycle, policy semantics, observability, auditability, and governance across business landscapes. Put simply, OpenShell helps answer, “Can this agent action safely execute?” Joule Studio runtime helps answer, “Should this action happen at all?” Together, they close the gap between technical containment and business accountability.

The SAP and NVIDIA collaboration, which includes SAP as a key contributor to the NVIDIA OpenShell open source project, also reflects NVIDIA's broader full-stack view of AI. NVIDIA’s founder and CEO, Jensen Huang, has framed AI as a five-layer stack; energy, chips, infrastructure, models, and applications; the application layer is where AI creates value in real workflows. For SAP customers, that point matters. Enterprise AI becomes real when agents can operate inside the business applications, identities, policies, and audit models that companies already depend on. SAP and NVIDIA’s work on Joule Studio runtime is about making that next step practical: allowing agents to act, while staying within the boundaries enterprises require.

This week at Computex / GTC Taipei, NVIDIA is announcing new open source software and models to continue making it easier to build and deploy autonomous agents. And now, the next step is to put this into the hands of builders. SAP customers and partners building custom agents should engage with the new Joule Studio early access / Early Adopter Program to start shaping their own trusted agent execution model. Explore how SAP enterprise with OpenShell-based runtime security and governance powered by OpenShell can help you understand your security posture, define workload-specific risk profiles, and move from pilots to production with confidence. Autonomous enterprise is no longer only a vision. With SAP and NVIDIA working together on secure, responsible agent execution, it is beginning now.

Now is the time to get in line.

Generative AI Hub Governance: Controlling Foundation Model Access on SAP BTP

2026-06-01T23:45:41.581000+02:00

When you provision SAP AI Core's Generative AI Hub, you get access to dozens of foundation models through a single orchestration endpoint. One service key, all of OpenAI, Anthropic, Google, Meta — ready to go. That works fine for a single team or a proof of concept, but as soon as multiple departments want access, questions arise: who is allowed to administer the tenant, use which models, how much can they spend, and can you enforce content safety centrally?

This guide is split in two parts.

Part 1 shows what advanced governance you get out of the box with the Content-as-a-Service (CaaS) mechanism. With a single YAML file the provider can hand consumers credentials that are structurally restricted and let them call orchestration without ever giving them admin access.

Part 2 is about everything CaaS does not cover — per-team model allowlists when orchestration is shared, token budgets, content-safety enforcement. We sketch a minimal FastAPI proxy that sits transparently between consumers and AI Core, and we run it live to show the principle. We deliberately stop short of a full reference implementation: the moment you want to govern more than orchestration (direct OpenAI/Anthropic/Gemini deployments), the proxy stops being a thin layer.

All examples use a real test environment: a provider subaccount that owns the AI Core instance, and a consumer subaccount that consumes through CaaS. Every curl and JSON response shown was captured live. This blog's purpose is to show you what is possible and where you need to head to achieve it.

One Instance per Team — or One for Everyone?

Before governance tooling, there is a structural question: should each team get their own AI Core instance, or should you centralize?

With foundation model APIs, the traditional cost argument for centralization does not apply. Unlike the older AI Core pattern of GPU-based model serving where sharing replicas saved real money, foundation models use token-based consumption. There is no GPU infrastructure to share that we manage ourselves. The orchestration "deployment" is an endpoint routing traffic to a provider's model deployment. Every team's tokens are billed per use regardless of how many orchestration endpoints exist.

So centralization is a choice, not a necessity. Each team could provision their own AI Core instance in their own subaccount and get natural isolation through BTP entitlements and directory-level cost allocation.

If you do choose to centralize, the practical benefits are: one place to see all usage across teams, faster onboarding (creating a service instance through a broker takes minutes), and a single integration point where you can enforce governance policies. That last point is exactly what we will make use of in the chapters that follow.

Part 1: Native CaaS Governance

The mechanism that makes centralized governance possible is SAP AI Core's Content-as-a-Service (CaaS) model. CaaS is a multi-tenant distribution mechanism: one subaccount (the provider) owns the AI Core instance and all its deployments. Other subaccounts (consumers) get access through a service broker that the provider publishes. When a consumer creates a service instance through this broker, they receive credentials that are structurally different from the provider's: fewer scopes, different identity, limited to a shared resource group.

On a standard AI Core instance every service key is equivalent — same clientid, same 47 scopes, same admin access. Creating "a key for Team Alpha" and "a key for Team Beta" gives you the illusion of separation with none of the substance. CaaS changes that.

Setting Up CaaS

The provider does this once. After that, consumer onboarding is self-service.

1. Define the service in YAML. Commit this to the AI Core artifacts repository that is connected via GitOps. The flags here control what consumers can and cannot do:

# caas-foundation-models.yaml
apiVersion: ai.sap.com/v1alpha1
kind: Service
metadata:
  name: foundation-model-service
spec:
  brokerSecret:
    name: caas-broker-credentials
    usernameKeyRef: username
    passwordKeyRef: password
  capabilities:
    basic:
      staticDeployments: true       # provider-managed deployments are visible
      userDeployments: false        # consumers cannot create/stop/delete deployments
      createExecutions: false       # consumers cannot run training executions
      userPromptTemplates: true
    logs:
      executions: false
      deployments: false
  enableSharedResourceGroup: true   # provider deploys orchestration + models here
  serviceCatalog:
    - extendCredentials:
        shared:
          serviceUrls:
            AI_API_URL: https://api.ai.internalprod.eu-central-1.aws.ml.hana.ondemand.com
      extendCatalog:
        name: foundation-model-service
        bindable: true
        plans:
          - id: standard
            name: standard
            description: Standard plan - access to pre-deployed foundation models only

The extendCredentials.serviceUrls.AI_API_URL is what every consumer binding will receive as their AI Core endpoint. In Part 2 we will swap this URL for a governance proxy and the consumer SDK will not notice.

2. AI Core registers the service broker. Once the YAML is applied, AI Core creates an Application and exposes a service broker behind a URL like https://aisvc-<id>-foundation-model-service.servicebroker.<region>.aws.ml.hana.ondemand.com. The broker is what consumer subaccounts will talk to when they create a service instance.

3. Provider deploys orchestration in the shared resource group. The shared RG is the only resource group consumers can see. Whatever the provider puts here is what consumers can call — typically the orchestration deployment, which routes to all 50+ foundation models.

4. Consumer subaccounts onboard. The provider registers the broker in each consumer subaccount with the BTP CLI:

btp register services/broker \
  --name foundation-model-broker \
  --url https://aisvc--foundation-model-service.servicebroker..aws.ml.hana.ondemand.com \
  --user  --password  --use-sm-tls \
  --subaccount

After that, the consumer is self-service: they create a service instance through the BTP catalog, then a binding, and receive credentials that include the injected AI_API_URL. Their SAP AI SDK uses those credentials without knowing or caring that a proxy may sit in front.

Once the broker is registered, foundation-model-service shows up in the consumer's BTP Service Marketplace just like any other service — there is no AI Core-specific UI, the consumer treats it as a standard managed service:

The consumer creates a service instance, then a service key (binding). The credentials look exactly like a "normal" AI Core service key would — clientid, clientsecret, url (the consumer's identity zone), and the AI_API_URL that was injected by the provider's YAML:

This is the point of CaaS: from the consumer team's perspective they just consumed a managed service. From the provider's perspective every credential handed out is structurally constrained.

The official AI Core CaaS documentation still describes the older CLI. With BTP CLI 2.106+ the btp register services/broker command above is the supported path — it works against any subaccount in the global account regardless of CF org/space layout.

Refer to the official Help page for additional insights into this feature and its setup.

Scoped Credentials per Team

When a consumer creates a binding through the broker, they receive a credential that is fundamentally different from the provider's:

Property Provider key Consumer key

Scopes	47 (full admin)	3 (minimal)
`clientid`	`sb-<provider-id>!b13079\\|xsuaa_std!b77089`	`sb-<consumer-id>!b65018\\|xsuaa_aicaas!b77089`
Auth endpoint	`<provider-subdomain>.authentication...`	`<consumer-subdomain>.authentication...`
Identity zone	provider	consumer
Reach	everything	call shared deployments

Decoding the consumer JWT confirms it. Three scopes, none of them administrative:

!b65018|xsuaa_aicaas!b77089.servicename.foundation-model-service
!b65018|xsuaa_aicaas!b77089.provider.
uaa.resource

The token also carries ext_attr.serviceinstanceid — the consumer's own service instance ID. In Part 2 the proxy uses this exact field to identify who is calling.

Deployment Protection

The userDeployments: false flag in the YAML is what enforces this. Any attempt by a consumer to create a deployment is denied at the AI Core boundary — before it touches Kubernetes or the orchestration runtime:

curl -s -X POST "$AI_API_URL/v2/lm/deployments" \
  -H "Authorization: Bearer $CONSUMER_TOKEN" \
  -H "AI-Resource-Group: shared" \
  -H "Content-Type: application/json" \
  -d '{"configurationId": "00000000-0000-0000-0000-000000000000"}'

HTTP/1.1 403
RBAC: access denied

Only the provider controls what is deployed and available.

Resource Group Isolation

AI Core organises work into resource groups, and the provider typically has several — development environments, production workloads, project spaces. Consumers can only see the shared resource group. Everything else is invisible:

# Consumer tries to list deployments in the provider's "default" RG
curl -s "$AI_API_URL/v2/lm/deployments" \
  -H "Authorization: Bearer $CONSUMER_TOKEN" \
  -H "AI-Resource-Group: default"

{"count": 0, "resources": []}

The provider has 11 deployments in default and dozens more elsewhere. The consumer sees zero. Listing the shared RG, on the other hand, returns exactly what the provider chose to put there:

{
  "count": 2,
  "resources": [
    {"id": "", "scenarioId": "orchestration", "status": "RUNNING"},
    {"id": "", "scenarioId": "foundation-models", "status": "RUNNING"}
  ]
}

In summary, CaaS gives you scoped credentials, deployment protection, and resource group isolation out of the box — SAP-native, zero custom code.

Model Restriction Without Orchestration

There is one more thing CaaS gives you natively: model restriction, but only if you give up orchestration. If you do not need templating, content filtering, grounding or data masking, you can deploy each allowed model individually in the shared RG and skip orchestration. The consumer calls them with the native provider inference endpoint — for OpenAI models that is the Azure-compatible chat completions API:

curl -s -X POST \
  "$AI_API_URL/v2/inference/deployments//chat/completions?api-version=2024-02-01" \
  -H "Authorization: Bearer $CONSUMER_TOKEN" \
  -H "AI-Resource-Group: shared" \
  -H "Content-Type: application/json" \
  -d '{"messages":[{"role":"user","content":"Say hello"}],"max_tokens":15}'

{
  "choices": [
    {"message": {"role": "assistant", "content": "Hello! How can I assist you today?"}}
  ],
  "usage": {"prompt_tokens": 9, "completion_tokens": 10, "total_tokens": 19}
}

Models that are not deployed simply do not exist for the consumer — a 404 from AI Core, not a custom error. The trade-off: you lose all orchestration features. No prompt templating, no centralised content filtering, no grounding, no data masking. For simple chat-completion use cases this is enough. For workflows that need safety guardrails, it is not — which is where Part 2 begins.

Part 2: Custom Governance Proxy

Once orchestration is deployed in the shared resource group, every consumer can request any of the 50+ models through it. Orchestration is a universal model router, and there is no native configuration to restrict which models a specific consumer can use, to track per-team token spend, or to mandate content-safety filters. Even Token Tracking per Team - or maintaining certain orchestration configurations centrally - is technically feasible if we can put a gouvernance proxy in between the consuming team and the centrally hosted AI Core Endpoints.

The honest assessment up front: this proxy approach scales cleanly when you only proxy the orchestration endpoint. Orchestration is one unified API with one body schema. The moment you also want to govern direct provider deployments — OpenAI chat-completions, Anthropic Messages API, Google Gemini — each schema needs its own model-extraction logic, its own streaming format, its own token usage infos. You end up maintaining a small adapter zoo, and the proxy stops being a thin layer. So when building such a proxy - limitations need to be thought of smartly.

Where the Proxy Goes

Consumer App  -->  Governance Proxy  -->  AI Core Orchestration  -->  Foundation Model
                  (same API)              (consumer credentials)     (token-based)

Two pieces matter:

The proxy implements the same API path as AI Core (/v2/inference/deployments/{id}/completion). Any other path is forwarded unchanged.
The CaaS service YAML injects the proxy URL transparently. The same extendCredentials.serviceUrls.AI_API_URL field we saw in Part 1 now points at the proxy:

serviceCatalog:
  - extendCredentials:
      shared:
        serviceUrls:
          AI_API_URL: https://governance-proxy.cfapps.sap.hana.ondemand.com

The next time a consumer requests a binding, their service key contains the proxy URL as AI_API_URL. Their SDK, their CLI, their notebook — all start talking to the proxy without code changes. The Bearer token they send is unchanged: it is still a CaaS-issued JWT, signed by the consumer's own identity zone, carrying ext_attr.serviceinstanceid. And this is the beauty of this approach - we still give teams the chance to provision the service - get their own service keys and manage them - via the native BTP ways - by hijacking a bit this CaaS approach by infusing a proxy layer. You could of course taks care yourself of hosting a proxy that then authenticates clients with some sort of credentials - but this way a bunch of things are given out of the box.

A Minimal Proxy

The full proxy is a single 90-line main.py. It does three things:

decode the consumer's JWT and identify them via ext_attr.serviceinstanceid (handy for logging, even if we do not branch on it here)
enforce a global model allowlist on orchestration calls
pass everything else (/v2/lm/..., model metadata, scenarios) straight through to AI Core

AICORE_API_URL = os.environ["AICORE_API_URL"]
ALLOWED_MODELS = {"gpt-4o", "gpt-4o-mini", "gpt-5"}  # OpenAI only


def consumer_id_from_token(request: Request) -> str:
    auth = request.headers.get("Authorization", "")
    if not auth.startswith("Bearer "):
        raise HTTPException(401, "Missing Bearer token")
    payload_b64 = auth[7:].split(".")[1]
    payload_b64 += "=" * (-len(payload_b64) % 4)
    payload = json.loads(base64.urlsafe_b64decode(payload_b64))
    sid = payload.get("ext_attr", {}).get("serviceinstanceid")
    if not sid:
        raise HTTPException(401, "Token missing ext_attr.serviceinstanceid")
    return sid


@app.post("/v2/inference/deployments/{deployment_id}/completion")
async def orchestration_completion(deployment_id: str, request: Request):
    sid = consumer_id_from_token(request)
    body = await request.json()

    model = (body.get("orchestration_config", {})
                  .get("module_configurations", {})
                  .get("llm_module_config", {})
                  .get("model_name"))

    if model not in ALLOWED_MODELS:
        return JSONResponse(
            status_code=403,
            content={"error": f"Model '{model}' not in allowlist",
                     "allowed": sorted(ALLOWED_MODELS)},
        )

    upstream = f"{AICORE_API_URL}/v2/inference/deployments/{deployment_id}/completion"
    resp = await request.app.state.http.post(
        upstream, headers=forward_headers(request), json=body
    )

    if resp.status_code == 200:
        usage = resp.json().get("orchestration_result", {}).get("usage", {})
        print(f"usage consumer={sid} model={model} tokens={usage.get('total_tokens', 0)}")
        # TODO: persist this to a database to enforce real budgets

    return Response(content=resp.content, status_code=resp.status_code,
                    media_type=resp.headers.get("content-type"))


@app.api_route("/{path:path}", methods=["GET","POST","PUT","DELETE","PATCH","HEAD"])
async def passthrough(path: str, request: Request):
    """Forward every other AI Core call unchanged."""
    url = f"{AICORE_API_URL}/{path}"
    if request.url.query:
        url += f"?{request.url.query}"
    body = await request.body()
    resp = await request.app.state.http.request(
        request.method, url, headers=forward_headers(request), content=body or None
    )
    return Response(content=resp.content, status_code=resp.status_code,
                    media_type=resp.headers.get("content-type"))

The allowlist is global here — the rule applies to every consumer that goes through this proxy. A common reason to do this is vendor trust: an organisation may decide that for a given environment only OpenAI models are approved while Anthropic, Google or Meta models require additional review. With orchestration the model name is in the request body, so a constant set at the top of the proxy is enough to enforce it.

When you do need per-team allowlists or budgets, swap the constant for a database lookup keyed by ext_attr.serviceinstanceid from the JWT — the consumer identity is already in every request, you just have to use it.

Deployment is a one-line cf push against a 9-line manifest.yml. The full source is in the governance-proxy/ directory of the GitHub repository.

Result

With the YAML in Part 2 applied and the proxy deployed at governance-proxy.cfapps.sap.hana.ondemand.com, here is what the consumer sees.

Allowed model passes through:

curl -s -X POST \
  "https://governance-proxy.cfapps.sap.hana.ondemand.com/v2/inference/deployments//completion" \
  -H "Authorization: Bearer $CONSUMER_TOKEN" \
  -H "AI-Resource-Group: shared" \
  -H "Content-Type: application/json" \
  -d '{
    "orchestration_config": {
      "module_configurations": {
        "llm_module_config": {"model_name":"gpt-4o-mini","model_params":{"max_tokens":15}},
        "templating_module_config": {"template":[{"role":"user","content":"Say hello in German"}]}
      }
    }
  }'

HTTP/1.1 200

{
  "orchestration_result": {
    "choices": [{"message": {"content": "Hello in German is \"Hallo.\"", "role": "assistant"}}],
    "usage": {"prompt_tokens": 11, "completion_tokens": 8, "total_tokens": 19}
  }
}

Identical response format to AI Core, because the proxy returns AI Core's response unchanged. In the proxy logs:

usage consumer= model=gpt-4o-mini tokens=19

A model that is not in the allowlist is blocked before it reaches AI Core:

curl -s -X POST \
  "https://governance-proxy.cfapps.sap.hana.ondemand.com/v2/inference/deployments//completion" \
  -H "Authorization: Bearer $CONSUMER_TOKEN" \
  -H "AI-Resource-Group: shared" \
  -H "Content-Type: application/json" \
  -d '{
    "orchestration_config": {
      "module_configurations": {
        "llm_module_config": {"model_name":"anthropic--claude-3-5-sonnet","model_params":{"max_tokens":10}},
        "templating_module_config": {"template":[{"role":"user","content":"hi"}]}
      }
    }
  }'

HTTP/1.1 403

{
  "error": "Model 'anthropic--claude-3-5-sonnet' not in allowlist",
  "allowed": ["gpt-4o", "gpt-4o-mini", "gpt-5"]
}

Non-orchestration calls pass straight through. The consumer's CaaS scopes still constrain what they can reach — listing deployments works, but only in the shared RG:

curl -s "https://governance-proxy.cfapps.sap.hana.ondemand.com/v2/lm/deployments" \
  -H "Authorization: Bearer $CONSUMER_TOKEN" \
  -H "AI-Resource-Group: shared"

{"count": 2, "resources": [{"scenarioId": "orchestration"}, {"scenarioId": "foundation-models"}]}

That is governance: the model allowlist is enforced at the proxy, the rest of AI Core's surface area still works for the consumer, and from the SDK's perspective nothing has changed.

What You Could Add for Production

The minimal example above is a starting point. There are a number of additional governance levels we can achieve with this approach in a clean way:

Persistent token accounting. The current proxy logs usage to stdout. Persisting this in HANA, Postgres or Redis lets you enforce real budgets ("Team Beta has a 1M-token monthly cap"). We can use the unique identifiers per service instance to implement this per tenant.
Content-safety policy injection. Some customers want to enforce a certain level of orchestration configuration for their custom use cases. For example, one could enforce a certain masking operation to be mandatory across all working teams, or add mandatory content filtering. Without it you rely on the developers to do it in their own code.
Multi-provider adapters. If consumers also call provider-native deployments, each schema needs its own model-extraction logic. This is where the proxy stops being thin. Consider whether you really need to govern those paths or whether you can require all governed traffic to go through orchestration.

The pattern is the same in every case: a transparent proxy that the consumer cannot distinguish from AI Core, with governance logic applied between authentication and forwarding. CaaS gives you the credential isolation; the proxy gives you everything you want to enforce on top of it.

Conclusion

This blog showed how to achieve deeper levels of governance on top of the AI Foundation for custom AI use cases on BTP. We walked through setting up CaaS for AI Core, what isolation it gives you out of the box, and how a small proxy can fill the gaps when orchestration is shared. Checkout this blog to read more on tracking tokens with Generative AI Hub. Find the code example on GitHub here. I hope you enjoyed the content — leave any comments below.

NEW: 🇩🇪 SAP BTP Live Sessions auf Deutsch 🇩🇪

2026-06-10T09:28:00.168000+02:00

Hi SAP Community,

am Montag ging’s bei uns mit englischen Sessions los. Und heute legen wir nach. Denn Mittwoch ist doch eigentlich perfekt, um den eigenen Lernplan aufzustellen: Genug vom Wochenstart geschafft und genau der richtige Moment, um die nächsten Schritte zu planen 😉

Wenn ihr also Lust habt, eure Lernreise weiterzuführen, haben wir jetzt etwas Neues, speziell für unsere deutschsprachige Community:

👉 Unsere neuen deutschsprachigen Live Sessions starten Mitte Juli!

Freut euch auf verschiedene Themen rund um SAP BTP, ideal, um gezielt tiefer in einzelne Bereiche einzusteigen.

Hier ein erster Überblick:

Einige Sessions sind bereits offen zur Anmeldung, und für weitere Live Sessions ist die Registrierung ebenfalls schon freigeschaltet:

Weitere folgen nach und nach. Es lohnt sich also, regelmäßig vorbeizuschauen. Wer weiß, vielleicht ist genau die nächste Session dabei, die perfekt zu eurem aktuellen Lernziel passt 😉

Sichert euch gerne schon jetzt euren Platz. Ich freue mich, viele von euch dort (wieder) zu sehen!

Viele Grüße,
Isabella

SAP’s Autonomous Enterprise: beyond the announcement, toward the architecture

2026-06-11T09:40:52.566000+02:00

When SAP says it’s becoming a ‘Business AI company,’ that’s not marketing. It’s a structural admission that the ERP paradigm built around systems of record is being replaced by something that executes on your behalf.

Here’s what I find most interesting as a technical architect, and what I think gets underplayed.

The architecture

Most coverage focuses on Joule, the 224 agents, and the Claude partnership. These are components. What matters is how they stack.

Figure 1: SAP Joule Architecture Stack

SAP isn’t trying to build the world’s best AI model. It’s building an AI-powered enterprise operating system. An Anthropic partnership makes sense because the roles are distinct: Claude handles reasoning, and SAP handles domain intelligence and governance.

“For the mission-critical processes of our customers, ‘almost right’ just isn’t good enough.” Quote by Christian Klein, CEO, SAP

What the Autonomous Finance demo actually tells us

The most concrete example from Sapphire: a CFO asks Joule to prepare a bank briefing. Minutes later, a completed presentation surfaces with live data, flagged risks, and analysis. That used to take hours across multiple people.

That’s a testable claim, which is the right kind of proof point for enterprise buyers. The same logic applies across Autonomous Spend and Autonomous Supply Chain.

The Autonomous Close Assistant compresses the financial close from weeks to days by automating journal entries, reconciliation, and error resolution. In financial systems with regulatory requirements, there’s no tolerance for ‘good enough.’ That’s what makes the SAP Knowledge Graph central here. It’s not just retrieving data. It’s giving agents the business context to act correctly.

How SAP solved the governance problem

What makes this architecture different from previous enterprise AI attempts is the governed execution layer SAP built around the agents. Joule doesn’t connect directly to agents. Every request routes through the SAP Agent Gateway, which handles identity authentication, principal propagation, and policy enforcement before any agent acts. Agents can collaborate via Agent-to-Agent (A2A) protocol, but every A2A interaction is routed through that gateway. No agent acts outside the governed path. No identity is lost between hops. Every interaction is auditable.n enterprise software, that last point determines whether a CFO will actually sign off on autonomous finance processes.

Figure 2: SAP Joule — Joule as orchestrator, SAP Agent Gateway, A2A protocol, and end-to-end governed flow

The SAP and NVIDIA collaboration on Joule Studio runtime adds another layer. NVIDIA OpenShell provides isolated execution environments, filesystem and network policy enforcement, and runtime containment. SAP contributes the enterprise governance side: roles, identity lifecycle, policy semantics, observability. OpenShell answers ‘Can this agent action safely execute?’ Joule Studio runtime answers ‘Should this action happen at all?’ SAP is a key contributor to the OpenShell open source project. The Joule Studio Early Adopter Program is open now.

What this means for the SAP architect

The required skill set is shifting. The next generation of SAP architects won’t train foundation models, but they will need to understand how agentic systems fit into existing business process logic.

Figure 4: SAP Architect Skill Stack — core platform, agentic layer, AI fundamentals

Agent mining is one of the less-discussed announcements worth paying attention to. It’s an extension of process mining: it catalogs what agents did, where they slowed down, and whether they behaved as expected. The AI Agent Hub, included free for all SAP Business AI Platform customers, is where this governance lives. As more agents start operating inside finance and supply chain, this observability is not optional.

Functional expertise in finance, supply chain, and procurement doesn’t get less valuable here. Someone has to define what ‘correct’ looks like for an agent operating in those domains. The architect who can connect deep process knowledge with agentic design patterns will be at the center of these transformations.

My take

SAP Sapphire 2026 moved the enterprise AI conversation from roadmap to production intent. The partnerships with Anthropic, AWS, NVIDIA, and Google Cloud are real. The domain depth built from 50 years of ERP process logic is a genuine differentiator that general-purpose AI platforms will find hard to replicate.

Figure 3: SAP Autonomous Enterprise — Autonomous Suite, Joule Work, Business AI Platform and key partners

SAP has also been serious about the data foundation underneath the agents. The Dremio acquisition makes SAP Business Data Cloud an Apache Iceberg-native lakehouse for SAP and non-SAP data. Prior Labs brings tabular foundation modelling in-house. Reltio adds master data management. SAP-RPT-1.5 is a relational pretrained transformer built for structured enterprise data. The model is a commodity layer. The data and context SAP has assembled are not.

What SAP has built is the coordination layer between AI systems and the systems of record they need to operate inside. That’s been the missing piece in enterprise AI for two years. Joule Studio, the Agent Gateway, agent mining via the AI Agent Hub, and the NVIDIA OpenShell runtime together answer the question most agentic initiatives couldn’t: not whether an agent can act, but whether you can prove it was allowed to.

One question I keep sitting with: will enterprise AI be won by the best model, or by the platform that best combines business context, governance, and execution? I suspect it’s the latter. SAP is making a credible bet on exactly that.

#SAP #SAPPHIRE2026 #AutonomousEnterprise #EnterpriseAI #Joule #SAPBTP #AgenticAI #DigitalTransformation

Check and then Re-Check Your Cloud Foundry Org and Spaces for Correct User Assignments

2026-06-25T07:38:01.950000+02:00

Summary: A user can have zero access to SAP BTP Global and SubAccount and still be able to create, read, edit, or delete every service key in BTP! All you need is access at the Cloud Foundry level. Your landscape can be compromised leading to data privacy issues and business continuity can be disrupted significantly. Read more to find out how.

Most of the organizations use SAP BTP Integration Suite to connect systems across their landscape. A standard pattern is exposing HTTP endpoints (or other inbound endpoints) to third party systems so they can trigger integration flows.

To authenticate against those endpoints, you create service keys on the Process Integration Runtime service instance (integration-flow). These are basically API credentials in a way which we call Service keys (the other API credentials are available in the API Management - Developer Hub) and they live at the Cloud Foundry space tied to the service instance. Anyone with those credentials can call your integration endpoints directly and send or read data.

BTP admins generally manage user access carefully at SubAccount and Global Account level but generally find it too taxing to manage carefully at Cloud Foundry org and space level. When offboarding someone, most admins remove the user from the SubAccount and Global Account either manually or using IAS and then stop there. If that person still has any kind of CF access, they retain full access to every service key -- and they don't need the BTP cockpit to use it. In fact they won't have access to these using the BTP Cockpit. All they need is CF CLI or CF API to access these. The CF CLI and CF API are available to anyone on the internet for download, and a few commands is all it takes to create, read or delete any service key in the BTP environment.

I have found this security hole at many customers I am working with. The team has removed the user from the SubAccount but the user is still active in Cloud Foundry with no one having bothered to remove them from there thinking that removing them from SubAccount using IAS is enough. It is not! Even if you remove someone through IAS you must separately ensure they are fully removed from CF membership, not just their roles.

Concrete Example: say Target orders flow into S/4HANA via Integration Suite secured by service keys. A disgruntled ex-employee with no BTP cockpit access but still active in CF can delete every one of those keys. Integrations go down, orders stop getting received, and the business stops!

SAP does offer a connector to automate CF user and role management via SAP IPS (Identity Provisioning Service): https://community.sap.com/t5/technology-blog-posts-by-sap/streamlining-user-management-integrating-sap-integration-suite-with-sap/ba-p/14069705

If you have used, please comment and share you experience especially on how easy it is to use it.

A Big thanks to the SAP BTP xID tool because of which I was able to find this issue.

In the meanwhile I urge all SAP BTP Administrators to check their CF Orgs and Spaces for any assigned users who should not be there.

Update: Possibly, the following security standards get violated when you just rely on controlling S user lifetime to control access to the API and Service Keys.

1. ISO/IEC 27001:2022 (Information Security Management) - Control A.5.15 (Access Control): Requires access to assets to be restricted based on business and security requirements.

2. NIST SP 800-53 (Security and Privacy Controls) - AC-2 (Account Management)

3. PCI DSS 4.0 (Payment Card Industry Data Security Standard) - Requirement 8.6: Strictly regulates the use of application accounts

4. SOC 2 Type II (Trust Services Criteria) - Logical Access Controls (CC6.1/CC6.2): Internal controls must prevent unauthorized logical access to data.

5. Sarbanes-Oxley (SOX) Section 404 (Internal Controls) Compliance - Section 404 mandates that management and auditors establish, maintain, and regularly assess the effectiveness of internal controls over financial reporting to prevent fraud and data tampering. Financial data generally passes through these integrations on a regular basis. If the keys are freely accessible, it is possible, that a rogue internal or external actor can tamper with integrations, run them with incorrect data with no way to find out later who did it.

My recommendation: I would recommend that apart from one nominated administrator, nobody else should have access to the Production SAP BTP Cloud Foundry Environment in normal course of business. The access should be given to the CF environment only as temporary firefighter access same as is today done in SAP ERP or S/4HANA Production systems. Developers generally do not have unhindered access in these systems, most of the time not even read only access. The same concept needs to be applied to SAP BTP production environments also. This needs to be matured as part of SAP BTP Governance setup.

Ask Me Anything with SAP Champions – Monthly Series (Session 5)

2026-07-01T08:21:48.442000+02:00

Hi folks, Martin here 👋

🎬We're back — and this time we're getting our hands dirty with security.

The Ask Me Anything with SAP Champions series is rolling into Session 5, and I'm excited to be in the hot seat this time. The concept is dead simple: you ask, I answer. No slides, no scripted demos, no marketing gloss — just honest answers to the questions you actually care about.

And the topic? The one that keeps SAP architects, Basis admins, and CISOs up at night: SAP Security 🛡️

Securing S/4HANA, RISE, GROW, BTP, threat detection, identity and access, integration security, and the brand-new headache of AI agents poking around in your SAP data — if it's about keeping SAP safe, it's fair game.

🤔So what should you ask me?

Honestly? Whatever's bugging you. But if you want a head start, here's what fits this session perfectly:

- 🔐 Securing SAP in the cloud — RISE, S/4HANA, BTP and the works

- 👀 Threat detection & monitoring — actually *seeing* what's happening inside SAP

- 🪪 Identity & access — SSO, principal propagation, federation, least privilege done right

- 🔗 Integration security — APIs, OData, BTP, connecting SAP to the outside world without leaving the door open

- 🤖 AI & automation — keeping copilots and agents that read SAP data on a tight leash

- 🚀 Getting started — practical first steps when you're maturing your SAP security posture

Don't see your topic? Ask anyway. The questions I have to *think* about are always the best ones — and far more fun than the easy ones. 😉

📨How to send me your questions (pick whatever's easiest)

Three ways in, all roads lead to the same place:

1. Microsoft Forms — name or community handle optional, ask anonymously if you like 👉 link

2. Comment right here — drop your question under this blog post

3. LinkedIn — reply to my announcement post 👉 LinkedIn post link

🗓️ Get them in by: July 7th

🎥What happens next

Here's the neat part — there's nothing to attend, nothing to squeeze into your calendar:

1. You send your questions before the deadline.

2. I pick the most interesting and widely useful ones.

3. I answer them on camera in a recorded video on the SAP Community YouTube channel 📺

4. And for the readers among you (I see you 👀), a written recap blog with all the questions and answers lands right here afterwards.

So whether you prefer to watch or read, you get the full thing on your own schedule. 🙌

💡Why bother joining in?

- Get a real answer to a real problem — bring me the thing you're genuinely stuck on.

- Learn from questions you'd never have thought to ask — this community always surfaces angles I love.

- Steer the series — your questions shape what we tackle next.

👉Over to you

SAP security isn't a one-and-done checkbox — it's an ongoing conversation. So let's have it.

Fire your question over via anonymous Forms, drop it in the comments, or hit me up on [LinkedIn — placeholder] before July 6th.

I'll see you in the recording — and in the recap blog right here on the community. Let's go! 🚀

See the other series editions in the community corner and where it all began here.

#SAPChampions #AMA #SAPCommunity #SAPSecurity #SAPCyberDefense

Integrating SAP Concur with SAP IAG – Implementation Guide and Key Learnings

2026-07-01T22:58:56.028000+02:00

Introduction

SAP IAG Enterprise (Standard) edition provides out-of-the-box integration with SAP Concur for user provisioning and access governance. However, during implementation, it has been observed that certain areas require deeper understanding beyond standard documentation.

This blog covers:

Detailed configuration steps
Important technical considerations
Practical challenges faced during implementation

The intent is to provide a simple and practical guide for SAP IAG consultants working on SAP Concur integration.

Initial SAP IAG System Setup

Before starting the integration, ensure the following setup is completed:

SAP BTP setup: Global Account → Subaccount → SAP IAG Enterprise Edition subscription (Test/Prod)
Trust configuration is completed with SAP Cloud Identity Services (CIS), including attribute mapping
Standard SAP IAG groups are created in SAP CIS, such as: IAG_USER, IAG_WF_MANAGER, IAG_WF_ADMIN, IAG_RAA_DEFAULT, etc.
If the manager is used as an approval stage in access requests, the user’s manager must be assigned with the IAG_WF_MANAGER group so that it is automatically derived in the access request form. Otherwise, the requester needs to manually select the manager from users assigned to this group
Role collection to CIS group mapping is configured (for example): CIAG_Access_Request, CIAG_Access_Analysis mapped to a custom CIS group like ZIAG_Access_Requestor.
Access to SAP IAG with administrator privileges
User data source is configured using SAP Identity Services Identity Directory or Identity Authentication Service via IPS_PROXY V2.
Application parameters and master data are properly maintained
User and group synchronization is configured using SCIM
Mail server is configured for outbound emails (Destinations: parameters_destination and bpmworkflowruntime_mail)

SAP Concur to SAP IAG Integration and Configuration Steps

The following steps outline the end-to-end configuration required to integrate SAP Concur with SAP IAG after completing the initial system setup.

Step 1: User Provisioning Service V4 (UPSv4)

User Provisioning Service V4 (UPSv4) is an SAP Concur API framework that enables SAP IAG to automate user provisioning and lifecycle management in SAP Concur.

To use the User Provisioning Service (UPSv4) API, the client must have Concur Expense, Concur Travel, or both.

Clients using Concur Expense Professional/Premium Edition and/or Concur Request Professional/Premium Edition need to get UPS enabled through their Concur Client Executive (Sales Representative).

In addition, the client must subscribe to Client Web Services after signing the web services agreement. This will then be included as part of the SAP Concur contract.

For API details, refer to:

There are also certain limitations with UPS, which can be referred to in SAP Note:

SAP Note 3363157

Step 2: Configure OAuth2 authentication application and Generate company refresh token and UUID

Once the User Provisioning Service (UPSv4) is enabled, the next step is to configure OAuth2 authentication for SAP Concur integration.

This step establishes secure API-based authentication between SAP IAG and SAP Concur using OAuth2 credentials and tokens.

This involves two key activities:

Step 2.1: Configure OAuth2 Application

This helps to create authentication credentials (Client ID/Secret) and defines required API access scopes.

Create an OAuth2 authentication application in SAP Concur
Generate Client ID and Client Secret
Maintain the required grants and scopes

Step 2.2: Generate Company Token and UUID

This provides tenant-specific identifiers and tokens required for API communication with SAP Concur.

Generate the Company Request Token
Obtain: Token Service URL, Refresh Token, Company UUID

A detailed reference for this setup is available in the SAP Community blog by @tim_chapman24

Introduction to Web Services for Concur Expense Authentication

Additional reference:

Concur Authentication API Documentation

Important Configuration Points

While configuring the OAuth2 application, ensure that the required grants and scopes are maintained correctly
Missing grant or scope may result in 403 (Forbidden) errors in provisioning logs

For SAP IAG integration, the following grants can be maintained:

refresh_token
password

For more details, refer to:

Scopes to be Maintained

Below are the commonly required scopes:

Scope	Scope Description
identity.user.core.read	Read user core data
identity.user.coresensitive.read	Read core sensitive data
identity.user.emails.verified.writeonly	Write access for verified email
identity.user.enterprise.read	Read user enterprise data
identity.user.coreenterprise.writeonly	Write access to all core and enterprise fields except external ID
identity.user.externalID.writeonly	Write access to external ID only
identity.user.ids.read	Read user ID data
identity.user.sap.read	Read a user’s SAP Global ID. Used for intra SAP service communication
identity.user.sap.writeonly	Write a user’s SAP Global ID. Used for intra SAP service communication
spend.user.general.read	View spend user information
spend.user.general.writeonly	Change spend user information
travel.user.general.read	Read general Travel data: Travel approval manager, Travel Name, Rule Class, Groups, Org Unit, Travel Custom Fields
travel.user.private.read	Read private Travel data: CRS Name/GDS Sync ID, Travel Name Remark, Gender
user.provision.read	Request status of a provisioning request
user.provision.write	Provision a user

Required Permissions in SAP Concur

Ensure that the Concur administrator has the following permissions:

Activity	Permission
Configure OAuth2 authentication Application	Web Services Administrator
Generate Company Request Token and Company UUID	Web Services Administrator
User Creation and Maintenance	Employee Administrator
Permission Assignment and Administration	Role Administrator

Step 3: Destination Setup in BTP Subaccount

This step defines the connectivity configuration in SAP BTP to enable SAP IAG to communicate with SAP Concur APIs.

Create a destination for SAP Concur in the BTP subaccount where the SAP IAG service is subscribed.

Maintain the destination with the following details:

Property Key	Values
Name	CONCUR (or any other preferred name)
Type	HTTP
Description	Concur Destination (or any other preferred description)
URL	<Enter SAP Concur API URL> For example: https://us.api.concursolutions.com (Refer to https://me.sap.com/notes/2914977/E for Concur URLs)
ProxyType	Internet
Authentication	OAuth2RefreshToken
Use mTLS for token retrieval	<Unchecked>
Client ID	Enter the generated Concur Client ID in Step 2.1
Client Secret	Enter the generated Concur Client Secret in Step 2.1
Token Service URL Type	Dedicated
Token Service URL	Enter the SAP Concur token URL in Step 2.2
CompanyEntityCode	Registered Company Entity Code can be obtained from SAP Concur team
CompanyUUID	Generated Company UUID in Step 2.2 (will be used as prefix to user ID in SAP Concur)
RefreshToken	Generated refresh token in Step 2.2
Use default client truststore	<Checked>

Important Note: The Company Entity Code is used as a prefix for the user ID during provisioning in SAP Concur from SAP IAG. As a result, the user ID is created in the format: <user_ID>@<CompanyEntityCode>

Step 4: Create an Application in SAP IAG

This step registers SAP Concur as a managed application in SAP IAG to enable access governance and provisioning.

Click on the ‘+’ icon to create a new application and maintain the following details:

Field	Value
Application Name	CONCUR (or Any other preferred name)
Description	SAP Concur Application (or any other preferred description)
Application Type	SAP Concur
HCP Destination	<BTP destination created above. Provide exactly same name of BTP destination.>

Mandatory Custom Fields

Once the application is created, SAP IAG automatically creates four mandatory custom fields.
These can be verified under: Administration → Custom Fields

Name	Description	Label	Input Type	Data Type	Field Length	Required	Allowed values
COUNTRY	Spend User Country	Country	Input Text	String	2	Yes	A two-letter country code defined in ISO 3166-1 alpha-2 F(e.g. GB for UK, AU for Australia, US for United States of America, etc.)
LOCALE	Spend User Locale	Spend-User Locale	Input Text	String	5	Yes	Required when using Spend User extension. Valid locale from the list of configured locales as defined in [RFC5646]. But here for Concur, the locale will be an ISO 639 language code with an ISO 3166 country/region code, separated by a underscore (e.g., en_US, en_AU, de_DE, etc.)
REIMBURSEMENT_CURRENCY	SpendUser Reimbursement Currency	Reimbursement Currency	Input Text	String	3	Yes	Valid three digit currency code in the list of system reimbursement currencies. Ex. AUD, USD, etc.
REIMBURSEMENT_TYPE	SpendUser Reimbursement Type	Reimbursement Type	Input Text	String	20	Yes	The reimbursement type for the user. Supported values: ACCOUNTS_PAYABLE, ADP_PAYROLL, CONCUR_PAY, OTHER.

Important Points

These custom fields will appear in the access request form for SAP Concur
All four fields are mandatory for both new and existing users
Values must be provided in the correct format, otherwise provisioning will fail

Even though SAP IAG provides an option to edit or deactivate these fields under Custom Fields, it is recommended not to change them, as they are required for Concur provisioning.

Additional Note

SAP is introducing additional custom fields to support more Concur attributes. You can track updates here: SAP Roadmap Explorer – SAP IAG Concur Enhancements

Step 5: Run Repository Sync Job

This step helps to synchronize users and access (roles/profiles) from SAP Concur into SAP IAG for governance processes.

After creating the application, run the Repository Sync job to fetch data from SAP Concur.

Navigate to Administration → Job Scheduler and execute the Repository Sync job for the SAP Concur application

Once the job is completed successfully, user and access data from SAP Concur are synchronized to SAP IAG.

You can verify the synchronized data in:

Maintain User Data
Access Maintenance (use filters for SAP Concur)

User Data

SAP Concur user ID is displayed in the format: <user_id>@<CompanyEntityCode>
The <user_id> corresponds to the login name maintained in SAP CIS

Access Data

Under Access Maintenance, two types of access are available for SAP Concur:

Concur Product: Represents Concur profiles such as Expense, Invoice, Reporting, Request, and Travel
Single Roles: Represents authorization roles such as EXP_APPROVER, EXP_ATTENDEE_ADMIN, EXP_CONFIG_ADMIN_CLIENT, etc.

Both access types can be requested via SAP IAG. Additional attributes such as: Business Process, Subprocess, Criticality, Alias, Assignment Approvers etc. can be maintained to control workflow routing and approval determination.

Note:
Only users assigned with the IAG_RAA_DEFAULT group are available for role assignment approval.

Step 6: Configure Access Risk Ruleset

This step helps to enable risk analysis by importing and activating SAP Concur-specific segregation of duties rules.

For risk analysis, the standard GLOBAL ruleset for SAP Concur needs to be requested.

Create an SAP Support case for component: GRC-IAG-AA (Access Analysis Service)
Provide required access (IAS Administration) to SAP to upload the ruleset

Once the ruleset is uploaded:

A business function group SAP_CONCUR is created
All SAP Concur-related risks are available under this group

Ruleset Behavior

SAP Concur roles are standard and cannot be customized
Risks are defined based on conflicting role combinations

Example:

Post ruleset setup, validate the risk count against the business function group and run the Access Analysis job from the Job Scheduler.

After completion of Access Analysis job User-level risks can be checked in ‘Access Analysis’ application and role-level risks can be checked in ‘Access Maintenance’ application.

Step 7: User ID mapping

This step aligns user identities across systems to avoid duplicates and ensure accurate license consumption.

User ID mapping is important for license optimization in SAP IAG. The Monitored User List in Maintain User Data shows users consuming IAG licenses

Key Consideration

SAP Concur uses a different user ID format: <user_ID>@<prefix>

If multiple applications are integrated with SAP IAG:

The same user may appear as different users due to different ID formats
This can lead to duplicate license consumption

SAP IAG supports auto user ID mapping for most applications Refer: SAP Note 3553352 (Auto-Generated Entries in User ID Mapping) however, SAP Concur is not supported for auto-mapping

Hence to avoid duplicate license consumption user ID mapping must be maintained manually. This requires additional monitoring as part of ongoing operations for new user creation and also increases administrative effort.

How to Maintain Mapping

Navigate to: Administration → Maintain User ID Mapping
Mapping can be maintained: Individually or via Bulk upload through CSV file

Master User ID → Login name from user source and Mapped ID → SAP Concur User ID

Additional Notes

Other IAG services (Access Request, Workflow, Role Design, Access Analysis, Access Certification) work similarly to other applications
Privileged Access Management (PAM) Service is not supported for SAP Concur

Key Learnings and Limitations

Based on implementation experience, below are some important points to be aware of:

1. Provisioning Behavior (Asynchronous Processing)

Provisioning in SAP Concur works in an asynchronous manner.

Step 1: When the access request is submitted, the first run of the provisioning job shows the status as “In Process”
Step 2: In the next job run, the final status is updated as “Successful” or “Failed” based on the actual result

So, the provisioning result is not available immediately in the first run.

2. Manual User ID Mapping Required

As SAP Concur does not support automated user ID mapping:

Manual mapping is required in SAP IAG
Continuous monitoring is needed for new users

Without this, duplicate users may be created, leading to additional license consumption.

3. Mandatory Custom Fields

All four custom fields are mandatory:

COUNTRY
LOCALE
REIMBURSEMENT_CURRENCY
REIMBURSEMENT_TYPE

If any field is left empty or deactivated, provisioning will fail.

4. No Validation for Custom Fields

Custom fields accept only specific values (mentioned in step 4) and formats (case-sensitive).

However:

Validation is not enforced at the request submission stage, which may require additional checks during provisioning
Users can submit incorrect values
Request goes through full approval workflow
Failure happens only during provisioning job execution.

In addition:

Logs may require additional analysis to identify the exact issue
Administrators need to analyze logs to find the problem

5. No Pre-population of Custom Fields

Custom fields need to be maintained for both new and existing users
There is no pre-filled data even for existing users

This requires proper end-user training before rollout.

6. Partial User Creation in case of errors

If incorrect values are provided in custom fields user may still get created in SAP Concur but no profiles or roles are assigned

Such users are difficult to find using standard user search and may require support from SAP Concur functional team to verify at database level.

Users who exist in SAP Concur but do not have any profiles (Expense, Travel, etc.) will still appear in Maintain User Data and will be counted for SAP IAG licensing.

7. No Bulk Provisioning Support

SAP IAG currently does not support bulk user provisioning/deprovisioning for SAP Concur.

Recommended approach:

Use SAP ICS (Integration with SAP Concur Solutions) / SAP IPS for user creation with basic roles and/or user account termination/deactivation.
Use SAP IAG only for role-based access requests

8. Option for HR-Driven Provisioning

Integration with SuccessFactors can be used to trigger user creation/termination and manage lifecycle and provisioning automatically.

9. Refresh Token Handling

Refresh token used in BTP destination has a validity of 6 months
SAP IAG / SAP IPS automatically refreshes the token during provisioning job execution

No manual intervention is required in normal scenarios.

10. Standard Risk Rules May Need Adjustment

The Global ruleset for SAP Concur includes some risks which may not be relevant because SAP Concur has built-in controls for certain scenarios to prevent risks.

Such risks can be reviewed with business and deactivated, if required.

Overall, the integration is manageable, but attention to detail is important, especially around custom fields and user mapping. This guidance is based on practical implementation experience, highlighting what worked well and the challenges encountered during execution.

Going forward, SAP may address some of these challenges, such as improvements in custom field handling, automated user ID mapping, more relevant global rulesets, and clearer provisioning logs, which should simplify the integration further.

If you have faced similar challenges or have additional insights, feel free to share your experience in the comments.

How to Scan Custom ABAP for Security Issues in Eclipse (Step-by-Step)

2026-07-03T10:20:40.741000+02:00

Disclosure: I work on this tool at RedRays. This post is a straightforward setup guide, not a product pitch.

This post walks through connecting Eclipse to a static analysis backend that scans custom ABAP for common security issues (SQL injection, missing authorization checks, hard-coded credentials, weak crypto, and similar) and returns findings directly in the IDE.

Prerequisites

- Eclipse 2024-09 or newer
- SAP ABAP Development Tools (ADT) installed
- Java 17
- Network access to the backend you plan to scan against (in this walkthrough, a demo instance)

Step 1: Get an API key

The plugin needs an API key to authenticate against a scan backend. For testing, there's a self-service demo instance:

1. Open get.abap-security.com.
2. Enter a name and email address.
3. Click Create my Eclipse API key.
4. Copy the key immediately - it is displayed once.

Notes on the demo instance:
- Limited to one key per IP address per time window.
- It is a shared instance - do not submit confidential or production code to it. For real use, point the plugin at your own tenant or an on-premise instance instead (see "Beyond the demo" below).

Step 2: Install the plugin

In Eclipse:

1. Help → Install New Software…
2. Click Add… and enter the update site: plugin.abap-security.com
3. Select RedRays ABAP Scanner from the list.
4. Finish the wizard and restart Eclipse when prompted.

Step 3: Configure the connection

1. Window → Preferences → RedRays Scanner
2. Set Working mode to RedRays.
3. Set RedRays URL to https://demo.abap-security.com:8443/ (or your own instance's URL).
4. Paste the API key from Step 1 into RedRays API key.
5. Click Test connection and confirm it succeeds before continuing.

Step 4: Run a scan

1. Right-click any ABAP object in the Project Explorer.
2. Select Scan with RedRays.
3. Choose the Quick scan profile for a first run.
4. Findings appear in a dedicated Eclipse view as the scan completes.

Reading the results

- Findings are grouped by severity: Critical, High, Medium, Low.
- Double-clicking a finding opens the source at the exact line.
- Each finding includes a CVSS score and an automated exploitability check, intended to reduce false positives that would otherwise need manual triage.

Categories currently covered include: SQL/ADBC injection, OS command execution, dynamic WHERE/ORDER BY clauses, path traversal on OPEN DATASET, RFC trust issues, missing AUTHORITY-CHECK, hard-coded credentials, and weak cryptographic algorithms (MD5/SHA-1), among others.

Beyond the demo

The same plugin can point at a privately provisioned tenant or an on-premise instance instead of the shared demo, with isolated access per subaccount and no source retention (code is scanned in memory and discarded; only findings are stored). There is also a REST API for scanning from CI/CD, including an endpoint that returns an allow/block decision for a transport based on a severity threshold - useful as a pre-import gate.

Resources

- Plugin overview: redrays.io/abap-scanner-eclipse-plugin
- Demo / API key: get.abap-security.com

Migrating SAP BTP Service Bindings from Binding-Secret to mTLS (X.509) — A Step-by-Step Fix

2026-07-05T13:55:59.350000+02:00

The Error

During the upgrade, the following error appeared for an older service instance:

Async operation for service binding "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"(Guid of the servivce instance)

between app "application-name" and service instance "service-name" with offering "html5-apps-repo" and plan "app-runtime" failed with errors: 10009 CF-UnableToPerform bind could not be completed: Service broker error: Service broker html5-apps-repo-sb failed with: Failed to obtain UAA cloning binding information. Status code: 400. Body: {"error":"Unsupported credential type"}.

Root cause

The existing XSUAA configuration of the service instance only allowed `binding-secret` as the credential type. It had no awareness of X.509, so any attempt to create an mTLS binding was rejected by the service broke

The Fix

Step 1 — Create a Service Key for the Existing Instance

First, create a service key using the old credential type to access the instance's current XSUAA configuration using below cli command:

cf create-service-key <serviceInstanceName> <serviceInstanceKeyName>

Step 2 — Extract the UUID from the xsappname

Retrieve the service key and locate the `xsappname` field using below cli command:

cf service-key <serviceInstanceName> <serviceInstanceKeyName>

The xsappname will look like this: fec39a25-a570-46b0-8ac9-1691f8d663cc!b6711|html5-apps-repo-uaa!b6711

Extract the UUID portion — everything before the `!`: fec39a25-a570-46b0-8ac9-1691f8d663cc

Step 3 — Update the Service Instance to Allow X.509

Create a file named `update-instance.json` with the following content, using the UUID extracted above:

{

"xs-security": {

"xsappname": "fec39a25-a570-46b0-8ac9-1691f8d663cc",

"oauth2-configuration": {

"credential-types": ["binding-secret", "x509"]

}

Include both `binding-secret` and `x509` in `credential-types` if you need to support both during a rolling migration.

Then apply the update using below cf cli command:

cf update-service <serviceInstanceName> -c update-instance.json

This updates the XSUAA app configuration to allow X.509-based bindings for this service instance.

Verification

To confirm the instance now supports X.509 bindings, create a new service key explicitly requesting the `x509` credential type.

Create `parameters.json`:

{

"xsuaa": {

"credential-type": "x509",

"x509": {

"key-length": 2048,

"validity": 7,

"validity-type": "DAYS"

}

Create the service key using below cli command:

cf create-service-key <serviceInstanceName> <serviceInstanceKeyNameNew> -c parameters.json

Retrieve it using below cf cli command:

cf service-key <serviceInstanceName> <serviceInstanceKeyNameNew>

A successful result will include a `certificate` field and `"credential-type": "x509"`:

{

"certificate": "-----BEGIN CERTIFICATE-----...-----END CERTIFICATE-----\n...",

"clientid": "...", "credential-type":

"x509",

...

}

If you see the certificate chain in the output, the service instance is now configured correctly and your mTLS-based application binding will succeed.

This fix is applicable to any SAP BTP service instance backed by XSUAA where the credential type was never explicitly configured to support X.509.

If you hit the "Unsupported credential type" error during an mTLS migration, updating the XSUAA "oauth2-configuration" on the service instance is the path forward.

Referred help document - https://help.sap.com/docs/btp/sap-business-technology-platform/configure-credential-type-for-html5-application-repository-service-instances?locale=en-US

Lernen verbindet – Entdecke unsere 🇩🇪 deutschsprachigen 🇩🇪 Live Sessions in Q3

2026-07-06T18:19:45.569000+02:00

Q3 ist in vollem Gange. Welche Themen möchtest du dieses Quartal noch entdecken?

Vielleicht gibt es ein Thema, das schon länger auf deiner Lernliste steht. Vielleicht möchtest du dein Wissen vertiefen oder einfach neue Impulse mitnehmen.

Unsere deutschsprachigen SAP BTP Live Sessions bieten die Gelegenheit dazu. Von Grundlagen über Integration und Entwicklung bis hin zu Architektur- und Automatisierungsthemen wartet ein vielfältiges Lernangebot auf dich.

Vielleicht ist genau die Session, die dich weiterbringt, bereits Teil des aktuellen Programms:

https://community.sap.com/t5/technology-platform-learning-group-blog-posts/new-sap-btp-live-sessions-auf-deutsch/ba-p/14415241

Also welches Thema möchtest du in Q3 noch entdecken?

Wir sehen uns in den Live Sessions!

Q2 2026: Quarterly Release Highlights for SAP BTP Security and Identity & Access Management

2026-07-10T10:32:22.335000+02:00

The world of security never stands still, and neither do we. Here's a quick look at the latest SAP BTP Security and Identity & Access Management updates from this quarter, with the features and improvements worth adding to your radar.

For a complete overview of feature deliveries for SAP Cloud Identity Services, check out our list of all new feature announcements in the SAP Cloud Identity Services Release Notes on the SAP Help Portal.

SAP Cloud Identity Services: Technical users

SAP Cloud Identity Services now supports technical users—a new user type designed for non-human identities that enable secure, automated system-to-system communication and integrations. Technical users are managed separately from regular users through the new Technical Users tile under Users & Authorizations in the administration console, making it easier to create, organize, and maintain service identities. For step-by-step instructions, see Managing Technical Users.

SAP Cloud Identity Services: Block and delete users

Keeping your Identity Directory clean has just become easier. You can configure SAP Cloud Identity Services to automatically delete users who were created but never signed in to an application, helping reduce inactive accounts and simplify user lifecycle management. We’ve extended this functionality by adding a grace period. For configuration details, check Block or Delete Users Due to Inactivity.

SAP Cloud Identity Services: Automatic creation of Identity Provisioning tenants on SAP Cloud Identity for Neo tenants

Starting June 10, 2026, SAP automatically creates a new Identity Provisioning tenant on the SAP Cloud Identity infrastructure for every existing Identity Provisioning tenant running on the Neo environment that is linked to a shared IAM tenant with Identity Authentication.

This automatic provisioning gives you access to the latest Identity Provisioning capabilities and configuration options available on the SAP Cloud Identity infrastructure—features that are not supported on Neo. The newly created tenant is used for integrations related to bundled SAP cloud solutions, helping prepare your landscape for future enhancements. For migration details, see Migrate Identity Provisioning Bundle Tenant.

SAP Secure Login Service for SAP GUI: Now available in China

Organizations in China can now subscribe to the SAP Secure Login Service for SAP GUI and run the service on infrastructure located within China. This availability helps customers meet local deployment requirements while modernizing authentication for SAP GUI. They will be able to simplify integration by connecting more easily with enterprise identity providers, and strengthen security with enhanced support for multifactor authentication (MFA).

You can see the supported data centers here. For more information on the SAP Secure Login Service for SAP GUI, check the SAP Help Portal.

Application Vulnerability Report for SAP BTP

In December 2025, SAP introduced the Application Vulnerability Report (beta) for SAP BTP, providing an API-driven way to identify open-source vulnerabilities in your Cloud Foundry applications.

The service has now been enhanced with its first graphical user interface, available directly in the SAP BTP Cockpit. The new interface features an intuitive findings dashboard with a severity breakdown, along with a detailed findings view that provides actionable remediation guidance to help you address identified vulnerabilities.

The Application Vulnerability Report is currently available as a beta service in the EU10 region. While subscriptions are not yet available in other SAP BTP landscapes, the service's scanning scope has been expanded significantly. It now scans applications deployed across 42 Cloud Foundry landscapes worldwide, including regions in the United States, Asia Pacific, Japan, Brazil, and additional European landscapes beyond the original EU10 region.

Stay in the loop

Join the SAP BTP Security and SAP Cloud Identity Services communities to get updates, share feedback, and connect with others!

Leading the Way for Post-Quantum Cryptography

2026-07-13T20:18:23.396000+02:00

By Sandip Dholakia, Chair Cryptography Innovation Hub, and Volkmar Lotz, Project Lead Crypto Agility Initiative, SAP

Quantum technologies are advancing rapidly, leading to a cryptographically relevant quantum computer that can break today’s public-key cryptography, which will be available sooner rather than later.

Like major industry peers, SAP is aware of the increased risk and is striving to be post-quantum ready by 2029 across its products, services and infrastructure. SAP has established a Cryptography Center or Excellence (CoE) that governs the migration process, maintains a cryptographic inventory, and coordinates migration projects across the company following a roadmap recognizing technical and business priorities for the identified cryptographic assets. Protecting customer data and privacy remains SAP’s highest priority, and to support this commitment, the SAP cryptography CoE has adopted a long-term strategy focused on cryptographic agility rather than one-off migration projects.

The Risk

Quantum computers can solve certain mathematical problems faster than classical computers. In 1994, Peter Shor demonstrated that a sufficiently powerful quantum computer could efficiently factor large integers and solve discrete logarithm problems. This breakthrough directly threatens widely used public-key cryptography algorithms, including RSA, Diffie-Hellman, and Elliptic Curve Cryptography (ECC) as their security relies on the difficulty of solving these problems with a classical computer. These algorithms form the foundation of many security mechanisms used across the industry, including within SAP products.

Why the Timeline Matters

Although the cybersecurity professionals understood the threat for decades, momentum accelerated after the National Institute of Standards and Technology (NIST) proposed a timeline in 2024 to introduce Post-Quantum Cryptography (PQC) alongside traditional cryptography, starting in 2030 and fully phasing out traditional cryptography by 2035. This timeline is challenged by recent advances in quantum technologies: accelerated hardware development, improved quantum error correction and optimizations for Shor’s algorithm suggest that the gap between existing quantum computers and those needed to break public-key cryptography is closing. Considering these developments, SAP has raised the ambition to replace the current algorithms by quantum-resilient ones across its products, services and infrastructures by 2029.

This reflects an industry trend: Earlier in 2026, major industry peers, Google and Microsoft among them, announced plans to complete their PQC migration by 2029. In June 2026, the White House issued Executive Order 14412, requiring High Value Assets (HVAs) within U.S. federal agencies to be quantum-safe by the end of 2030.

The Challenge

History shows that replacing cryptographic standards can take years, sometimes decades. Cryptographic protocols are deeply embedded in applications, infrastructure, communications, and operational processes. Even small changes can have far-reaching and unintended consequences. As a result, organizations often hesitate to take immediate action to perform necessary upgrades, increasing exposure to evolving threats.

SAP leverages cryptographic agility to implement a sustainable approach to meet evolving cryptographic requirements.

Cryptographic Agility at SAP

SAP’s strategy is built around cryptographic agility—the ability to adapt quickly to future cryptographic changes without major disruption. SAP is implementing a phased enterprise-wide approach:

• Governance: The Cryptography CoE provides executive oversight, establishes milestones, defines success metrics, and guides product teams.
• Inventory: Teams identify cryptographic assets and generate Cryptographic Bills of Materials (CBoMs) using industry-standard tools and CycloneDX formats.
• Prioritization: Assets are ranked based on criticality to guide migration planning. This takes into account that some types of attacks can be launched already today, for instance, collecting encrypted data in transit for later decryption with a quantum computer (“harvest now, decrypt later”)
• Implementation: PQC algorithms are introduced in phases, following established roadmaps reflecting the prioritization.
• Validation: New implementations undergo rigorous testing before production deployment.

Over time, these capabilities will become automated and embedded into SAP’s Secure Software Development and Operations Lifecycle (SecureSDOL).

SAP’s Position

• Taking recent developments in quantum technology into account, SAP strives to become post-quantum cryptography ready by 2029.
• SAP is actively advancing toward quantum resistance and aligning with emerging regulatory and industry expectations. The company’s primary focus is on adopting NIST-recommended PQC algorithms while remaining open to other industry-proven solutions where appropriate.
• SAP has already released an updated Common Cryptographic Library (v8.6.4) that includes PQC capabilities for product teams. At present, SAP does not anticipate significant performance or cost impacts for customers, partners, or vendors during the migration.

SAP’s objective is: protect products, services, and customer data against evolving threats while delivering secure, resilient, and future-ready solutions in the post-quantum era.

From Code to Strategy: How MCP, CPI, and Lightweight Agents Unlock AI‑Driven SAP Integrations

2026-07-17T17:58:20.038000+02:00

Introduction

SAP Cloud Platform Integration (CPI) allows enterprises to connect diverse systems through iFlows — integration flows that define how data moves and transforms between endpoints. By combining CPI with the Model Context Protocol (MCP) and a lightweight Agent, we can expose SAP processes as consumable services — enabling seamless orchestration, automation, and intelligent interaction across enterprise systems.

Understanding the Components

SAP Cloud Platform Integration (CPI)

SAP CPI is the integration backbone of the SAP ecosystem. It enables secure, scalable, and real-time data exchange between SAP and non-SAP systems. In this architecture, CPI acts as the execution layer, where business logic resides. The iFlow processes requests coming from the MCP Server, performs necessary transformations, and interacts with SAP backend systems such as S/4HANA, SuccessFactors, or Finance modules.

In the AI world: CPI provides the structured data foundation that intelligent agents rely on. By exposing iFlows as APIs, it allows AI systems to access enterprise data securely and contextually — bridging traditional ERP with modern AI-driven automation.

Model Context Protocol (MCP) Server

The MCP Server is the middleware bridge between the Agent and SAP CPI. It defines “tools” — essentially API endpoints — that the Agent can call to trigger specific SAP processes. It handles authentication, routing, and error management, ensuring that requests from the Agent are properly formatted and securely transmitted to CPI.

In the AI world: MCP acts as the contextual translator between natural language and enterprise APIs. It enables AI agents to understand what business functions are available and how to invoke them, making enterprise systems conversational and intelligent.

Copilot Agent

The Agent is the frontline interface — a lightweight application (built with FastAPI or similar frameworks) that interacts with users or other systems. It consumes the MCP tools and provides a simple way to trigger SAP processes, either through a web UI or API calls.

In the AI world: The Agent represents the intelligence layer — capable of interpreting user intent, orchestrating workflows, and connecting to enterprise data through MCP and CPI. It’s the component that transforms static APIs into dynamic, AI-driven interactions.

Key Steps

1. Expose the iFlow in SAP CPI

Design and deploy your iFlow (e.g., invoice retrieval or employee data).
Ensure it’s accessible via HTTPS with proper authentication.

2. Create the MCP Server

Define tools mapping to CPI endpoints.
Configure the MCP server to expose these tools securely.
Example endpoint: http://localhost:8000/tools/sayHello

3. Consume with an Agent

Build a lightweight Agent using FastAPI.
Connect it to the MCP server and expose an endpoint like http://localhost:9000/agent/sayHello.
Provide a simple UI for users to trigger CPI processes.

Tools Used

SAP CPI → iFlow design and deployment
MCP Server → Tool definition and orchestration
FastAPI → Agent development
OAuth2 / SAP IAS → Authentication and security

Architecture Overview

Embed your architecture diagram here showing the flow: User → Copilot Agent → MCP Server → SAP CPI → SAP Backend Systems

Figure 1: End-to-end architecture connecting the Agent, MCP Server, and SAP CPI iFlow.

Step: Create a Simple iFlow in SAP CPI

Design a basic iFlow in SAP Cloud Platform Integration (CPI) that accepts a name as input payload and returns a greeting message. For example, if the payload contains "Dibyajyoti", the iFlow should respond with "Hello Dibyajyoti".

Once the development is complete, deploy the iFlow to generate the endpoint URL. This URL will be used later by the MCP Server and Copilot Agent to invoke the iFlow and integrate it into the overall architecture.

"https://<SUBACCOUNT>.it-cpitrial06-rt.cfapps.us10-001.hana.ondemand.com/http/hello"

Step 2: Test the iFlow Endpoint in Postman

Once the iFlow is deployed in SAP CPI, you’ll receive an endpoint URL. To validate it, use Postman:

Open Postman and create a new request.
Set the method to POST (or GET, depending on your iFlow design).
Enter the endpoint URL generated during deployment (e.g., https://cpi.example.com/http/endpoint/sayHello).
Authentication:
- Username → Client ID
- Password → Client Secret These credentials are provided when you configure the CPI tenant and are required for secure access.
Payload:
- In the request body, pass the input JSON or text payload (e.g., { "name": "Dibyajyoti" }).
Send the request and verify the response.
- Expected output: Hello Dibyajyoti

Step 3: Set Up the MCP Environment

Before working with the MCP Server, ensure your development environment is ready. You’ll need the following installed on your system:

Python (version 3.9 or above recommended)
PIP (Python package manager)
Visual Studio Code (for editing and running your project)

Step 4: Create the Project Folder Structure

To organize your MCP setup, create the following folders:

Main Project Folder
- Name: MCPPROJECT
Subfolders inside MCPPROJECT
- SAP_MCP_SERVER → Contains the MCP Server files (server.py, .env, requirements.txt)
- COPILOT_AGENT → Contains the Agent files (agent.py, templates/index.html, requirements.txt)

SAP_MCP_SERVER

.env---->

requirements.txt---->

server.py---->

COPILOT_AGENT

requirements.txt------>

agent.py------->

create a subfolder

index.html--------->

Step 5: Run the MCP Server and Copilot Agent

Inside `sap_mcp_server`

Install dependencies and start the MCP Server:

pip install -r requirements.txt
uvicorn server:app --reload --port 8000

pip install -r requirements.txt → Installs all required Python packages.
uvicorn server:app --reload --port 8000 → Launches the MCP Server on port 8000 with auto-reload enabled.

Inside `copilot_agent`

Install dependencies and start the Copilot Agent:

pip install -r requirements.txt
uvicorn agent:app --reload --port 9000

pip install -r requirements.txt → Installs Agent dependencies.
uvicorn agent:app --reload --port 9000 → Launches the Agent on port 9000 with auto-reload enabled.

Test the Agent

Once both services are running, open the Agent URL in your browser:

http://localhost:9000/

This will load the Agent’s web interface, allowing you to trigger the MCP tools and ultimately invoke the SAP CPI iFlow.

Conclusion

By exposing SAP CPI iFlows through an MCP Server and consuming them with an Agent, enterprises can create a modular, API-driven integration layer. This approach simplifies access to SAP processes, improves reusability, and lays the foundation for AI-powered enterprise automation — where intelligent agents can interact with SAP systems naturally, securely, and efficiently.

Regards,

Dibyajyoti Nanda

https://www.linkedin.com/in/dibyajyoti-nanda-23907429/

🚀Upcoming Expert-guided Implementation (EGIs) for Cloud ALM and Security: August 2026

2026-07-20T12:08:12.454000+02:00

Supercharge your SAP outcomes this August 2026 with live, instructor-led Expert-guided Implementation (EGI) sessions - focused on rapid adoption of SAP Cloud ALM and stronger Security. Achieve faster time-to-value, reduce risk, and apply best practices immediately - all included with your SAP Enterprise Support or SAP Enterprise Support, Cloud Edition at no extra cost. Ready to move from learning to results? Reserve your spot now. For more details on this service, please refer to the following here.

EGI registration link	Schedule
EGI: Roles and Authorization Concept	NA English 17–21 August 2026, 11:00 – 13:00 America/New York LA Spanish 24–28 August 2026, 10:00 – 12:00 America/Mexico City EMEA English 31 August – 4 September 2026, 10:00 – 12:00 Europe/Berlin
EGI: Security Optimization Service (SOS)	EMEA English 31 August – 3 September 2026, 10:00 – 12:00 Europe/Berlin
EGI: Implementing an SAP Security Baseline Dashboard	NA English 10–14 August 2026, 11:00 – 13:00 America/New York EMEA English 24-28 August 2026, 10:00 – 12:00 Europe/Berlin
EGI: All you need to know about SAP Cloud ALM	EMEA English 03–07 August 2026, 10:00 – 12:00 Europe/Berlin APJ Chinese 17–21 August 2026, 10:00 – 12:00 Asia/Shanghai NA English 10–14 August 2026, 11:00 – 13:00 America/New York APJ Japanese 03- 07 August 2026, 10:00 – 12:00 Asia/Tokyo EMEA English 31 August – 4 September 2026, 10:00 – 12:00 Europe/Berlin LA Spanish 31 August – 4 September 2026, 10:00 – 12:00 America/Mexico City LA Portuguese 24–28 August 2026, 09:00 – 11:00 America/Sao Paulo
EGI: Selective Data Transfer (from SAP Solution Manager) to SAP Cloud ALM	NA English 04 – 06 August 2026, 11:00 – 13:00 America/New York LA Portuguese 31 August – 2 September 2026, 09:00 – 11:00 America/Sao Paulo

Important to Note:

Browse all available topics in the SAP Enterprise Support Academy EGI Catalog.

Note: Some sessions require a minimum number of participants to run. In such cases, cancellation notifications are sent by email.

Enhance Your SAP Experience with Value Maps

Beyond Expert-guided Implementation sessions, SAP Enterprise Support offers additional resources to help you drive innovation. SAP Cloud ALM & Cross-Solution Topics Value Map bring together guidance, recommended actions, and supporting resources to help you decide what to focus on next - all included in your SAP cloud subscription.

Watch our short demo video, then head over to our page to explore our range of topics and request a call with a topic expert for guidance tailored to your goals.

About the author:

Anisa Tuscano is a Topic Expert for SAP Enterprise Support value maps, specializing in SAP Cloud ALM and Security. Anisa is passionate about helping customers succeed through SAP Enterprise Support offerings.

💡Have questions or feedback around this content? Don’t hesitate to comment down below or contact @AnisaTuscano .

Building CPI Explorer – My Journey to Simplify Searching SAP Integration Suite iFlows

2026-07-20T12:12:08.365000+02:00

Building CPI Explorer – My Journey to Simplify Searching SAP Integration Suite iFlows

Introduction

As an SAP Integration Suite consultant, a large part of my day involves supporting existing integrations, troubleshooting production issues, and understanding how different systems are connected. One challenge kept coming up repeatedly: finding where a particular SFTP directory, HTTP endpoint, ProcessDirect endpoint, or credential was configured across dozens (sometimes hundreds) of Integration Flows.

SAP's Design-Time APIs let you retrieve Integration Packages and Integration Flows, but there's no built-in way to search adapter configurations across an entire tenant. In practice, that meant opening package after package and manually inspecting each iFlow — slow, repetitive, and easy to get wrong in a large landscape.

Instead of continuing to do this by hand, I decided to build a tool to solve it for myself, and hopefully for other developers too.

Where It All Started

I started my career as an ABAP developer, and one feature I relied on constantly was the "Where Used" list. If I needed to know where a table, function module, or field was being used, I could just look it up. It was simple, fast, and always available.

When I moved into PI/PO and later CPI, that convenience disappeared. There's no equivalent way to instantly search where something is used across your integration landscape.

This became a real problem in day-to-day support. An FICO or SD colleague would come to me and say "my file isn't moving, can you check?" Half the time, they weren't even sure whether their interface was flowing through PI/CPI at all — they just knew something was stuck and assumed I'd know where to look. Other times, someone from the infra team would ask "are we using this host anywhere? We need to update it" or "can you find every flow using this username, we're rotating credentials." Each of these meant manually opening iFlow after iFlow, hoping I didn't miss one.

That's where the idea for CPI Explorer actually came from — not as a big architectural vision, but as a way to get back something as basic as the ABAP "Where Used" list, just for CPI.

One real example was during an infrastructure change where we had to update an SFTP host. Before CPI Explorer, the only option was to manually open multiple Integration Flows and inspect every SFTP adapter. With CPI Explorer, I can simply search for the hostname and immediately see every Integration Flow that references it.

The Idea

The question I started with was simple:

Can I build a "Where Used" list for CPI?

I spent quite some time exploring the SAP Business Accelerator Hub and Design-Time APIs to see whether this functionality already existed. The Design-Time APIs gave me metadata, but not the adapter-level detail I needed. So I went a level deeper: download each Integration Flow artifact, extract the .iflw file, parse the XML, and build a local searchable index from it.

Once that was working, I wrapped it in a Chrome Extension so I could search directly from the browser instead of running scripts every time.

How CPI Explorer Works

At a high level, the tool:

Authenticates with SAP Integration Suite using OAuth
Retrieves Integration Packages and Integration Flows via the Design-Time APIs
Downloads Integration Flow artifacts
Extracts and parses the .iflw XML files
Builds a searchable metadata index
Lets you search adapter properties from the Chrome Extension

It currently supports searching for:

SFTP directories
Host names
HTTP endpoints
ProcessDirect endpoints
JMS queues
Credentials
Externalized parameters
Other adapter properties

What I Learned

Building this taught me more than I expected about:

SAP Integration Suite Design-Time APIs
The structure of Integration Flow artifacts
Parsing .iflw XML files
Chrome Extension development
Organizing a Node.js application into reusable modules

The trickiest part was making sure every downloaded artifact mapped back correctly to its source Integration Flow while the index was being built. Getting that mapping right was what made the search results trustworthy across a whole tenant.

Why I'm Sharing This

I built CPI Explorer to solve my own problem, but I believe many SAP Integration Suite developers face the same challenge. That's why I decided to make it open source, so others can use it, contribute ideas, and help improve it over time.

GitHub

The project is available here: https://github.com/lokeshbhukya2019-netizen/cpi-explorer

Feedback, suggestions, and contributions are welcome.

What's Next

A few things I'm planning to add:

Search by adapter type
Multi-tenant support
Export to Excel/CSV
Dependency visualization
Support for additional adapter types

If you have ideas for other useful features, I'd like to hear them.

Closing Thoughts

CPI Explorer started as an attempt to fix a problem I ran into constantly in day-to-day SAP Integration Suite work. Along the way it turned into a good excuse to learn more about SAP's APIs, artifact structures, and browser extension development.

I hope it saves other SAP Integration Suite developers some time during troubleshooting and impact analysis. If you try it, I'd genuinely like to hear how it goes.

Thank you for taking the time to read about CPI Explorer. If you try it out, I'd love to hear your feedback, suggestions, or ideas for new features. I hope it helps make troubleshooting and impact analysis in SAP Integration Suite a little easier for the community.

Happy integrating!