SAP Community - SAP BTP, Kyma runtime

Mastering Kyma Multi-Tenancy: Mapping namespaces to different BTP Subaccounts

2026-01-29T07:09:07.312000+01:00

Introduction

In the world of SAP BTP, the Kyma runtime is often seen as an expensive resource, as by default, a Kyma cluster is tied to the subaccount where it was created. This means every BTP Service Instance you create in your Kyma Cluster using the pre-install BTP Service Operator is provisioned in that single "home" subaccount.

However, to leverage Kyma with keeping costs low you need to share one cluster across multiple applications / provider subaccounts. To do this properly, you must be able to isolate entitlements and manage application-specific services in dedicated so-called provider subaccounts.

In this post, I will show you how to achieve a 1:1 mapping between a Kyma Namespace and a BTP Subaccount.

The Core Concept: Overriding the default BTP Service Operator configuration

The magic happens via the SAP BTP Service Operator. By default, it uses a cluster-wide configuration. However, if you create a secret named sap-btp-service-operator with the label services.cloud.sap.com/config: "true" inside a specific namespace, the operator will prioritize those credentials for any resource created in that namespace.

Option 1: The manual approach

If you want to quickly test this for a single project, follow these steps:

1. Prepare the Provider Subaccount

Go to your Provider BTP Subaccount.
Create a Service Instance for Service Manager using the plan service-operator-access.
Create a Service Binding and note the following: clientid, clientsecret, sm_url, and the url (which we will use as tokenurl).

2. Create the Secret in Kyma

Apply the following YAML template adjusted to your configuration to your specific application namespace (e.g., incident). This tells Kyma to "look" at the provider subaccount instead of the default one which is configured under your kyma-system namespace.

apiVersion: v1
kind: Secret
metadata:
  name: sap-btp-service-operator
  namespace: incident 
  labels:
    services.cloud.sap.com/config: "true" # Mandatory label
type: Opaque
stringData:
  clientid: "<cliendid>"
  clientsecret: "<clientsecret>"
  sm_url: "https://service-manager.cfapps.us10.hana.ondemand.com"
  tokenurl: "https://your-subaccount.authentication.us10.hana.ondemand.com"
  tokenurlsuffix: "/oauth/token"

Option 2: The automated approach using Terraform

Doing this manually is exhausting and error-prone. Using the SAP BTP Terraform Provider, you can automate the entire "handshake" between the subaccount and the Kyma cluster.

Create a folder where you place the following 2 Terraform files.

1. File provider.tf

terraform {
  required_providers {
    btp = {
      source  = "SAP/btp"
      version = "1.18.1" # Use the latest stable version
    }
    kubernetes = {
      source  = "hashicorp/kubernetes"
      version = "~> 2.0"
    }
  }
}

# Configure the BTP Provider
provider "btp" {
  globalaccount =   "xxxxtrial-ga"        # "your-global-account-subdomain"
  # Credentials are best passed via Environment Variables 
  # (BTP_USERNAME and BTP_PASSWORD)
}

# Configure the Kubernetes Provider
provider "kubernetes" {
  # This targets your current active Kyma context
  config_path = "~/.kube/config" 
}

2. File main.tf

variable "provider_subaccount_id" {
  type        = string
  description = "The GUID of the target BTP Subaccount"
}

variable "target_kyma_namespace" {
  type        = string
  description = "The Namespace created and mapped to the BTP Provider Subaccount"
}

# 1. Ensure the subaccount is entitled first
resource "btp_subaccount_entitlement" "sm_entitlement" {
  subaccount_id = var.provider_subaccount_id
  service_name  = "service-manager"
  plan_name     = "service-operator-access"
}

# 2. Lookup the Service Plan ID after entitlement is created
data "btp_subaccount_service_plan" "sm_plan" {
  depends_on    = [btp_subaccount_entitlement.sm_entitlement]
  subaccount_id = var.provider_subaccount_id
  offering_name = "service-manager"
  name          = "service-operator-access"
}

# 3. Create the Service Manager instance using the plan ID
resource "btp_subaccount_service_instance" "sm_operator_access" {
  depends_on     = [data.btp_subaccount_service_plan.sm_plan]
  subaccount_id  = var.provider_subaccount_id
  serviceplan_id = data.btp_subaccount_service_plan.sm_plan.id
  name           = "sm-operator-for-kyma"
}

# 4. Create the Service Binding
resource "btp_subaccount_service_binding" "sm_binding" {
  subaccount_id      = var.provider_subaccount_id
  service_instance_id = btp_subaccount_service_instance.sm_operator_access.id
  name               = "kyma-operator-binding"
}

# 5. Create the Kubernetes Namespace with Istio enabled
resource "kubernetes_namespace" "app_namespace" {
  metadata {
    name = var.target_kyma_namespace
    labels = {
      "istio-injection" = "enabled"
    }
  }
}

# 6. Create the Secret inside that new Namespace
resource "kubernetes_secret" "sap_btp_service_operator" {
  metadata {
    name      = "sap-btp-service-operator"
    namespace = kubernetes_namespace.app_namespace.metadata[0].name
    labels = {
      "services.cloud.sap.com/config" = "true"
    }
  }

  data = {
    clientid       = jsondecode(btp_subaccount_service_binding.sm_binding.credentials).clientid
    clientsecret   = jsondecode(btp_subaccount_service_binding.sm_binding.credentials).clientsecret
    sm_url         = jsondecode(btp_subaccount_service_binding.sm_binding.credentials).sm_url
    tokenurl       = jsondecode(btp_subaccount_service_binding.sm_binding.credentials).url
    tokenurlsuffix = "/oauth/token"
  }

  type = "Opaque"
}

Set your BTP cli credentials as environment variables before running Terraform (prerequisite Terraform, btp cli and kubectl cli are installed on the maschine where you execute it).

For Bash:

export BTP_USERNAME="your-email@example.com" 

export BTP_PASSWORD="your-password"

For Powershell:

$Env:BTP_USERNAME = "your-email@example.com"

$Env:BTP_PASSWORD = "your-password"

Run the necessary commands like terraform init, plan, apply or destroy. You can pass the input variables as parameters. Example:

terraform apply -var="target_kyma_namespace=tf1" -var="provider_subaccount_id=553bcbbb-e809-450f-82db-60de3ef76b1f"

Summary

By using this 1:1 mapping technique, you can:

Reduce Costs: Share one Kyma cluster across many applications and business units.
Isolate Resources: Ensures that applications are running in a separate namespaces using its services and quotas from its provider subaccount.
Scale Securely: Use Terraform to ensure that credentials are never handled manually by developers and integrate it into your workflows like GitHub Actions.

This makes Kyma not just a powerful developer tool, but as well a cost-effective enterprise platform.

Runtime Threat Detection for SAP BTP Kyma with Azure Arc + Microsoft Defender for Containers

2026-02-02T15:52:32.766000+01:00

Securing an external Kubernetes cluster with Microsoft Defender for Containers (via Azure Arc)

When I say "secure Kubernetes", I'm not just thinking about admission policies and CIS checklists. I'm thinking about what happens when something is already running and turns malicious — a web shell lands in a pod, a container starts burning CPU for crypto mining, or someone drops network scanning tools into an otherwise boring workload.

If you're running SAP BTP Kyma runtime, this matters. Kyma has strong platform hardening (Gardener-managed control plane, DISA STIG alignment), and API server audit logs exist — but those logs go to SAP's Platform Logging Service, not directly to you. That's fine for platform-level auditing, but it's not the same as seeing threats inside your workloads at runtime.

That's the gap I'm filling: runtime threat detection — the ability to detect and alert on malicious activity (crypto mining, web shells, credential theft) while workloads are running.

Real-world threats

These aren't hypotheticals — crypto mining and container compromise campaigns are actively targeting Kubernetes clusters:

DERO Cryptojacking (2023–2024): Attackers scanned for misconfigured Kubernetes API servers, then deployed DaemonSets named "proxy-api" to blend in with legitimate cluster components. The mining process itself was named "pause" — masquerading as the standard Kubernetes pause container. CrowdStrike found malicious images with over 10,000 pulls on Docker Hub. How runtime detection helps: Defender's eBPF monitoring catches unusual process spawning from "pause" containers and flags sustained high CPU from processes that shouldn't be compute-intensive. (Source: CrowdStrike — DERO Cryptojacking Discovery)

Kinsing Campaign (2023–ongoing): This campaign exploits vulnerabilities in PostgreSQL, WebLogic, Liferay, and WordPress to gain initial access to containers, then pivots to deploy crypto miners across the cluster. The campaign has affected 75+ cloud-native applications. How runtime detection helps: Defender detects process genealogy anomalies — for example, a WebLogic process spawning shell commands that enumerate Kubernetes resources or deploy new containers.

The pattern: attackers get in through a misconfiguration or vulnerability, then run workloads inside the cluster. Admission policies and CIS benchmarks don't catch threats that start after deployment — that's the gap runtime detection fills.

The solution: Azure Arc + Defender for Containers

For non-AKS clusters, the approach is: Azure Arc (makes the cluster an Azure resource) + Defender for Containers (deploys the runtime sensor as an Arc extension).

What gets installed:

Arc agents (azure-arc namespace): maintain outbound connection to Azure
Defender sensor (DaemonSet on each node): collects runtime telemetry via eBPF — process creation, network activity, system calls

What the sensor detects: crypto mining patterns, web shell activity, network scanning tools, binary drift. (Docs: Workload runtime detection)

Arc also provides an extension platform — Defender isn't the only add-on you can deploy this way. And Microsoft provides a verification checklist so you can prove it's working.

Networking note: Both Arc and Defender require outbound connectivity. If egress is blocked, onboarding fails silently. Check the Arc network requirements and ensure *.cloud.defender.microsoft.com:443 is allowed.

How

I’ll show a portal-first path (fastest to understand), then a programmatic path (fastest to automate).

Step 0 — Pre-flight checklist

Here’s what I personally confirm before I touch the portal:

1) Network egress (outbound)

Arc agents require outbound access to a set of URLs (Azure Resource Manager, Entra ID token endpoints, container registries for pulling agent images, and more depending on features). (Docs: Azure Arc-enabled Kubernetes network requirements)
Defender for Containers on Arc requires outbound access to *.cloud.defender.microsoft.com:443. (Docs: Enable Defender for Containers on Arc-enabled Kubernetes (portal))

2) Tooling

Azure CLI + the connectedk8s extension (for Arc onboarding). (Docs: Quickstart: Connect an existing Kubernetes cluster to Azure Arc)
If I want to script extension deployment, I also install the k8s-extension extension. (Docs: Deploy and manage Arc-enabled Kubernetes extensions)

3) Cluster access

kubectl works and points at the cluster I’m onboarding.
If I’m missing kubeconfig on my workstation, the Kyma Dashboard has a Download kubeconfig link for the cluster.
I sanity-check that my kubeconfig/current context is the Kyma cluster before running anything destructive:

kubectl config current-context
kubectl cluster-info

I have capacity for Arc agents (the Arc quickstart calls out resource requirements and that agents are deployed on connect). (Docs: Quickstart: Connect an existing Kubernetes cluster to Azure Arc)

Step 1 — Connect the cluster to Azure Arc

I typically do this from a workstation that already has kubectl access to the cluster.

1.1 Register providers (if needed)

The Arc quickstart includes registering resource providers like Microsoft.Kubernetes, Microsoft.KubernetesConfiguration, and Microsoft.ExtendedLocation. (Docs: Quickstart: Connect an existing Kubernetes cluster to Azure Arc)

1.2 Run the connect command

From the Arc quickstart, the core command is:

az connectedk8s connect --name <cluster-name> --resource-group <resource-group>

In practice, I prefer to be explicit (especially on shared subscriptions) and set --location and --tags:

az connectedk8s connect \
    --name <cluster-name> \
    --resource-group <resource-group> \
    --location <azure-region> \
    --tags env=<env> owner=<team> system=<system>

What I’m explicitly setting there:

--location: the Azure region where the Azure Arc-enabled Kubernetes resource is created. If you omit it, it’s created in the same region as the resource group.
--tags: Azure Resource Manager tags on the Arc resource (space-separated key[=value]).

If this command hangs or fails in weird ways, I go back to egress first — the Arc network requirements doc is the authoritative “what URLs/ports must my cluster reach?” list. (Docs: Azure Arc-enabled Kubernetes network requirements)

(Docs: Quickstart: Connect an existing Kubernetes cluster to Azure Arc and Azure CLI reference — az connectedk8s connect)

1.3 Verify Arc agents in the cluster

The quickstart calls out that Arc deploys agents into the azure-arc namespace. I validate that they’re Running:

kubectl get deployments,pods -n azure-arc

(Docs: Quickstart: Connect an existing Kubernetes cluster to Azure Arc)

Here’s what that looks like in practice on my Kyma cluster:

And here’s the connected cluster resource in Azure (showing things like connectivity status, location, and tags):

At this point, if Arc isn’t healthy, I stop and fix that first. Everything else depends on it.

Step 2 — Enable the Containers plan in Microsoft Defender for Cloud

Now I go to Defender for Cloud and enable the Containers plan for the subscription where my Arc-enabled cluster lives.

The portal walkthrough is:

Microsoft Defender for Cloud → Environment settings → pick subscription → toggle Containers plan On
Select Settings next to the Containers plan → choose Enable specific components

(Docs: Enable Defender for Containers on Arc-enabled Kubernetes (portal))

At this point you’ll be asked which Containers plan components to enable.

You can enable everything, but for this post I’m intentionally focusing on the Defender sensor (runtime detections). The important callout: from a pricing perspective there’s no cost benefit to enabling one vs. many — the cost is the same — so this is purely about keeping the walkthrough scoped to runtime detection.

Here’s what that looks like in the portal (first the Containers plan settings, then the component selection where I keep only the sensor in scope):

Step 3 — Deploy Defender components to the Arc-enabled cluster

I use one of two flows.

Option A (recommended): Deploy via Defender for Cloud Recommendations

This is the “guided remediation” path:

Defender for Cloud → Recommendations
Find “Azure Arc-enabled Kubernetes clusters should have Defender extension installed”
Select the clusters → Fix

(Docs: Enable Defender for Containers on Arc-enabled Kubernetes (portal))

Option B: Deploy manually from the Arc cluster resource

If I want explicit control (or I’m debugging), I do:

Arc-enabled Kubernetes resource → Extensions → + Add
Install Microsoft Defender for Containers
Choose/configure the Log Analytics workspace during installation (this is where the extension sends collected logs/telemetry used by Defender for Cloud and Azure Monitor Logs)
- I can select an existing workspace, create a new one, or use the default: DefaultWorkspace-[subscription-id]-[region]

(Docs: Enable Defender for Containers on Arc-enabled Kubernetes (portal))

Step 4 (optional) — Programmatic deployment (repeatable automation)

If I’m onboarding clusters at scale, I don’t want a click path. The programmatic doc gives the Azure CLI commands for creating the Defender extension.

Defender sensor extension:

Note: Some examples include an auditLogPath setting for clusters where you control the API server audit log file location. In Kyma, audit logs are handled via SAP’s Platform Logging Service and you generally don’t have direct access to that file path, so I’m omitting it here.

az k8s-extension create \
    --name microsoft.azuredefender.kubernetes \    --cluster-type connectedClusters \    --cluster-name <cluster-name> \    --resource-group <resource-group> \    --extension-type microsoft.azuredefender.kubernetes \    --configuration-settings \        logAnalyticsWorkspaceResourceID="/subscriptions/<subscription-id>/resourceGroups/<rg>/providers/Microsoft.OperationalInsights/workspaces/<workspace-name>"

(Docs: Deploy Defender for Containers on Arc-enabled Kubernetes (programmatic))

If you need the generic “how do extensions work / how do I list/update/delete them” reference, the Arc extensions doc is the canonical place. (Docs: Deploy and manage Arc-enabled Kubernetes extensions)

Step 5 — Verify it’s actually working

This is where I slow down and prove success.

Microsoft’s verification checklist is:

Arc connection is healthy
Defender extension shows as installed
Sensor pods are running
Alerts appearing

(Docs: Verify Defender for Containers on Arc-enabled Kubernetes)

5.1 Verify Arc connectivity

az connectedk8s show \
    --name <cluster-name> \    --resource-group <resource-group> \    --query connectivityStatus

The expected output is Connected. (Docs: Verify Defender for Containers on Arc-enabled Kubernetes)

5.2 Verify Defender extension provisioning

az k8s-extension show \
    --name microsoft.azuredefender.kubernetes \    --cluster-type connectedClusters \    --cluster-name <cluster-name> \    --resource-group <resource-group> \    --query provisioningState

The expected output is Succeeded. (Docs: Verify Defender for Containers on Arc-enabled Kubernetes)

5.3 Verify sensor pods

kubectl get pods -n kube-system -l app=microsoft-defender

# If you don’t see anything in kube-system, also check the mdc namespace:
kubectl get ds -n mdc
kubectl get pods -n mdc

This is the simplest “is the sensor deployed?” check. If the DaemonSet exists and the pods are Running, you’re in good shape.

(Docs: Verify Defender for Containers on Arc-enabled Kubernetes)

5.4 Verify in the portal

This is the “did Azure actually receive the signals?” check.

After you’ve deployed the Defender extension and the sensor is running, go to Microsoft Defender for Cloud and look at Security alerts (or the Alerts view in the Defender for Cloud experience). If you just ran the simulator (next step), this is where you’ll see the resulting alerts.

It can take a bit of time (think minutes, not seconds) for the cluster and alerts to show up after onboarding. (Docs: Verify Defender for Containers on Arc-enabled Kubernetes)

5.5 (Optional) Prove runtime detection by simulating alerts

If I want hard proof that the sensor-backed detections are flowing end-to-end, I use Microsoft’s Kubernetes alerts simulation tool.

It has two prerequisites that matter in practice:

Defender for Containers is enabled and the Defender sensor is deployed.
I have admin permissions on the cluster.

Then I download and run the simulator:

curl -O https://raw.githubusercontent.com/microsoft/Defender-for-Cloud-Attack-Simulation/refs/heads/main/simulation.py
python simulation.py

After it runs, I go back to Defender for Cloud and look at the alerts that were generated:

(Docs: Kubernetes alerts — Kubernetes alerts simulation tool)

5.6 Inspect the alert details (example: binary drift)

To make this feel real (and to sanity-check what Defender is actually flagging), I open one of the generated alerts and look at the Alert details pane. For example, the “A drift binary detected executing in the container” alert includes fields like the suspicious process path, command line, parent process, and the affected Arc-enabled Kubernetes resource.

Step 6 — Troubleshooting (the short list)

6.1 If an extension is stuck, check egress first

Arc-required outbound URLs: (Docs: Azure Arc-enabled Kubernetes network requirements)
Defender-required outbound endpoint (*.cloud.defender.microsoft.com:443) (Docs: Enable Defender for Containers on Arc-enabled Kubernetes (portal))

6.2 If things drift over time

The Arc extensions doc notes that if Arc agents don’t have network connectivity for an extended period, an extension can transition to Failed, and you may need to recreate the extension. (Docs: Deploy and manage Arc-enabled Kubernetes extensions)

Closing thoughts

If you’re running Kubernetes outside AKS, it’s easy to end up with fragmented security tooling. The Arc + Defender for Containers pattern is one of the cleaner ways I’ve found to bring:

centralized visibility,
actionable runtime alerts,
and runtime security signals

into a hybrid Kubernetes estate—without replatforming.

In future posts, I’ll explore what else we can do with Kyma + Azure Arc + Azure beyond Defender for Containers (observability, more security patterns, etc.).

References (Microsoft Learn)

Kyma Evolution: Transforming SAP Kyma into a tailor-made SaaS Platform for sbs extensions

2026-02-03T07:53:06.319000+01:00

Introduction

Hello SAP Community!

As an Extensibility Expert, I’m constantly looking for the most efficient ways to build and operate enterprise-grade extensions for the SAP Cloud ERP following the Clean Core principles. We all know the Cloud Application Programming Model (CAP) is the go-to framework for Cloud Native side-by-side Extensions on BTP, but where you run them on large scale matters just as much as how you code it.

Today, I’m starting a 3-part series (Part 2, Part 3 ) "Kyma Evolution". We will explore how the powercouple of Kyma in combination with the CAP Operator provides a scalable, high-performance, cost-effective runtime for CAP Multitenancy SaaS applications. In case you don’t know SAP Kyma and its benefits yet, please have a look at the Kyma Learning which explains it quite well.

The paradigm shift: From monolithic to a modular environment

For a long time, SAP Kyma was seen as a fixed bundle of tools. You got everything, whether you needed it or not. That has changed. With the Kyma Module Concept, the platform is now modular and extensible. Even more exciting is the introduction of Community Modules. This means Kyma is no longer limited to what SAP provides out-of-the-box. The community can now contribute extensions. One of the most powerful examples so far is the CAP Operator. By adding the CAP Operator as a module, you transform a generic Kyma cluster into a specialized CAP SaaS Runtime.

The "Smart Broker": Why the CAP Operator is a game-changer

When we compare Kyma to SAP BTP Cloud Foundry, the advantages of using a dedicated Operator become clear. While Cloud Foundry is a great general-purpose platform, the CAP Operator on Kyma acts as a "smart broker" specifically for CAP Applications.

Key Benefits for Partners and Customers:

100% Automated Lifecycle Management: The Operator understands CAP. It handles application deployment, tenant management, DB model updates, and service bindings automatically and new capabilities like SAP HANA Cloud Native tenants (Videocast) including tenant backup and restore management can be added once available.
Cost-Efficiency via Higher Container Density: In contrast to Cloud Foundry, Kyma allows for fine-grained resource limits. This means you can run more services on the same infrastructure, lowering your BTP bill when you are running multiple CAP Applications.
Cost-Efficiency via Resource Sharing: Expensive Services like SAP HANA Cloud and Cloud Logging can be shared in CF and Kyma. However we will see in Part 2 that in the Kyma environment this will be more elegant and simplified using the CAP Operator.
Enterprise Resilience & Day-2 Ops: It provides built-in "Reconciliation Loops." If a tenant's database connection fails, the Operator detects and fixes it without human intervention.
Advanced Networking & Security (Zero Trust Architecture): One of the most significant advantages over Cloud Foundry is how Kyma handles connectivity. In Cloud Foundry, preventing a service from being publicly accessible often requires manual effort. In Kyma, thanks to the CAP Operator's integration with Istio, your internal services stay cluster-internal by default. You have full control over the attack surface.
Integrated Domain Management: Managing Custom Domains becomes a native experience using the CAP Operator. Instead of juggling external services for certificates, you can orchestrate your SaaS-brand URLs directly within the Kyma environment, providing a seamless, secure and automated experience.

The ecosystem enablers: Extensibility using CAP Plugins + Kyma Modules

SAP is providing enablers for the ecosystem on different levels:

At the Infrastructure Level (Kyma): We use Modules (like the CAP Operator) to make the runtime "CAP-aware."
At the Application Level (CAP): We use CAP Plugins to add business features like multitenancy or audit logging with a single command.
At CAP CLI Level: We can add plugins like CAP Operator Plugin to the cds cli which provides capabilities to generate CAP Operator resources essential for deploying multi-tenant CAP Applications from your project setup.

This synergy creates the ultimate development and operations experience. You use plugins to build fast and the Operator to run smart and it enables you to contribute and to add your specific capabilities at any level.

Turning Kyma into a CAP Runtime

The beauty of this evolution is simplicity. You can now add the CAP Operator Community Module directly from your Kyma Cockpit using the Add Modules or Modify Modules Button on the Cluster Details Screen.

The Modules overview shows you the SAP Provided and Managed Modules under the Module Pane and the installed Community Modules in a separate Pane.

As a next step use the Add button on the Community Module Pane.

On the next screen you need to choose the Add Source YAML’s button to get the list of community modules.

Just keep the defaults and press the Add button.

This will load the list of currently available Community Modules from which you need to check the cap-operator Tile and press Add.

This will start the automatic installation of the CAP Operator Components into the namespace called cap-operator-system.

The installation and module status will be displayed in the overview and will turn into green after installation is successfully finished.

By doing this, you aren't just deploying code; you are creating an intelligent system that manages your S/4HANA Multitenancy extensions built with CAP for you as it adds Custom Resources (CRs) like CAPApplication, CAPApplicationVersion, CAP Tenant and other to your cluster. This will enable:

Quick and easy deployment of CAP application backends, router, and related networking components.
Integration with SAP Software-as-a-Service Provisioning service to handle asynchronous tenant subscription requests, executing provisioning / deprovisioning tasks as Kubernetes jobs.
Automated upgrades of known tenants as soon as new application versions are available.
Support for deployment of service-specific content / configuration as a Kubernetes job with every application version (for example, HTML5 application content to SAP HTML5 Application Repository Service).
Management of TLS certificates and DNS entries related to the deployed application, with support of customer-specific domains.

and further capabilities.

What’s Next?

In Part 2, we will dive deeper. We’ll look in more details of the runtime and at a cost benefits to prove why this modular approach is a win for your bottom line. What are your thoughts on the modular Kyma concept? Have you tried the CAP Operator yet? Have you ideas for additional community modules for the ecosystem?

When Innovation Meets Real Business Impact - VNSG SAP BTP Hackathon 2026

2026-02-04T13:53:21.455000+01:00

A community powered by creativity

The VNSG SAP BTP Hackathon has once again shown what happens when passionate people, real business challenges, and SAP Business Technology Platform come together. Teams of customers, partners, and experts turned ideas into tangible solutions that demonstrate how SAP BTP can drive measurable value in day-to-day operations.

Over the course of the Hackathon, every team brought its own perspective, business context and technical skills – from integration and automation to SAP Business AI and extensions on SAP BTP.

The result: a set of working prototypes that not only impress technically, but are rooted in real customer needs and adoption potential.

Celebrating the 2026 finalists

After intense jury deliberation, three teams earned a spot in the grand final at SYNC 2026 for their strong presentations, clear business impact, and high potential for real-world rollout.

Promocean (supported by SOA People) – “Operational Excellence through SAP Business AI”: A showcase of how SAP BTP and Business AI can streamline operations and enhance decision-making in a very pragmatic way.
Ecotone (supported by Expertum) – “Interface Maintenance”: A smart solution addressing the often underestimated pain of interface management, using SAP BTP to bring transparency, stability and control.
NTT Data – “ProTrack”: A forward-looking use case that leverages SAP BTP to better track, steer, or optimize processes

These finalists did not just deliver “cool demos”, they delivered stories where business and technology reinforce each other, with SAP BTP at the core as the innovation platform.

A strong field beyond the finalists

Of course, a hackathon is about much more than just three winners. Aarini Consulting, Nederlandse Spoorwegen, and Simac IT & BSC also delivered impressive solutions that made the jury’s job anything but easy.

Each of these teams tackled real business scenarios and used SAP BTP services to create innovation that can move quickly from prototype to production. The organizers explicitly encourage all teams to work with their coaches on post-hackathon follow-up to drive implementation and adoption, because the real success of a hackathon is measured when the ideas go live.

SYNC 2026: where the stage is yours

As recognition of this milestone, the three finalist teams are invited to present at SYNC 2026, the VNSG Annual Conference on March 12. During the opening session, each finalist will pitch their solution live on stage to the SYNC audience. The audience will then vote to determine the VNSG SAP BTP Hackathon Champion – a great opportunity to showcase innovation, customer impact and the power of SAP BTP in front of the wider SAP community.

Keep the momentum going

For everyone involved – finalists, other teams, coaches and the broader community – this hackathon is a starting point, not an ending. The next steps are about refining solutions, planning production rollouts, and scaling adoption so that the innovation created during the hackathon translates into lasting business impact.

If you are part of the VNSG or wider SAP community and feel inspired by these stories, take this as a call to action: bring your own business challenges, experiment on SAP BTP and co-innovate with partners and customers.

The SYNC 2026 VNSG SAP BTP Hackathon has proven once more that with the right mix of creativity, collaboration and platform capabilities, you can turn ideas into value – fast...

SAP Business Technology Platform SAP Build SAP Integration Suite

@hansvp @qmrjvd @sricsi98 @BvE @mdschoenmakers @tamasszirtes @f_van_leeuwen @Petra1 @BartvdKamp @tedcastelijns @Arjan_deMol @dvvelzen @JdTeuling @AnnikaHeus @LaurensSteffers

Part 2: Runtime Architecture & Cost efficiency gains

2026-02-04T16:53:28.002000+01:00

Introduction

In Part 1, we introduced the CAP Operator as the brain to make out of your Kyma Cluster a runtime for CAP Multitenancy SaaS applications. Today, we dive into technical architecture. We will see why Kyma isn't just "another place to run containers," but can be turned into a highly optimized environment that saves costs by being smarter about how it uses resources, especially when compared to a traditional Cloud Foundry setup, important if you need to run CAP Multitenancy Applications on a large scale.

1. The Core Architecture paradigm: Declarative Tenant Management

While Cloud Foundry relies on imperative commands (like cf push or cf deploy), the CAP Operator uses Custom Resources (CRs) the Kubernetes extensibility API for customization. The most important one for SaaS Multitenancy CAP Solutions is the CAPTenant.

In Cloud Foundry, the Service Manager handles the creation of HDI containers, and it does the same in Kyma. However, the CAP Operator adds a layer of "Operational Intelligence":

Autonomous Monitoring: The Operator doesn't just trigger the Service Manager; it monitors the entire lifecycle of the tenant's database schema. If a cds deploy (migration) fails, the Operator detects the "Unhealthy" state and can automatically retry or alert, integrated directly into the Kubernetes event stream.
State Reconciliation: It ensures that the state of your tenants always matches your configuration. If a tenant record is stuck, the Operator's reconciliation loop acts as an automated "Day-2" administrator.
Automatic creation of the Provider tenant: The CAP Operator will automatically take care that the provider tenant for your SaaS Application is created and updated like for the Subscriber tenants, whereas in Cloud Foundry you will need to to care.

2. The "Zero-Idle" secret: On-Demand MTXS Pods

In a typical CAP multitenancy setup, the CAP MTXS component is the heavy lifter. It handles onboarding, unsubscription and database upgrades.

The Cloud Foundry Challenge: In CF, the MTXS logic often runs as one container or a permanent process within your application instance. This means you are constantly paying for the RAM and CPU of this "waiting" process, even if no one is subscribing to your app for days.

The Kyma + CAP Operator Advantage: The Operator implements what we call a "Zero-Idle" policy for provisioning tasks:

Trigger-based Lifecycle: When a subscription event occurs, the CAP Operator spins up a short-lived Job Pod specifically for the MTXS task of that tenant. For more details on how the CAP Operator manages the tenant lifecycle please have a look at the Tenant Provisioning Documentation.
Scale-to-Zero: With the CAP Operator you can run upgrades of your database tenants in parallel. Once the tenant is successfully managed and the database tenant is ready, the MTXS Pod is terminated.
Cost Benefit: You pay zero for the MTXS infrastructure during idle times. In large-scale landscapes with many extensions, this optimization can reduce your runtime memory footprint by 20–30%.

3. Scaling without linear cost growth

A common concern is that Kubernetes might be more expensive than Cloud Foundry. The reality is the opposite when scaling SaaS:

Bin-Packing: Kubernetes allows for "Overcommitting." Since your applications and tenants aren't all active at the same millisecond, you can pack more application instances onto a single K8S Node than the rigid memory cells of CF allow.
Resource Pooling: By using the CAP Operator to orchestrate the Service Manager, you can efficiently fill up large, cost-effective HANA Cloud instances. You avoid the "base cost" of having many small, underutilized HANA instances.
Efficiency Gains: As you grow from 10 to 100 tenants, your infrastructure costs grow at a much flatter angle because the "management overhead" (like MTXS) only consumes resources when it's actually working.

4. Centralized Observability: Selective Logging

Logging is often an overlooked cost driver. While both BTP environments use the SAP Cloud Logging Service which can be shared among multiple deployments, the way how it's done and how they handle logging data (storage as the major cost driver) is fundamentally different.

Cloud Foundry: Every app instance pushes all logs blindly to the service. You have little control over the volume.
Kyma (The Daemon Approach): Kyma uses the Telemetry Module (Fluent Bit) running as a daemon on every node.

Pre-Filtering: You can define a LogPipeline to filter logs before they leave the cluster. For example, you can exclude send logs from specific production namespaces or filter the logs by specific attributes.
Centralized Sharing: You don't need to bind every app. You define one central pipeline that securely routes logs from the entire cluster to a single Cloud Logging instance, providing a unified view with significantly lower ingest costs.

On how to use the SAP Cloud Logging with SAP Kyma, please have a look into the Kyma Integration with SAP Cloud Logging Blog.

Summary: The Architect's choice

Choosing Kyma and the CAP Operator isn't just about a "new technology." It's a strategic decision to move from reserved resources to on-demand resources and how to utilize them more efficiently.

CF: Predictable, but you often pay for "idling" capacity.
Kyma + CAP Operator: Dynamic, ensuring you only pay for what is actively serving your business or your tenants.

What’s Next?

Now that we have seen how the Power couple ”BTP Kyma&CAP Operator” enables you to lower your infrastructure cost in case of running CAP applications on large scale, we will see in Part 3 how the CAP Operator helps you to run your Application Lifecycle Management 100% automated which is a further important pillar to reduce your overall TCO.

Part 3: Automated Application Lifecycle Management in Action

2026-02-04T16:53:39.614000+01:00

Introduction

Enough theory. In Part 1 and 2, we discussed how and why the CAP Operator turns SAP Kyma into a runtime for CAP Multitenancy SaaS applications. Forget complex deployment scripts and manual tenant lifecycle tracking. We will take the official SAP-samples/btp-cap-multitenant-saas and show you how to deploy, manage, and monitor your SaaS application with zero friction. This is Platform Engineering for DevOps at its best.

1. The Application Blueprint

Instead of managing dozens of individual Kubernetes objects, you define in a declarative way your CAP Application using Custom Resources (CRs) like CAPApplication, CAPApplicationVersion which will create the necessary Kubernetes native artifacts to manage your application lifecycle. In the Sample Repository the necessary steps to deploy the Sustainable SaaS (SusaaS) example using the CAP Operator is described under deploy/capoperator. The example will use a Helm Chart which creates the required BTP service instances and bindings using the SAP BTP Operator Kyma Module which is installed by default in your Kyma Cluster. Using the helm dry-run option you will be able to see all artifacts which will be managed via the Helm Chart. The output of:

helm upgrade -i -n susaas susaas chart -f chart/values-private.yaml --dry-run=client

includes for instance the CAPApplication Custom Resource:

apiVersion: sme.sap.com/v1alpha1
kind: CAPApplication
metadata:
  name: cap-saasmt
spec:
  domainRefs:
    - kind: Domain
      name: dom-saasmt
  btpAppName: "saasmt"
  globalAccountId: "8ec9195a-6924-45d2-94da-a5c798578808"
  provider:
    subDomain: "saasmtcws"
    tenantId: "7fced6ad-dada-4ffe-a5ec-6f75bfd9d67c"
  btp:
    services:
      - class: "xsuaa"
        name: "xsuaa-api"
        secret: "saasmt-xsuaa-api-bind-btp"
…
      - class: "service-manager"
        name: "sm-admin"
        secret: "saasmt-sm-admin-bind-btp"

and the CAPApplicationVersion Custom Resource which specifies all your Application workloads like Approuter, Backend, Service Broker which are running permanently with its specific configurations. In addition it includes the Content Deployment Jobs like to deploy HTML5 Content to the HTML5 Content Repository Service and the Operations to create, update and to delete Application Tenants. These Jobs are scaled to Zero once successfully done.

apiVersion: sme.sap.com/v1alpha1
kind: CAPApplicationVersion
spec:
  capApplicationInstance: "cap-saasmt"
  version: "1"
  registrySecrets:
    - regcred
  workloads:
  - name: srv
    consumedBTPServices:
    - "xsuaa"
    - "saas-registry"
    - "destintation"
    - "com-hdi-container"
    - "sm-container"
    - "sm-admin"
    deploymentDefinition:
      type: CAP
      image: "espchris/capop-susaas-srv:0.0.1"
      env:
          - name: DEBUG
            value: "mtx"
          ...
      volumeMounts:
           ...
      volumes:
           ...
      securityContext:
           ...
      resources:
           ...
  - name: router
          ...
  - name: api
          ...
  - name: broker
  - name: hdi-deployer
          ...
  - name: html5-apps-deployer
          ...
  - name: mtxs
          ...
  contentJobs:
  - hdi-deployer
  - html5-apps-deployer
  tenantOperations:
    provisioning:
    - workloadName: mtxs
    - workloadName: automator
    upgrade:
    - workloadName: mtxs
    deprovisioning:
    - workloadName: mtxs
    - workloadName: automator

2. Deploy and watch the automation

Once you deploy the application using helm upgrade -i -n susaas susaas chart -f chart/values-private.yaml like described in the documentation the automation for instance includes:

Service Auto-Provisioning: It talks to the BTP Operator Module, creates the required instances, and binds them.
Manages the Application workload and content deployment: Create for instance the Certificate for your Application wildcard domain including the necessary DNS entry for your SaaS Application. Triggers the content deployment jobs like to deploy the Fiori Application HTML5 content the BTP HTML5 repository Service.
Provider Tenant creation/upgrade: It automatically initializes your provider subaccount database tenant by calling the MTX Job automatically, a step that used to be a manual headache.

3. Native Monitoring in the Kyma Dashboard (Busola)

Who says Kubernetes is CLI-only? One of the biggest advantages of the CAP Operator is its native integration into the Kyma Dashboard (Busola) which is integrated into the BTP Cockpit. In Busola, you don't just see "Pods"; you see the status of your Application:

Visual Health Check: Check the status of your CAPApplication, CAPApplicationVersions and CAPTenants at a glance. Green status means the DB is migrated, services are bound, and the app is ready for consumers.
Tenant Provisioning Deep-Dive: Click on a specific subscriber tenant to see its specific configuration and history and
Real-time Logs: If a tenant upgrade fails you will see that directly in the UI.

Here is an example showing the details of the CAPApplicationVersion.

CAPTenants

4. Subscriber tenant provisioning including specific tenant operations

Once the application is in a Ready State the subscription of further tenants is done in the same way like for Cloud Foundry Applications by creating a new subscriber subaccount and creating a new subscription which will trigger the Tenant subscription workflow creating a new database schema, ISTIO Virtual Service for you Subaccount and will trigger all other defined automations.

The result will be again visible in the Kyma Dashboard where we will see all Jobs including Status which have been executed.

5. Scaling your lifecycle operations

What happens when you have 100+ tenants and a new release?

Parallel Upgrades: The Operator doesn't wait in line. It spins up parallel MTXS jobs to upgrade your tenants' database schemas simultaneously, respecting the limits you define.
Self-Healing: If a tenant's schema drifts or a migration fails, the Operator's reconciliation loop kicks in. It's like having a 24/7 SRE (Site Reliability Engineer) built into your cluster.

The results of a Application upgrade using command helm upgrade -i -n saasmt susaas chart -f chart/values-private.yaml can be again seen in the Kyma Dashboard.

6. The "Golden Path": GitOps with the CAP Operator

Automated ALM is great, but manually running commands is still a potential source of error. This is where GitOps comes in. Since the CAP Operator uses a purely declarative approach, it provides the perfect foundation for tools like Argo CD.

Infrastructure as Code (IaC): Your entire SaaS landscape from the CAPApplication definition to the individual CAPApplicationVersion configurations is stored in a Git repository.
Automatic Sync: When you push a new image version or a new tenant configuration to Git, Argo CD (or any GitOps tool) detects the change and synchronizes it with your Kyma cluster.
Audit Trail & Revert: Every change to your SaaS environment is tracked in Git. Need to rollback a buggy tenant upgrade? Just revert the commit, and the CAP Operator will automatically restore the previous state.

By combining GitOps with the CAP Operator, you achieve the highest level of maturity in cloud-native operations: Your Git repo becomes the single source of truth for your entire "CAP-as-a-Service" platform.

Summary: Kyma as the runtime for CAP Multitenancy SaaS applications

SAP provides with Kyma a runtime for running CAP Multitenancy solutions with minimal costs on a large scale and it includes openness to allow the ecosystem to extend it with additional operators. Using the Kyma Module CAP Operator we've turned a complex Kubernetes cluster into a specialized "CAP-as-a-Service" platform.

We have seen how to:

Turn your cluster into a "CAP-as-a-Service" platform with a view clicks (Part 1).
Reduce Infrastructure Cost through resource sharing and optimization (Part 2).
Automate the Application Lifecycle with the help of the CAP Operator (Part 3).

The future of SAP CAP Application development and operations is open, modular and operator-led. Start exploring the capabilities and transform your Kyma cluster into a high-performance and scalable engine! To create the necessary Helm artifacts to deploy your CAP Application using the CAP Operator please make use of the cap-operator-plugin which we will explain in more detail in one of the next blogs.

Reimagining Utility Transformation: Clean Core Principles Powered by SAP BTP

2026-02-06T07:51:30.744000+01:00

Introduction

Across the utility industry, one message appears in every transformation discussion: “Keep the core clean.” The guidance is sound, especially for organizations preparing for S/4HANA. But inside SAP IS‑U—where regulatory complexity, legacy billing logic, and decades of Z‑programs coexist—this principle often feels contradictory.

Utilities must modernize rapidly while protecting the stability of their revenue engine. This creates a familiar tension: innovation requires speed, but the core requires caution.

This post explores why that tension exists, how SAP BTP resolves it, and how utilities can operationalize a Clean Core strategy without compromising business continuity.

Main Body

1. The Customization Cage: How Utilities Got Here

For many years, utilities solved business needs by customizing the ERP core:

Custom ABAP for tariffs
Modified standard tables for regulatory fields
Embedded workflows inside IS‑U
Enhancements tightly coupled to billing and device management

These decisions were practical at the time—but over decades, they created a Rigid Core that is difficult to upgrade, expensive to test, and slow to evolve.

Resulting challenges:

High upgrade risk
Long regression cycles
Slow innovation
Technical debt that compounds every year

Your first diagram captures this reality perfectly.

Diagram 1 — The Customization Cage

2. Clean Core + SAP BTP: The Agility Layer Utilities Needed

A Clean Core strategy is not about reducing capability—it’s about relocating capability.

SAP Business Technology Platform (BTP) provides the architectural separation utilities have needed for years:

S/4HANA Core → Stable, standardized, upgrade-friendly
SAP BTP → Custom logic, workflows, APIs, event-driven processes

This separation transforms the ERP into a system of record, while BTP becomes the system of innovation.

Key benefits:

Faster delivery cycles
Reduced regression testing
Lower upgrade effort
Event-driven operations
Extensibility without core modification

3. A Practical Framework for Utility Clean Core Adoption

SAP Community readers expect actionable, practitioner-focused guidance. Here is a structured approach utilities can follow.

Step 1: Start With a Core Assessment

Identify:

Business-critical customizations
Redundant or obsolete logic
Enhancements blocking upgrade cycles
High-change areas suitable for BTP

This reframes Clean Core as risk reduction, not cleanup.

Step 2: Move High-Variability Logic to BTP First

Ideal candidates include:

Rate and tariff changes
Regulatory reporting
Credit & collections workflows
Meter-to-cash orchestration
BPEM automation

These areas generate the most upgrade friction—and deliver the fastest BTP wins.

Step 3: Use SAP Event Mesh to Break the Batch Mindset

Utilities can begin shifting toward real-time operations by triggering events for:

Move-in / move-out
Billing determinants
Meter read exceptions
Payment events
Outage notifications

This enables a hybrid model: batch where necessary, real-time where possible.

Step 4: Establish Governance That Protects the Core

No custom code in S/4 unless SAP mandates it
BTP-first evaluation for all new logic
Standard APIs and events as default patterns
Quarterly architecture reviews to prevent “core creep”

Governance is the long-term safeguard of Clean Core.

Step 5: Treat BTP as a Business Platform

Executives respond when BTP is positioned as:

A revenue protection tool
A regulatory accelerator
A customer experience enabler
A technical debt reduction mechanism

Step 6: Build a 24‑Month Roadmap

A practical roadmap includes:

Phase 1: Core assessment + quick wins
Phase 2: Event-driven architecture rollout
Phase 3: Predictive and AI-driven use cases
Phase 4: Full Clean Core enforcement + S/4 readiness

This provides clarity, sequencing, and measurable ROI.

4. The Modern Utility Innovation Stack

Your second diagram illustrates the future-state architecture:

A stable S/4HANA core
A flexible BTP layer
A connected utility ecosystem

Diagram 2 — The Utility Innovation Stack

Conclusion

A Clean Core is not a limitation—it is a strategic advantage.

Utilities preparing for S/4HANA should shift the conversation from:

“How do we migrate everything we built?” to “How do we protect the core and modernize the business at the same time?”

SAP BTP provides the answer:

Keep the core stable
Move innovation to the agility layer
Adopt event-driven operations
Reduce technical debt
Build a future-ready architecture

Utilities that embrace this model will be better positioned to innovate, comply, and scale in the decade ahead.

A SAP BTP Kyma Encryption/Decryption Microservice for ALL Contexts (e.g. SAP Datasphere/BDC/ABAP)

2026-02-11T16:12:01.099000+01:00

G’day!

Warning: This is only for readers who are really interested in this subject 😍 The article is quite comprehensive and has got some cross-article links inside, that also need to be considered. Therefore: A lot of reading and a lot of hands-on + thinking if you want to rebuild the thing.

Below is the structure of this article:

1 Status Quo on En-/Decryption in BTP
2 Motivation
3 Fundamentals
4 Architecture
5 HDLFS Configuration
6 Insights into Python
7 Containerization & Deployment in Kyma
8 Achievements
9 More Scope
10 References

Let's begin:

1 Status Quo on En-/Decryption in BTP

When it comes to En-/Decryption on SAP BTP, there are a couple of pitfalls to be considered. The following roughly outlines the situation, platform and application-wise:

Individual applications (e.g. SAP Successfactors) got proprietary encryption/decryption mechanisms available. They are typically not reusable.
SAP Integration Suite has got PGP En-/Decryptor nodes available. However, it is not advisable to run large volume scenarios using this approach. It has been built for data sizes on the levels represented within message handling scenarios (I‘m not an expert therein, but I guess thats typically not in the area of GBs).
A policy/rule for data to remain encrypted until its landing into BTP: You face challenges to securely onboard large volume files containing sensitive data into BTP, because there is no out-of-the-box solution to keep them encrypted in motion and decrypt them at rest once available in BTP (and vice versa for an outbound flow).

The Challenge

2 Motivation

Due to the above limitations, we were eager to find an appropriate solution approach that first of all satifies our specific scenario, but can also be augmented to other contexts. This is why the following motivation arose:

Especially En-/Decryption for larger files on BTP side seems to be a missing piece in the puzzle.
Our ambition is to encapsulate such kind of mechanism centrally as a reusable service. Multiple kinds of contexts can be served, exposing this service: Applications, data flows & transformations etc. – in our context the consumer will be SAP Datasphere.
There is another consequence of finally being able to load decrypted large data sets into BTP. To be more precise: To onboard this data into SAP Datasphere to further process and transform, the fact that Base64 encoded data must be handled in our context too, why not also expose or incorporate columnar Base64 En-/Decoding into the microservice?
The intended solution is custom-built and must be managed individually. However, the baseline that will be set can be reused and adapted to various customer needs and application contexts.

3 Fundamentals

The following represent some fundamentals and success criteria we‘ve established for our solution:

Use HANA Data Lake Files (HDLFS) as a file store for inbound/outbound persistency
Implement the service as containerized Python code logic
Service capabilities must be controllable and schedulable within Kyma
Service can handle PGP encrypted files, but can also decrypt for outbound delivery
Service can decode Base64 columns for inbound source files
Service manages and cleans up directories and file in-/output on HDLFS
Service can handle files with sizes in GB range
Deploy service into a Kyma Cluster (Cloud Foundry? -> no, Memory/Sizing limitations)
Security: Facilitate simple and secure handling of all required secrets and certificates
Service not exposed via HTTP endpoints (this is kind of a contradiction to a true microservice, however this requirement applies in our context. Under "More Scope" you will find guidelines/directions how to enable HTTP based microservices)

4 Architecture

The following architectural components represent what we‘ve picked out for our solution:

Usage of HANA Data Lake Files (HDLFS) as a file store for inbound/outbound persistency
Use BTP Kyma for service runtime (Kyma deployed in the 2nd smallest T-Shirt size)
SAP Datasphere represents the persistency layer (DSP as a consumer is exchangeable but in our case relevant for the business scenario)
The other more general blue box "other BTP Solutions" indicates, that the service implementation on Kyma isn't necessary limited to SAP Datasphere only, but should be rather considered as something agnostic. This of course heavily depends how it is built and finally implemented.

BTP Solution Architecture Kyma Microservice

5 HDLFS Configuration

I strongly recommend to read the tutorial by Jason Hinsperger to familiarize yourself with the HDLFS REST API dependencies and the essential steps to spin up the instance. You must follow all the steps described therein.

Its important to note that the generated client key and client certificate is what you are about to use from python level. Moreover you should take note of the REST API endpoint. This is the endpoint you run all your requests against (you find it in HANA Cloud Central -> Instances -> HDLFS Instance -> "Files REST API Endpoint".).

To familiarize yourself in general with the HDLFS REST API documentation, you can use this link.

HDLFS REST API Endpoint

One essential detail I don't want to hide, is the IP whitelisting of the Kyma environment. In order to do that, navigate to the start page of your cluster dashboard. There is a section called "Cluster Overview --> Metadata". Copy the (typically three) IP listed there: "NAT Gateway IP Addresses".

Go to your HANA Cloud Central and navigate to your HDLFS instance. Click "Manage Configuration" and go to the section "Connections": If you have enabled the setting to only allow specific IP addresses, likewise maintain the ones of the Kyma Cluster that you previously copied:

HDLFS Configuration Connections

6 Insights into Python

The python coding part is split into several modules, which are all described in a detailed way further below:

Inbound processing
Outbound processing
Common functions
Crypto function for encryption/decryption

Python Modules Sketch

Inbound Module (1)

The inbound part scans a given datalake path for .gpg files, then decrypts each file locally in parallel using a configurable worker count. After decryption, it samples the CSV (semicolon-delimited), detects which columns contain base64-encoded data, and runs a transformation step to produce a cleaned output file. The transformed result is uploaded to a decrypted output path, and the original encrypted input is moved to an archive folder. It logs success or errors with timing details on file level and exits with a failure code if any file fails.

This code snippet describes the parallel processing of files:

    with ThreadPoolExecutor(max_workers=MAX_PARALLEL_JOBS) as exe:
        futs = {exe.submit(processFile, f): f for f in files}
        for fut in as_completed(futs):
            f = futs[fut]
            try:
                res = fut.result()
                ok += 1
                print(f"[OK] {res['input']} -> {res['output']} sec={res['sec']:.2f} base64_cols={res['base64_cols']}")
            except Exception as ex:
                err.append((f, str(ex)))
                print(f"[ERR] {f}: {ex}")

Sampel code of processing an individual file:

def processFile(file_name: str):
    t0 = timer()
    out_name = normalize_output_name(file_name)

    with tempfile.TemporaryDirectory() as td:
        enc_path = os.path.join(td, file_name)
        dec_path = os.path.join(td, out_name + ".decrypted.csv")
        out_path = os.path.join(td, out_name)

        download_to_file(f"{PATH_IN_DATALAKE}/{file_name}", enc_path)
        decrypt_symmetric(enc_path, dec_path)

        header, sample = sample_csv(dec_path, delimiter=";")
        base64_cols = detect_base64_columns(out_name, header, sample)

        transform_csv(dec_path, out_path, base64_cols, delimiter=";")

        mkdirs(PATH_OUT_DATALAKE)
        upload_file_chunked(f"{PATH_OUT_DATALAKE}/{out_name}", out_path)

    mkdirs(PATH_ARCHIVE)
    rename(f"{PATH_IN_DATALAKE}/{file_name}", f"{PATH_ARCHIVE}/{file_name}")

    return {"input": file_name, "output": out_name, "base64_cols": base64_cols, "sec": timer() - t0}

Outbound module (2)

It scans the HDLFS outbound folder for .csv files and subdirectories containing Parquet parts, then processes them in parallel using a configurable worker count. CSV files are downloaded locally, then encrypted and uploaded back again to an encrypted outbound path. The originals are moved to an archive folder. Parquet file based directories on HDLFS (when enabled) are downloaded, consolidated into a single CSV using PyArrow, encrypted and uploaded similarly. As a last step, they are marked with an _SUCCESS file to prevent reprocessing and moved to the archive.

Crypto Module (3)

It provides helper functions for symmetric file encryption and decryption using the gpg command-line tool with an AES-256 cipher. It requires a passphrase supplied via the PASSPHRASE environment variable (from a Kyma Secret). Both encrypt_symmetric and decrypt_symmetric execute GPG in batch mode through subprocess, capturing stdout/stderr and validating the return code.

The decrypt_symmetric function is implemented as follows:

def decrypt_symmetric(enc_path: str, dec_path: str):
    _require_passphrase()
    cmd = [
        "gpg", "--batch", "--yes",
        "--pinentry-mode", "loopback",
        "--passphrase", PASSPHRASE,
        "--output", dec_path,
        "--decrypt", enc_path
    ]
    r = subprocess.run(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
    if r.returncode != 0:
        raise RuntimeError(f"GPG decrypt failed: {r.stderr.decode('utf-8', 'replace')}")

Common Functions Module (4)

All major control variables are built using environment variables (defined as secrets in Kyma) for endpoint/container, TLS certificates, verification behavior, timeouts, retries, and chunk size.

In one function it builds a reusable SSL context. API requests are wrapped with exponential-backoff retries for transient HTTP statuses (e.g., 429/5xx) and network errors. It provides HDLFS related helpers to list files/directories, check existence, create directories, rename paths, download remote content to disk in chunks, and upload files.

The below part builds the SSL context to connect to HDLFS via its REST API:

def buildSSLContext() -> ssl.SSLContext:
    ctx = ssl.SSLContext(ssl.PROTOCOL_TLS_CLIENT)
    if os.path.exists(CRT_PATH) and os.path.exists(KEY_PATH):
        ctx.load_cert_chain(certfile=CRT_PATH, keyfile=KEY_PATH)

    if TLS_VERIFY:
        if CA_CERT_PATH:
            ctx.load_verify_locations(CA_CERT_PATH)
        else:
            ctx.load_default_certs()
        ctx.verify_mode = ssl.CERT_REQUIRED
        ctx.check_hostname = True
    else:
        ctx.check_hostname = False
        ctx.verify_mode = ssl.CERT_NONE

    return ctx

This part establishes a connection to the HDLFS REST API endpoint as defined in the environment variable FILES_REST_API:

def _conn():
    if not FILES_REST_API:
        raise RuntimeError("FILES_REST_API is empty (set env FILES_REST_API).")
    return http.client.HTTPSConnection(FILES_REST_API, timeout=HTTP_TIMEOUT, context=_SSL_CTX)

The below function represents the upload (HDLFS REST API PUT) of a file in streaming mode to an HDLFS directory:

def _put_to_location(location: str):
        url = urlparse(location)
        if u.scheme and u.netloc:
            host = url.netloc
            path = (url.path or "/") + (("?" + url.query) if url.query else "")
            conn = http.client.HTTPSConnection(host, timeout=HTTP_TIMEOUT, context=_SSL_CTX)
        else:
            path = location
            conn = _conn()

        try:
            conn.putrequest("PUT", path)
            conn.putheader("x-sap-filecontainer", CONTAINER)
            conn.putheader("Content-Type", "application/octet-stream")
            conn.putheader("Content-Length", str(size))
            conn.putheader("Connection", "close")
            conn.endheaders()

            with open(file_path, "rb") as f:
                while True:
                    chunk = f.read(CHUNK_SIZE)
                    if not chunk:
                        break
                    conn.send(chunk)

            r = conn.getresponse()
            data = r.read()
            status = r.status
            r.close()

            if status in _RETRYABLE_STATUSES:
                raise RetryableHttpError(f"PUT retryable: {status} {data[:200]!r}")
            if status not in (200, 201):
                raise RuntimeError(f"PUT failed {remote_path_no_leading_slash}: {status} {data[:200]!r}")
        finally:
            conn.close()

7 Containerization & Deployment in Kyma

I won't describe in detail, how the creation of a docker container is made step by step. I just provide some essentials + hints to guarantee that you succeed and don't stumble upon the same issues I had faced. The following prerequisites must be met in order to create a runnable docker container based on your Dockerfile + python code:

Local installation of docker (Docker Desktop)
Docker registry (e.g. GitHub Docker Registry) – this is from where the Pod pulls the docker image
kubectl cli
IDE such as Visual Studio code

For an overall procedure, including the part in Kyma, you can refer to this blog entry on SCN. I strongly recommend that you try to rebuild the example the author walks through first, BEFORE you tackle your actual project.

Recommendations out of my personal learnings:

Try to not create any Kyma artifacts via the UI, but rather define those within descriptor yaml files of the corresponding kinds (e.g. kind: Deployment or Service or APIRule).
!!! A minor but very important thing to consider when running the docker build command, run it as follows:

docker build . --tag ghcr.io/<github_user>/<git_repo_name>:latest --platform linux/amd64

The deployment.yaml in the blog specified above is based on three Kyma/K8S artifacts that are created: Deployment, Service + APIRule. Which kind of artifacts you actually require strongly depends on your python implementation and how your service/logic runs. In the event of a purely job schedule based execution of your processing logic, you don't need a service or APIRule artifact, of course. Instead, you'd only need a deployment of kind: CronJob. This will spin up all dependent artifacts implicitely. In a CronJob based deployment you will have to specify the following details in the yaml file: scheduling details (time, frequency, time zone), required volumes, container spec including secrets to pull image, container level: mounts & env variables, resource allocation.
A template for a CronJob based deployment can look like this:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: <job_name>
  namespace: <kyma_namespace>
spec:
  suspend: false
  schedule: "* * * * *" 
  timeZone: "Europe/Berlin"

  jobTemplate:
    spec:
      backoffLimit: 3
      template:
        spec:
          restartPolicy: Never
          imagePullSecrets:
            - name: ghcr-pull-secret

          volumes:
            - name: gnupg-home
              emptyDir: {}

          initContainers:
            - name: init-gnupg
              image: busybox:1.36
              command: ["sh","-c","mkdir -p /tmp/gnupg && chmod 700 /tmp/gnupg"]
              volumeMounts:
                - name: gnupg-home
                  mountPath: /tmp/gnupg

              resources:
                requests:
                  cpu: "10m"
                  memory: "32Mi"
                limits:
                  cpu: "50m"
                  memory: "64Mi"

          containers:
            - name: inbound
              image: <container_registry_path>
              imagePullPolicy: Always
              command: [<custom_os_level_command_if_required>]
              volumeMounts:
                - name: gnupg-home
                  mountPath: /tmp/gnupg

              env:
                - name: KEY_PATH
                  value: "/keys/keyfile.key"
                - name: PASSPHRASE
                  valueFrom:
                    secretKeyRef:
                      name: kyma-secret
                      key: PASSPHRASE

              resources:
                requests:
                  cpu: "100m"
                  memory: "1Gi"
                limits:
                  cpu: "200m"
                  memory: "2Gi"

8 Achievements

The following functionality and service details were delivered:

The Python code was improved multiple times: Handling approx. 30 files in one go with a total of 10 GB in encrypted state could be accelerated to < 30 minutes of processing time
Cron Jobs in the Kyma cluster can be used to schedule individual services, e.g. inbound processing of files that reside in a specific folder on HDLFS
SAP Datasphere writes local tables via Replication Flows back into HDLFS, on which the outbound service performs encryption and marks the files to „collectible“

9 More Scope

...up to come soon. I will cover aspects how to further mature the microservice/python logic and moreover exemplify on HTTP based encryption/decryption service endpoints, exposed on the Kyma Cluster.

10 References

K8S/Kyma + Python SCN Blog

Getting Started with Data Lake Files HDLFSCLI

HDLFS REST API Guide

Thx...

...to my fellow colleagues at SAP who provides meaningful input and discussed about solution options. Furthermore I am especially grateful to our implementation partner who also supported, implemented and showed strong endurance in building up this scenario.

I hope you enjoyed reading this article and could have gained some deeper insights into what we did. If you have comments or suggestions of any kind, don't hesitate to comment and start-off a discussions with me and hopefully other SMEs.

🚀 SAP Job Scheduling Service: Free Tier Now Available on BTP Live

2026-02-13T12:48:39.945000+01:00

🚀 Free Tier Now Available on BTP Live: Schedule Jobs at Zero Cost!

Great news for the SAP BTP community! After the successful launch of our Free plan on BTP Trial, we're thrilled to announce that the Free tier for SAP Job Scheduling Service is now available on BTP Live (Production)! 🎉

Whether you're building personal projects, creating proof-of-concepts, or running small-scale production workloads, you can now leverage the power of automated job scheduling without incurring any costs!

🌟 What is the Free Tier?

The Free tier is a no-cost service plan that provides you with production-grade job scheduling capabilities on SAP Business Technology Platform. It's designed to give developers, students, indie builders, and enterprises access to powerful scheduling features without financial barriers.

Key Highlights

✅ Zero Cost - No charges, no hidden fees, no credit card required.
✅ Production Ready - Available on both BTP Trial AND BTP Live.
✅ OAuth 2.0 Security - Modern authentication, same as Standard plan.
✅ Full Feature Set - Access to all core scheduling capabilities.
✅ 15 Schedules - Enough for real-world small to medium applications.
✅ Hourly Scheduling - Perfect for regular tasks and automation.

🎯 Who is the Free Tier For?

The Free tier is perfect for:

🧪 Proof of Concepts

Validate scheduling logic before committing to Standard plan
Demonstrate capabilities to stakeholders
Test integration with other BTP services
Build MVPs and demos

🏢 Small Production Workloads

Run lightweight scheduled tasks in production
Automate periodic maintenance jobs
Schedule regular reports and notifications
Power small-scale applications

💼 Enterprise Evaluation

Test Job Scheduling Service in your landscape
Evaluate before enterprise-wide adoption
Train your team on production patterns
Prototype solutions for larger implementations

Update to the Standard plan when you need more schedules, sub-hourly intervals, or SLA-backed support for business-critical workloads.

🆚 How Does Free Compare to Standard?

Here's a detailed comparison to help you choose the right plan:

Feature	`Free` Plan 🆓	`Standard` Plan 💼
Cost	$0/month	Pay-as-you-go pricing
Availability	Trial & Live	Live
Number of Schedules	15	Unlimited
Minimum Interval	1 hour ⏰	5 minutes ⚡
Authentication	OAuth 2.0 🔒	OAuth 2.0 🔒
Multitenancy	✅	✅
REST API	Full access ✅	Full access ✅
Alert Notifications	Unlimited ✅	Unlimited ✅
CF Tasks	✅	✅
Cloud ALM	✅	✅
Support	No, only Community 👥	SLA-backed 🛡️
Best For	Learning, small workloads, PoCs	Production, enterprise, high-frequency jobs

💡 Tip: For production workloads requiring SLA-backed support, consider the Standard plan.

When to Choose Free

✅ You need 15 or fewer scheduled jobs
✅ Hourly or less frequent scheduling is sufficient
✅ You're comfortable with community support
✅ You want zero cost scheduling
✅ You're building PoCs, demos, or learning projects

When to Update to Standard

✅ You need more than 15 schedules
✅ You require sub-hourly scheduling (every 5 minutes, etc.)
✅ You need SLA-backed support
✅ You're running business-critical production workloads
✅ You require faster response times from SAP support

💡 Good News: Updating from Free to Standard is seamless! Your jobs, schedules, and configurations are preserved. (continue reading for detailed instructions)

That's it for the overview! Scroll down for a quick reference guide and step-by-step instructions to get started with the Free tier on BTP Live.

🚀 How to create instance of Free Tier on BTP Live

Using the BTP Cockpit

Step 1: Access BTP Cockpit

Log in to your SAP BTP Cockpit
Navigate to your Global Account → Subaccount
Make sure you're in the Live (production) environment

Step 2: Find Job Scheduling Service

In your subaccount, go to Service Marketplace
Search for "Job Scheduling Service"
Click on the service to see available plans

Step 3: Create Free Plan Instance

Using the BTP Cockpit:

Click Create button
Select Service: Job Scheduling Service
Select Plan: free ⭐
Enter an Instance Name: e.g., my-free-scheduler
Optionally configure parameters (usually not needed)
Click Create

Using the Cloud Foundry CLI

# Log in to your CF space
cf login -a <api-endpoint>

# Create free tier instance
cf create-service jobscheduler free my-free-scheduler

# Verify creation
cf service my-free-scheduler

Note: you can check what is available in your region with cf marketplace -e jobscheduler

🔄 Updating from Free to Standard

Need more power? Updating is seamless (see below)! Everything is preserved!

Using the BTP Cockpit

Navigate to your Job Scheduling Service instance in the BTP Cockpit
Click on the instance to view details
Click the Actions dropdown and select Update
Choose the standard plan and press Update Instance
Wait for the update to complete (usually a few seconds)
Restage your app to pick up changes

Using the Cloud Foundry CLI

# Update service plan
cf update-service my-free-scheduler -p standard

# Restage your app to pick up changes

⚠️ Note: Updating to Standard will start incurring charges based on usage. When you update your plan, all executions performed on the same day are charged toward the standard plan.

📚 Additional Resources

Documentation

Discovery Center

Job Scheduling Service in Discovery Center

Community

🎉 Start Scheduling Today!

The Free tier makes SAP Job Scheduling Service accessible to everyone. Whether you're a student learning the ropes, a developer building a side project, or an enterprise evaluating the service, you can now schedule jobs at zero cost on BTP Live!

⚖️ Terms and Conditions

Free tier service plans are subject to additional terms:

⚠️ No SLA: Service Level Agreements do not apply to free plans
⚠️ Community Support Only: No official SAP support tickets
⚠️ Subject to Terms: Usage governed by Business Technology Platform Supplemental Terms and Conditions
⚠️ Fair Use: SAP reserves the right to enforce fair use policies
⚠️ Service Changes: SAP may modify or discontinue free tier with notice

💡 For production workloads requiring SLAs and official support, update to the Standard plan.

Happy Scheduling! 🎉

The SAP Job Scheduling Service Team

Have questions? Drop a comment below or visit the SAP Community to start a discussion!

From Cloud Foundry to Kyma on SAP BTP: 5 Essential Migration Patterns

2026-02-17T08:40:01.820000+01:00

From Cloud Foundry to Kyma on SAP BTP: 5 Essential Migration Patterns

Introduction

This blog covers five core patterns you'll need when moving from CF to Kyma, with working examples you can test on a BTP Trial Kyma cluster. Each pattern is presented as a direct comparison: here's how you did it in Cloud Foundry, here's how you do it in Kyma. The code examples are complete and tested—you can copy them into your own Kyma environment and see them work. By the end, you'll have a practical understanding of the migration path and reference code you can adapt for your own applications.

What you'll learn:

Basic deployment with APIRules (Istio-based routing)
Service bindings using Kubernetes-native patterns
Pre-runtime configuration with init containers
Credential Store integration for secrets management
Destination Service integration from Kyma

Prerequisites

Before starting, you'll need:

SAP BTP Trial account with Kyma environment enabled
kubectl CLI installed locally
Basic familiarity with Kubernetes concepts

Setup: Download Your Kubeconfig

First, let's get connected to your Kyma cluster:

# Create directory structure
mkdir -p ~/kyma-tutorials
cd ~/kyma-tutorials

# Download kubeconfig from BTP Cockpit
# Navigate to: Subaccount → Kyma Environment → Download Kubeconfig
# Save to ~/.kube/config-kyma-trial

# Set kubeconfig
export KUBECONFIG=~/.kube/config-kyma-trial

# Verify connection
kubectl cluster-info

Critical first step: Enable Istio sidecar injection on your namespace. Kyma requires this for external routing to work:

# Create namespace
kubectl create namespace demo-app

# Enable Istio injection
kubectl label namespace demo-app istio-injection=enabled

# Set as default
kubectl config set-context --current --namespace=demo-app

Pattern 1: Deployment and Routing with APIRules

CF Pattern:

cf push myapp

Kyma Pattern: In Kyma, you need three resources: Deployment, Service, and APIRule.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-kyma
  namespace: demo-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: hello-kyma
  template:
    metadata:
      labels:
        app: hello-kyma
    spec:
      containers:
      - name: hello
        image: hashicorp/http-echo:latest
        args:
          - "-text=Hello from Kyma!"
        ports:
        - containerPort: 5678
---
apiVersion: v1
kind: Service
metadata:
  name: hello-kyma-service
  namespace: demo-app
spec:
  selector:
    app: hello-kyma
  ports:
  - protocol: TCP
    port: 80
    targetPort: 5678
---
apiVersion: gateway.kyma-project.io/v2alpha1
kind: APIRule
metadata:
  name: hello-kyma-api
  namespace: demo-app
spec:
  gateway: kyma-system/kyma-gateway
  hosts:
    - hello-kyma.<YOUR_CLUSTER_DOMAIN>
  service:
    name: hello-kyma-service
    port: 80
  rules:
    - path: /*
      methods: ["GET"]
      noAuth: true

Deploy it:

kubectl apply -f deployment.yaml

# Wait for pod with Istio sidecar
kubectl get pods -n demo-app
# You should see 2/2 containers (app + istio-proxy)

# Test your app
curl https://hello-kyma.<YOUR_CLUSTER_DOMAIN>

Key differences:

CF Router → Istio + APIRule
CF routes → APIRule hosts
Automatic SSL in both, but APIRule uses noAuth: true vs App Router patterns

Pattern 2: Service Bindings - From VCAP_SERVICES to Kubernetes Secrets

CF Pattern:

cf create-service xsuaa application myxsuaa
cf bind-service myapp myxsuaa
# Credentials appear in VCAP_SERVICES environment variable

Kyma Pattern: In Kyma, service bindings create Kubernetes Secrets.

apiVersion: services.cloud.sap.com/v1
kind: ServiceInstance
metadata:
  name: kyma-xsuaa
  namespace: demo-app
spec:
  serviceOfferingName: xsuaa
  servicePlanName: application
  parameters:
    xsappname: kyma-demo-xsuaa
    tenant-mode: dedicated
    scopes:
      - name: "$XSAPPNAME.Read"
        description: "Read permission"
    role-templates:
      - name: Reader
        scope-references:
          - "$XSAPPNAME.Read"
---
apiVersion: services.cloud.sap.com/v1
kind: ServiceBinding
metadata:
  name: kyma-xsuaa-binding
  namespace: demo-app
spec:
  serviceInstanceName: kyma-xsuaa
  secretName: kyma-xsuaa-secret

Deploy it:

kubectl apply -f xsuaa-instance.yaml

# Wait for ready (takes 1-2 minutes)
kubectl get serviceinstance kyma-xsuaa -n demo-app -w

Now use the credentials in your app - you have two options:

Option 1: Environment Variables

env:
- name: XSUAA_CLIENTID
  valueFrom:
    secretKeyRef:
      name: kyma-xsuaa-secret
      key: clientid
- name: XSUAA_CLIENTSECRET
  valueFrom:
    secretKeyRef:
      name: kyma-xsuaa-secret
      key: clientsecret

Option 2: Volume Mounts

volumeMounts:
- name: xsuaa-volume
  mountPath: /etc/secrets/xsuaa
  readOnly: true
volumes:
- name: xsuaa-volume
  secret:
    secretName: kyma-xsuaa-secret

Then read credentials from files:

const fs = require('fs');
const clientId = fs.readFileSync('/etc/secrets/xsuaa/clientid', 'utf8');
const clientSecret = fs.readFileSync('/etc/secrets/xsuaa/clientsecret', 'utf8');

Key differences:

Cloud Foundry Kyma

`cf bind-service`	`ServiceBinding` resource
`VCAP_SERVICES` JSON	Kubernetes Secret
Auto-injected as env var	Mount as volume OR env vars
App parses JSON	App reads individual keys

Pattern 3: Pre-Runtime Configuration - From .profile to Init Containers

CF Pattern: Create a .profile script in your app directory:

#!/bin/bash
echo "Decrypting secrets..."
# Runs before app starts, in same container

Kyma Pattern: Use Kubernetes Init Containers that run before your main app:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: init-demo
  namespace: demo-app
spec:
  template:
    spec:
      # Init container runs FIRST
      initContainers:
      - name: decrypt-config
        image: busybox:latest
        command:
        - sh
        - -c
        - |
          echo "Init container running..."
          # Decrypt secrets, download certs, etc.
          cat /encrypted/config.txt | base64 -d > /decrypted/config.txt
          echo "Runtime info: $(date)" >> /decrypted/runtime-info.txt
          echo "Init complete!"
        volumeMounts:
        - name: encrypted-volume
          mountPath: /encrypted
        - name: decrypted-volume
          mountPath: /decrypted
      
      # Main app runs AFTER init completes
      containers:
      - name: app
        image: myapp:latest
        volumeMounts:
        - name: decrypted-volume
          mountPath: /decrypted
          readOnly: true
      
      volumes:
      - name: encrypted-volume
        configMap:
          name: encrypted-config
      - name: decrypted-volume
        emptyDir: {}

Key differences:

CF .profile Kyma Init Containers

Shell script only	Any container image
Same container	Separate container
Sequential only	Multiple init containers (chained)
No resource limits	CPU/memory limits per init

Real-world use cases:

Decrypt Credential Store secrets
Download certificates from external CA
Run database migrations
Generate dynamic configuration
Wait for dependencies to be ready

Pattern 4: Credential Store Integration

In CF, you might fetch credentials in your .profile script. In Kyma, use an init container to fetch from Credential Store and write to a shared volume.

First, create the Credential Store service:

apiVersion: services.cloud.sap.com/v1
kind: ServiceInstance
metadata:
  name: credstore
  namespace: demo-app
spec:
  serviceOfferingName: credstore
  servicePlanName: trial
---
apiVersion: services.cloud.sap.com/v1
kind: ServiceBinding
metadata:
  name: credstore-binding
  namespace: demo-app
spec:
  serviceInstanceName: credstore
  secretName: credstore-secret

Then fetch credentials in an init container:

spec:
  initContainers:
  - name: fetch-credentials
    image: curlimages/curl:latest
    command:
    - sh
    - -c
    - |
      # Get OAuth token
      OAUTH_URL="$(cat /credstore/url | sed 's|/api.*||')/oauth/token"
      TOKEN=$(curl -s -X POST "$OAUTH_URL" \
        -d "grant_type=client_credentials" \
        -d "client_id=$(cat /credstore/username)" \
        -d "client_secret=$(cat /credstore/password)" \
        | jq -r '.access_token')
      
      # Fetch credential
      CRED_URL=$(cat /credstore/url)
      curl -s "$CRED_URL/password?name=database-password" \
        -H "Authorization: Bearer $TOKEN" \
        | jq -r '.value' > /secrets/db-password
    volumeMounts:
    - name: credstore-creds
      mountPath: /credstore
      readOnly: true
    - name: runtime-secrets
      mountPath: /secrets
  
  containers:
  - name: app
    image: myapp:latest
    volumeMounts:
    - name: runtime-secrets
      mountPath: /secrets
      readOnly: true
  
  volumes:
  - name: credstore-creds
    secret:
      secretName: credstore-secret
  - name: runtime-secrets
    emptyDir: {}

Why this matters:

Credentials NOT stored in Kubernetes Secrets (more secure)
Credentials fetched at runtime (can rotate without redeploying)
Main app doesn't need Credential Store SDK
Init container separates credential management from app logic

Pattern 5: Destination Service Integration

CF Pattern: In CF, you use the App Router with @sap/approuter package, which handles Destination Service integration automatically.

Kyma Pattern: In Kyma, you need to call the Destination Service API directly from your application.

First, create the destination in BTP Cockpit:

Go to Connectivity → Destinations
Create destination:
- Name: backend-api
- URL: https://api.example.com
- Authentication: NoAuthentication
- Additional Property: forwardAuthToken = true

Then create the Destination service instance:

apiVersion: services.cloud.sap.com/v1
kind: ServiceInstance
metadata:
  name: destination
  namespace: demo-app
spec:
  serviceOfferingName: destination
  servicePlanName: lite
---
apiVersion: services.cloud.sap.com/v1
kind: ServiceBinding
metadata:
  name: destination-binding
  namespace: demo-app
spec:
  serviceInstanceName: destination
  secretName: destination-secret

Use it in your Node.js app:

const express = require('express');
const axios = require('axios');
const fs = require('fs');
const app = express();

// Read Destination Service credentials from mounted secret
const destCreds = {
  uri: fs.readFileSync('/etc/secrets/destination/uri', 'utf8').trim(),
  clientid: fs.readFileSync('/etc/secrets/destination/clientid', 'utf8').trim(),
  clientsecret: fs.readFileSync('/etc/secrets/destination/clientsecret', 'utf8').trim(),
  url: fs.readFileSync('/etc/secrets/destination/url', 'utf8').trim()
};

app.get('/call-backend', async (req, res) => {
  try {
    // 1. Get OAuth token for Destination Service
    const tokenResponse = await axios.post(
      `${destCreds.url}/oauth/token`,
      new URLSearchParams({
        grant_type: 'client_credentials',
        client_id: destCreds.clientid,
        client_secret: destCreds.clientsecret
      }),
      { headers: { 'Content-Type': 'application/x-www-form-urlencoded' } }
    );
    
    const token = tokenResponse.data.access_token;
    
    // 2. Get destination configuration
    const destResponse = await axios.get(
      `${destCreds.uri}/destination-configuration/v1/destinations/backend-api`,
      { headers: { Authorization: `Bearer ${token}` } }
    );
    
    const backendUrl = destResponse.data.destinationConfiguration.URL;
    
    // 3. Call backend via destination
    const backendResponse = await axios.get(`${backendUrl}/posts/1`);
    
    res.json({
      message: 'Success!',
      data: backendResponse.data
    });
    
  } catch (error) {
    res.status(500).json({ error: error.message });
  }
});

app.listen(8080);

Deploy with the secret mounted:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: destination-demo
spec:
  template:
    spec:
      containers:
      - name: app
        image: node:18-alpine
        volumeMounts:
        - name: destination-creds
          mountPath: /etc/secrets/destination
          readOnly: true
      volumes:
      - name: destination-creds
        secret:
          secretName: destination-secret
---
apiVersion: gateway.kyma-project.io/v2alpha1
kind: APIRule
metadata:
  name: destination-demo-api
spec:
  gateway: kyma-system/kyma-gateway
  hosts:
    - destination-demo.<YOUR_CLUSTER_DOMAIN>
  service:
    name: destination-demo-service
    port: 80
  rules:
    - path: /*
      methods: ["GET"]
      noAuth: true

Key differences:

Cloud Foundry Kyma

App Router handles it	Manual API calls
`@sap/approuter` package	Custom integration code
Auto-configured routes	Explicit OAuth + API calls

Summary: CF vs Kyma Migration Checklist

Feature Cloud Foundry Kyma Equivalent

Deploy	`cf push`	`kubectl apply -f deployment.yaml`
Service Binding	`cf bind-service`	`ServiceBinding` resource
Credentials	`VCAP_SERVICES` JSON env var	Kubernetes Secret (volume/env)
Pre-runtime	`.profile` script	Init Containers
Routing	CF Router + routes	Istio + APIRule
Authentication	App Router	APIRule `accessStrategies`
Namespace isolation	CF Spaces (shared network)	K8s Namespaces (network policies)
Scaling	`cf scale`	`kubectl scale` or HPA

Key Takeaways

Istio is mandatory: Always enable istio-injection=enabled on namespaces before deploying apps that need external access.
Secrets are files, not JSON: In Kyma, service credentials are individual files in a mounted volume, not a single JSON object.
Init containers are powerful: They're not just a .profile replacement—they can use any container image, have independent resource limits, and can be chained.
Manual integration required: Unlike CF's App Router, Kyma requires you to integrate with BTP services (like Destination Service) directly via API calls.
Kubernetes-native: Kyma uses standard Kubernetes patterns. If you know Kubernetes, you know Kyma. If you don't, learning Kyma teaches you portable Kubernetes skills.

Conclusion

The patterns in this blog give you a foundation to migrate existing CF apps to Kyma. Start with simple apps, master these five patterns, then tackle more complex workloads.

SAP Job Scheduling Service: We Redesigned the Dashboard (And Added Analytics)

2026-02-24T08:11:17.768000+01:00

We Redesigned the Dashboard (And Added Analytics)

Fewer clicks. More insights. Still in preview — we need your feedback.

Hi folks 👋

You may have already seen it, but we put some love into our Job Scheduling Dashboard.

It's now more intuitive - we've eliminated some pages so you can navigate with fewer clicks - saving you precious time. And we've standardized the look and feel, so you can easily find what you need.

But the bigger change? We're experimenting with analytics. 📊

Many of you have told us you use the dashboard for monitoring your jobs - but honestly, it doesn't always do the job well. One example we kept hearing: "How do I find if some execution failed in a schedule?" Good question. We didn't have a good answer. So we built one. 🛠️

We want to give you more insights into your jobs, so you can easily identify issues and optimize your workflows. But this is just the beginning - we have many more ideas in the pipeline, and we can't wait to share them with you.

These features are in preview, so we'd love your feedback. Some of them are limited to certain regions or depend on the number of jobs in your instance. Let us know what works and what doesn't.

The Overview Page

What's new here:

Configuration Page is gone - it's now a simple edit right in this page (one less click, you're welcome)
Two statistics cards - one for Job Statistics and one for Schedule Statistics

Jobs

In the Jobs overview we decided to show the filter by default. You have a filter??? Yes we have - but it was kind of hidden from you. We know. Sorry about that. 😅 Apart from the filter, only the layout has changed.

In the Job details page we merged the overview with schedules - everything in one place now.

But here's the interesting part - we've added analytics cards. Schedule statistics. Best practices warnings. Like when you have a POST job without a body defined in the schedule - because trust me, that leads to issues on your side. We've seen it happen too many times. ⚠️

Schedule Overview

Same idea as Jobs - we merged the overview and details pages into one.

Here we thought you might be interested in the success rate of your schedules, so we added a card for that. Simple question, simple answer: are your schedules healthy or not?

Help Us Make It Better 💬

This is preview for a reason - your feedback shapes what comes next.

Now it's your turn. Try the new features and tell us what you think. What's working? What's broken? What's missing? We're listening. 👂

Comment here - post a comment or send a message
Influence Portal - BTP Foundation - help shape the roadmap
Documentation feedback - Help Portal or GitHub
Reach out directly - I'm Denis, the PM for Job Scheduling service. Find me on LinkedIn - always happy to chat.

Deploying a Python Microservice on SAP BTP Kyma Runtime

2026-03-01T10:07:07.875000+01:00

This tutorial deploys a Python Flask application to Kyma runtime. Most tutorials lean towards Node.js or Java, so I wanted to document the Python path properly — including the gotchas that aren't covered in the official docs.

Prerequisites

SAP BTP account with Kyma enabled (trial is fine to follow along)
kubectl installed and configured with your Kyma kubeconfig
Docker Desktop installed and running
Docker Hub account
Python 3.11+

Project Structure

my-btp-python/
├── app.py
├── requirements.txt
├── Dockerfile
└── k8s/
    ├── deployment.yaml
    ├── service.yaml
    └── apirule.yaml

The Flask App

A simple two-endpoint app — a health check and a data endpoint:

app.py

from flask import Flask, jsonify
import os

app = Flask(__name__)

@app.route("/health", methods=["GET"])
def health():
    return jsonify({"status": "ok"}), 200

@app.route("/api/data", methods=["GET"])
def get_data():
    return jsonify({
        "message": "Hello from Kyma!",
        "environment": os.getenv("ENVIRONMENT", "dev")
    }), 200

if __name__ == "__main__":
    port = int(os.getenv("PORT", 8080))
    app.run(host="0.0.0.0", port=port)

requirements.txt

flask==3.0.3

Dockerfile

FROM python:3.11-slim

WORKDIR /app

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY app.py .

EXPOSE 8080

ENV FLASK_APP=app.py

CMD ["flask", "run", "--host=0.0.0.0", "--port=8080"]

Apple Silicon Users

Kyma clusters run on amd64 (x86) nodes. If you're on Apple Silicon your Mac builds arm64 images by default, which won't run on the cluster. Build explicitly for the right platform:

docker buildx build --platform linux/amd64 -t yourusername/btp-python-app:v1 --push .

Kubernetes Manifests

k8s/deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: btp-python-app
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: btp-python-app
  template:
    metadata:
      labels:
        app: btp-python-app
    spec:
      containers:
        - name: btp-python-app
          image: yourusername/btp-python-app:v1
          imagePullPolicy: Always
          ports:
            - containerPort: 8080
          env:
            - name: ENVIRONMENT
              value: "kyma-trial"
          resources:
            requests:
              memory: "64Mi"
              cpu: "100m"
            limits:
              memory: "128Mi"
              cpu: "200m"

Set imagePullPolicy: Always during development — without it Kubernetes will use a cached image on the node and ignore newly pushed changes.

k8s/service.yaml

apiVersion: v1
kind: Service
metadata:
  name: btp-python-app
  namespace: default
spec:
  selector:
    app: btp-python-app
  ports:
    - port: 80
      targetPort: 8080

APIRule v2

APIRule v1beta1 was removed from Kyma in mid-2025. If you're following older tutorials you'll hit errors. The current version is v2 and the syntax changed significantly.

First, get your cluster domain:

kubectl get gateway -n kyma-system kyma-gateway -o jsonpath='{.spec.servers[0].hosts[0]}'

This returns something like *.c-abc123.kyma.ondemand.com. Strip the *. prefix and use that as your base domain.

k8s/apirule.yaml

apiVersion: gateway.kyma-project.io/v2
kind: APIRule
metadata:
  name: btp-python-app
  namespace: default
spec:
  gateway: kyma-system/kyma-gateway
  hosts:
    - btp-python-app.c-abc123.kyma.ondemand.com
  service:
    name: btp-python-app
    port: 80
  rules:
    - path: /*
      methods: ["GET", "POST"]
      noAuth: true

Key changes from v1beta1:

host is now hosts (a list)
Requires a fully qualified domain name
accessStrategies with handler: noop is replaced by noAuth: true
/.* path syntax is no longer valid — use /*

Istio Sidecar Injection

APIRule v2 is Istio-based. Without sidecar injection enabled on your namespace, the APIRule will show an Error status. Enable it before deploying:

kubectl label namespace default istio-injection=enabled

Deploy

kubectl apply -f k8s/

Watch the pods — you're looking for 2/2 in the READY column (your container plus the Istio sidecar):

kubectl get pods -w

Verify the APIRule is ready:

kubectl get apirule btp-python-app

Test

curl https://btp-python-app.c-abc123.kyma.ondemand.com/health
# {"status":"ok"}

curl https://btp-python-app.c-abc123.kyma.ondemand.com/api/data
# {"environment":"kyma-trial","message":"Hello from Kyma!"}

Troubleshooting

404 from istio-envoy — Check the VirtualService that the APIRule generates has the correct hostname:

kubectl get virtualservice

If it shows an incorrect domain, delete and recreate the APIRule:

kubectl delete apirule btp-python-app
kubectl apply -f k8s/apirule.yaml

Test the app inside the pod before blaming the networking:

kubectl exec -it $(kubectl get pod -l app=btp-python-app -o jsonpath='{.items[0].metadata.name}') -c btp-python-app -- python -c "import urllib.request; print(urllib.request.urlopen('http://localhost:8080/health').read())"

If this returns {"status":"ok"} then Flask is running fine and the problem is in the routing layer.

Trial cluster expiry — Trial Kyma clusters expire after 14 days. When they go down, kubectl commands will throw DNS errors. Recreate the cluster from BTP Cockpit and re-download the kubeconfig. Keep your manifests in source control so you can redeploy quickly.

Next Steps

From here you can extend this with:

XSUAA JWT validation on the APIRule for authentication
A ServiceInstance and ServiceBinding for BTP services like Destination or Connectivity
Reading bound service credentials from environment variables injected via Kubernetes secrets

Conclusion

Getting Python running on Kyma is more involved than it might first appear, but once you understand the moving parts — container registry, Istio sidecar injection, APIRule v2 syntax, and architecture compatibility — it becomes fairly repeatable. The trial environment adds some extra friction with expiring clusters and kubeconfigs, but the underlying platform is solid.

The key is understanding that Kyma is a proper Kubernetes-native environment rather than a traditional PaaS. Once that clicks, the tooling makes sense — Istio out of the box, a clean service binding model, and automatic TLS via Let's Encrypt. There's a learning curve, but it's worth the investment.

SAP Job Scheduling Service REST API Now on Business Accelerator Hub - Explore and Try It Out!

2026-03-05T07:00:00.029000+01:00

🚀 SAP Job Scheduling Service REST API Now on Business Accelerator Hub - Explore and Try It Out!

Big news for SAP developers! The SAP Job Scheduling Service REST API is now available on the SAP Business Accelerator Hub (API Hub for short), making it easier than ever to discover, explore, and integrate job scheduling capabilities into your SAP BTP applications.

Whether you're building Cloud Foundry or Kyma applications, automating workflows, or managing background tasks, you can now find everything you need in one centralized location alongside other SAP APIs.

🎯 What's New?

As of February 18, 2026, the SAP Job Scheduling Service REST API is live on Business Accelerator Hub https://api.sap.com/

Why This Matters

Before this release, developers had to piece together API documentation from help portals, blog posts, and code examples. Now, everything is in one place with:

✅ Centralized Discovery - Find the Job Scheduling Service API alongside 1000+ other SAP APIs
✅ Interactive Testing - Try API endpoints directly in your browser with the "Try It Out" feature
✅ OpenAPI 3.0.3 Specification - Standards-based documentation that works with any OpenAPI tool
✅ Code Generation - Generate client libraries in your favorite programming language
✅ Live Documentation - Always up-to-date API reference with request/response examples

🔍 What Can the Job Scheduling Service API Do?

The Job Scheduling Service REST API provides complete programmatic control over job scheduling on SAP BTP:

📋 Job Management
🕐 Schedule Management
📊 Monitoring & Run Logs
🔐 Authentication

🔎 How to Find the API on Business Accelerator Hub

Let's walk through discovering the Job Scheduling Service API on BAH:

Option 1: Search for "Job Scheduling service"

Search for "SAP Job Scheduling Service" directly in the search bar.

Option 2: Direct Link

Directly go to https://api.sap.com/api/sap-btpjss-admin-v1/overview

API Details Page

You'll see:

Overview - High-level description of the API capabilities
API Reference - Complete list of all endpoints organized by category
Schema View - Detailed definitions of request and response objects
Try It Out - Interactive testing of API endpoints with real authentication
Documents - Additional documentation links

📖 Exploring the API Documentation

The API documentation on BAH is organized into clear sections:

API Endpoints Overview

The Job Scheduling Service API groups endpoints into three main categories:

🔧 Jobs (/scheduler/jobs)

POST /jobs - Create a new job
GET /jobs - Retrieve all jobs
GET /jobs/{jobId} - Get details of a specific job
PATCH /jobs/{jobId} - Update an existing job
DELETE /jobs/{jobId} - Delete a job

📅 Schedules (/scheduler/jobs/{jobId}/schedules)

POST /jobs/{jobId}/schedules - Create a schedule for a job
GET /jobs/{jobId}/schedules - Get all schedules for a job
GET /jobs/{jobId}/schedules/{scheduleId} - Get a specific schedule
PATCH /jobs/{jobId}/schedules/{scheduleId} - Update a schedule
DELETE /jobs/{jobId}/schedules - Delete all schedules
DELETE /jobs/{jobId}/schedules/{scheduleId} - Delete a specific schedule

📊 Run Logs (/scheduler/jobs/{jobId}/schedules/{scheduleId}/runs)

GET /jobs/{jobId}/schedules/{scheduleId}/runs - Get execution logs
GET /jobs/{jobId}/schedules/{scheduleId}/runs/{runId} - Get details of a specific run

Schema Definitions

The API documentation includes detailed schema definitions for all request and response objects:

CreateJobRequest - Job creation with schedules
JobDetails - Complete job information
ScheduleDetails - Schedule configuration (cron, time, repeatInterval)
RunLog - Execution details, status, and HTTP responses
Error responses - Standard error format with messages and HTTP status codes

Each schema shows:

Property names and types
Required vs. optional fields
Default values
Validation constraints (min/max length, patterns, enums)
Example values

🎮 Try It Out - Test the API Interactively

One of the most powerful features of Business Accelerator Hub is the "Try It Out" functionality. Let's walk through testing a real API endpoint!

Prerequisites

Before you can test the API, you'll need:

✅ A Job Scheduling service instance on SAP BTP (Trial or Live)
✅ A service key with OAuth credentials

Don't have these yet? Check out our first blog post in the series for setup instructions.

Getting Your Service Key

Open the SAP BTP Cockpit
Navigate to your subaccount → space → Service Instances
Find your Job Scheduling service instance
Click "Create Service Key" (or use an existing one)
Open the service key and note the following values:
- url - The base URL for the REST API - extract the Landscape Region from this (e.g. eu10 from https://jobscheduler-rest.cfapps.eu10.hana.ondemand.com)
- uaa.identityzone - The zone where the Identity Authentication service is located (e.g. my-subdomain.authentication.eu10.hana.ondemand.com)
- uaa.clientid - Your OAuth client ID
- uaa.clientsecret - Your OAuth client secret

Example service key structure:

{
  "url": "https://jobscheduler-rest.cfapps.eu10.hana.ondemand.com",
  "uaa": {
    "identityzone": "my-subdomain",
    "clientid": "sb-clone-jobscheduler-service!b1234",
    "clientsecret": "your-secret-here"
  }
}

Step-by-Step: Testing GET /jobs

Let's test the GET /jobs endpoint to retrieve all jobs in your Job Scheduling service instance.

1. Configure Environment for Authentication

Click the "Select environment" button:

In the environment dialog enter:

Display name - e.g. "My Trial instance"
Landscape Region - e.g ap21 (trial) - extracted from the url
Client ID - From your service key (uaa.clientid)
Client Secret - From your service key (uaa.clientsecret)
Cf-subaccount-domain - the domain of your BTP subaccount (e.g. dadb4adetrial) from identityzone
Landscape Region - again - same as above (e.g. ap21) - yes, we need that, and yes it is confusing

If successful, you'll see a confirmation that the access token was obtained automatically.

2. Find the GET /jobs Endpoint

Navigate to the Jobs section and expand the GET /jobs endpoint and click "Run":

4. Configure Parameters (Optional)

The GET /jobs endpoint supports optional query parameters:

displaySchedules (boolean) - Include schedule details in response
page (integer) - Page number for pagination
pageSize (integer) - Number of jobs per page

For this example, we'll use the defaults (no parameters needed).

6. View the Response

You'll see the HTTP response directly in the browser:

Response Code: 200 OK

Response Body (example):

{
  "total": 2,
  "results": [
    {
      "jobId": 2523708,
      "name": "validateSalesOrder",
      "description": "Validates sales order requests",
      "action": "https://my-app.cfapps.eu10.hana.ondemand.com/orders/validate",
      "active": true,
      "httpMethod": "POST",
      "jobType": "HTTP_ENDPOINT",
      "ansConfig": { "onError": true, "onSuccess": false },
      "calmConfig": { "enabled": false },
      "createdAt": "2026-02-15 10:30:00"
    },
    {
      "jobId": 2440430,
      "name": "dailyReport",
      "description": "Generate daily sales report",
      "action": "https://my-app.cfapps.eu10.hana.ondemand.com/reports/daily",
      "active": true,
      "httpMethod": "GET",
      "jobType": "HTTP_ENDPOINT",
      "ansConfig": { "onError": false, "onSuccess": false },
      "calmConfig": { "enabled": true },
      "createdAt": "2026-02-10 08:00:00"
    }
  ],
  "prev_url": null,
  "next_url": null
}

🎉 Success! You've just called the Job Scheduling service REST API directly from your browser!

Understanding the Response

The response shows:

total - Total number of jobs in your instance
results - Array of job objects with:
- jobId - Unique job identifier
- name - Job name
- description - Job description
- action - HTTP endpoint that gets invoked
- httpMethod - HTTP method (GET, POST, PUT, DELETE, PATCH)
- active - Whether the job is currently active
- jobType - Type of job (e.g. HTTP_ENDPOINT)
- ansConfig - Alert Notification Service settings (onError, onSuccess)
- calmConfig - SAP Cloud ALM integration settings (enabled)
- createdAt - When the job was created (UTC timestamp)
prev_url / next_url - Pagination links for navigating result pages

Tips for Exploring Other Endpoints

Now that you know how "Try It Out" works, explore other endpoints:

Try creating a job:

Use POST /jobs with a sample request body
See the created job immediately in the response

Retrieve job details:

Copy a job ID from the GET /jobs response
Use GET /jobs/{jobId} to see full details including schedules

Check run logs:

Find a schedule ID from a job's schedules
Use GET /jobs/{jobId}/schedules/{scheduleId}/runs to see execution history

📚 Additional Resources

Official Documentation

SAP Job Scheduling Service Help Portal - Complete product documentation
Authentication Guide - OAuth 2.0 setup

Blog Series

Overview of All Blog Posts - Complete tutorial series

Discovery

SAP Discovery Center - Service overview and capabilities

🎯 What's Next?

Now that you know how to explore and test the Job Scheduling Service API on Business Accelerator Hub, you're ready for the next level:

📖 Coming Soon: Generate Your Own Job Scheduling Service Client Library

In our next blog post, we'll show you how to:

🔧 Download the OpenAPI specification from Business Accelerator Hub
⚙️ Generate a type-safe client library in your favorite language (Node.js, Java, Python, Go, etc.)
💻 Use the generated client to create jobs, schedules, and monitor execution
🚀 Build a complete working example with authentication and error handling

Whether you're building with Node.js, Java, Python, or another language, you'll be able to generate a custom client tailored to your needs!

Stay tuned! Subscribe to the SAP Job Scheduling Service blog series to get notified.

💬 Questions or Feedback?

Have questions about the Job Scheduling Service API on Business Accelerator Hub? Found a bug or have a feature request?

Idea - Submit your ideas on the Influence Portal
📚 Help Portal - Check the official documentation and leave feedback
💬 Community - Comment here in this post
📧 Contact me - Find me on Linkedin: https://www.linkedin.com/in/denis-duev/

🎉 Summary

The SAP Job Scheduling Service REST API is now discoverable on the Business Accelerator Hub, bringing:

✅ One central location for API discovery alongside 1000+ SAP APIs
✅ Interactive testing with "Try It Out" - no code required
✅ OpenAPI 3.0.3 specification for standards-based integration
✅ Up-to-date documentation with examples and schemas
✅ Foundation for client generation (covered in our next blog!)

Whether you're just starting with Job Scheduling service or looking to integrate it into your SAP BTP applications, the Business Accelerator Hub makes it easier than ever to get started.

Happy Scheduling! 🚀

From Sales Data to Design Blueprints: How RPT-1 Enabled Our Fashion Inverse Design Engine

2026-03-10T03:31:48.778000+01:00

What We Built

The Fashion Trend Alchemist is a fully functional inverse design engine that turns historical sales data into concrete design recommendations — complete with product visualizations, a catchy product name, and compelling sales copy. It works across product categories: coats, t-shirts, dresses, trousers, even shoes and sunglasses. The system adapts to any product type without retraining or reconfiguration.

How it creates a product — the full pipeline:

The product creation workflow: from context selection through AI enrichment and RPT-1 prediction to the final product profile with images, name, and sales text. The refine loop lets users iterate on any design decision.

As shown in the diagram above, product creation flows through four core phases:

1. Context Setup — Select a product category (e.g., men's winter coats), define filters and date ranges, and let the system build a curated context of top and bottom performers from the sales data

2. Enrichment — A Vision LLM analyzes product images to extract detailed design attributes (collar type, button style, fabric weight...) that don't exist in the raw database

3. Prediction — The user specifies which attributes to lock and which to predict; RPT-1 fills in the optimal values using in-context learning from the enriched dataset

4. Product Profile — The system generates multi-view product images, proposes a product name, and drafts sales copy — creating a complete, tangible design concept that can be refined and saved to a collection

Technical Architecture

This isn't a Jupyter notebook experiment — it's a deployed, interactive application where users explore design decisions in real time.

The Fashion Trend Alchemist runs on SAP BTP's Kyma runtime as a three-container deployment. The React frontend communicates with a Fastify/Node.js backend that orchestrates three AI services: RPT-1 for attribute prediction and GPT-4.1 for data enrichment and text generation (both via SAP AI Core), and a **self-hosted Z-Image Turbo** instance (product visualization, deployed as a Kyma microservice). PostgreSQL, Redis, and SeaweedFS handle data persistence, caching, and image storage respectively.

How It Works: Designing a Men's Winter Coat

Let's walk through a concrete example to see each phase in action: a product manager wants to know what the next successful men's winter coat should look like.

Building the Context

The user selects "Coats" as the product type, filters for winter seasons and men's wear, and the system queries a large transaction dataset for matching products.

For each matching product, the system calculates a velocity score — first computing units sold per day of availability (transaction count divided by days between first and last sale), then converting this to a percentile rank (0-100) across all matching products. A coat that sold 200 units in 30 days scores higher than one that sold 200 units over 6 months. The system then selects the top and bottom performers to create a balanced context showing RPT-1 clear examples of "success" and "failure."

Enriching Products with Design Attributes

Fashion databases store generic columns: color, material, product group. But a coat's success depends on collar type, insulation level, and closure style — attributes that don't exist in the raw data.

We solve this with AI enrichment. First, an LLM generates a product-specific attribute schema (e.g., `collar_type`, `button_style`, `insulation_level` with their possible values). Then, GPT-4.1 analyzes each product's image and extracts these attributes as structured data.

Real-time enrichment with progress tracking — GPT-4.1 extracts structured design attributes from product images.

RPT-1 in Action: The Prediction

Now the core moment. The enriched context — ~50 products with their detailed attributes and velocity scores — is sent to RPT-1. The user constructs a query row where some attributes are fixed and others contain `[PREDICT]` placeholders.

The interface uses a three-column layout:

- Locked (left): Attributes the user wants to fix — "I know I want a Navy coat"

- AI-Predicted (center): Attributes RPT-1 should determine — "What collar type? What button style?"

- Excluded (right): Attributes irrelevant to this prediction

The user sets a target success score and clicks "Transmute." RPT-1 receives the full context plus the query row in a single API call — no model training, no feature engineering, no pipeline orchestration. Formatted tabular data in, predictions out.

The entire ML layer is essentially: _format data as rows → add query row with `[PREDICT]` → call API → parse response_. The system complexity lives in data preparation, not model management.

Bringing It to Life: The Full Product Profile

The predicted attributes are combined with locked values to generate a complete product profile. The system translates the attribute combination into structured image prompts and produces multiple product views via a self-hosted image generation model running on Kyma — using category-aware prompt templates (coats use ghost mannequin photography; footwear uses product pair shots; accessories get contextual framing). This is completed by a catchy product name and a sales text.

The result isn't an abstract list of attributes — it's a concrete product concept that a designer or product manager can evaluate, iterate on, and refine. The refine loop shown in the pipeline diagram lets users adjust any attribute and regenerate until they're satisfied, then save the design to a collection.

What We Learned About RPT-1

Prediction Becomes a Data Formatting Problem

RPT-1 is pretrained and uses in-context learning — you don't train the model, you provide examples and a query. The API structure is remarkably simple:

The entire prediction integration is ~50 lines of TypeScript. No training scripts, no model serialization, no serving infrastructure. This drastically lowers the barrier for teams outside ML/data science — if you can format tabular data, you can use RPT-1.

Dynamic schemas come free: coats need `collar_type` and `button_style`, sunglasses need `lens_tint` and `frame_shape`. With traditional ML, changing features means re-encoding, retraining, revalidating. With RPT-1, just change the columns.

Validating RPT-1 in the Fashion Domain

Our goal wasn't to build a production prediction system — it was to test whether RPT-1's in-context learning could handle fashion data meaningfully. To validate this, we inverted the workflow: instead of predicting attributes from success scores (inverse design), we tested how well RPT-1 predicts success from attributes (forward prediction). This serves as a sanity check — if the model understands attribute-success relationships, it can leverage them for inverse predictions.

We benchmarked RPT-1 against traditional gradient boosting models (XGBoost, CatBoost) across five product categories using an 80/20 random split:

Model	R²	NDCG	Hit@25
RPT-1	+0.302	0.954	60.5%
XGBoost	+0.267	0.946	55.1%
CatBoost	+0.258	0.945	56.4%

Aggregated across five product categories. RPT-1 matches established gradient boosting models on absolute fit (R²) and edges them out on ranking quality (NDCG, Hit@25) — the metrics that matter most for separating winners from losers.

The scatter plot below shows this concretely for ladies' dresses: top performers (Q4, green) cluster where predicted, while bottom performers (Q1, red) separate clearly. The model isn't perfect, but the quartile separation confirms RPT-1 successfully learned from the in-context examples.

Actual vs. predicted rank for Ladies All-Season Dresses (ρ = 0.626). Clear quartile separation demonstrates RPT-1 effectively distinguishes high from low performers using only in-context examples.

The key finding: RPT-1 worked out-of-the-box for fashion data without domain-specific tuning. For teams exploring tabular foundation models in new domains, this suggests the pretrained capabilities transfer broadly. RPT-1's in-context learning architecture particularly shines in low-data scenarios — some niche categories had only ~23 items in the context, where RPT-1 handled these gracefully.

Context Quality Matters More Than Context Structure

We systematically tested what affects RPT-1's prediction quality:

Row and column ordering — by design, RPT-1's architecture is invariant to the ordering of rows and columns, so reordering should not affect predictions (up to minor numerical artifacts). Our experiments confirmed this: shuffling context rows or reordering columns produced no measurable difference in results — exactly as expected.

Column naming — inherently relevant, though RPT-1 proved surprisingly resilient. Even when we degraded names to synonyms, German translations, or numeric codes, performance variations were minor and inconsistent. Descriptive column names remain a best practice, but the model handles imperfect naming gracefully.

Spearman correlation across naming conditions (Original, Synonyms, German, Mixed, Legacy, Chaos, Numeric). RPT-1 proved robust across conditions in our dataset, though meaningful column names remain a best practice for optimal predictions.

Out-of-distribution contamination — high impact. When wrong products polluted the context (e.g., shirts mixed into a hoodies dataset), prediction quality degraded significantly.

Spearman correlation drops as OOD contamination increases from 0% to 40%. Clean data matters far more than clever formatting.

The takeaway: RPT-1 handles structural variations gracefully — row/column ordering has no effect, and naming degradation had limited impact in our tests. Your primary effort should go into data cleaning and proper normalization.

Challenges We Faced and How We Solved Them

Real-World Data is Messy

Problem: Product catalogs contain labeling errors — shirts categorized as hoodies, skirts labeled as pants. In-context learning amplifies these errors: garbage in, garbage out.

Solution: Our Vision LLM enrichment returns a `mismatchConfidence` score (0-100) alongside extracted attributes. Products scoring above 80 are flagged for human review. The user sees a prefiltered list and can correct or exclude problematic items before prediction. What started as an afterthought became essential.

GenAI Output is Unpredictable

Problem: LLM outputs can be wrong or malformed — invalid JSON, attributes outside valid ranges, unexpected structures.

Solution: Multi-layer guardrails:

- Prompting with positive examples and explicit output structure

- Runtime validation with Zod schemas to catch structural errors

- Attribute values validated against the ontology's allowed options

- Retry logic with exponential backoff (up to 3 attempts)

Users can manually adjust results or send them back to the LLM with feedback.

Consistency Across Generated Images

Problem: Three product views (front, back, model) must show the same design. Different prompts lead to inconsistent products.

Solution: The LLM generates a single shared `productDescription` used as the consistent core across all views, combined with view-specific prefixes and category-aware templates (wearables use ghost mannequin photography; footwear uses product pair shots).

Closing

Three takeaways for your next project:

1. RPT-1 turns prediction into a data selection & formatting problem. No training pipeline, no ML expertise required — just clean tabular data with a success metric.

2. Context quality is paramount. Row and column ordering has no effect on RPT-1 by design, and the model proved resilient to naming variations in our experiments — though descriptive column names remain recommended. What matters most is clean, relevant data: wrong items in the context degrade predictions significantly.

3. Build guardrails around GenAI. Validate LLM outputs with schemas, constrain responses to allowed values, and keep humans in the loop for edge cases.

Developed at BTP Solution Advisory APAC by Danylo Polishchuk and Nils Dittrich.

For questions or collaboration opportunities, connect with us on LinkedIn: Danylo Polishchuk | Nils Dittrich.

Want to see the Fashion Trend Alchemist in action? Check out the demo video for a walkthrough of the complete workflow.

Want to try RPT-1 yourself? Explore the RPT-1 Playground to test tabular predictions with your own data.

Getting Started with SAP BTP Kyma Runtime Using the CLI

2026-03-12T10:27:43.536000+01:00

Introduction

If you're learning SAP BTP Kyma Runtime, most tutorials point you straight to the cockpit UI. But understanding the CLI tools — btp and kubectl — gives you a much deeper understanding of what's actually happening under the hood. In this post I'll walk through connecting to a Kyma cluster and exploring its core components purely from the command line.

Prerequisites

SAP BTP Trial account with Kyma Runtime enabled
btp CLI installed (download here)
kubectl installed

Step 1: Find Your Subaccount and Kyma Instance

btp login
btp list accounts/subaccount

Then find your Kyma environment instance:

btp list accounts/environment-instance --subaccount <subaccount-id>

You should see something like:

environment name              environment id       environment type   state
<subdomain>-7tn04i0d          <environment-id>     kyma               OK

Get the details including your kubeconfig URL:

btp get accounts/environment-instance <environment-id> --subaccount <subaccount-id>

This returns a labels field containing your KubeconfigURL and APIServerURL.

Step 2: Download the Kubeconfig and Connect kubectl

Download the kubeconfig from the Kyma Dashboard or via the KubeconfigURL, then point kubectl at it:

cp ~/Downloads/kubeconfig.yaml ~/.kube/kyma-config.yaml
export KUBECONFIG=~/.kube/kyma-config.yaml
kubectl get nodes

On a trial cluster you'll see an AWS EC2 worker node:

NAME                        STATUS   ROLES    AGE   VERSION
<node-name>.ec2.internal    Ready    worker   7d    v1.33.7

Step 3: Explore the Kyma Cluster

Namespaces

kubectl get namespaces

Key namespaces:

Namespace Purpose

`kyma-system`	Core Kyma components
`istio-system`	Service mesh
`default`	Your workloads

Core Components in kyma-system

kubectl get pods -n kyma-system

Pod Purpose

`api-gateway-controller-manager`	Manages APIRule resources
`btp-manager-controller-manager`	Manages BTP service bindings
`istio-controller-manager`	Manages Istio service mesh
`sap-btp-operator-controller-manager`	Provisions BTP services as Kubernetes resources
`warden-*`	Image trust validation

Kyma Custom Resources (CRDs)

kubectl api-resources | grep kyma

Key CRDs:

Resource Purpose

`APIRule`	Expose services externally with auth/routing
`RateLimit`	Throttle API traffic
`BtpOperator`	Configure BTP service operator
`Kyma`	Top-level Kyma installation resource

Step 4: Understanding an APIRule

The APIRule is the most important Kyma concept for exposing workloads. Here's what a typical one looks like:

apiVersion: gateway.kyma-project.io/v2
kind: APIRule
spec:
  gateway: kyma-system/kyma-gateway
  hosts:
    - myapp.<cluster-id>.kyma.ondemand.com
  rules:
    - methods: [GET, POST]
      noAuth: true
      path: /*
  service:
    name: myapp
    port: 80

Traffic flow:

Internet
  → https://myapp.<cluster-id>.kyma.ondemand.com
  → kyma-gateway (Istio ingress in kyma-system)
  → Service: myapp:80
  → Pod (with Istio sidecar injected automatically)

Note the noAuth: true setting — fine for development but in production you'd replace this with a JWT handler pointing to XSUAA or another identity provider.

Key Observations

Istio sidecar injection is automatic — any pod in a labelled namespace gets a second container (2/2 in kubectl get pods)
APIRules replace Ingress in Kyma — don't use standard Kubernetes Ingress resources
BTP services bind as Kubernetes Secrets — via ServiceInstance and ServiceBinding resources managed by the SAP BTP Operator

Next Steps

Bind a BTP service (XSUAA, Destination Service) using ServiceInstance and ServiceBinding
Secure an APIRule with JWT authentication
Deploy a Kyma Serverless Function

How Our Team Started Using AI to Supercharge Daily Dev Work in SAP Logistics Management

2026-03-12T10:28:51.321000+01:00

Taming the Dependency Update Avalanche

If you've ever managed dependency updates across multiple repositories, you know the pain. Every morning, there's a fresh batch of version bumps waiting for you. Click into GitHub, check the build status, review the diff, approve, merge, repeat. Multiply that by half a dozen repos, and congratulations — your morning is gone. With AI assistance, we condensed that entire ritual into a single conversation. Ask the AI to check all open dependency PRs, get a summary table with build status and update needs, then tell it which ones to approve. What used to be a 20-minute clicking marathon now takes seconds. It's not glamorous, but reclaiming that time every single day adds up fast.

From Task Description to Implementation Plan — Without the Ramp-Up

We've all been there: you pick up a task from the backlog, and you have zero context. The description references some integration pipeline, a data model you've never touched, and a field mapping buried in documentation you didn't know existed. Instead of spending an hour ramping up, we started asking the AI to do the legwork. It reads the task description, pulls up relevant documentation, cross-references technical specs, and even verifies assumptions against design documents. Then it drafts an implementation plan — sometimes spinning up parallel research threads to speed things up. The key insight here isn't that AI writes perfect plans. It's that the research phase — the part where you're just gathering context — gets compressed dramatically. You still make the decisions, but you make them faster because the information is already in front of you.

Rolling Out Fixes Across Multiple Repos

Here's a scenario every team knows: you find a bug that affects multiple repositories. The fix is straightforward, but applying it means cloning each repo, making the same change, creating a PR, writing the description — rinse and repeat. We found that AI assistants are surprisingly good at this. Describe the issue once, point it at the affected repos, and let it implement the fix across all of them. It even creates individual pull requests with proper descriptions. Three PRs from a single conversation, no copy-pasting required. This is the kind of task where AI doesn't need to be creative — it just needs to be consistent and thorough. And it nails that.

Build Failure Detective Work

The classic "hey, can you check why the pipeline failed?" message. Sometimes you're in a meeting, sometimes you're just deep in another task and don't want to context-switch. Build logs are long, noisy, and full of red herrings. We started delegating the initial investigation to AI. It digs through CI/CD build logs, identifies the actual failures buried in the noise, and gives you a verdict: is this a safe update that just needs a test fix, or is there a genuine regression? The kind of log archaeology that normally takes 15 minutes of scrolling and squinting — done in about one. You still make the call on what to do next. But at least you're making it with a clear summary instead of raw log output.

What We Actually Learned

After a few weeks of working this way, a few things became clear:

AI is best at the boring stuff. The more repetitive and well-defined a task is, the more value you get. Don't start with "write me a new microservice." Start with "check these 12 PRs for me."
Trust, but verify. AI will confidently give you wrong answers sometimes. Cross-checking matters. The good news is that the AI itself can help you verify — ask it to double-check against documentation or specs.
Context is everything. The more your AI assistant understands your codebase, conventions, and tooling, the more useful it becomes. Invest time in setting that up — it pays off quickly.
It changes how you plan your day. When you know you can offload the tedious parts, you start structuring your work differently. Kick off an AI task before a meeting, review the results after. It's like having a junior developer who never gets bored.

[UPDATE] BTP Trial Update: Kyma Runtime Availability

2026-03-31T17:18:32.448000+02:00

Dear SAP BTP trial community,

We always aimed to give users the most freedom and flexibility in the SAP BTP trial to ensure that everyone can test and explore our software or use it for learning purposes. For the next weeks, the SAP BTP trial will not be able to deliver this experience for new SAP BTP trial accounts as we have to prioritize the security and reliability of our SAP BTP trial system. We are experiencing an unusually high amount of misuse limiting the availability for all of our users.

Therefore, we decided to temporarily reduce the offering for the SAP BTP Kyma runtime for new BTP Trial Accounts. You will still be able to build applications and preview them, but deployment in the SAP BTP Kyma runtime will not be possible for the next weeks.

How can you still explore SAP BTP?

All other services will remain available and can be explored on the SAP Discovery Center
As a partner: Refer to our newly released free TDD licenses
As a customer: Leverage the free tier offering as part of Pay-As-You-Go for SAP BTP available in the SAP Store

All updates will be posted in the SAP Community.

See you soon,

SAP BTP trial product team

Calling the SAP Business Partner API from a Kyma Serverless Function via BTP Destination Service

2026-04-02T10:12:48.110000+02:00

Introduction

One of the most common integration patterns in SAP BTP is connecting a Kyma serverless function to an external SAP API — securely, without hardcoding credentials. In this post I'll walk through exactly how to do that using the BTP Destination Service, a Kyma ServiceBinding, and the SAP API Business Accelerator Hub sandbox.

By the end you'll have a working Node.js Kyma function that:

Obtains an OAuth token from XSUAA using client credentials
Resolves a named BTP Destination to get the target API URL
Calls the SAP Business Partner API (A_BusinessPartner) and returns JSON results

All credentials are stored in Kubernetes secrets — nothing is hardcoded.

Prerequisites

SAP BTP Trial account with a Kyma cluster enabled
kubectl configured against your Kyma cluster
An account on api.sap.com with an API key for the sandbox
VSCode with the Kubernetes extension (optional but useful)

Step 1: Enable the Serverless Module in Kyma

By default, the Serverless module may not be enabled on your Kyma cluster. Check:

kubectl get crd | grep serverless

If nothing is returned, go to your BTP cockpit, open the Kyma cluster overview, click Modules → Add, and enable Serverless. Wait a few minutes and recheck.

Step 2: Create the BTP Destination Service Instance

We need a Destination Service instance to store and resolve our API destination. Rather than creating it through the BTP cockpit UI (which has limitations on Trial for Kyma runtime), we use the BTP Service Operator directly in Kubernetes.

First verify the BTP Service Operator CRDs are available:

kubectl get crd | grep sap

You should see serviceinstances.services.cloud.sap.com and servicebindings.services.cloud.sap.com.

Create k8s/destination-instance.yaml:

apiVersion: services.cloud.sap.com/v1
kind: ServiceInstance
metadata:
  name: destination-service
  namespace: default
spec:
  serviceOfferingName: destination
  servicePlanName: lite

Apply it:

kubectl apply -f k8s/destination-instance.yaml
kubectl get serviceinstances -n default

Wait until the status shows Ready.

Step 3: Create the Service Binding

The binding injects the Destination Service credentials (XSUAA client ID, client secret, token URL, and service URI) into a Kubernetes secret.

Create k8s/destination-binding.yaml:

apiVersion: services.cloud.sap.com/v1
kind: ServiceBinding
metadata:
  name: destination-service-binding
  namespace: default
spec:
  serviceInstanceName: destination-service

Apply it:

kubectl apply -f k8s/destination-binding.yaml
kubectl get servicebindings -n default

Verify the secret was created and check the keys:

kubectl get secret destination-service-binding -n default -o jsonpath='{.data}' | python3 -m json.tool

You'll see keys including clientid, clientsecret, url (XSUAA token endpoint), and uri (Destination Service endpoint).

Step 4: Create the BTP Destination

In BTP cockpit go to Connectivity → Destinations → New Destination → From Scratch and fill in:

Field Value

Name	S4H_SANDBOX_BP
Type	HTTP
URL	https://sandbox.api.sap.com/s4hanacloud/sap/opu/odata/sap/API_BUSINESS_PARTNER
Authentication	NoAuthentication
Additional Property: APIKey	your api.sap.com API key

Save it. The API key is stored as a destination property — the function will pass it as a request header.

Step 5: Store the API Key as a Kubernetes Secret

Never put API keys in your function code or YAML. Create a secret:

kubectl create secret generic bp-function-apikey \
  --from-literal=apikey='<your-api-key>' \
  -n default

Step 6: Enable Istio Sidecar Injection

The Kyma APIRule requires Istio to be injected into the function pod. Label the namespace:

kubectl label namespace default istio-injection=enabled --overwrite

Step 7: Deploy the Function

Here is the complete k8s/function.yaml. The inline source contains the full Node.js function — no external dependencies required beyond Node built-ins.

apiVersion: serverless.kyma-project.io/v1alpha2
kind: Function
metadata:
  name: bp-function
  namespace: default
  labels:
    app: bp-function
spec:
  runtime: nodejs20
  source:
    inline:
      dependencies: |
        {
          "name": "kyma-bp-function",
          "version": "1.0.0",
          "description": "Kyma serverless function to fetch SAP Business Partners via BTP Destination Service",
          "main": "handler.js",
          "engines": {
            "node": ">=18"
          }
        }
      source: |
        const https = require("https");
        const http = require("http");
        const zlib = require("zlib");

        async function getDestinationToken() {
          const credentials = Buffer.from(
            `${process.env.CLIENTID}:${process.env.CLIENTSECRET}`
          ).toString("base64");
          const tokenUrl = new URL(`${process.env.XSUAA_URL}/oauth/token`);
          const body = "grant_type=client_credentials";

          return new Promise((resolve, reject) => {
            const options = {
              hostname: tokenUrl.hostname,
              path: `${tokenUrl.pathname}?${body}`,
              method: "POST",
              headers: {
                Authorization: `Basic ${credentials}`,
                "Content-Type": "application/x-www-form-urlencoded",
              },
            };
            const req = https.request(options, (res) => {
              let data = "";
              res.on("data", (chunk) => (data += chunk));
              res.on("end", () => {
                try {
                  resolve(JSON.parse(data).access_token);
                } catch (e) {
                  reject(new Error(`Failed to parse token response: ${data}`));
                }
              });
            });
            req.on("error", reject);
            req.end();
          });
        }

        async function getDestination(destinationName, token) {
          const destUrl = new URL(
            `${process.env.DESTINATION_URI}/destination-configuration/v1/destinations/${destinationName}`
          );
          return new Promise((resolve, reject) => {
            const options = {
              hostname: destUrl.hostname,
              path: destUrl.pathname,
              method: "GET",
              headers: {
                Authorization: `Bearer ${token}`,
              },
            };
            const req = https.request(options, (res) => {
              let data = "";
              res.on("data", (chunk) => (data += chunk));
              res.on("end", () => {
                try {
                  resolve(JSON.parse(data));
                } catch (e) {
                  reject(new Error(`Failed to parse destination response: ${data}`));
                }
              });
            });
            req.on("error", reject);
            req.end();
          });
        }

        async function fetchBusinessPartners(destination) {
          const destUrl = destination.destinationConfiguration;
          const targetUrl = new URL(`${destUrl.URL}/A_BusinessPartner?$format=json&$top=20`);
          const protocol = targetUrl.protocol === "https:" ? https : http;
          return new Promise((resolve, reject) => {
            const options = {
              hostname: targetUrl.hostname,
              path: `${targetUrl.pathname}${targetUrl.search}`,
              method: "GET",
              headers: {
                APIKey: process.env.API_KEY,
                Accept: "application/json",
              },
            };
            const req = protocol.request(options, (res) => {
              const chunks = [];
              const encoding = res.headers["content-encoding"];
              const stream = encoding === "gzip" ? res.pipe(zlib.createGunzip())
                           : encoding === "deflate" ? res.pipe(zlib.createInflate())
                           : res;
              stream.on("data", (chunk) => chunks.push(chunk));
              stream.on("end", () => {
                const raw = Buffer.concat(chunks).toString("utf8");
                try {
                  resolve({ statusCode: res.statusCode, body: JSON.parse(raw) });
                } catch (e) {
                  resolve({ statusCode: res.statusCode, body: raw });
                }
              });
              stream.on("error", reject);
            });
            req.on("error", reject);
            req.end();
          });
        }

        module.exports = {
          main: async function (event, context) {
            const DESTINATION_NAME = "S4H_SANDBOX_BP";
            try {
              const token = await getDestinationToken();
              const destination = await getDestination(DESTINATION_NAME, token);
              const result = await fetchBusinessPartners(destination);
              return {
                statusCode: result.statusCode,
                headers: { "Content-Type": "application/json" },
                body: result.body,
              };
            } catch (err) {
              console.error("Error:", err.message);
              return {
                statusCode: 500,
                headers: { "Content-Type": "application/json" },
                body: { error: err.message },
              };
            }
          },
        };
  resourceConfiguration:
    function:
      resources:
        requests:
          cpu: 50m
          memory: 64Mi
        limits:
          cpu: 100m
          memory: 128Mi
  env:
    - name: CLIENTID
      valueFrom:
        secretKeyRef:
          name: destination-service-binding
          key: clientid
    - name: CLIENTSECRET
      valueFrom:
        secretKeyRef:
          name: destination-service-binding
          key: clientsecret
    - name: XSUAA_URL
      valueFrom:
        secretKeyRef:
          name: destination-service-binding
          key: url
    - name: DESTINATION_URI
      valueFrom:
        secretKeyRef:
          name: destination-service-binding
          key: uri
    - name: API_KEY
      valueFrom:
        secretKeyRef:
          name: bp-function-apikey
          key: apikey

Apply it:

kubectl apply -f k8s/function.yaml
kubectl get functions -n default

Wait for RUNNING: True.

Step 8: Expose the Function with an APIRule

Create k8s/apirule.yaml using the v2 API (v1beta1 is deprecated):

apiVersion: gateway.kyma-project.io/v2
kind: APIRule
metadata:
  name: bp-function
  namespace: default
spec:
  gateway: kyma-system/kyma-gateway
  hosts:
    - bp-function.<your-cluster-domain>.kyma.ondemand.com
  rules:
    - methods:
        - GET
      noAuth: true
      path: /*
  service:
    name: bp-function
    port: 80

Get your cluster domain:

kubectl get gateway -n kyma-system kyma-gateway -o jsonpath='{.spec.servers[0].hosts[0]}'

Apply and check status:

kubectl apply -f k8s/apirule.yaml
kubectl get apirule bp-function -n default -o jsonpath='{.status.state}'

Step 9: Test It

curl https://bp-function.<your-cluster-domain>.kyma.ondemand.com

You should get a JSON response containing Business Partner records from the SAP sandbox:

{
  "statusCode": 200,
  "body": {
    "d": {
      "results": [
        {
          "BusinessPartner": "1000037",
          "BusinessPartnerFullName": "...",
          ...
        }
      ]
    }
  }
}

How It Works

The flow is:

The function starts and reads XSUAA credentials from the Kubernetes secret injected by the BTP Service Operator
It calls the XSUAA token endpoint with client credentials to get a bearer token
It uses that token to call the BTP Destination Service and resolve the S4H_SANDBOX_BP destination — getting back the target URL and any stored properties
It calls the SAP API sandbox using the resolved URL, passing the API key as a header
The response is gzip-decoded (the sandbox always returns gzip) and returned as JSON

A Note on Gzip

The SAP API Hub sandbox always returns gzip-compressed responses. Node's https module does not automatically decompress these. The function handles this explicitly using Node's built-in zlib module, detecting the content-encoding response header and piping through zlib.createGunzip() or zlib.createInflate() as appropriate.

Key Points

No external npm packages — the function uses only Node.js built-ins (https, http, zlib), keeping the deployment simple and fast.

Credentials never touch code or git — XSUAA credentials come from the BTP Service Operator binding secret, the API key from a manually created Kubernetes secret. Neither appears in any YAML committed to source control.

Destination Service as the integration layer — by resolving the destination at runtime rather than hardcoding the URL, you can swap the backend (sandbox vs. production, different regions) just by changing the BTP destination configuration, with no code changes.

Istio sidecar is required — the Kyma APIRule validation requires the function pod to have the Istio sidecar injected. Make sure you label the namespace with istio-injection=enabled before deploying the function.

What's Next

From here you could extend this pattern to:

Query specific Business Partners by key
POST data back to the API
Chain multiple API calls within a single function
Trigger the function from a Kyma event rather than an HTTP call
Deploy to a production BTP account pointing at a real S/4HANA system rather than the sandbox

The same pattern — BTP Destination Service + Kyma ServiceBinding + serverless function — works for any SAP API on the Business Accelerator Hub, and for non-SAP APIs too.

The Utility Clean Core Blueprint: How SAP BTP Enables Modernization Without Disrupting Regulated OPR

2026-04-07T13:31:11.299000+02:00

The Utility Clean Core Blueprint: How SAP BTP Enables Modernization Without Disrupting Regulated Operations

A White Paper by Atul Joshi

Executive Summary

Utilities today face a paradox: they must modernize rapidly to support digital customer expectations, DER integration, and grid intelligence — yet they operate in one of the most regulated, risk‑averse environments in the world. Traditional SAP landscapes, especially SAP IS‑U, are burdened with decades of custom code, point‑to‑point integrations, and rigid processes that make transformation slow, expensive, and operationally risky.

This white paper introduces The Utility Clean Core Blueprint, a modernization model that enables utilities to evolve their SAP landscape without destabilizing missions, critical billing, metering, and customer operations. The blueprint leverages SAP Business Technology Platform (BTP) as the innovation and integration layer, allowing utilities to decouple custom logic, orchestrate processes, and adopt cloud capabilities — all while keeping the SAP core stable, compliant, and upgrade‑ready.

The Modernization Challenge in Regulated Utilities

Utilities operate under unique constraints:

Regulatory oversight limits downtime and process changes.
High‑volume billing cycles require predictable system performance.
Legacy customizations make upgrades risky and expensive.
Aging IS‑U systems cannot support modern digital experiences.
Integration sprawl slows innovation and increases operational risk.

Most utilities want to move toward S/4HANA Utilities, but the path is blocked by:

10–20 years of Z‑code
tightly coupled interfaces
custom workflows embedded in IS‑U
inflexible monolithic architecture

This is where Clean Core becomes not just a best practice — but a survival strategy.

2. What Clean Core Really Means for Utilities

Clean Core is often misunderstood as “removing custom code.” For utilities, it means something deeper:

Clean Core = A stable SAP transactional engine + an agile innovation layer on SAP BTP

This approach allows:

predictable billing and metering operations
faster innovation cycles
safer upgrades
cloud‑ready architecture
regulatory compliance

In other words: Keep the core clean. Move the complexity out. Modernize without breaking operations.

3. SAP BTP: The Enabler of Utility Modernization

SAP BTP provides the capabilities utilities need to modernize safely:

Key BTP Services for Utilities

Capability	BTP Service	Utility Value
Event-driven decoupling	Event Mesh	Real-time meter events, outage events, billing triggers
Integration modernization	Integration Suite	Replace PI/PO, eliminate point-to-point interfaces
Extension development	SAP CAP / Kyma	Move Z‑logic out of IS‑U
Workflow automation	BTP Workflow	Field service approvals, credit workflows
Data intelligence	HANA Cloud	Meter analytics, billing insights
Security & governance	IAS/IPS	Unified identity for customer and employee apps

BTP becomes the innovation shell around the SAP core.

4. The Utility Clean Core Blueprint

The Utility Clean Core Blueprint consists of five practical steps:

Step 1 — Stabilize the Core

Freeze custom development in IS‑U
Identify Z‑objects that block upgrades
Classify custom code into: retire, refactor, or externalize
Clean up unused interfaces

Step 2 — Externalize Custom Logic to BTP

Move the following out of IS‑U:

complex billing rules
validation logic
workflow approvals
customer-facing processes
meter data transformations

Use CAP, Node.js, or Java on BTP.

Step 3 — Modernize Integrations

Replace:

PI/PO mappings
RFC-based interfaces
batch jobs

With:

Event Mesh
Integration Suite
APIs

Step 4 — Introduce Event-Driven Architecture

Trigger events for:

meter reads
billing completion
move-in/move-out
credit actions
outage notifications

This decouples processes and reduces core load.

Step 5 — Enable Coexistence with S/4HANA

Run IS‑U + S/4HANA + BTP in hybrid mode:

IS‑U remains the billing engine
S/4 handles finance, procurement, asset management
BTP orchestrates innovation

This avoids a risky “big bang” migration.

5. Practical Utility Case Studies (Realistic, Practitioner-Level)

Case Study 1: Reducing Billing Run Failures with BTP Event Mesh

A North American utility struggled with billing run failures caused by custom validations embedded in IS‑U.

Problem: Every enhancement point slowed down billing and caused unpredictable dumps. Solution:

Move validation logic to a CAP service on BTP
Trigger validation via Event Mesh before billing
Return results via API

Outcome:

Billing runtime reduced by 27%
Zero dumps in 3 months
Clean Core achieved without touching core billing logic

Case Study 2: Modernizing Move-In/Move-Out Without Touching IS‑U

A regulated utility needed a digital customer onboarding experience.

Problem: IS‑U move-in/out processes were too rigid and heavily customized.

Solution:

Build a customer onboarding app on BTP
Orchestrate workflow using BTP Workflow
Trigger IS‑U move-in via API only at the final step

Outcome:

Customer onboarding time reduced from 3 days to 30 minutes
No changes required in IS‑U core
Regulatory compliance maintained

Case Study 3: Eliminating 40+ Point-to-Point Integrations

Problem: European utility had PI/PO interfaces that were expensive to maintain.

Solution:

Replace PI/PO with Integration Suite
Introduce canonical data models
Use Event Mesh for asynchronous processes

Outcome:

Integration failures reduced by 60%
Upgrade downtime reduced by 40%
IT operations cost reduced significantly

6. The Coexistence Architecture: IS‑U + S/4 + BTP

Utilities cannot afford a big-bang migration. The coexistence model allows:

IS‑U

→ Billing, metering, device management

S/4HANA

→ Finance, procurement, asset management

SAP BTP

→ Innovation, integration, automation, analytics

This architecture supports:

gradual modernization
regulatory stability
continuous innovation

7. Governance: The Missing Piece in Most Utility Programs

Clean Core is not a technical exercise — it is a governance discipline.

Key governance principles

No custom code in the core
All new extensions must be BTP-first
Event-driven architecture preferred over batch
API-led integration
Quarterly review of Z‑objects
Architecture board approval for all enhancements

This is how utilities stay modern after the transformation.

8. Conclusion: Modernize Without Disruption

Utilities cannot pause operations to modernize. They need a blueprint that:

protects regulated processes
reduces technical debt
accelerates innovation
prepares for S/4HANA
supports the energy transition

The Utility Clean Core Blueprint provides exactly that.

By using SAP BTP as the innovation layer, utilities can modernize safely, incrementally, and intelligently — without destabilizing the mission-critical systems that keep the lights on.

Configure Kyma to work with Akamai CDN

2026-04-21T08:38:31.650000+02:00

The article describes how to configure SAP BTP, Kyma runtime to work with Content Delivery Network (CDN) such as Akamai CDN.

A Content Delivery Network consists of multiple servers placed around the world. These servers, called edge servers, are responsible for caching website content and serving it to end users from the nearest location. The original content lives in the 'origin server', which is Kyma in our case.

The configuration that defines how Akamai edge servers handle traffic for a given domain is called a 'Property'. It maps hostnames (for example, www.example.com) to specific edge behaviors, such as caching rules, security settings, and origin server communication.

Akamai edge servers also support TLS termination, so they act as endpoints for HTTPs connections and serve TLS certificates for external domains.

A single Kyma instance can serve content for multiple domains (multiple Akamai Properties), which may then be redirected to any workloads. It is visualized in the following diagram:

As we can see, there are two Akamai Properties, each with two host names. We want to redirect requests for all external host names to the same Kyma instance, ab1234.kyma.ondemand.com, with the IP address 203.0.113.50. At this point, we need a host name on the Kyma side that would accept the traffic. To keep things simple, we may use a subdomain of the Kyma cluster domain, like cdn.ab1234.kyma.ondemand.com, for which we can easily register a DNS entry and generate a TLS certificate.

In the Akamai Property, you need to configure a rule in the following way:

Let's now imagine that an end user makes a request to the domain www.foo.example.com, configured as in the above screenshot. In such a case, the Akamai edge server acts as a reverse proxy and contacts the Kyma origin server in the following way:

Connection is technically made to the origin server defined in the 'Origin Server Hostname', so the edge server resolves the DNS name cdn.ab1234.kyma.ondemand.com and connects to the IP address 203.0.113.50.
In Layer 4, the SNI host name points to the external domain www.foo.example.com.
In Layer 7, the Host header also points to the external domain www.foo.example.com.
It is expected that the origin server provides a valid TLS certificate with a Common Name or Subject Alternative Name equal to the origin hostname, which is cdn.ab1234.kyma.ondemand.com.

To accept such traffic on the Kyma side, we need a custom Istio Gateway:

With internal domain:
- cdn.ab1234.kyma.ondemand.com
With external domains:
- Either www.foo.example.com, api.foo.example.com, www.bar.example.com, www.bar.example.com, m.bar.example.com
- Or *.foo.example.com, *.bar.example.com
- Or *.example.com
Pointing to secret with a key and a certificate for internal domain cdn.ab1234.kyma.ondemand.com.

Note that the Gateway above doesn't need a TLS certificate for external domains, which is hosted by the CDN. The Akamai edge server expects the certificate to be valid for the origin hostname.

To create such a configuration, follow this example:

1. Create three resources: DNSEntry, Certificate, and Istio Gateway.

kubectl create ns gateway-ns

apiVersion: dns.gardener.cloud/v1alpha1
kind: DNSEntry
metadata:
  name: cdn-internal-domain-dnsentry
  namespace: gateway-ns
  annotations:
    dns.gardener.cloud/class: garden
spec:
  dnsName: "cdn.ab1234.kyma.ondemand.com"
  ttl: 600
  targets:
   - 203.0.113.50   # Load Balancer IP address

apiVersion: cert.gardener.cloud/v1alpha1
kind: Certificate
metadata:
  name: cdn-internal-domain-certificate
  namespace: istio-system
spec:
  secretName: cdn-internal-domain-certificate
  commonName: "cdn.ab1234.kyma.ondemand.com"
  issuerRef:
    name: garden

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: cdn-gateway
  namespace: gateway-ns
spec:
  selector:
    app: istio-ingressgateway
    istio: ingressgateway
  servers:
    - port:
        number: 443
        name: https
        protocol: HTTPS
      tls:
        mode: SIMPLE
        credentialName: cdn-internal-domain-certificate
      hosts:
        - "cdn.ab1234.kyma.ondemand.com"
        - "*.example.com"

2. Deploy an application.

kubectl create ns application
kubectl label namespace application istio-injection=enabled --overwrite

apiVersion: v1
kind: ServiceAccount
metadata:
  name: httpbin
  namespace: application
---
apiVersion: v1
kind: Service
metadata:
  name: httpbin
  namespace: application
  labels:
    app: httpbin
    service: httpbin
spec:
  ports:
  - name: http
    port: 8000
    targetPort: 80
  selector:
    app: httpbin
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: httpbin
  namespace: application
spec:
  replicas: 1
  selector:
    matchLabels:
      app: httpbin
      version: v1
  template:
    metadata:
      labels:
        app: httpbin
        version: v1
    spec:
      serviceAccountName: httpbin
      containers:
      - image: docker.io/kennethreitz/httpbin
        imagePullPolicy: IfNotPresent
        name: httpbin
        ports:
        - containerPort: 80

3. Create an APIRule resource, which exposes the above application via the previously created Gateway and on a particular external domain:

apiVersion: gateway.kyma-project.io/v2
kind: APIRule
metadata:
  name: application-foo-external-domain
  namespace: application
spec:
  gateway: gateway-ns/cdn-gateway
  hosts:
    - "www.foo.example.com"
  rules:
    - methods:
        - GET
      noAuth: true
      path: /*
  service:
    name: httpbin
    port: 8000

4. For each external domain, create a separate APIRule resource:

apiVersion: gateway.kyma-project.io/v2
kind: APIRule
metadata:
  name: application-bar-external-domain
  namespace: application
spec:
  gateway: gateway-ns/cdn-gateway
  hosts:
    - "www.bar.example.com"
  rules:
    - methods:
        - GET
      noAuth: true
      path: /*
  service:
    name: httpbin
    port: 8000

5. To test this configuration, we need to simulate what the Akamai edge server does:

Make a TLS connection to the internal domain cdn.ab1234.kyma.ondemand.com
Use SNI host name pointing to external domain www.foo.example.com
Provide an HTTP Host header pointing to the external domain www.foo.example.com

You can use the following bash command:

(
  echo -ne "GET /headers HTTP/1.1\r\n"
  echo -ne "Host: www.foo.example.com\r\n"
  echo -ne "Connection: close\r\n\r\n"
) | openssl s_client -connect "cdn.ab1234.kyma.ondemand.com:443" -servername "www.foo.example.com" -quiet

6. If this works, your Kyma instance is prepared. Once the Akamai Property configuration is applied, try to make a request via the external domain:

curl "https://www.foo.example.com/headers"