SAP Community - SAP BTP, Kyma runtime

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

My previous post walked through calling the SAP Business Partner API from a Kyma Serverless Function. That post was written against a BTP trial account where the Kyma environment came fully loaded — Serverless enabled, full cockpit access, no restrictions.

When I came to apply the same approach on a free tier account, I hit two blockers straight away. These are the same constraints you'd likely encounter trying to apply this pattern on a real engagement, where you're working on a shared cluster and don't own the BTP subaccount:

The Serverless module wasn't installed — kind: Function doesn't exist as a resource type, so the function YAML simply won't apply
No permission to create BTP Destinations via the cockpit — the New Destination button was greyed out

This post is about working around both. By the end you'll have the same result as the original — a live endpoint returning SAP Business Partner JSON — but deployed as a standard Kubernetes Deployment instead of a Kyma Function, and with the BTP Destination created via the REST API rather than the cockpit.

What Changed vs the Original Approach

Original This Post

`kind: Function` (Kyma Serverless)	`kind: Deployment` (standard Kubernetes)
Code inline in YAML	Code in a Docker container
No registry needed	Image pushed to GitHub Container Registry
Destination created in BTP cockpit	Destination created via Destination Service REST API

The call chain is identical — your container still calls XSUAA for a token, resolves the destination, then calls the SAP API sandbox. The difference is purely in how the code is packaged and deployed.

Prerequisites

kubectl configured against a Kyma cluster
Docker installed locally
A GitHub account (for the container registry)
An account on api.sap.com with an API key

Step 1: Check What's Actually Available

Before spending time on a Kyma Function approach, verify whether Serverless is installed:

kubectl api-resources | grep serverless

If nothing is returned, the Serverless module isn't enabled. You'll need either cluster admin access to enable it, or the approach in this post.

Also verify the BTP Service Operator is available (needed for ServiceInstance and ServiceBinding):

kubectl api-resources | grep services.cloud.sap.com

You should see serviceinstances and servicebindings. If these are missing, stop here — the BTP Service Operator isn't installed and none of this will work.

Step 2: Create the Destination Service Instance and Binding

This is identical to the original post. Apply these to your namespace:

k8s/destination-instance.yaml

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

k8s/destination-binding.yaml

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

kubectl apply -f k8s/destination-instance.yaml
kubectl apply -f k8s/destination-binding.yaml

Wait until both show Ready: True:

kubectl get serviceinstance,servicebinding -n dev-space-neil

The binding creates a Kubernetes secret called destination-service-binding containing clientid, clientsecret, url (XSUAA token endpoint), and uri (Destination Service endpoint). Your container will read these as environment variables.

Step 3: Create the BTP Destination via REST API

If you have access to the BTP cockpit, create the destination there as described in the original post. If not, use the Destination Service REST API directly — the service binding credentials you just created have enough access to create instance-level destinations.

Get a token and POST the destination:

TOKEN=$(kubectl get secret destination-service-binding -n dev-space-neil \
  -o jsonpath='{.data.clientid}' | base64 -d)
SECRET=$(kubectl get secret destination-service-binding -n dev-space-neil \
  -o jsonpath='{.data.clientsecret}' | base64 -d)
XSUAA=$(kubectl get secret destination-service-binding -n dev-space-neil \
  -o jsonpath='{.data.url}' | base64 -d)
URI=$(kubectl get secret destination-service-binding -n dev-space-neil \
  -o jsonpath='{.data.uri}' | base64 -d)

ACCESS_TOKEN=$(curl -s -X POST "$XSUAA/oauth/token" \
  -u "$TOKEN:$SECRET" \
  -d "grant_type=client_credentials" \
  | python3 -c "import sys,json; print(json.load(sys.stdin)['access_token'])")

curl -X POST "$URI/destination-configuration/v1/instanceDestinations" \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "Name": "S4H_SANDBOX_BP",
    "Type": "HTTP",
    "URL": "https://sandbox.api.sap.com/s4hanacloud/sap/opu/odata/sap/API_BUSINESS_PARTNER",
    "Authentication": "NoAuthentication",
    "ProxyType": "Internet",
    "APIKey": "<your-api.sap.com-key>"
  }'

The distinction between subaccountDestinations and instanceDestinations matters here. Subaccount destinations are managed at the BTP subaccount level (requires admin access). Instance destinations are scoped to the service instance and can be created by the binding credentials — which is what we have.

Step 4: Write the Handler and HTTP Server

The business logic in handler.js is unchanged from the original post — get a token, resolve the destination, call the API. The only difference is gzip handling (the SAP API sandbox always compresses responses) and reading the API key from the destination properties rather than a separate Kubernetes secret.

handler.js

const https = require("https");
const http = require("http");
const zlib = require("zlib");

/**
 * Gets an OAuth2 access token from XSUAA using client credentials flow.
 * Credentials are injected as env vars from the destination-service-binding secret.
 */
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`);

  return new Promise((resolve, reject) => {
    const options = {
      hostname: tokenUrl.hostname,
      path: `${tokenUrl.pathname}?grant_type=client_credentials`,
      method: "POST",
      headers: {
        Authorization: `Basic ${credentials}`,        // Base64-encoded clientid:clientsecret
        "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(`Token parse failed: ${data}`)); }
      });
    });
    req.on("error", reject);
    req.end();
  });
}

/**
 * Resolves a named BTP Destination via the Destination Service REST API.
 * Returns the full destination object including destinationConfiguration,
 * which contains the target URL and any additional properties (e.g. APIKey).
 */
async function getDestination(name, token) {
  const destUrl = new URL(
    `${process.env.DESTINATION_URI}/destination-configuration/v1/destinations/${name}`
  );
  return new Promise((resolve, reject) => {
    const options = {
      hostname: destUrl.hostname,
      path: destUrl.pathname,
      method: "GET",
      headers: { Authorization: `Bearer ${token}` },  // Token obtained from getDestinationToken()
    };
    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(`Destination parse failed: ${data}`)); }
      });
    });
    req.on("error", reject);
    req.end();
  });
}

/**
 * Calls the SAP Business Partner API via the resolved destination.
 * The SAP API Hub sandbox always returns gzip-compressed responses,
 * so we explicitly handle gzip/deflate decompression via Node's zlib module.
 */
async function fetchBusinessPartners(destination) {
  const config = destination.destinationConfiguration;
  const targetUrl = new URL(`${config.URL}/A_BusinessPartner?$format=json&$top=20`);
  // Use http or https depending on the destination URL scheme
  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: config.APIKey,   // API key stored as a destination property, not a separate secret
        Accept: "application/json",
      },
    };
    const req = protocol.request(options, (res) => {
      const chunks = [];
      const encoding = res.headers["content-encoding"];
      // Pipe through the appropriate decompressor based on Content-Encoding header
      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();
  });
}

/**
 * Main entry point — orchestrates the full call chain:
 * 1. Get XSUAA token
 * 2. Resolve the S4H_SANDBOX_BP destination
 * 3. Fetch Business Partners from the SAP API sandbox
 * Returns a response object compatible with both Kyma Functions and the HTTP server wrapper.
 */
module.exports = {
  main: async function (event, context) {
    try {
      const token = await getDestinationToken();
      const destination = await getDestination("S4H_SANDBOX_BP", 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 },
      };
    }
  },
};

Since this is a container rather than a Kyma Function, we need a simple HTTP server to drive it. server.js wraps the handler:

server.js

const http = require("http");
const handler = require("./handler");

const PORT = process.env.PORT || 8080;  // Default to 8080; override via env var if needed

/**
 * Minimal HTTP server that wraps handler.js for container deployment.
 * Kyma Functions have their own runtime that calls handler.main() directly —
 * this server provides the equivalent entry point when running as a standard Deployment.
 * Every request regardless of path/method triggers the Business Partner fetch.
 */
const server = http.createServer(async (req, res) => {
  try {
    const result = await handler.main({}, {});
    // handler.main() may return body as object or string — normalise to string
    const body = typeof result.body === "string"
      ? result.body
      : JSON.stringify(result.body);
    res.writeHead(result.statusCode || 200, {
      "Content-Type": "application/json",
      ...result.headers,
    });
    res.end(body);
  } catch (err) {
    res.writeHead(500, { "Content-Type": "application/json" });
    res.end(JSON.stringify({ error: err.message }));
  }
});

server.listen(PORT, () => console.log(`Listening on port ${PORT}`));

Step 5: Build and Push a Multi-Platform Container Image

This step doesn't exist in the original Kyma Function approach — the serverless runtime handles that for you. Here you need to build a Docker image and push it to a registry the cluster can reach.

Dockerfile

FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm install --omit=dev
COPY handler.js server.js ./
EXPOSE 8080
CMD ["node", "server.js"]

One important detail: if you're on an Apple Silicon Mac, Docker builds linux/arm64 by default. Most cloud Kubernetes clusters run linux/amd64. Build for both to avoid an ImagePullBackOff with the error no match for platform in manifest:

# Authenticate with GitHub Container Registry
echo $(gh auth token) | docker login ghcr.io -u <your-github-username> --password-stdin

# Build and push for both platforms
docker buildx build \
  --platform linux/amd64,linux/arm64 \
  -t ghcr.io/<your-github-username>/bp-function:latest \
  --push .

Make the package public in GitHub (your profile → Packages → bp-function → Package settings → Change visibility → Public) so the cluster can pull it without credentials.

Step 6: Deploy to Kyma

k8s/deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: bp-function
  namespace: dev-space-neil
  labels:
    app: bp-function
spec:
  replicas: 1
  selector:
    matchLabels:
      app: bp-function
  template:
    metadata:
      labels:
        app: bp-function
    spec:
      containers:
        - name: bp-function
          image: ghcr.io/<your-github-username>/bp-function:latest
          ports:
            - containerPort: 8080
          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
          resources:
            requests:
              cpu: 50m
              memory: 64Mi
            limits:
              cpu: 100m
              memory: 128Mi
---
apiVersion: v1
kind: Service
metadata:
  name: bp-function
  namespace: dev-space-neil
spec:
  selector:
    app: bp-function
  ports:
    - port: 80
      targetPort: 8080

k8s/apirule.yaml

Use the full cluster domain rather than a short hostname. Find yours with:

kubectl get configmap shoot-info -n kube-system -o jsonpath='{.data.domain}'

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

Apply both:

kubectl apply -f k8s/deployment.yaml
kubectl apply -f k8s/apirule.yaml

Check the pod is running:

kubectl get pods -n dev-space-neil -l app=bp-function

Step 7: Test

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

You should see Business Partner records:

{
  "d": {
    "results": [
      {
        "BusinessPartner": "11",
        "BusinessPartnerFullName": "Cust15 Cust15",
        ...
      }
    ]
  }
}

How It Works

The call chain is the same as the original Kyma Function approach:

Internet -> APIRule (Istio) -> Service -> Pod
  -> XSUAA (get OAuth token)
  -> Destination Service (resolve S4H_SANDBOX_BP)
  -> SAP API Hub sandbox (fetch Business Partners)
  -> JSON response

The difference is that your code runs in a container you built and pushed, rather than in the Kyma serverless runtime. The BTP Service Operator still injects the Destination Service credentials into the pod as environment variables via the ServiceBinding secret — that part is identical.

Key Points

The Serverless module is optional. The BTP Service Operator, APIRule, and Istio are the parts that matter for this integration pattern. If Serverless isn't enabled, a standard Deployment works just as well.

Instance destinations vs subaccount destinations. If you can't create destinations in the BTP cockpit, use POST /destination-configuration/v1/instanceDestinations. These are scoped to the service instance and can be created using the binding credentials. They're resolved at runtime just like subaccount destinations.

Multi-platform builds matter. Apple Silicon Macs build linux/arm64 by default. Use docker buildx build --platform linux/amd64,linux/arm64 to produce a manifest list that works on both architectures — avoiding the cryptic no match for platform in manifest error.

Use the full APIRule hostname. In Kyma API Gateway v2, short hostnames in the hosts field expand to include the namespace (bp-function.dev-space-neil.<cluster-domain>). This may not match your cluster's wildcard DNS. Use the full explicit hostname (bp-function.<cluster-domain>) to be safe — check what format existing APIRules in your cluster use.

Gzip is not optional. The SAP API Business Hub sandbox always returns gzip-compressed responses regardless of what you put in Accept-Encoding. Handle it explicitly with Node's built-in zlib module.

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"

n8n on SAP BTP Kyma — Part 1: From Local Docker to Enterprise-Grade Deployment

2026-05-13T11:24:38.536000+02:00

Technology Blogs | SAP Community | n8n meets SAP — Part 1 of 3

Enterprise Automation — Deploying n8n on SAP BTP Kyma

A Step-by-Step Guide to Hosting n8n in a Cloud-Native SAP Environment

Technology Blogs · n8n · SAP BTP · Kyma · Kubernetes

Series Overview:

Enterprise Automation: Deploying n8n on SAP BTP Kyma 📍
Create a Custom SAP AI Core Chat Model Node in n8n
Workflow n8n Integration with Joule Studio

1. The Big Picture

If you have ever run n8n on a local machine or a simple VM, you already know how powerful it is. A few clicks, a running container, and you have a workflow automation engine at your fingertips. But when it comes to real enterprise use, shared access, uptime guarantees, integration with SAP systems, and data that cannot simply disappear when a server restarts, a more robust foundation is needed.

This is where SAP BTP, Kyma runtime comes in. Kyma is SAP's fully managed Kubernetes environment, running directly on the Business Technology Platform. Instead of you managing cluster infrastructure, SAP manages the control plane. You deploy workloads; SAP keeps the platform running. Your n8n instance gets all the benefits of Kubernetes — automatic restarts on failure, persistent storage, a stable external URL, and native proximity to other BTP services like SAP AI Core or SAP HANA Cloud — without the overhead of operating a cluster yourself.

This post comes with all the files you need. At the bottom of this post you will find the complete contents of the deployment files, docker-compose.yml for local development, and n8n-pvc.yaml together with n8n-kyma.yaml for the Kyma deployment. You can create each file locally by simply copying the code provided. By the end of this post, you will have a live, publicly accessible n8n instance running inside your SAP BTP subaccount.

2. Provisioning the Infrastructure

Enabling Kyma Runtime in SAP BTP Cockpit

Before any deployment can happen, the Kyma runtime needs to be enabled in your SAP BTP subaccount. If you have not done this yet, the process is straightforward.

Log in to the SAP BTP Cockpit and navigate to your subaccount. In the left-hand navigation, open "Kyma Environment". If Kyma has not been provisioned yet, you will see an "Enable Kyma" button. Click it, choose a plan (for most scenarios the default plan is sufficient), and confirm. Provisioning takes several minutes — SAP is standing up a fully managed Kubernetes cluster on your behalf.

Once complete, the status in the Cockpit changes to "Created" and a "Link to dashboard" appears. That dashboard is your Kyma control plane — a Kubernetes-native UI where you can inspect namespaces, deployments, services, and more. Keep it open alongside your terminal throughout this guide.

SAP BTP Cockpit subaccount view showing the Kyma Environment tile with status "Created" and the "Link to dashboard" button visible.

The Kyma Dashboard landing page after clicking through — showing the cluster overview and the left-hand namespace selector.

A Note on Resource Sizing

n8n is a Node.js application. It is not particularly memory-hungry at rest, but it spins up processes to execute workflows, and those processes can be CPU-intensive depending on what your workflows do. For a shared team instance handling moderate workflow loads, a cluster with at least 2 vCPUs and 4 GB of memory available for your workloads is a comfortable starting point.

In Kyma's managed environment, the underlying node pool is managed by SAP. If you are on a trial account, be aware that trial clusters have resource limits. For any production or shared team usage, an enterprise subaccount with a properly sized instance type is the right choice. You can check available capacity in the Kyma Dashboard under the cluster's node details.

3. Establishing the Connection

Your cluster is running in the SAP cloud. Your deployment files are on your local machine. To bridge the two, you need two tools installed locally: kubectl (the Kubernetes command-line client) and a Docker engine (for building custom images — relevant in Part 2 of this series).

The Toolbelt

kubectl is the standard CLI for interacting with any Kubernetes cluster. Install it following the official guide for your operating system. On macOS, brew install kubectl is the fastest path. On Windows, the installer is available directly from the Kubernetes project.

Docker Desktop covers both the Docker engine and an optional local Kubernetes cluster for testing. Download it from docker.com. For this post, Docker is only needed for the local docker-compose option and for Part 2 — the Kyma deployment itself pulls images directly from Docker Hub.

The Key to the Kingdom: Downloading your Kubeconfig

kubectl does not know which cluster to talk to until you give it a configuration file — the kubeconfig. This file contains the cluster's API endpoint URL, authentication credentials, and context information. Kyma makes it easy to download.

In the BTP Cockpit, select Kyma Enviroment and click the "KubeconfigURL" . Save the file somewhere accessible, for example ~/.kube/kyma-config.yaml. Then tell kubectl to use it by setting the KUBECONFIG environment variable in your terminal:

export KUBECONFIG=~/.kube/kyma-config.yaml

For this to persist across terminal sessions, add the line to your shell profile (.zshrc, .bashrc, or equivalent).

Verification

With the kubeconfig set, run:

kubectl get nodes

If everything is configured correctly, you will see a list of the worker nodes in your Kyma cluster — their names, status (Ready), and age. This confirms that your local machine is communicating with the SAP cloud cluster. If you see an authentication error instead, double-check that the KUBECONFIG variable is set in the correct terminal session.

4. Deploying the Application

With the cluster accessible, it is time to deploy. The process has a deliberate order: storage first, secrets second, application third. Never the other way around — a Pod that starts without its volume or credentials will crash and require manual intervention.

Namespace Creation

Kubernetes clusters are shared environments. Namespaces are the mechanism for creating logical isolation within a cluster — separate resource quotas, separate access controls, separate network policies. Running n8n in its own n8n namespace keeps it cleanly separated from any other workloads you deploy later.

kubectl create namespace n8n

Always use a dedicated namespace. Deploying into default is a habit that causes confusion fast once you have more than one workload in a cluster.

Persistence First

n8n stores everything on disk: your workflow definitions, saved credentials, execution history, and configuration. Without a persistent volume, all of that disappears every time the Pod restarts — and in Kubernetes, Pods restart. For updates, node maintenance, or any crash, the container is replaced with a fresh one. Without persistence, you start from zero every time.

The n8n-pvc.yaml file in the repository defines a PersistentVolumeClaim — a request to the cluster for a dedicated 5 GB storage volume. Apply it first:

kubectl apply -f n8n-pvc.yaml

Kyma provisions the underlying storage automatically. You can verify it was created and is in Bound status with:

kubectl get pvc -n n8n

The Secret Sauce: The Encryption Key

n8n encrypts all credentials it stores — API keys, passwords, OAuth tokens — using an encryption key that you provide via the N8N_ENCRYPTION_KEY environment variable. This key is critical. If you lose it, n8n can no longer decrypt any of the credentials you have saved, and you will need to re-enter them all from scratch.

Generate a secure key using:

openssl rand -hex 32

Copy the output. Now create a Kubernetes Secret to hold it safely — secrets in Kubernetes are stored separately from your application manifests and are not exposed in plain text in your deployment files:

kubectl create secret generic n8n-secret \
  --from-literal=N8N_ENCRYPTION_KEY='<your-generated-key>' \
  -n n8n

Never put a real key directly into a YAML file that you commit to a repository. The .env.example file in the repo shows the expected format for local development — use that for Docker Compose, and use Kubernetes Secrets for Kyma.

Deploying n8n

With storage claimed and the secret created, apply the main deployment manifest:

kubectl apply -f n8n-kyma.yaml -n n8n

The n8n-kyma.yaml file defines a Kubernetes Deployment — a declaration of the desired state for the n8n application. It tells Kubernetes to run one Pod using the official n8nio/n8n:latest image, mount the persistent volume at /home/node/.n8n (where n8n writes all its data), and inject a set of environment variables including the host domain, protocol, port, and CORS origins.

Before applying, open n8n-kyma.yaml and replace the two placeholder values:

Placeholder What to put here

`<your-encryption-key>`	The key you generated above — or better, reference the Kubernetes Secret
`<your-kyma-domain>`	Your Kyma app domain, e.g. `n8n.abc1234.kyma.ondemand.com`

Once applied, Kubernetes pulls the n8n image from Docker Hub and starts the container. Track the startup with:

kubectl get pods -n n8n --watch

The Pod status will move from Pending (image being pulled) to ContainerCreating to Running. Once it shows Running and 1/1 in the Ready column, n8n is up.

5. Creating the Service — The Internal Bridge

At this point n8n is running inside a Pod. But Pods in Kubernetes are ephemeral — every time the Pod is restarted, recreated, or updated, it gets a new internal IP address. Any other component trying to reach n8n by IP would break on the next restart.

A Kubernetes Service solves this. It is a stable, named internal endpoint that always points to the correct Pod, regardless of how many times that Pod has been replaced. The Service does not change; the Pod behind it can.

Create a file called n8n-service.yaml and apply it to the cluster. The most important part of the Service definition is the selector:

selector:
  app: n8n

This tells the Service: "route traffic to any Pod that carries the label app: n8n." If you look at n8n-kyma.yaml, the Pod template carries exactly that label — that is how the Service and the Deployment find each other. External traffic arriving at the Service on port 80 is forwarded to the n8n container on port 5678.

kubectl apply -f n8n-service.yaml -n n8n

The Kyma Dashboard Services view in the n8n namespace, showing n8n-service listed with its cluster IP.

6. The API Rule — The External Gateway

The Service we just created is internal. It is reachable within the cluster, but not from your browser. The final piece is exposing n8n to the outside world through Kyma's API Gateway.

Kyma uses a custom resource called an APIRule to manage external access to services. An APIRule is more than just an ingress route — it integrates with Kyma's Istio service mesh and the Oathkeeper access control layer. This means you can add authentication policies directly at the gateway level, before a request ever reaches your application.

Creating the API Rule via the Kyma Dashboard

The simplest way to create an APIRule for a first deployment is directly through the Kyma Dashboard UI:

Open the Kyma Dashboard and switch to the n8n namespace using the namespace selector at the top.
In the left-hand navigation, find "API Rules" under the Networking section.
Click "Create API Rule".
Fill in the form:
- Name: n8n
- Service: select n8n-service, port 80
- Host: choose a subdomain — n8n is a natural choice. Kyma will append your cluster's base domain automatically, resulting in a URL like https://n8n.abc1234.kyma.ondemand.com.
- Access Strategy: set to NoAuth for the initial setup.

A Word on the Access Strategy

Setting the access strategy to NoAuth means Kyma's gateway passes all requests through to n8n without performing any additional authentication check at the gateway level. This does not mean the instance is unsecured — n8n has its own built-in user management and requires account login before anyone can see or edit workflows.

For a first deployment and internal team use, this is a perfectly reasonable starting point. For production environments or public-facing instances, you can tighten this by configuring the APIRule to use JWT validation against SAP Identity Authentication Service (IAS), restricting access to authenticated SAP BTP users before requests even reach the n8n container.

Verify External Access

Once the APIRule is created, copy the host URL from the dashboard and open it in your browser. You should be greeted by the n8n login screen. If the browser shows a connection error, give it 30–60 seconds — APIRules take a moment to propagate through the Istio gateway. A green checkmark on the APIRule in the Kyma Dashboard confirms it was processed successfully.

Browser showing the n8n login screen at the live Kyma domain URL — the confirmation that the full stack is working end-to-end.

docker-compose.yml :

services:
  n8n:
    image: n8nio/n8n:latest
    restart: always
    ports:
      - "5678:5678"
    environment:
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
      - N8N_HOST=localhost
      - N8N_PROTOCOL=http
      - NODE_ENV=production
    volumes:
      - ./n8n_data:/home/node/.n8n

.env.example :

# n8n Encryption Key — generate with: openssl rand -hex 32
N8N_ENCRYPTION_KEY=your-random-32-byte-hex-key-here

n8n-kyma.yaml :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: n8n
  namespace: n8n
spec:
  replicas: 1
  selector:
    matchLabels:
      app: n8n
  template:
    metadata:
      labels:
        app: n8n
    spec:
      securityContext:
        runAsUser: 1000
        fsGroup: 1000
      containers:
      - name: n8n
        image: n8nio/n8n:latest
        env:
          - name: N8N_ENCRYPTION_KEY
            value: "<your-encryption-key>"

          - name: N8N_HOST
            value: "<your-kyma-domain>"
          - name: WEBHOOK_URL
            value: "https://<your-kyma-domain>/"
          - name: N8N_PROTOCOL
            value: "https"
          - name: N8N_PORT
            value: "5678"

          - name: N8N_CORS_ALLOWED_ORIGINS
            value: "https://<your-kyma-domain>/"

          - name: N8N_USER_FOLDER
            value: "/home/node/.n8n"
        volumeMounts:
          - name: n8n-data
            mountPath: /home/node/.n8n
      volumes:
      - name: n8n-data
        persistentVolumeClaim:
          claimName: n8n-pvc

n8n-pvc.yaml:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: n8n-pvc
  namespace: n8n
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi

AI Usage Disclosure: Gen AI was used exclusively for linguistic refinements such as grammar, spelling, and phrasing as well as for the structural organisation of this text. All conceptual content, technical knowledge, architecture decisions, and implementation steps were developed independently by the author.

Up Next — Part 2 of 3

Create a Custom Language Model Node for SAP AI Core

You now have a live, persistent n8n instance running on SAP BTP. In Part 2, we take it further: building a custom n8n node that connects directly to SAP AI Core's Generative AI Hub — turning your automation platform into an AI-capable engine that can call SAP-hosted language models like GPT-4o or Llama 3 from within any workflow. The full source code is already available; we will walk through exactly how it works and how to bundle it into your Kyma deployment.

Part 2 - Create a Custom SAP AI Core Chat Model Node in n8n

2026-05-14T14:06:32.507000+02:00

SAP Community — Technology Blogs n8n meets SAP — 3-Part Series

Part 2 of 3

Bringing SAP AI Core into n8n — Building and Deploying a Custom Chat Model Node

How to build a custom node that connects n8n's AI Agent to SAP's Generative AI Hub, package it into a Docker image, and deploy it to your Kyma instance.

Series Overview

Enterprise Automation — Deploying n8n on SAP BTP Kyma
Create a Custom Language Model Node for SAP AI Core 📍
Workflow n8n Integration with Joule Studio

In Part 1 we deployed a clean, vanilla n8n instance on SAP BTP, Kyma runtime. That instance uses the official n8nio/n8n:latest Docker image with no modifications. It works perfectly for most integration scenarios — but it has no built-in understanding of SAP AI Core or the Generative AI Hub.

n8n solves this through a custom node system. Any developer can write a node, package it as a Node.js module, and bake it into a custom Docker image on top of the official n8n base. That image replaces the default one in your deployment, and your new node appears in the editor alongside every built-in node. This post walks through exactly that process from understanding how the node works, to building and testing it locally, pushing it to a private registry, and finally swapping the image in your Kyma deployment. At the end, we build a first real AI workflow to put it all together.

All files used in this post are available at the bottom of this page. You can create each file locally by copying the code provided directly from there. The custom node in this post was built on top of the official n8n-nodes-starter template provided by n8n, which gives you the correct project structure.

1 How the Custom Node Works

Before touching a terminal, it helps to understand what kind of node this actually is because it is not a standard action node. It is a Language Model node.

Nodes in n8n's AI System

n8n has a built-in AI framework based on LangChain. Within that framework, nodes play different roles. An AI Agent node orchestrates a conversation loop , it receives a user message, decides whether to call a tool or respond directly, and produces a final answer. But the Agent node itself does not contain a language model. It expects one to be plugged into it from the outside.

That is exactly what our custom node does. It acts as a model provider, it outputs a ready-to-use language model connection that the Agent node can pick up and use. In n8n's visual canvas, you connect our SAP AI Core node to the "Chat Model" input of an Agent node, and from that point forward the agent uses SAP AI Core as its brain.

n8n canvas showing the SAP AI Core Chat Model node connected to the "Chat Model" input of an AI Agent node

The Authentication Flow

SAP AI Core is protected by XSUAA — SAP's OAuth2 authorization server. Every request to the Generative AI Hub must carry a valid Bearer token. The node handles this automatically: when a workflow runs, the node fetches a fresh token from the XSUAA token endpoint using the Client ID and Client Secret from the saved credentials, then passes that token to every subsequent API call.

This token fetch uses the client credentials grant type, the standard machine-to-machine OAuth2 flow. There is no user redirect or browser interaction involved. The credentials are stored securely in n8n's encrypted credential store (encrypted with the N8N_ENCRYPTION_KEY from Part 1).

The LangChain Bridge

SAP AI Core's Generative AI Hub exposes an API that is compatible with the OpenAI chat completions format. The custom node takes advantage of this by using LangChain's ChatOpenAI client and pointing it at the AI Core endpoint instead of OpenAI's servers. This gives n8n's entire AI framework immediate compatibility with any model deployed in your AI Core resource group, with no custom request logic required.

The node constructs the endpoint URL dynamically from two pieces of information you provide: the Base URL from your AI Core service key, and the Deployment ID of the specific model you want to call. It also attaches the ai-resource-group header to every request so AI Core knows which resource group to bill and route the request to.

Node Parameters

When you add the node to a canvas, you configure it with four fields:

Parameter	Where to find it	Example value
Base URL	AI Core service key — field `AI_API_URL`	`https://api.ai.prod.eu-central-1.aws.ml.hana.ondemand.com`
Deployment ID	SAP AI Launchpad — your active deployment	`d1a2b3c4e5f6`
Model Name	The model behind your deployment	`gpt-4o`
Resource Group	AI Core resource group name	`default`

The credentials (Access Token URL, Client ID, Client Secret) are stored separately in n8n's credential manager and reused across multiple nodes. You create them once and reference them from any number of SAP AI Core nodes in any workflow.

The SAP AI Core Chat Model node configuration panel in n8n, showing all four parameters filled in and the credential selector pointing to a saved "SAP AI Core OAuth2" credential.

2 Building the Image Locally

The repository contains a multi-stage Dockerfile that handles everything: compiling the TypeScript source, assembling the distributable files, and embedding them into a fresh n8n image. You do not need to understand every line of it — but it is worth knowing what the two stages do.

Stage 1 — The Builder

The first stage uses a standard Node.js 20 image as a build environment. It installs all dependencies (including dev tools like the TypeScript compiler), copies the source files, normalises line endings to avoid cross-platform issues between Windows and Linux, and runs the TypeScript build. The output is a compiled dist/ folder containing plain JavaScript — ready to run in any Node.js environment.

Stage 2 — The Final Image

The second stage starts fresh from n8nio/n8n:latest — the same base image used in Part 1. It copies only the compiled output from Stage 1 into a specific system path: /usr/local/lib/node_modules/n8n-nodes-sap-ai-core/.

Why that path specifically? The PersistentVolumeClaim from Part 1 is mounted at /home/node/.n8n. If the node were installed there, the volume mount would hide it at runtime — the node would silently disappear. Installing it to a system path outside the mount point ensures it is always present, regardless of what the PVC contains.

Running the Build

Clone the repository, then build the image with a name and tag of your choice:

docker build -t n8n-sap-ai-core:latest .

Docker will work through both stages. The first time you run this it will take a couple of minutes as it downloads base images and compiles dependencies. Subsequent builds are faster thanks to Docker's layer cache.

3 Testing the Image Locally

Before pushing anything to a registry or touching the Kyma deployment, it is worth confirming that the image works as expected on your local machine. The companion repository from Part 1 already contains a docker-compose.yml for running n8n locally — you just need to point it at your new custom image instead of the default one.

Open the docker-compose.yml and change the image field from n8nio/n8n:latest to n8n-sap-ai-core:latest (the tag you used in the build step). Then start the stack:

docker compose up -d

Open http://localhost:5678 in your browser. Log in, create a new workflow, and open the node picker. Search for "SAP" — the SAP AI Core Chat Model node should appear in the results. If it does, the custom image is working correctly.

n8n node picker (local instance) with "SAP" typed in the search field and the SAP AI Core Chat Model node visible in the results list with the SAP icon.

4 Pushing to a Private Registry

Kyma pulls container images from a registry — either Docker Hub (public) or a private registry that you control. For enterprise use, a private registry is the right choice: it keeps your custom image within your organisation's infrastructure and prevents unauthorised access.

The exact registry URL depends on what your organisation uses. Common choices include the SAP Container Registry, a registry in your cloud provider's environment or a self-hosted Harbor instance. In this Tutorial we used a Docker Hub private repository.

Tag and Push

First, tag your locally built image with the full registry path. Then push it:

# Tag the image with your registry path
docker tag n8n-sap-ai-core:latest <your-registry>/n8n-sap-ai-core:1.0.0

# Push to the registry
docker push <your-registry>/n8n-sap-ai-core:1.0.0

Use a specific version tag (like 1.0.0) rather than latest for anything going to Kyma. This makes rollbacks straightforward if a new version causes problems, you simply update the deployment YAML back to the previous tag and re-apply.

Registry Credentials in Kyma

If your registry is private, Kyma needs credentials to pull the image. You provide these as a Kubernetes imagePullSecret, a Secret of type kubernetes.io/dockerconfigjson that contains your registry login. Create the secret in the n8n namespace and reference it in your deployment manifest. The Kyma Dashboard has a built-in form for creating Docker registry secrets under Configuration → Secrets.

5 Updating the Kyma Deployment

With the image in the registry, the final step is telling the Kyma deployment to use it. Open n8n-kyma.yaml from the Part 1 repository and locate the image field inside the container spec. Change it from the default n8n image to your custom one:

# Before
image: n8nio/n8n:latest

# After
image: <your-registry>/n8n-sap-ai-core:1.0.0

If your registry is private, also add the imagePullSecrets entry pointing to the secret you created in the previous step. Then apply the updated manifest:

kubectl apply -f n8n-kyma.yaml -n n8n

Kubernetes detects that the image has changed and performs a rolling update — it starts a new Pod with the new image, waits for it to become healthy, then terminates the old one. Your n8n instance will be briefly in a transitional state but will not go fully offline. Watch the rollout with:

kubectl rollout status deployment/n8n -n n8n

Once the rollout is complete, open your live n8n Kyma URL in a browser. Create a new workflow and search for "SAP" in the node picker. The custom node should now be available in your production instance.

6 Building the Sample Workflow

With the custom node deployed, we can build a real AI workflow. The scenario is an IT Helpdesk Assistant, a conversational agent that can look up tickets, knowledge articles, and employee skills from a live OData API and answer questions about them in natural language. This workflow also serves as the foundation for Part 3, where we surface it through Joule Studio.

Workflow Overview

Step 1 — Create the Workflow & add Agent-Node

In n8n, create a new workflow and name it IT-Helpdesk-Agent. Add an AI Agent node to a blank canvas, n8n automatically pairs it with a Chat Trigger, so both nodes appear together. This gives you a built-in chat interface directly inside n8n where you can test the agent in real time without any additional setup.

Step 2 — Add the AI Agent Node

Add an AI Agent node. In its configuration, set the System Message to give the agent a proper persona.

AI Agent node configuration panel showing the Prompt field and the "Chat Model" and "Tools" inputs visible at the bottom of the node ready to be connected.

Step 3 — Connect the SAP AI Core Chat Model

Add the SAP AI Core Chat Model node to the canvas. Configure it with your AI Core credentials, Base URL, Deployment ID, and the model name of your active deployment. Connect the output of this node to the Chat Model input of the AI Agent node.

The agent will now use your SAP-hosted model as its reasoning engine for every workflow execution.

Step 4 — Add the OData Tool

Add an HTTP Request Tool node, this is the tool that gives the agent access to real data. The Description tells the agent when and how to use this tool. The URL is where the dynamic behaviour lives. Instead of a fixed endpoint, the URL uses n8n's $fromAI() expression to let the model itself decide which entity to query:

httpRequest node configuration panel showing the Description field and the URL field.

At this point you have a working AI workflow running entirely within your SAP BTP environment, powered by SAP AI Core, querying a live OData API, and producing natural language answers. No external AI provider, no data leaving your BTP boundary.

SapAiCore.node.ts:

import {
    INodeType,
    INodeTypeDescription,
    ISupplyDataFunctions,
    SupplyData,
    NodeConnectionTypes,
} from 'n8n-workflow';
import { ChatOpenAI } from '@langchain/openai';
import * as https from 'https';
import { URL } from 'url';

function fetchXsuaaToken(tokenUrl: string, clientId: string, clientSecret: string): Promise<string> {
    return new Promise((resolve, reject) => {
        const body = 'grant_type=client_credentials';
        const basicAuth = Buffer.from(`${clientId}:${clientSecret}`).toString('base64');

        let url: URL;
        try {
            url = new URL(tokenUrl);
        } catch {
            return reject(new Error(`Invalid accessTokenUrl: "${tokenUrl}"`));
        }

        const req = https.request({
            hostname: url.hostname,
            path: url.pathname + (url.search ?? ''),
            port: url.port ? parseInt(url.port) : 443,
            method: 'POST',
            headers: {
                'Authorization': `Basic ${basicAuth}`,
                'Content-Type': 'application/x-www-form-urlencoded',
                'Content-Length': Buffer.byteLength(body),
            },
        }, (res) => {
            let data = '';
            res.on('data', (chunk) => { data += chunk; });
            res.on('end', () => {
                try {
                    const json = JSON.parse(data);
                    if (json.access_token) {
                        resolve(json.access_token);
                    } else {
                        reject(new Error(
                            `XSUAA [${res.statusCode}]: ${data} | ` +
                            `clientId prefix: ${clientId.substring(0, 10)}... | ` +
                            `tokenUrl: ${tokenUrl}`
                        ));
                    }
                } catch {
                    reject(new Error(`XSUAA parse error [${res.statusCode}]: ${data}`));
                }
            });
        });

        req.on('error', (err) => reject(new Error(`XSUAA request error: ${err.message}`)));
        req.write(body);
        req.end();
    });
}

export class SapAiCore implements INodeType {
    description: INodeTypeDescription = {
        displayName: 'SAP AI Core Chat Model',
        name: 'sapAiCoreChatModel',
        icon: 'file:sap.svg',
        group: ['transform'],
        version: 1,
        description: 'SAP Generative AI Hub Chat Model via AI Core',
        defaults: {
            name: 'SAP AI Core Model',
        },
        inputs: [],
        outputs: [NodeConnectionTypes.AiLanguageModel],
        credentials: [
            {
                name: 'sapAiCoreAuth',
                required: true,
            },
        ],
        properties: [
            {
                displayName: 'Base URL',
                name: 'baseUrl',
                type: 'string',
                default: '',
                required: true,
                placeholder: 'https://api.ai.prod.eu-central-1.aws.ml.hana.ondemand.com',
                description: 'The AI_API_URL from your SAP Service Key',
            },
            {
                displayName: 'Deployment ID',
                name: 'deploymentId',
                type: 'string',
                required: true,
                default: '',
                description: 'The ID of your specific model deployment in SAP AI Core',
            },
            {
                displayName: 'Model Name',
                name: 'modelName',
                type: 'string',
                default: 'gpt-4o',
                description: 'The name of the model being used (e.g., gpt-4o, gpt-35-turbo)',
            },
            {
                displayName: 'Resource Group',
                name: 'resourceGroup',
                type: 'string',
                default: 'default',
                description: 'The AI Core resource group',
            },
        ],
    };

    async supplyData(this: ISupplyDataFunctions, itemIndex: number): Promise<SupplyData> {
        const credentials = await this.getCredentials('sapAiCoreAuth');

        const baseUrlRaw = this.getNodeParameter('baseUrl', itemIndex, '') as string;
        const baseUrl = baseUrlRaw.replace(/\/$/, '').replace(/\/v2$/, '');
        const deploymentId = this.getNodeParameter('deploymentId', itemIndex, '') as string;
        const modelName = this.getNodeParameter('modelName', itemIndex, 'gpt-4o') as string;
        const resourceGroup = this.getNodeParameter('resourceGroup', itemIndex, 'default') as string;

        const accessTokenUrl = (credentials.accessTokenUrl as string ?? '').trim();
        const clientId = (credentials.clientId as string ?? '').trim();
        const clientSecret = (credentials.clientSecret as string ?? '').trim();

        if (!accessTokenUrl || !clientId || !clientSecret) {
            throw new Error(
                `SAP Auth: credentials incomplete — ` +
                `tokenUrl=${accessTokenUrl ? 'OK' : 'MISSING'}, ` +
                `clientId=${clientId ? 'OK' : 'MISSING'}, ` +
                `clientSecret=${clientSecret ? 'OK' : 'MISSING'}. ` +
                `Delete and re-create the credential in n8n if you recently changed the node.`
            );
        }

        const apiToken = await fetchXsuaaToken(accessTokenUrl, clientId, clientSecret);

        const model = new ChatOpenAI({
            openAIApiKey: apiToken,
            configuration: {
                baseURL: `${baseUrl}/v2/inference/deployments/${deploymentId}`,
                defaultHeaders: {
                    'Authorization': `Bearer ${apiToken}`,
                    'ai-resource-group': resourceGroup,
                    'Content-Type': 'application/json',
                },
                defaultQuery: {
                    'api-version': 'latest',
                },
            },
            modelName: modelName,
            maxRetries: 2,
        });

        return { response: model };
    }
}

SapAiCoreAuth.credentials.ts :

import { ICredentialType, INodeProperties } from 'n8n-workflow';

export class SapAiCoreAuth implements ICredentialType {
    name = 'sapAiCoreAuth';
    displayName = 'SAP AI Core OAuth2 (Client Credentials)';
    documentationUrl = 'https://help.sap.com/docs/sap-ai-core';

    properties: INodeProperties[] = [
        {
            displayName: 'Access Token URL',
            name: 'accessTokenUrl',
            type: 'string',
            default: '',
            placeholder: 'https://tenant.authentication.sap.hana.ondemand.com/oauth/token',
            required: true,
        },
        {
            displayName: 'Client ID',
            name: 'clientId',
            type: 'string',
            default: '',
            required: true,
        },
        {
            displayName: 'Client Secret',
            name: 'clientSecret',
            type: 'string',
            typeOptions: { password: true },
            default: '',
            required: true,
        },
    ];
}

Dockerfile :

# Stage 1: Build 
FROM node:20 AS builder
WORKDIR /build
COPY package*.json tsconfig.json ./
RUN npm install --include=dev --ignore-scripts
COPY . .


# This is critical for proper credential parsing and script execution in Linux containers
RUN find /build -type f \( -name "*.js" -o -name "*.ts" -o -name "*.json" \) -exec sed -i 's/\r$//' {} \; || true

RUN npm run build

# Stage 2: Final n8n Image
FROM n8nio/n8n:latest

USER root

# 1. Use a system path instead of /home/node/.n8n 
# This prevents the PVC from "hiding" your files
RUN mkdir -p /usr/local/lib/node_modules/n8n-nodes-sap-ai-core

# 2. Copy the compiled files and package.json
COPY --from=builder /build/dist /usr/local/lib/node_modules/n8n-nodes-sap-ai-core/dist
COPY --from=builder /build/package.json /usr/local/lib/node_modules/n8n-nodes-sap-ai-core/package.json

# 3. Ensure the icon is in the correct place
COPY --from=builder /build/nodes/SapAiCore/sap.svg /usr/local/lib/node_modules/n8n-nodes-sap-ai-core/dist/nodes/SapAiCore/sap.svg

# 4. Install dependencies in this new system folder
WORKDIR /usr/local/lib/node_modules/n8n-nodes-sap-ai-core
RUN npm install --omit=dev --legacy-peer-deps

# 5. Set permissions so the 'node' user can read the files
RUN chown -R node:node /usr/local/lib/node_modules/n8n-nodes-sap-ai-core

USER node
WORKDIR /home/node

package.json :

{
    "name": "n8n-nodes-sap-ai-core",
    "version": "1.0.0",
    "main": "dist/nodes/SapAiCore/SapAiCore.node.js",
    "scripts": {
        "build": "tsc && npm run copy:assets",
        "copy:assets": "copyfiles -u 1 \"nodes/**/*.svg\" dist/"
    },
    "n8n": {
        "n8nNodesApiVersion": 1,
        "credentials": [
            "dist/credentials/SapAiCoreAuth.credentials.js"
        ],
        "nodes": [
            "dist/nodes/SapAiCore/SapAiCore.node.js"
        ]
    },
    "dependencies": {
        "@langchain/core": "^1.1.41",
        "@langchain/openai": "^0.0.28"
    },
    "peerDependencies": {
        "n8n-workflow": "*"
    },
    "devDependencies": {
        "copyfiles": "^2.4.1",
        "n8n-workflow": "*",
        "typescript": "5.4.3"
    }
}

Up Next — Part 3 of 3

In Part 3 we take this workflow further. We will expose it as a callable tool inside Joule Studio — SAP's agent development environment — turning this n8n automation into a skill that Joule agents can invoke conversationally from within any Joule-enabled SAP application.

No Kyma Runtime? No Problem — Running Kyma Locally with k3d

2026-05-15T09:14:54.960000+02:00

If you've tried to spin up a Kyma runtime on SAP BTP trial recently, you'll have hit the same wall as the rest of us: the Kyma trial has been suspended for the foreseeable future. No ETA.

For anyone actively building skills around Kyma — whether that's for BTP development, cert prep, or just keeping pace with where SAP is heading — this is genuinely frustrating. You can read the docs all day, but without something to deploy to, you're not really learning anything.

So here's what I did instead: I ran Kyma locally using k3d (k3s in Docker) on my MacBook. It's not a perfect substitute for BTP Kyma runtime, but it's close enough to work through real scenarios, debug real problems, and actually understand how the stack fits together.

This post covers what it takes to get there — including the parts the official docs glide past.

What You Need

Docker (running)
k3d v5.x or higher
kubectl
Kyma CLI

Step 1 — Spin Up the Cluster

The k3d cluster creation command is doing several things at once, so it's worth understanding before you paste and run:

k3d cluster create kyma \
  --kubeconfig-switch-context \
  -p '30080:80@loadbalancer' \
  -p '30443:443@loadbalancer' \
  --k3s-arg '--disable=traefik@server:*' \
  --k3s-arg '--tls-san=host.docker.internal@server:*'

The port mappings (30080 → 80, 30443 → 443) expose the ingress gateway on localhost ports that don't require elevated privileges
Traefik is disabled because Kyma uses Istio as its ingress — you don't want them fighting over traffic
The tls-san flag adds host.docker.internal as a valid TLS hostname, which matters later

Then create the required namespace:

kubectl create ns kyma-system

Step 2 — Install the Modules

Kyma is modular. You don't have to install everything — pick what you need. For a useful local setup, I'd recommend starting with at minimum Istio, API Gateway, and Serverless.

Istio (the service mesh — everything else depends on this):

kubectl label namespace kyma-system istio-injection=enabled --overwrite
kubectl apply -f https://github.com/kyma-project/istio/releases/latest/download/istio-manager.yaml
kubectl apply -f https://github.com/kyma-project/istio/releases/latest/download/istio-default-cr.yaml

Serverless (for Functions):

kubectl apply -f https://github.com/kyma-project/serverless-manager/releases/latest/download/serverless-operator.yaml
kubectl apply -f https://github.com/kyma-project/serverless-manager/releases/latest/download/default-serverless-cr.yaml -n kyma-system

API Gateway (exposes your functions externally via APIRules):

kubectl label namespace kyma-system istio-injection=enabled --overwrite
kubectl apply -f https://github.com/kyma-project/api-gateway/releases/latest/download/api-gateway-manager.yaml
kubectl apply -f https://github.com/kyma-project/api-gateway/releases/latest/download/apigateway-default-cr.yaml

Give everything a couple of minutes to come up. You can watch progress with:

kubectl get pods -n kyma-system --watch

Step 3 — Fix CoreDNS

This is the step that will silently break everything if you skip it.

By default, local.kyma.dev subdomains don't resolve to anything useful inside the cluster. You need to tell CoreDNS to rewrite them to point at the Istio ingress gateway:

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns-custom
  namespace: kube-system
data:
  kyma.override: |
    rewrite name regex (.*)\.local\.kyma\.dev istio-ingressgateway.istio-system.svc.cluster.local
EOF

kubectl rollout restart deployment -n kube-system coredns

Without this, you'll spend a while wondering why curl is timing out and nslookup is returning nothing — which brings me to the next section.

Step 4 — Deploy a Function and Test It

Once everything is running, deploy a simple test function. Here's a minimal Node.js example:

apiVersion: serverless.kyma-project.io/v1alpha2
kind: Function
metadata:
  name: hello-kyma
  namespace: default
spec:
  runtime: nodejs20
  source:
    inline:
      source: |
        module.exports = { main: function (event, context) {
          return "Hello from local Kyma!";
        }}

Apply it, wait for it to reach Running state, then create an APIRule to expose it. Once that's in place, test with:

curl http://hello-kyma.local.kyma.dev:30080

Note the port — because of the k3d port mapping, HTTP traffic goes through 30080, not 80 directly.

Issues

The official quick-start docs are accurate, but they assume a fairly smooth path. Here's what debugging actually looked like once I had everything deployed but couldn't get a response through the gateway.

The problem wasn't Kyma. It was a combination of:

DNS not resolving — nslookup hello-kyma.local.kyma.dev was returning nothing. Root cause: CoreDNS rewrite not applied (see Step 3).
Port confusion — I'd been curling port 80 and 443 directly, which don't work from the host. The k3d port mappings mean you need 30080 for HTTP and 30443 for HTTPS from outside the cluster.
Istio mTLS — Once DNS was working, I hit RBAC: access denied. This turned out to be Istio's strict mTLS mode combined with an AuthorizationPolicy that wasn't correctly matching the ingress gateway's service account. Checking kubectl get authorizationpolicy -n default -o yaml and cross-referencing the actual service account name on the ingress gateway pod sorted it.

The fix that confirmed everything was working:

curl http://hello-kyma.local.kyma.dev:30080

Response: Hello from local Kyma!

A Note on HTTPS

HTTP works cleanly with the setup above. HTTPS on a local k3d cluster involves self-signed certificates and some extra trust configuration on the host side — that's a separate infrastructure problem rather than a Kyma one, and deserves its own post.

Why Bother?

Running Kyma locally isn't a replacement for BTP Kyma runtime — you won't be able to bind real BTP services without the BTP Operator pointing at a real subaccount. But for understanding how Functions, API Gateway, Istio, and service mesh concepts actually hang together, it's genuinely valuable. You can break things, fix things, and read actual logs — which is where the learning happens.

If SAP is going to keep Kyma trial offline for a while, this is the next best thing.

Tested on macOS (Apple Silicon) with k3d v5.7, Kyma Istio module latest, and API Gateway module latest.

Running a Python Microservice on Local Kyma (k3d).

2026-05-17T10:46:54.455000+02:00

This is a follow-up to my previous post on deploying Python to SAP BTP Kyma runtime. That post assumed you had a working Kyma runtime available on BTP. This one doesn't — because if you're reading this, there's a reasonable chance you don't.

SAP has withdrawn the Kyma runtime from BTP trial accounts. If you want to learn Kyma without an enterprise subscription, you now need to provide your own environment. The answer is to run Kyma locally using k3d — and that's what this post covers.

It also covers the bits that went wrong. There were quite a few.

Why Local?

If your BTP Kyma runtime is gone, it's because SAP has withdrawn it from trial. There's no workaround on the BTP side — the managed runtime simply isn't available anymore without an enterprise account.

Running Kyma locally on k3d — a lightweight Kubernetes in Docker tool — gives you a real cluster on your local machine with the same Kyma components: Istio, Serverless, API Gateway. You own the environment. It doesn't disappear on you, you can break it and fix it, and you don't need a BTP account to do anything.

The trade-off is setup complexity. There's more to configure than a managed runtime, and the local setup isn't particularly well documented. This post is the documentation I wished existed.

Prerequisites

Docker Desktop (or OrbStack on macOS Apple Silicon)
k3d — brew install k3d on macOS, or see k3d.io for Linux/Windows install options
kubectl
Kyma CLI (optional but useful)
Python 3.11+

Step 1 — Create the k3d Cluster

k3d cluster create kyma \
  --kubeconfig-switch-context \
  -p '30080:80@loadbalancer' \
  -p '30443:443@loadbalancer' \
  --k3s-arg '--disable=traefik@server:*' \
  --k3s-arg '--tls-san=host.docker.internal@server:*'

A few things worth understanding here:

30080 and 30443 are the ports exposed on your local machine. Kubernetes traffic goes in through these.
--disable=traefik removes the default k3d ingress controller — Kyma uses Istio instead, and having both causes conflicts.
--tls-san=host.docker.internal is needed so you can reach the API server from inside Docker containers.

Then create the Kyma system namespace:

kubectl create ns kyma-system

Step 2 — Install Kyma Modules

Follow the Kyma quick install guide to deploy the modules. At minimum you want:

Istio — service mesh and ingress gateway
Serverless — function runtime (optional for this post, but useful)
API Gateway — the APIRule controller

You can add BTP Manager if you want to connect BTP services later, but it's not needed for a basic Python deployment.

After installation:

kubectl get pods -n kyma-system

You should see the controller pods running — istio-controller-manager, api-gateway-controller-manager, and so on. These are the operators that manage the actual Kyma components. The Istio data plane (istiod, ingress gateway) lives in istio-system and gets created separately when you apply the Istio custom resource.

Step 3 — CoreDNS

This step routes *.local.kyma.dev hostnames to the Istio ingress gateway inside the cluster. Without it, DNS resolution for your app hostnames won't work within the cluster.

Create coredns-custom.yaml:

apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns-custom
  namespace: kube-system
data:
  kyma.override: |
    rewrite name regex (.*)\.local\.kyma\.dev istio-ingressgateway.istio-system.svc.cluster.local

Apply it and restart CoreDNS:

kubectl apply -f coredns-custom.yaml
kubectl rollout restart deployment -n kube-system coredns

Note this only affects DNS resolution inside the cluster. For curl from your local machine you'll need /etc/hosts entries and the --resolve flag — more on that later.

Step 4 — Sort Out HTTPS (The Painful Bit)

This is where I lost the most time.

The Kyma gateway is configured with PASSTHROUGH TLS mode by default — it expects TLS to be terminated at the application, not the gateway. For a local setup with self-signed certificates, you want SIMPLE mode instead, where the gateway handles TLS termination.

Getting there required three things.

Generate a self-signed wildcard certificate:

openssl req -x509 -newkey rsa:4096 \
  -keyout /tmp/kyma-tls.key \
  -out /tmp/kyma-tls.crt \
  -days 365 -nodes \
  -subj "/CN=*.local.kyma.dev" \
  -addext "subjectAltName=DNS:*.local.kyma.dev"

Create a TLS secret in istio-system:

kubectl create secret tls kyma-tls -n istio-system \
  --cert=/tmp/kyma-tls.crt \
  --key=/tmp/kyma-tls.key

The namespace matters here. The secret must be in istio-system because that's where the ingress gateway pod runs. Putting it anywhere else and it won't be found.

Patch the gateway to use SIMPLE TLS:

kubectl patch gateway kyma-gateway -n kyma-system --type=json \
  -p='[{"op":"replace","path":"/spec/servers/0/tls","value":{"mode":"SIMPLE","credentialName":"kyma-tls"}}]'

Once this is done, HTTPS requests go to the gateway, TLS is terminated there, and traffic is forwarded in plain HTTP to the service.

To test from your local machine you need the --resolve flag in curl. This is because the TLS handshake needs to use the correct hostname as the SNI value — if you curl 127.0.0.1 directly, the SNI won't match the certificate and the handshake fails.

curl -k --resolve hello-kyma.local.kyma.dev:30443:127.0.0.1 \
  -H "Host: hello-kyma.local.kyma.dev" \
  https://hello-kyma.local.kyma.dev:30443

This took longer to figure out than it should have. The SSL error (SSL_ERROR_SYSCALL) wasn't particularly informative.

Step 5 — The Flask App

Nothing clever here. Create a project folder and the following files.

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"]

Build it:

docker build -t btp-python-app:v1 .

Test it locally before touching Kubernetes:

docker run --rm -p 8080:8080 btp-python-app:v1
curl http://localhost:8080/health

If that returns {"status":"ok"} the app is fine. Stop it and move on.

Step 6 — Import the Image into k3d

On a managed Kyma runtime you'd push the image to Docker Hub or a container registry. Locally you can skip that entirely and import directly into the cluster nodes:

k3d image import btp-python-app:v1 -c kyma

This is much faster for local development. The important thing to remember is that the image is imported into the cluster at that point in time — if you rebuild the image you need to import again.

Step 7 — Kubernetes Manifests

Create a k8s/ folder in your project directory and add three files.

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: btp-python-app:v1
          imagePullPolicy: Never
          ports:
            - containerPort: 8080
          env:
            - name: ENVIRONMENT
              value: "kyma-local"
          resources:
            requests:
              memory: "64Mi"
              cpu: "100m"
            limits:
              memory: "128Mi"
              cpu: "200m"

imagePullPolicy: Never is critical here. Without it Kubernetes tries to pull from a registry, fails, and the pod never starts.

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

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.local.kyma.dev
  service:
    name: btp-python-app
    port: 80
  rules:
    - path: /*
      methods: ["GET", "POST"]
      noAuth: true

A note on APIRule v2 syntax — if you've seen older Kyma examples using gateway.kyma-project.io/v1beta1, that's deprecated as of mid-2025. The v2 differences that catch people out:

host is now hosts (a list)
Path syntax changed — /.* is no longer valid, use /*
accessStrategies with handler: noop is replaced by noAuth: true

Step 8 — Enable Istio Sidecar Injection

Before deploying, label the default namespace for sidecar injection:

kubectl label namespace default istio-injection=enabled

If you skip this, the APIRule will sit in an Error state with the message: Pod does not have an injected istio sidecar. The sidecar is required for Istio's traffic routing to work.

Step 9 — Deploy

kubectl apply -f k8s/

Watch the pod:

kubectl get pods -l app=btp-python-app -w

Wait for 2/2 in the READY column — that's your container plus the Istio sidecar. Then check the APIRule:

kubectl get apirule btp-python-app

You want Ready. If it shows Error, describe it to see why:

kubectl describe apirule btp-python-app

Step 10 — Test It

Add the host entry:

echo "127.0.0.1 btp-python-app.local.kyma.dev" | sudo tee -a /etc/hosts

HTTP:

curl -H "Host: btp-python-app.local.kyma.dev" http://127.0.0.1:30080/health
curl -H "Host: btp-python-app.local.kyma.dev" http://127.0.0.1:30080/api/data

HTTPS:

curl -k --resolve btp-python-app.local.kyma.dev:30443:127.0.0.1 \
  -H "Host: btp-python-app.local.kyma.dev" \
  https://btp-python-app.local.kyma.dev:30443/health

curl -k --resolve btp-python-app.local.kyma.dev:30443:127.0.0.1 \
  -H "Host: btp-python-app.local.kyma.dev" \
  https://btp-python-app.local.kyma.dev:30443/api/data

Expected responses:

{"status": "ok"}
{"environment": "kyma-local", "message": "Hello from Kyma!"}

Things That Tripped Me Up

The nodePort mismatch. When Istio installs it grabs a random nodePort for 443 — in my case 31985, not 30443. k3d only exposes the ports you mapped at cluster creation, so 31985 was unreachable. Fix is to patch the Istio ingress gateway service to use the correct nodePort:

kubectl patch svc istio-ingressgateway -n istio-system --type='json' \
  -p='[{"op": "replace", "path": "/spec/ports/2/nodePort", "value": 30443}]'

The gateway didn't exist. The Kyma quick install guide doesn't create an Istio Gateway resource — it installs the controller that manages them, but the actual Gateway has to be created separately. The APIRule error Could not get specified Gateway is the clue.

SSL_ERROR_SYSCALL. This is what you get when the TLS handshake fails before it even gets to the certificate. It's not an obvious error. In this case the root cause was the gateway being in PASSTHROUGH mode with no certificate configured. Switching to SIMPLE mode and providing a self-signed cert fixed it.

The sidecar. Easy to forget, easy to diagnose — the APIRule error message is clear enough. Label the namespace before you deploy, not after.

Debugging Toolkit

If the app is running but the routing isn't working, test inside the pod first

Running a Node.js Microservice on Local Kyma with BTP Service Operator

2026-05-17T15:31:43.631000+02:00

This post picks up where the Python microservice post left off. If you haven't read that one, the short version is: SAP has withdrawn Kyma runtime from BTP trial, so we built a local Kyma environment on k3d instead. That gave us a working cluster with Istio, API Gateway, and a deployed Python Flask app accessible over HTTP and HTTPS.

This post does two things. First, it connects that local cluster to SAP BTP trial using the BTP Service Operator — so you can provision real BTP services from your local environment. Second, it deploys a Node.js microservice through the same stack, partly to show the pattern works across runtimes, and partly because doing it twice cements how the pieces fit together.

Part 1 — Connecting to SAP BTP Trial

Why Bother?

The local Kyma cluster works fine in isolation, but the point of Kyma in the SAP context is the integration with BTP services — Destination Service, XSUAA, Connectivity, and so on. The BTP Service Operator is what bridges the gap. It lets you create ServiceInstance and ServiceBinding resources on your local cluster that provision real services on BTP, the same way a managed Kyma runtime would.

Your BTP trial account still works — it's just the managed Kyma runtime that's been withdrawn. The service marketplace is still there.

Prerequisites

You'll need:

The local Kyma cluster from the previous post (k3d, Istio, API Gateway, BTP Manager installed)
BTP CLI (btp) installed and logged in
Helm — brew install helm on macOS, or see helm.sh for other platforms
kubectl pointed at your local cluster

Step 1 — Create a Service Manager Instance

Set your BTP CLI target to your subaccount:

btp target --subaccount <your-subaccount-id>

Then create a Service Manager instance with the service-operator-access plan:

btp create services/instance \
  --subaccount <your-subaccount-id> \
  --offering-name service-manager \
  --plan-name service-operator-access \
  --name btp-operator-access

This is what gives the BTP Service Operator permission to talk to the BTP service marketplace on your behalf.

Step 2 — Create a Service Binding and Extract Credentials

Create a binding for the instance:

btp create services/binding \
  --subaccount <your-subaccount-id> \
  --instance-name btp-operator-access \
  --name btp-operator-key

Get the binding ID:

btp get services/binding \
  --subaccount <your-subaccount-id> \
  --name btp-operator-key

Extract the credentials:

btp get services/binding --id <binding-id>

You're looking for four values: clientid, clientsecret, url, and tokenurl. You'll need these in the next step.

Step 3 — Install cert-manager

The BTP Service Operator depends on cert-manager for webhook certificate management. Install it:

kubectl apply -f https://github.com/cert-manager/cert-manager/releases/latest/download/cert-manager.yaml

kubectl wait --for=condition=Available deployment --all -n cert-manager --timeout=90s

Step 4 — Install the BTP Service Operator via Helm

Add the SAP BTP operator Helm repo:

helm repo add sap-btp-operator https://sap.github.io/sap-btp-service-operator
helm repo update

Install the operator, passing credentials directly as Helm values:

helm install sap-btp-operator sap-btp-operator/sap-btp-operator \
  --namespace operators \
  --set manager.secret.clientid="<clientid>" \
  --set manager.secret.clientsecret="<clientsecret>" \
  --set manager.secret.sm_url="<url>" \
  --set manager.secret.tokenurl="<tokenurl>"

A note on passing credentials directly via --set rather than creating the secret first: the alternative approach (running the setup script and then installing Helm) can cause field manager conflicts where Helm and kubectl both think they own the secret. Passing them as Helm values at install time avoids that.

Verify it's running:

kubectl get pods -n operators

You're looking for the BTP operator pod in a Running state.

Part 2 — The Node.js Microservice

Why Node.js?

The Python post covered the core pattern — Dockerfile, Deployment, Service, APIRule. This post uses Node.js to show the same approach works across runtimes. The Kubernetes side is identical; only the application code and Dockerfile change.

The Application

app.js

const express = require('express');
const app = express();
const port = process.env.PORT || 8080;

app.get('/health', (req, res) => {
  res.json({ status: 'ok' });
});

app.get('/api/data', (req, res) => {
  res.json({
    message: 'Hello from Kyma!',
    environment: process.env.ENVIRONMENT || 'dev'
  });
});

app.listen(port, '0.0.0.0', () => {
  console.log(`Server running on port ${port}`);
});

Initialise the project and install dependencies:

mkdir -p ~/Documents/GitHub/kubernetes-course/kyma/btp-node-app
cd ~/Documents/GitHub/kubernetes-course/kyma/btp-node-app
npm init -y
npm install express

The Dockerfile

FROM node:20-slim

WORKDIR /app

COPY package*.json .
RUN npm install --production

COPY app.js .

EXPOSE 8080

CMD ["node", "app.js"]

Build and Test Locally

docker build --no-cache -t btp-node-app:v1 .

The --no-cache flag matters here. If you've run npm install in the project folder before adding express to package.json, Docker may have a cached layer from that earlier run. When it rebuilds, it sees the npm install step hasn't changed and uses the cache — which means express never gets installed in the image. The --no-cache flag forces every layer to rebuild from scratch.

This is the kind of thing that produces a perfectly healthy-looking container that crashes immediately on startup with a module not found error. Worth knowing.

Test it before touching Kubernetes:

docker run --rm -p 8081:8080 btp-node-app:v1
curl http://localhost:8081/health
curl http://localhost:8081/api/data

If both return JSON, the app is fine. Stop the container.

Import into k3d

k3d image import btp-node-app:v1 -c kyma

Kubernetes Manifests

Create a k8s/ folder in the project directory.

k8s/deployment.yaml

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

k8s/service.yaml

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

k8s/apirule.yaml

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

Deploy

kubectl apply -f k8s/

Add the hosts entry:

echo "127.0.0.1 btp-node-app.local.kyma.dev" | sudo tee -a /etc/hosts

Check the pod and APIRule:

kubectl get pods -l app=btp-node-app
kubectl get apirule btp-node-app

Pod should be 2/2 (container plus Istio sidecar). APIRule should be Ready.

Test

HTTP:

curl -H "Host: btp-node-app.local.kyma.dev" http://127.0.0.1:30080/health
curl -H "Host: btp-node-app.local.kyma.dev" http://127.0.0.1:30080/api/data

HTTPS:

curl -k --resolve btp-node-app.local.kyma.dev:30443:127.0.0.1 \
  -H "Host: btp-node-app.local.kyma.dev" \
  https://btp-node-app.local.kyma.dev:30443/health

curl -k --resolve btp-node-app.local.kyma.dev:30443:127.0.0.1 \
  -H "Host: btp-node-app.local.kyma.dev" \
  https://btp-node-app.local.kyma.dev:30443/api/data

Expected:

{"status": "ok"}
{"environment": "kyma-local", "message": "Hello from Kyma!"}

At this point you have a local Kyma cluster that:

Runs containerised microservices in multiple runtimes
Exposes them externally via Istio and APIRule v2
Is connected to SAP BTP trial via the BTP Service Operator

The next logical step is creating a ServiceInstance and ServiceBinding on the local cluster to provision a real BTP service — Destination Service is the obvious one — and consuming it from a microservice. That's where the SAP-specific integration story starts to get interesting.

That'll be the next post.

From Concept to action: Hands-On with the CAP Operator and the Partner Reference Application

2026-05-21T15:34:01.526000+02:00

Introduction

In my recent blog series, Kyma Evolution: Transforming SAP Kyma into a Tailor-Made SaaS Platform for CAP, I explored the architecture behind turning SAP BTP, Kyma runtime into a native, clean-core-compliant foundation for multitenant Software-as-a-Service (SaaS) applications. We discussed the concept of shifting heavy operational workloads—like tenant provisioning, container routing, and database migration—away from custom application logic and directly into the Kubernetes control plane via the CAP Operator.

Concepts and architecture diagrams are crucial, but as developers, we truly understand a framework when we see it working in real code.

To bridge the gap between architectural theory and practical deployment, I have created a hands-on technical walkthrough. I took the standard SAP-provided Partner Reference Application (PRA)—the gold standard sample for complex BTP multitenant SaaS engineering—and forked it to demonstrate exactly how to transition a standard CAP application into a declarative, CAP Operator-managed deployment.

You can find the complete implementation and step-by-step repository here: 👉ElectronicWizzard/partner-reference-application (kymapra1 branch)

Why the Partner Reference Application?

The Partner Reference Application is designed to showcase enterprise-grade SaaS development on SAP BTP. It contains complex real-world challenges:

Multitenancy with isolated data access.
Integration with BTP core services (XSUAA, Destination, SaaS Provisioning Service).
Explicit lifecycle tasks for tenant onboarding and offboarding.

By migrating this specific application to the CAP Operator, we demonstrate that the operator isn't just for simple "Hello World" microservices. It is fully capable of managing sophisticated, production-grade enterprise architectures.

Here is a glimpse of the migration workflow detailed in the hands-on guide:

1. Project Preparation & Plugin Integration

Instead of writing complex Kubernetes deployment manifests from scratch, we leverage the tooling built into the CAP ecosystem. By injecting the development dependency into the project root:

npm add @cap-js/cap-operator-plugin -D

We unlock the plugin capabilities that assist in automatically deriving the necessary configuration files and container patterns directly from our existing cds models and configuration schema.

2. Containerization and Registry Push

As container-native deployments are standard practice, the workflow guides you through leveraging Docker to containerize the CAP application services and push them to a container registry accessible by your Kyma cluster.

3. Transitioning to Custom Resources (CRDs)

The heart of the transformation lies in replacing standard Kubernetes Deployments and StatefulSets with custom resources defined by the CAP Operator, such as CAPApplication.

Instead of writing custom logic to handle mtxs (multitenancy/extensibility) operations during tenant registration, you simply declare the application's characteristics in a clean, unified manifest. The CAP Operator watches this resource and automatically sets up:

The necessary application pods.
Automated routing rules.
Secure BTP Services integration using the SAP BTP Service Operator.
Automated tenant provisioning
...

Prerequisites to Get Started

To follow along with the tutorial and deploy the project yourself, make sure you have the following environments prepared:

A Kyma Cluster with the CAP Operator Installed: Follow the setup detailed in the Kyma Evolution series to ensure your cluster control plane is ready to interpret the custom CAP resources.
BTP Provider Subaccount: A dedicated provider subaccount mapped to your Kyma namespace and entitlement of the required services.
Local Tooling: Docker installed on your machine and access to a container registry (e.g., Docker Hub, GitHub Packages).

Conclusion & Next Steps

Shifting from imperative scripting to a declarative, operator-driven cloud runtime is a massive step forward for building resilient, clean-core SaaS applications on SAP BTP. By analyzing the changes in this fork, you will see exactly how much boilerplate code and deployment complexity can be stripped away from your project lifecycle.

Head over to the repository, check out the kymapra1 branch, and walk through the implementation: 🔗 Read the Full Deployment Guide on GitHub

For those who want to start with there own workload I would like to recommend the new SAP Tutorial for the CAP Operator on the Kyma Environment.

I would love to hear your thoughts! Have you started experimenting with the CAP Operator in your own Kyma or Kubernetes environments? What challenges or successes have you encountered during the shift to declarative operations? Let's discuss in the comments below.

ATUL Architecture #3: Bridging OT and IT: Delivering Mission-Critical Grid Data to SAP BTP Safely, S

2026-06-08T10:52:29.828000+02:00

ATUL Architecture #3: Bridging OT and IT: Delivering Mission-Critical Grid Data to SAP BTP Safely, Scalably, and Cleanly

1. Introduction

Utilities are accelerating their digital transformation, but one architectural frontier remains notoriously difficult to conquer:

How do you safely ingest high-frequency Operational Technology (OT) data from substations, feeders, and Intelligent Electronic Devices (IEDs) into SAP Business Technology Platform (BTP) without introducing cyber vulnerabilities or disrupting grid reliability?

Legacy architecture often relied on brittle, custom-coded point-to-point connections or heavy middleware that violated basic security isolation principles. This article provides a comprehensive, production-ready, architecture-driven blueprint for securely integrating:

IEC 61850 substation telemetry (GOOSE/MMS)
MQTT/Sparkplug B telemetry streams
SCADA / RTU / IED asynchronous events
Grid-edge IoT sensors

We will achieve this by leverage modern event-driven architectures (EDA), Zero-Trust Network Access (ZTNA), and SAP Clean Core design patterns.

2. Why OT-to-IT Integration Challenges Enterprise

Bridging the physical grid and the digital cloud requires reconciling two fundamentally opposing engineering philosophies:

Dimension	Operational Technology (OT)	Enterprise Information Technology (IT)
Primary Priority	Availability & Safety: Human life and grid stability. Zero downtime tolerated.	Confidentiality & Integrity: Data security, compliance, and financial accuracy.
Protocols	Industrial, low-overhead, non-IP, or deterministic (IEC 61850, DNP3, Modbus).	Web-native, human-readable, RESTful (HTTPS, OData, gRPC).
Network Philosophy	Air-gapped, strictly segmented (Purdue Model Level 0-3), highly localized.	Cloud-native, perimeterless, distributed, global access.
Data Characteristics	Ultra-high frequency (milliseconds), time-series bursts, massive velocity.	Transactional, structured, stateful, request-response.

To bridge this gap safely, cloud ingestion must be completely outbound-only from the lower levels, strictly audited, cryptographically verified, and decoupled via an enterprise event broker.

3. Business impact on Utilities

This architecture is not just a technical modernization—it directly enables:

Reduced unplanned outages through real-time anomaly detection
Lower maintenance costs via predictive asset health insights
Improved regulatory compliance with secure audit-ready telemetry flows
Faster field response through automated S/4HANA work order generation
Scalable grid-edge onboarding without re-platforming legacy OT systems

4. Reference Architecture: Purdue Model to SAP BTP

The architecture below maps the telemetry flow across the classic Purdue Model for Industrial Control Systems, ensuring that no direct connection is ever established between the cloud and Level 2/3 critical infrastructure.

5. Architectural Safeguards Highlighted:

Directional Isolation: Firewalls block all inbound traffic to the Substation OT network. The Industrial Edge Gateway establishes an outbound connection to the Upper DMZ broker.
Decoupling Layer: SAP Advanced Event Mesh (AEM) acts as the shock absorber, ensuring that high-frequency grid telemetry bursts do not overwhelm downstream ERP APIs.

*Architectural Principle: Direct OT-to-cloud integrations without DMZ brokers are inherently unsafe. Any architecture that bypasses the industrial DMZ violates fundamental Purdue Model isolation and must be avoided.

6. Deep-Dive: Protocol Translation & Topic Design

The Conversion: IEC 61850 to Lightweight Cloud Events: IEC 61850 uses Manufacturing Message Specification (MMS) for complex reporting and Generic Object-Oriented Substation Events (GOOSE) for peer-to-peer microsecond trips. These cannot be parsed by cloud apps directly.

An Edge Gateway maps these complex hierarchical Logical Nodes (e.g., MMXU1 for Three-Phase Voltage/Current) into standard JSON structures wrapped in the CloudEvents specification.

Production-Grade Ingestion Payload Example

Below is the exact schema passed from the Upper DMZ to SAP Advanced Event Mesh when a transformer experiences a thermal anomaly:

JSON { "specversion": "1.0",

"id": "evt-773a-4b92-88ef-22114949ad45", "source": "/us-east/substation-s12/transformer-tx03", "type":

"com.utility.grid.telemetry.v1",

"datacontenttype": "application/json",

"time": "2026-06-01T18:21:55.003Z",

"data": { "logical_node": "YPTR1",

"component": "WindingTemperature",

"metrics": { "temperature_celsius": 98.4,

"ambient_celsius": 32.1,

"cooling_fan_status": "ON_MAX" },

"status": { "health_score": 72.5,

"anomaly_detected": true,

"severity": "WARNING" } } }

Enterprise Topic Hierarchy Best Practices

To optimize routing efficiency within SAP Advanced Event Mesh and avoid bloated subscription wildcards, we enforce a structured, predictable topic hierarchy layout:

$$\text{Domain} \,/\, \text{Business Unit} \,/\, \text{Geographic Zone} \,/\, \text{Substation ID} \,/\, \text{Asset Category} \,/\, \text{Asset ID} \,/\, \text{Event Type}$$

Examples:

grid/distribution/northeast/sub-s12/transformer/tx03/telemetry
grid/transmission/midwest/sub-s45/circuit-breaker/cb07/state

This allows BTP consumers to subscribe with surgical precision. For instance, a predictive maintenance engine can listen to all transformer telemetry across the entire Northeast region using the pattern: grid/distribution/northeast/+/transformer/+/telemetry.

7. The Blueprint in Action: A Practitioner Scenario

To understand how this architecture operates under pressure, let's trace a real-world grid event: A severe thermal anomaly on Substation Transformer TX03 located in the Northeast distribution zone.

Step 1: The Edge Trigger (Purdue Level 2)

The physical temperature sensor on Transformer TX03 detects a sudden spike, hitting $98.4^\circ\text{C}$.
The local Intelligent Electronic Device (IED) broadcasts this telemetry via an IEC 61850 MMS (Manufacturing Message Specification) reporting block over the substation's internal fiber optic bus.

Step 2: Protocol Translation & Hardening (Industrial DMZ Level 3.5)

The OT Industrial Edge Gateway (running Litmus Edge) intercepts the raw MMS packet.
It strips out the heavy industrial headers, extracts the data fields from the Logical Node YPTR1 (the standard IEC 61850 node for a power transformer), and maps them into a standardized, web-friendly JSON payload.
The gateway packages this payload inside a standardized CloudEvents v1.0 wrapper.

Step 3: Secure Egress to the DMZ Proxy (Enterprise DMZ Level 3.5)

The Edge Gateway initiates an outbound-only TLS 1.3 connection to the Upper DMZ MQTT Broker (HiveMQ Cluster).
It passes hardware-secured mTLS client certificates to prove its identity and publishes the message to the strict, isolated topic:

“grid/distribution/northeast/sub-s12/transformer/tx03/telemetry”

Step 4: Ingestion by SAP Advanced Event Mesh (SAP BTP Layer)

The HiveMQ cluster securely routes the incoming stream over a secure WebSocket connection into SAP Advanced Event Mesh (AEM) via Dynamic Message Routing (DMR).
Because AEM natively understands the hierarchical topic layout, it instantly clones and routes the message to three concurrent, decoupled subscribers without any database lag:

SAP Datasphere Ingestion Queue: For long-term historical time-series storage and grid analytics.
SAP AI Core Engine: To recalculate the transformer's Remaining Useful Life (RUL) score.
CAP Event Processor Queue: Dedicated to immediate, critical rule evaluation.

Step 5: Real-Time Orchestration & Clean Core Action

A lightweight SAP CAP (Cloud Application Model) microservice consumes the message from its dedicated AEM queue.
The service executes an automated rule: If temperature_celsius > $95^\circ\text{C}$ and cooling_fan_status == "ON_MAX", trigger emergency field intervention.
Rather than writing complex custom ABAP tables inside the ERP, the CAP service uses the standard SAP Integration Suite to call the out-of-the-box S/4HANA OData v4 API (API_EQUIPMENT_SRV).
The Result: An automated Urgent Corrective Maintenance Work Order is instantly generated in SAP S/4HANA Asset Management with a high-priority dispatch flag—all accomplished within 2.3 seconds of the physical temperature spike, leaving the digital core clean, secure, and upgrade-ready.

8. Advanced Substation-to-BTP Integration Patterns

*Reality Check*: Batch ingestion architectures are fundamentally incompatible with modern grid telemetry. Millisecond-level data streams require real-time, event-driven processing models—not delayed batch pipelines.

Depending on your edge compute availability and governance requirements, choose one of these production deployment topologies:

Pattern A: Multi-Tiered Message Broker Architecture (Recommended for Zero-Trust)

Mechanism: An Edge Gateway pushes local data to an on-premises DMZ MQTT cluster (e.g., Hive MQ). Secure bridge configuration clones and forwards permitted topics out to SAP Advanced Event Mesh (AEM) via cloud connectors or secure WebSocket’s.
Pros: Strict isolation; if the cloud connection drops, the local DMZ broker caches events, mitigating data loss.

Pattern B: Intelligent Edge Compute with Stream Processing (Recommended for High Frequency)

Mechanism: Deploy an industrial edge compute node (running lightweight runtimes like Node-RED or KubeEdge) physically inside the substation. It aggregates millisecond telemetry, calculates rolling 1-minute means/standard deviations, and publishes only summarized statistical health events to SAP BTP.
Pros: Radically reduces egress data costs and avoids overwhelming BTP with trivial data points.

9. Security & Governance Blueprint (Non-Negotiable Controls)

Bringing OT data to the cloud is impossible without an airtight security architecture. Implement the following parameters at each layer:

Mutual TLS (mTLS) with Hardware Roots of Trust: Every edge gateway must authenticate against the DMZ broker using X.509 client certificates issued by an internal Utility Certificate Authority (CA). Private keys must be stored in secure TPM 2.0 hardware chips on the edge device.
Granular Access Control Lists (ACLs): Edge gateways must be explicitly barred from publishing to topics outside their assigned asset scope. A compromise of Substation A must never allow injection of malicious events into Substation B.
Schema Validation at the Ingress Gate: Use the Schema Validation features in SAP Advanced Event Mesh. If a message arrives containing bad structures, malformed types, or executable code payloads, it is immediately shunted to a Dead Letter Queue (DLQ) for forensics, blocking code injection vectors.
Network Partitioning & Backpressure Controls: If the connection between the utility DMZ and SAP BTP degrades, the DMZ broker must utilize Local Storage Buffering. High QoS (Quality of Service) 1 or 2 settings must be applied strictly to critical operational state changes (e.g., breaker trips) to guarantee delivery, while standard continuous metrics use QoS 0 to save bandwidth.

10. Realizing Enterprise Value in SAP BTP

Once normalized grid events stream cleanly into SAP Advanced Event Mesh, they become actionable assets without touching the digital core directly:

*Strategic Insight*: Event Mesh is not optional—it is the control plane for grid-scale ingestion. Without event-driven decoupling, high-frequency OT telemetry cannot be safely or scalable integrated into enterprise systems.

The Event Consumer Microservices Layer

Deploy lightweight, stateless microservices within the SAP BTP Kyma Runtime or SAP Cloud Application Model (CAP) to process incoming streams:

Real-Time Grid Insights: Kyma functions scan the event properties. If a transformer temperature exceeds defined thresholds (temperature_celsius > 95), an immediate event is triggered.
AI-Driven Asset Health Optimization: Data streams scale out directly into SAP Datasphere and SAP AI Core. Machine Learning models calculate remaining useful life (RUL) metrics based on historical load/thermal characteristics, sending updated health indices back to operational dashboards.

The Clean Core Imperative

By processing events asynchronously in BTP, the core enterprise system (SAP S/4HANA / IS-U) remains entirely untouched by heavy custom code. S/4HANA only participates when action is required—such as creating an asset maintenance order or executing a field service dispatch via standard standard OData v4 APIs. The system updates and upgrades effortlessly, unencumbered by massive custom databases full of RAW time-series data.

11. End-to-End Flow: Transformer Overheating Scenario

A transformer in Substation S12 exceeds thermal threshold (98.4°C).
IEC 61850 MMS reports are captured by Edge Gateway.
Gateway converts payload to Cloud Events JSON.
Event is securely published (mTLS) to DMZ MQTT broker.
Broker forwards allowed topics to SAP Advanced Event Mesh.
AEM routes the event to a CAP microservice.
CAP evaluates rules → triggers anomaly event.
SAP AI Core enriches with predictive health score.
SAP S/4HANA automatically creates a maintenance work order.
Field service team is dispatched proactively.

12. Operational Summary Blueprint

The convergence of OT and IT is no longer optional—it is foundational to modern utilities.
However, success depends not on connectivity alone, but on *how* that connectivity is governed.
Architectures that prioritize strict isolation, event-driven decoupling, and Clean Core principles will define the next generation of grid intelligence.
SAP BTP, when used correctly, becomes not just an integration platform—but the control tower for real-time, autonomous utility operations.

CAP Now Supports ReactJS - With working demo + UI5 Web components

2026-06-09T10:01:53.932000+02:00

Based on the latest CAP update in the official docs, React and VueJS are now fully supported as frontend options. I tested the setup end‑to‑end based on the official docs link and prepared a working demo in BTP Trial.

Reference links:

Anyhow, to start with, the blog shall include:

Creating Bookshop CAP and adding React app
Installing UI5 Web for React dependencies
Local testing
Setting up IAS and HANA deployment

Pre requisites:

@SAP/cds-dk library should be at least 9^ or latest version.
CAP version should be latest
Your BTP Subaccount is subscribed to SAP HANA Cloud with instance
Your BTP Subaccount is subscribed to CIS and Application Frontend Service with instances

To ensure latest CAP version, use BAS

1. Create Bookshop CAP and adding React app

Log-in to your BAS or VS-code
Open the terminal and enter the command to initiate CAP sample project

initiate adding react application using this command cds add react --into <your-react-app>

2. Installing UI5 Web Components for React dependencies

Open the terminal, go to your app folder
As per the official doc, enter the following commands:

Utilize UI5 elements. (See my example below):

App.jsx

import { Bar, Card, Label, Page, Table, TableCell, TableHeaderCell, TableHeaderRow, TableRow, Title } from '@ui5/webcomponents-react'
import { useEffect, useState } from 'react'

export default function App() {
  const [books, setBooks] = useState([])

  useEffect(() => {
    fetch('/odata/v4/catalog/Books')
      .then(r => r.json())
      .then(r => setBooks(r.value))
  }, [])

  return (
    <>
      <Page backgroundDesign='Solid'
        header={<Bar design='Header'>
           <Title>Books</Title>
        </Bar>}
        style={{ width: '100vw', height: '100vh' }}
      >
        <Card style={{ width: '150px', height: '150px', marginBottom: '3rem', position: 'relative', marginTop: '3rem' }}>
          <Label style={{ padding: '1rem'}}>Total Book count:</Label>
            
            <Title size='H1' style={{ padding: '1rem', position: 'absolute', bottom: '1%', textAlign: 'right' }}>{books.length}</Title>
        </Card>
        <Table headerRow={<TableHeaderRow sticky>
                            <TableHeaderCell>Title</TableHeaderCell>
                            <TableHeaderCell>Author</TableHeaderCell>
                          </TableHeaderRow>}>
           {books.map(b=>(
            <TableRow key={b.ID}>
             <TableCell key={b.ID}>
               <span>{b.title}</span>
             </TableCell>
             <TableCell>
                <span><i> by {b.author}</i></span>
             </TableCell>
            </TableRow>
           ))}
        </Table>
      </Page>
    </>
  )
}

3. Local Testing

Run the app (cds watch)

4. Setting up IAS and HANA Deployment

As per official document, you just need the following commands for deployment

cds add app-frontend
cds add ias or cds add xsuaa
cds add hana
cds up

cds up will automatically create the .mta file and deploy the CAP, React App, IAS and HANA deployer instances

Conclusion:

With all these pieces in place, you now have a full CAP + React setup running end‑to‑end, from local development to IAS authentication and HANA deployment. This approach gives you the flexibility of a modern frontend while still taking advantage of CAP’s service layer, security model, and deployment tooling. Feel free to extend the sample, plug in your own UI components, or adapt the structure for your next project.

Let me know if you have any further questions or wish to communicate, just comment below.

Calling the SAP Business Partner API from Kyma without Serverless

2026-06-10T22:01:00.221000+02:00

Introduction

My previous post walked through calling the SAP Business Partner API from a Kyma Serverless Function. This post covers what happens when that approach hits real-world constraints — and how to adapt.

The two problems I encountered on a managed Kyma cluster:

The Serverless module wasn't installed — kind: Function doesn't exist as a resource type, so the function YAML simply won't apply
No permission to create BTP Destinations via the cockpit — the New Destination button was greyed out

Both are common in corporate and training environments where you don't own the cluster or subaccount. Here's how to work around both.

By the end you'll have the same result as the original post — a live endpoint returning SAP Business Partner JSON — but deployed as a standard Kubernetes Deployment instead of a Kyma Function.

What Changed vs the Original Approach

Original This Post

`kind: Function` (Kyma Serverless)	`kind: Deployment` (standard Kubernetes)
Code inline in YAML	Code in a Docker container
No registry needed	Image pushed to GitHub Container Registry
Destination created in BTP cockpit	Destination created via Destination Service REST API

Prerequisites

kubectl configured against a Kyma cluster
Docker installed locally
A GitHub account (for the container registry)
An account on api.sap.com with an API key

Step 1: Check What's Actually Available

Before spending time on a Kyma Function approach, verify whether Serverless is installed:

kubectl api-resources | grep serverless

If nothing is returned, the Serverless module isn't enabled. You'll need either cluster admin access to enable it, or the approach in this post.

Also verify the BTP Service Operator is available (needed for ServiceInstance and ServiceBinding):

kubectl api-resources | grep services.cloud.sap.com

You should see serviceinstances and servicebindings. If these are missing, stop here — the BTP Service Operator isn't installed and none of this will work.

Step 2: Create the Destination Service Instance and Binding

This is identical to the original post. Apply these to your namespace:

k8s/destination-instance.yaml

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

k8s/destination-binding.yaml

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

kubectl apply -f k8s/destination-instance.yaml
kubectl apply -f k8s/destination-binding.yaml

Wait until both show Ready: True:

kubectl get serviceinstance,servicebinding -n dev-space-neil

Step 3: Create the BTP Destination via REST API

Get a token and POST the destination:

TOKEN=$(kubectl get secret destination-service-binding -n dev-space-neil \
  -o jsonpath='{.data.clientid}' | base64 -d)
SECRET=$(kubectl get secret destination-service-binding -n dev-space-neil \
  -o jsonpath='{.data.clientsecret}' | base64 -d)
XSUAA=$(kubectl get secret destination-service-binding -n dev-space-neil \
  -o jsonpath='{.data.url}' | base64 -d)
URI=$(kubectl get secret destination-service-binding -n dev-space-neil \
  -o jsonpath='{.data.uri}' | base64 -d)

ACCESS_TOKEN=$(curl -s -X POST "$XSUAA/oauth/token" \
  -u "$TOKEN:$SECRET" \
  -d "grant_type=client_credentials" \
  | python3 -c "import sys,json; print(json.load(sys.stdin)['access_token'])")

curl -X POST "$URI/destination-configuration/v1/instanceDestinations" \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "Name": "S4H_SANDBOX_BP",
    "Type": "HTTP",
    "URL": "https://sandbox.api.sap.com/s4hanacloud/sap/opu/odata/sap/API_BUSINESS_PARTNER",
    "Authentication": "NoAuthentication",
    "ProxyType": "Internet",
    "APIKey": "<your-api.sap.com-key>"
  }'

Step 4: Write the Handler and HTTP Server

handler.js

const https = require("https");
const http = require("http");
const zlib = require("zlib");

/**
 * Gets an OAuth2 access token from XSUAA using client credentials flow.
 * Credentials are injected as env vars from the destination-service-binding secret.
 */
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`);

  return new Promise((resolve, reject) => {
    const options = {
      hostname: tokenUrl.hostname,
      path: `${tokenUrl.pathname}?grant_type=client_credentials`,
      method: "POST",
      headers: {
        Authorization: `Basic ${credentials}`,        // Base64-encoded clientid:clientsecret
        "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(`Token parse failed: ${data}`)); }
      });
    });
    req.on("error", reject);
    req.end();
  });
}

/**
 * Resolves a named BTP Destination via the Destination Service REST API.
 * Returns the full destination object including destinationConfiguration,
 * which contains the target URL and any additional properties (e.g. APIKey).
 */
async function getDestination(name, token) {
  const destUrl = new URL(
    `${process.env.DESTINATION_URI}/destination-configuration/v1/destinations/${name}`
  );
  return new Promise((resolve, reject) => {
    const options = {
      hostname: destUrl.hostname,
      path: destUrl.pathname,
      method: "GET",
      headers: { Authorization: `Bearer ${token}` },  // Token obtained from getDestinationToken()
    };
    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(`Destination parse failed: ${data}`)); }
      });
    });
    req.on("error", reject);
    req.end();
  });
}

/**
 * Calls the SAP Business Partner API via the resolved destination.
 * The SAP API Hub sandbox always returns gzip-compressed responses,
 * so we explicitly handle gzip/deflate decompression via Node's zlib module.
 */
async function fetchBusinessPartners(destination) {
  const config = destination.destinationConfiguration;
  const targetUrl = new URL(`${config.URL}/A_BusinessPartner?$format=json&$top=20`);
  // Use http or https depending on the destination URL scheme
  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: config.APIKey,   // API key stored as a destination property, not a separate secret
        Accept: "application/json",
      },
    };
    const req = protocol.request(options, (res) => {
      const chunks = [];
      const encoding = res.headers["content-encoding"];
      // Pipe through the appropriate decompressor based on Content-Encoding header
      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();
  });
}

/**
 * Main entry point — orchestrates the full call chain:
 * 1. Get XSUAA token
 * 2. Resolve the S4H_SANDBOX_BP destination
 * 3. Fetch Business Partners from the SAP API sandbox
 * Returns a response object compatible with both Kyma Functions and the HTTP server wrapper.
 */
module.exports = {
  main: async function (event, context) {
    try {
      const token = await getDestinationToken();
      const destination = await getDestination("S4H_SANDBOX_BP", 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 },
      };
    }
  },
};

Since this is a container rather than a Kyma Function, we need a simple HTTP server to drive it. server.js wraps the handler:

server.js

const http = require("http");
const handler = require("./handler");

const PORT = process.env.PORT || 8080;  // Default to 8080; override via env var if needed

/**
 * Minimal HTTP server that wraps handler.js for container deployment.
 * Kyma Functions have their own runtime that calls handler.main() directly —
 * this server provides the equivalent entry point when running as a standard Deployment.
 * Every request regardless of path/method triggers the Business Partner fetch.
 */
const server = http.createServer(async (req, res) => {
  try {
    const result = await handler.main({}, {});
    // handler.main() may return body as object or string — normalise to string
    const body = typeof result.body === "string"
      ? result.body
      : JSON.stringify(result.body);
    res.writeHead(result.statusCode || 200, {
      "Content-Type": "application/json",
      ...result.headers,
    });
    res.end(body);
  } catch (err) {
    res.writeHead(500, { "Content-Type": "application/json" });
    res.end(JSON.stringify({ error: err.message }));
  }
});

server.listen(PORT, () => console.log(`Listening on port ${PORT}`));

Step 5: Build and Push a Multi-Platform Container Image

This step doesn't exist in the original Kyma Function approach — the serverless runtime handles that for you. Here you need to build a Docker image and push it to a registry the cluster can reach.

Dockerfile

FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm install --omit=dev
COPY handler.js server.js ./
EXPOSE 8080
CMD ["node", "server.js"]

# Authenticate with GitHub Container Registry
echo $(gh auth token) | docker login ghcr.io -u <your-github-username> --password-stdin

# Build and push for both platforms
docker buildx build \
  --platform linux/amd64,linux/arm64 \
  -t ghcr.io/<your-github-username>/bp-function:latest \
  --push .

Make the package public in GitHub (your profile → Packages → bp-function → Package settings → Change visibility → Public) so the cluster can pull it without credentials.

Step 6: Deploy to Kyma

k8s/deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: bp-function
  namespace: dev-space-neil
  labels:
    app: bp-function
spec:
  replicas: 1
  selector:
    matchLabels:
      app: bp-function
  template:
    metadata:
      labels:
        app: bp-function
    spec:
      containers:
        - name: bp-function
          image: ghcr.io/<your-github-username>/bp-function:latest
          ports:
            - containerPort: 8080
          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
          resources:
            requests:
              cpu: 50m
              memory: 64Mi
            limits:
              cpu: 100m
              memory: 128Mi
---
apiVersion: v1
kind: Service
metadata:
  name: bp-function
  namespace: dev-space-neil
spec:
  selector:
    app: bp-function
  ports:
    - port: 80
      targetPort: 8080

k8s/apirule.yaml

Use the full cluster domain rather than a short hostname. Find yours with:

kubectl get configmap shoot-info -n kube-system -o jsonpath='{.data.domain}'

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

Apply both:

kubectl apply -f k8s/deployment.yaml
kubectl apply -f k8s/apirule.yaml

Check the pod is running:

kubectl get pods -n dev-space-neil -l app=bp-function

Step 7: Test

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

You should see Business Partner records:

{
  "d": {
    "results": [
      {
        "BusinessPartner": "11",
        "BusinessPartnerFullName": "Cust15 Cust15",
        ...
      }
    ]
  }
}

How It Works

The call chain is the same as the original Kyma Function approach:

Internet -> APIRule (Istio) -> Service -> Pod
  -> XSUAA (get OAuth token)
  -> Destination Service (resolve S4H_SANDBOX_BP)
  -> SAP API Hub sandbox (fetch Business Partners)
  -> JSON response

Key Points

ATUL Architecture #4 — AI on SAP BTP for Grid Operations

2026-06-17T11:21:39.612000+02:00

ATUL Architecture #4 — AI on SAP BTP for Grid Operations

How AI Becomes Actionable Inside SAP Processes

1. Introduction

Utilities generate massive volumes of operational data every second—from SCADA systems, AMI networks, intelligent electronic devices (IEDs), weather feeds, and grid sensors. While collecting data is no longer the challenge, transforming that data into actionable operational decisions remains difficult. Most AI initiatives stop at dashboards and predictions. However, real business value is realized only when AI insights automatically trigger operational processes inside SAP.

In this architecture, I demonstrate how SAP BTP combines time-series data, machine learning, event-driven integration, and SAP S/4HANA workflows to create a closed-loop operational model where AI does not simply predict problems—it initiates action.

The goal is simple: AI should not just predict. AI should trigger work.

Most utilities already have advanced analytics and dashboards. The real challenge is operationalizing AI—moving from insight to action.
This architecture demonstrates how SAP BTP closes that gap by embedding AI directly into operational workflows, ensuring that predictions automatically trigger governed actions inside SAP S/4HANA.

2. Foundation: Timeseries + AI on BTP

Time‑Series Data Foundation: Grid operations run on time‑series data. Typical examples include:

Transformer temperature curves
Voltage fluctuations
Feeder imbalance
Breaker operation frequency
Meter communication patterns
Weather impact signals

SAP BTP provides two strong foundations for this:

SAP HANA Cloud — native time‑series functions, fast analytics
SAP Datasphere — semantic modeling + integration

Most utilities already have this data in SCADA, OMS, or AMI systems. The architecture standardizes and contextualizes this data within SAP BTP, ensuring it is immediately consumable by AI models and downstream processes.

Anomaly Detection on BTP

Once time‑series data is available, the next step is anomaly detection. Common utility scenarios:

Sudden voltage drop on a feeder
Transformer overheating pattern
Meter not reporting for 48 hours
Repeated breaker operations
Unusual load spike

SAP AI Core + AI Launchpad support models such as:

LSTM‑based anomaly detection
Isolation Forest
Autoencoders
Threshold‑based rules for simple cases

The output is always the same: “Something looks wrong here.” But anomaly detection alone does not help operations. The value comes when the anomaly creates an action. In grid operations, the value of anomaly detection lies not in identifying every deviation, but in identifying actionable deviations—those that require operational response within defined time windows.

3. Predictive Maintenance for Grid Assets

Predictive maintenance models help utilities answer:

When will this transformer fail
Which feeder is at highest risk next week
Which assets need inspection before summer load

SAP BTP supports this through:

AI Core for model training
HANA Cloud for feature engineering
Event Mesh for event‑driven triggers
SAP Build Process Automation for workflows

The model output becomes a risk score or failure probability. But prediction alone is not enough. It must flow into SAP S/4HANA. From a business perspective, predictive maintenance shifts operations from reactive repair to risk-based intervention, allowing utilities to prioritize maintenance budgets toward high-impact assets and reduce unplanned outage exposure.

4. AI Workflow S/4HANA Integration (The "Gatekeeper" Layer)

This is where the architecture ensures both speed and safety. AI becomes valuable only when it creates work, but critical infrastructure requires accountability.

Integrating Manual Approvals: Before the automated creation of a work order in S/4HANA, insert an Approval Step within SAP Build Process Automation.

This “gatekeeper layer” is essential in regulated industries. Fully autonomous AI decisions are rarely acceptable in utility operations. By inserting human approval only when risk thresholds are exceeded, the architecture balances automation with control. This ensures safety, regulatory compliance, and operator trust, while still preserving the speed advantages of AI-driven decisioning.

The Pattern: When the AI model reaches a "low-confidence" threshold or identifies a high-risk asset, the workflow automatically pauses.
The Interface: A task is pushed to the supervisor's SAP Build Inbox, displaying the AI’s risk score, supporting technical data, and a "Approve/Reject" button.
The Result: The S/4HANA work order is only generated after human verification, ensuring that the system is an "AI-assisted" tool rather than a fully autonomous one.
AI → Workflow → S/4HANA Integration

This is the most important part of architecture. AI becomes valuable only when it creates work.

Example Flow

AI model detects transformer overheating
Event Mesh publishes an event
SAP Build Process Automation starts a workflow
Workflow checks asset master data in S/4HANA
A maintenance notification or work order is created
Field technician receives the job in SAP FSM or mobile app

This is where utilities see real impact:

Faster response
Fewer outages
Better asset life
Lower O&M cost

AI is not a dashboard. AI is a trigger.

5. Real Utility Scenarios

Scenario 1 — Feeder Overload Prediction

AI predicts overload 48 hours ahead
Workflow creates a load‑balancing task
S/4HANA logs the action for audit

Scenario 2 — Transformer Failure Risk

Model detects abnormal temperature pattern
Work order created automatically
Technician dispatched before failure

Scenario 3 — Meter Communication Failure

AI detects repeated non‑reporting meters
Workflow assigns investigation to AMI team
S/4HANA tracks resolution

These are simple, but they save real money. Across utilities, such scenarios have the potential to significantly reduce mean time to detection (MTTD), minimize outage duration, and improve asset utilization efficiency.

6. Architecture View 1: AI‑Triggered Transformer Overheating Workflow (End‑to‑End)

Flow Explanation

SCADA / IoT Gateway Streams transformer temperature every 5 seconds.
SAP BTP – HANA Cloud Stores timeseries + applies smoothing, rolling averages, and feature extraction.
SAP AI Core LSTM model detects abnormal temperature rise → generates anomaly score.
SAP Event Mesh Publishes event: transformer->overheat->detected.
SAP Build Process Automation
- Reads asset master from S/4
- Apply business rules (risk threshold, asset criticality)
- Sends approval task to supervisor
SAP S/4HANA PM
- Creates Maintenance Notification
- Converts to Work Order after approval
SAP Field Service Management Dispatches technician with asset details + AI explanation.

7. Architecture View 2: AMI Meter Non‑Reporting Investigation Workflow

Meter Communication Failure Flow — A simple but high‑value scenario.

Flow Explanation

AMI Headend System Detects meter not reporting for 48 hours.
SAP BTP – Datasphere Harmonizes meter metadata, location, customer info.
SAP AI Core Isolation Forest model identifies “communication anomaly cluster.”
SAP Event Mesh Publishes event: meter->communication->anomaly.
SAP Build Process Automation
Checks if meter is in outage area
Checks last service history
Assigns task to AMI Ops Team
SAP S/4HANA Customer Service / PM Creates service order or investigation ticket.
Technician Mobile App Receives job with meter location + AI reasoning.

8. Ground‑Reality Example: “The Black Friday Surge Event”

Black Friday‑style load spikes happen in utilities too — sudden, unpredictable, and dangerous. Here’s the short version you can paste into your paper:

“During a sudden pre‑holiday cold‑weather surge, Feeder F‑19’s load jumped 14% in under 3 minutes. SAP HANA Cloud flagged the abnormal ramp, SAP AI Core predicted an overload within 45 minutes, and Event Mesh triggered an automated workflow. A supervisor approved a pre‑emptive load transfer, and S/4HANA executed the switching plan. The feeder stabilized within 20 minutes — preventing an outage during peak demand.”

9. Key Architectural Principles

Point 1 “AI runs on BTP, close to SAP data" or AI Proximity to SAP Data Matters

Right now, it just says "No complex integration." That's a feature, not an insight. What you should explain is why proximity matters architecturally — when AI models live in the same platform as your master data, you eliminate the ETL lag, data translation errors, and security surface area that come with external AI platforms. The practical implication: your anomaly detection is working on the same asset hierarchy that S/4HANA uses to create work orders, so there's no mismatch between "what the AI saw" and "what the technician gets dispatched to fix." That's a real architectural win worth spelling out.

Point 2 “Event-Driven Architecture Reduces Operational Latency"

"AI triggers work instantly" is too vague. The deeper idea here is about operational latency — in grid operations, the window between early warning and failure can be hours or even minutes. A polling-based batch integration would miss that window entirely. Event Mesh ensures the moment AI flags an anomaly; the downstream workflow fires. You could contrast this with the old model: AI generates a report overnight, an analyst reviews it in the morning, creates a ticket manually — by which time the transformer has already tripped. Event-driven isn't just faster; it changes the category of what's possible.

Point 3 "S/4HANA becomes the system of action"

The current line misses the real point, which is about organizational trust and auditability. Utilities are regulated industries. Work orders, notifications, and approvals don't just need to happen — they need to be traceable, auditable, and defensible to regulators and internal compliance teams. Because S/4HANA is already the system of record for asset management and maintenance, routing AI-triggered actions through it means you don't need a parallel tracking system. The AI's recommendation and the resulting field action live in the same audit trail. That's not a convenience — it's a compliance requirement for most utilities.

Point 4 “Measurable Business Outcomes Define Success"

"Fewer outages, faster response, better asset health" reads like a brochure. The improvement here is to be specific about how you'd measure these. For example: reduction in mean time to detect (MTTD) on grid anomalies, reduction in unplanned outage minutes per feeder, or improvement in asset utilization rates as preventive maintenance replaces reactive repair. Even if you don't have exact numbers, framing the metrics gives readers a way to build a business case internally — which is often exactly what a utility architect needs when presenting this to leadership.

10. Governance Considerations

AI model versioning and monitoring using SAP AI Core
Data lineage and semantic consistency via Datasphere
Secure integration through SAP BTP service layer
Role-based access for approval workflows

These elements ensure that AI-driven automation remains compliant, auditable, and enterprise-ready.

11. Final Thoughts

AI for grid operations is not about fancy models. It’s about connecting predictions to SAP processes.

Time‑series data → AI model → Event → Workflow → S/4HANA action.

The future of utility operations is not autonomous AI replacing operators. It is AI-driven workflows that help operators act earlier, with better information, inside trusted SAP business processes. When predictions automatically become notifications, approvals, work orders, and field actions, SAP BTP becomes the operational backbone of grid modernization.

12. Practical Architecture Example: “The 3 AM Save”

Step‑by‑Step Flow (Real Utility Reality)

2:58 AM — SCADA temperature spike Transformer T‑221 shows a sudden 9°C rise in 4 minutes.
3:00 AM — SAP HANA Cloud detects abnormal curve Rolling window + derivative features show a deviation from normal nighttime cooling.
3:01 AM — SAP AI Core LSTM flags anomaly Risk score jumps from 0.18 → 0.74. Not a failure yet — but trending toward one.
3:01:10 AM — SAP Event Mesh publishes event grid->transformer->overheat->predicted.
3:01:12 AM — SAP Build Process Automation starts workflow

Pulls asset master from S/4
Checks transformer age (17 years)
Checks last maintenance (14 months ago)
Checks load forecast (high morning peak expected)

3:01:30 AM — Supervisor approval triggered A mobile notification appears: “AI predicts overheating in 3–5 hours. Approve pre‑failure inspection?”
3:03 AM — Supervisor taps “Approve” (This is the human‑in‑the‑loop safety layer.)
3:03:10 AM — SAP S/4HANA creates work order Priority: High Task: Inspect cooling fins + oil level + load tap changer
3:20 AM — Field technician receives job on mobile Drives to site before failure window.
4:05 AM — Technician finds blocked cooling fins Dust + debris + vegetation restricting airflow.
4:40 AM — Issue cleared, temperature stabilizes Transformer returns to normal operating range.
Failure avoided. Outage avoided. $40k avoided. And the entire chain is auditable inside S/4HANA.

What Example Proves (The Architectural Insight)

This single incident captures the entire purpose of architecture. The utility didn’t just detect a problem — it prevented failure because AI, events, workflows, and S/4HANA acted as one system. The model didn’t need to be perfect; it only needed to be early. Event Mesh eliminated latency. Build Process Automation added human judgment. S/4HANA ensured the action was auditable and compliant. And the field technician received the job before the asset crossed the failure threshold.

This is the difference between “AI that predicts” and AI that protects the grid.

ATUL Architecture #5 — Designing a Utility Data Fabric on SAP BTP

2026-07-03T17:50:48.910000+02:00

ATUL Architecture #5 — Designing a Utility Data Fabric on SAP BTP

How Utilities Build a Unified, Governed, Real‑Time Data Layer for Grid + Customer Operations

1. Introduction

For SAP-centric utilities, the challenge is no longer simply managing growing volumes of data. Utilities have invested heavily in SAP IS-U, SAP S/4HANA, AMI platforms, SCADA systems, GIS applications, outage management solutions, and a growing ecosystem of grid technologies. Yet much of this information remains trapped within operational silos, making it difficult to create a unified view of grid and customer operations.

The real problem is no longer collecting data, but connecting, governing, and using it across the enterprise.

As utilities navigate the rise of distributed energy resources (DERs), electric vehicles (EVs), advanced metering infrastructure (AMI), and increasingly dynamic grid operations, traditional batch-oriented architectures struggle to keep pace. The grid is becoming real time, but the data architecture often remains fragmented.

A Business Data Fabric built on SAP Datasphere and SAP HANA Cloud provides a modern architectural approach for unifying SAP and non-SAP data without discarding existing investments. By combining data integration, semantic modeling, governance, and real-time access capabilities, utilities can create a trusted enterprise data layer that supports analytics, AI, operational intelligence, and regulatory reporting from a common foundation.

This is where Utility Data Fabric becomes essential—and where SAP BTP provides the platform to make it practical.

Most utilities still operate with:

Siloed operational systems
Fragmented data marts
Batch‑driven ETL pipelines
Inconsistent semantic definitions
Limited real‑time visibility

This creates a fundamental gap: The grid is real‑time, but the data architecture is not.

This is where Utility Data Fabric becomes essential — and SAP BTP provides the platform to build it.

2. A Utility Data Fabric in Action: Transformer Outage Scenario

To understand how Utility Data Fabric works, consider a common operational event transformer failure affecting several hundred customers.

A SCADA system detects abnormal voltage conditions and reports the event in real time. AMI smart meters simultaneously stop communicating, confirming the outage footprint. GIS identifies the affected transformer, feeder, and service territory, while the Outage Management System (OMS) creates an outage event and initiates restoration activities.

Within the Utility Data Fabric, these events are combined with asset history, maintenance records, weather conditions, and customer information to create a unified operational view. Customer notification systems can automatically communicate outage information, analytics platforms can assess business impact, and AI models can predict restoration timelines based on historical outage patterns.

This single event touches nearly every layer of the Data Fabric—from data ingestion and semantic modeling to governance, analytics, and AI-driven decision support.

3. What Utility Data Fabric Actually Means

Data Fabric is not a single product. It is an architectural approach that unifies:

Data ingestion
Data storage
Semantic modeling
Governance
Access control
Analytics
AI/ML consumption

Across all utility domains:

Grid operations
Customer operations
Metering
Billing
Asset management
Field operations
Regulatory reporting

In simple terms: A Data Fabric makes data findable, usable, trusted, and real‑time — across the entire utility.

SAP BTP provides the building blocks to make this practical.

4. The Core Components of a Utility Data Fabric on SAP BTP

Data Lake Layer

This is the foundation. SAP HANA Cloud provides the underlying multi-model data platform for storing and processing enterprise data, while SAP Datasphere delivers the semantic, integration, and governance capabilities that form the Business Data Fabric layer. A key principle of SAP's Business Data Fabric approach is that not all data must be physically moved into a central repository. SAP Datasphere supports both replication and federation techniques, allowing utilities to access and combine data across SAP and non-SAP systems while minimizing unnecessary data duplication. This approach helps reduce integration costs, improve data freshness, and preserve investments in existing operational platforms. For large historical datasets such as AMI interval reads and telemetry archives, SAP HANA Cloud Data Lake can provide lower-cost storage while maintaining integration with Datasphere and HANA Cloud analytics services. In the transformer outage scenario, telemetry from SCADA, outage events from OMS, AMI meter status, GIS network topology, and customer information are ingested and made available through the Data Fabric for unified analysis

The Data Fabric approach allows utilities to federate data across hybrid landscapes—keeping legacy data in on-premises systems while virtualizing access in the cloud—reducing the latency and cost of moving massive, static datasets.

Utilities ingest:

AMI meter events

SCADA/IoT streams
DER telemetry
Weather + Wildfire Risk Data
Customer interactions
Billing determinants
Asset health and maintenance history
Outage management events (OMS)

For utilities, geospatial information is as important as transactional data. Modern Data Fabrics must integrate GIS systems, network topology models, feeder maps, outage polygons, vegetation management zones, and wildfire risk areas. By combining spatial context with customer, asset, and operational data, utilities can perform advanced use cases such as outage impact analysis, restoration prioritization, vegetation risk assessment, DER hosting capacity planning, and climate resilience modeling. SAP Datasphere can combine this geospatial context with operational and customer data to create business-ready models for planning, analytics, and AI use cases.

The data lake must support:

High‑volume ingestion
Low‑cost storage
Real‑time streaming
Time‑series analytics
Geospatial analysis

This is where grid + customer data finally live together.

Analytical Model and Consumption Model concepts in Datasphere. In SAP Datasphere, analytical models define measures and semantics, while consumption models expose business‑ready views for analytics and AI. The goal is not to move every dataset into one database. The goal is to provide one trusted view of enterprise data regardless of where it physically resides

Semantic Models

This is the most misunderstood part of a Data Fabric.

Semantic models define:

What is a meter?
What is an outage?
What is a transformer?
What is billing determinant?
What is a customer event?

Without semantic consistency:

Analytics break
AI models fail
Reports contradict each other
Regulatory submissions become risky

A Business Data Fabric combines data integration, governance, semantic modeling, and real-time access into a single enterprise architecture without requiring all data to be physically centralized. SAP Datasphere’s Business Data Fabric capabilities allow utilities to create:

Harmonized data models
Domain‑specific views
Reusable data products
Cross‑domain relationships.

Rather than exposing raw tables or application-specific structures, utilities can publish governed data products that package data with business meaning, ownership, quality standards, and access controls. Examples include a customer 360 product, Asset Health product, Outage Operations product, DER Portfolio product, or Transformer Risk product. These reusable data products become the primary mechanism through which analytics teams, AI solutions, operational applications, and business users consume trusted enterprise data. For example, during a transformer outage, different systems may refer to the same asset using different identifiers. Semantic models help establish a consistent definition of transformers, feeders, outages, and affected customers across all participating systems.

Master Data Foundation

Semantic consistency begins with trusted master data. Utilities often maintain customer, asset, feeder, transformer, meter, and service point information across multiple systems, including SAP S/4HANA, SAP IS-U, GIS platforms, outage management systems, and third-party applications.

Utility Data Fabric must establish a consistent master data foundation so that the same business object is represented identically across the enterprise. Without master data harmonization, analytics become unreliable, AI models generate inconsistent results, and cross-domain reporting loses credibility.

By combining semantic models with governed master data, utilities create a trusted foundation for enterprise-wide analytics, operational intelligence, and regulatory reporting. SAP Master Data Governance (MDG) can further support this foundation by governing critical utility master data domains and synchronizing trust records across enterprise applications.

Governance Layer

Governance is not documentation. It is control + trust: Utilities must define

Data ownership (domain‑driven)
Data quality rules
Lineage and traceability
Access policies
Retention and compliance
Security and privacy

SAP BTP provides:

Central governance via Datasphere
Cataloging and lineage
Role‑based access
Policy enforcement
Auditability

Governance is what makes Data Fabric safe. Utility Data Fabrics must also address cybersecurity and regulatory requirements. As operational technology (OT) data from AMI, SCADA, and grid systems becomes integrated with enterprise IT platforms, utilities must enforce appropriate segmentation, access controls, auditability, and compliance requirements such as NERC CIP where applicable. During an outage investigation, data lineage and auditability help utilities understand where information originated, how it was transformed, and whether operational decisions were based on trusted data sources.

Active Metadata: The Intelligence Behind the Data Fabric

A modern Data Fabric does not operate solely on data; it also depends on metadata that describes how data is created, transformed, consumed, and governed. Active metadata captures information such as data lineage, ownership, quality scores, usage patterns, business definitions, and relationships between datasets.

Within SAP Datasphere, metadata helps utilities understand where data originated, who owns it, how it is being used, and whether it meets governance standards. As utility data landscapes continue to grow, active metadata becomes essential for automated impact analysis, policy enforcement, data discovery, and trusted AI consumption.

In many successful Data Fabric implementations, metadata acts as the operational intelligence layer that continuously monitors and improves the health of the overall data ecosystem.

Analytics for Grid + Customer

This is where Data Fabric becomes valuable. Utilities can build:

Grid Analytics

Outage prediction
Load forecasting
DER hosting capacity
Feeder‑level performance
Voltage optimization
Asset failure prediction

Customer Analytics

High‑bill alerts
Usage pattern segmentation
EV charging behavior
Payment risk scoring
Real‑time notifications
Personalized rate recommendations

Enterprise Analytics

Regulatory reporting
Operational KPIs
Financial performance
Workforce optimization

SAP Analytics Cloud + Datasphere + HANA Cloud provide a unified analytics stack.

AI Readiness Through Data Fabric

The long-term value of a Utility Data Fabric extends beyond reporting and analytics. It provides the trusted data foundation required for enterprise AI, machine learning, and autonomous decision-making. AI models perform best when they are trained and operated on governed, semantically consistent, and high-quality data.

By combining semantic models, master data harmonization, governance controls, and lineage capabilities, a Utility Data Fabric reduces the risk of inaccurate predictions, inconsistent recommendations, and model drift. This foundation becomes critical for initiatives such as outage prediction, asset failure forecasting, energy demand optimization, and intelligent customer engagement. Examples include outage prediction, transformer failure forecasting, DER optimization, and proactive customer notification models. In the transformer outage example, AI models can combine outage history, asset condition, weather data, and crew availability to improve restoration estimates and recommend remediation actions.

BTP Integration:

This architecture doesn't exist in a vacuum. It integrates directly with SAP Build Process Automation (for triggering workflows from data insights) and SAP AI Core (for deploying models trained on Datasphere data products). SAP Integration Suite plays a critical role in Data Fabric architecture by connecting SAP IS-U, SAP S/4HANA, SAP EAM, GIS systems, outage management platforms, and external data providers. Through Cloud Integration, API Management, and Event Mesh, Integration Suite enables secure, governed, and scalable movement of data across hybrid utility landscapes.

How the Data Fabric Works End‑to‑End

Step 1 — Ingest

AMI events via Event Mesh
IoT/SCADA via MQTT
Customer interactions via APIs
Asset data via S/4HANA

Traditional data architectures rely on batch-based movement of information between systems. Modern utility operations require a different approach. Smart meters, distributed energy resources, grid sensors, and customer engagement platforms continuously generate events that must be processed in near real time. SAP Event Mesh enables these events to be distributed across operational systems and data platforms, where they can be consumed by analytics, automation services, and AI models. creating a continuously updated Data Fabric rather than a periodically refreshed repository.

Step 2 — Store

Raw zone (immutable)
Refined zone (cleaned)
Curated zone (business‑ready)

Step 3 — Model

Semantic definitions
Domain views
Data products

Step 4 — Govern

Quality rules
Lineage
Access control

Step 5 — Consume

Grid operations
Customer operations
Field mobility
AI/ML models
Analytics dashboards

This is the Utility Data Fabric lifecycle. The Data Fabric helps align grid‑level latency requirements (millisecond responses for protection) with enterprise‑level latency (near real‑time analytics), ensuring the data architecture does not become a bottleneck for critical operations.

Returning to our transformer outage example, the same operational event moves through every stage of the Data Fabric lifecycle—from ingestion and storage through semantic modeling, governance, analytics, and AI-driven decision support.

5. Why Utilities Need Data Fabric Now

Because the grid is becoming real‑time: DERs, EVs, and AMI require continuous intelligence.
Because AI depends on clean, governed data: AI is useless without trusted data.
Because regulators expect transparency: Lineage, auditability, and data quality are no longer optional.
Because customer expectations have changed: Real‑time notifications, usage insights, and personalized experiences require unified data.
Because operational silos are too expensive: A Data Fabric reduces duplication, integration cost, and data chaos.

6. Data Fabric vs Traditional Utility Data Warehouse

Many utilities already operate enterprise data warehouses and may question why a Data Fabric is needed. Traditional data warehouses typically rely on periodic ETL processes that copy data into centralized repositories for reporting purposes. While effective for historical analytics, they often struggle to support real-time operational use cases, cross-domain intelligence, and AI-driven decision making.

Utility Data Fabric complements and extends the traditional warehouse by introducing semantic consistency, federated data access, active governance, reusable data products, and near real-time integration. Rather than simply storing data, the Data Fabric creates a governed and intelligent data layer that connects operational systems, analytical platforms, and AI services across the enterprise.

In simple terms, a traditional warehouse answers questions about the past, while a Data Fabric enables utilities to act on what is happening now.

Traditional Data Warehouse

Periodic ETL
Historical reporting
Centralized storage
Primarily analytics focused

Data Fabric

Real-time data access
Federation and virtualization
Semantic consistency
Data products
AI consumption
Cross-domain intelligence

7. Common Pitfalls (What Fails in Real Projects):

Pitfall: Attempting to replicate all data instead of federating it. Leverage Datasphere’s ability to virtualize data from SAP S/4HANA and external sources to reduce ETL overhead and latency.

Treating the Data Fabric as an IT project: It must be business‑owned and domain‑driven.
Overloading the data lake with unstructured noise: Raw data without governance becomes a “data swamp.”
No semantic consistency: Different teams define the same metric differently.
Ignoring real‑time ingestion: Batch pipelines cannot support modern grid operations.
Not designing data products: Data must be reusable, not one‑off.

The Architecture Principle That Matters Most

Data Fabric is not a database. It is a governed operating model for how utility data is shared, trusted, and consumed across the enterprise.

SAP BTP provides the platform. The utility provides discipline.

What Success Looks Like

A successful Utility Data Fabric delivers:

A single source of truth
Real‑time grid + customer visibility
Faster regulatory reporting
Higher data quality
Better AI outcomes
Lower integration cost
Stronger cybersecurity posture
Improved customer experience

This is the foundation for the AI‑enabled utility.

8. Executive Insight

Historically, utilities integrated applications.

The next generation utility will compete on the quality, trustworthiness, and usability of its data as much as the reliability of its physical infrastructure.

Organizations that establish trusted, governed, and reusable data products will be better positioned to deploy AI, automate operations, accelerate regulatory reporting, and improve customer experience. The competitive advantage will come not from possessing more data, but from creating a data architecture capable of turning data into operational intelligence.

9. Final Thought

Utilities don’t need more data. They need better architecture for the data they already have.

A Utility Data Fabric on SAP BTP creates:

A unified data layer
A governed semantic foundation
A real‑time operational backbone
A scalable platform for AI and analytics

In the next decade, utilities that master their data will lead. Those that don’t will struggle with reliability, cost, and customer expectations.

Next in the Series — ATUL Architecture #6

We move into the intelligence layer:

AI‑driven grid operations
Predictive models for BTP
Real‑time decision engines
Digital twins
Autonomous workflows

This is where Data Fabric becomes the brain of the modern utility.

Calling ABAP RFC Function Modules from SAP BTP Kyma with SAP Java Connector

2026-07-10T16:11:31.874000+02:00

Why I Wrote This

I recently wanted to build a small demo application that proves a simple point:

Can an application running on SAP BTP Kyma call an on-premise SAP system via RFC?

At first glance, this sounds like something that should be straightforward. SAP Java Connector exists, SAP Cloud Connector exists, Kyma has Connectivity Proxy, and SAP BTP has Destination service. Surely we just package sapjco3.jar, create a destination, and call STFC_CONNECTION, right?

Well — almost, but not quite.

While researching this, I found SAP Community questions such as “How can I connect my SAP BTP Kyma with my On-Premise system (ECC6 EHP7) via RFC”. The discussion captures the same uncertainty I ran into: Cloud Foundry examples exist, but Kyma is different because we build and run our own container images. There is no magic “built JCo” unless we explicitly bring the right runtime pieces (I was happy to see my own github repo referenced in the question - another indication that there is nothing out there for RFC and Kyma).

This blog documents the working path I ended up with.

Note: This is a proof of concept - SAP is not (yet) supporting this scenario. If that changes I will update the blog.

The Goal

The goal was intentionally small:

Run a Java application in SAP BTP Kyma.
Resolve an RFC destination from SAP BTP Destination service.
Route RFC traffic through Kyma Connectivity Proxy.
Reach an on-premise SAP S/4HANA system via SAP Cloud Connector.
Execute STFC_CONNECTION.

The successful response looked like this:

{
  "ok": true,
  "destination": "InsightSuiteDestination",
  "function": "STFC_CONNECTION",
  "jcoVersion": "3.1.13.2 (2026-04-22) for SAP Business Technology Platform",
  "exports": {
    "ECHOTEXT": "Hello from Kyma",
    "RESPTEXT": "SAP R/3 Rel. 816   Sysid: S4H ... Logon_Data: 201/RFC_TESTUSER/E"
  }
}

That was the happy end. The rest of this post is about how to get there.

High-Level Architecture

The final request flow is:

HTTP client
  -> Kyma Istio route
  -> Java/Tomcat app in Kyma
  -> SAP JCo cloud runtime
  -> SAP BTP Destination service
  -> Kyma Connectivity Proxy RFC port 20001
  -> SAP Cloud Connector
  -> on-premise SAP system RFC gateway
  -> STFC_CONNECTION

For this demo, the relevant names were:

Kyma namespace:        jco-rfc-test
RFC destination:       InsightSuiteDestination
Cloud Connector ID:    sap-insight-suite
Virtual RFC host:      s4hana-2025japan
System number:         00
SAP client:            201
RFC function:          STFC_CONNECTION

Key Lesson 1: Plain JCo Is Not Enough

My first attempt was the obvious one: package SAP JCo into a Tomcat image and run a servlet.

That was enough to start the app, but not enough to make the BTP/Kyma on-premise path work. The plain runtime did not know how to resolve BTP destinations and route RFC through the Kyma Connectivity Proxy with the required proxy authorization.

The working setup needed the SAP JCo cloud/connectivity runtime libraries that are normally provided by SAP Java Buildpack.

The important runtime ingredients were:

com.sap.conn.jco.cloud-3.1.13.2.jar
com.sap.conn.jco.cloud.rt.cloud-3.1.13.2.jar
com.sap.core.connectivity.jco-5.0.7.jar
com.sap.core.connectivity.jco.cf-5.0.7.jar
com.sap.core.connectivity.cloud.destinations.tunnel-0.9.267.jar

In my case these came from:

xs-java-buildpack-2.66.0-offline-cnb-tomcat.tgz

I used the buildpack archive as a runtime overlay and copied its Tomcat libraries into my image. If you have access to the official builder, using pack build is the cleaner path.

The Minimal Java Code

The Java code itself is pleasantly small. The servlet resolves a destination and calls a function module:

JCoDestination destination = JCoDestinationManager.getDestination("InsightSuiteDestination");
JCoFunction function = destination.getRepository().getFunction("STFC_CONNECTION");

function.getImportParameterList().setValue("REQUTEXT", "Hello from Kyma");
function.execute(destination);

String echoText = function.getExportParameterList().getString("ECHOTEXT");
String responseText = function.getExportParameterList().getString("RESPTEXT");

The demo app exposes this through an HTTP endpoint:

/rfc?destination=InsightSuiteDestination&text=Hello%20from%20Kyma

Build Setup

The app is a WAR file running on Java 17 and Tomcat 10.1.

One important detail: SAP Java Buildpack 2.x uses the Jakarta servlet stack, so the application uses jakarta.servlet.*, not javax.servlet.*.

Relevant Maven setup:

<packaging>war</packaging>

<properties>
  <maven.compiler.release>17</maven.compiler.release>
</properties>

<dependencies>
  <dependency>
    <groupId>com.sap.conn.jco</groupId>
    <artifactId>sapjco3</artifactId>
    <version>3.1.13</version>
    <scope>system</scope>
    <systemPath>${project.basedir}/lib/sapjco3.jar</systemPath>
  </dependency>

  <dependency>
    <groupId>jakarta.servlet</groupId>
    <artifactId>jakarta.servlet-api</artifactId>
    <version>6.1.0</version>
    <scope>provided</scope>
  </dependency>
</dependencies>

Container Image

The working image used Tomcat 10.1 and copied the SAP buildpack runtime overlay:

FROM docker.io/library/maven:3.9-eclipse-temurin-17 AS build
WORKDIR /workspace
COPY pom.xml ./
COPY lib ./lib
COPY src ./src
RUN mvn -q -DskipTests package

FROM docker.io/library/tomcat:10.1-jre17-temurin
ENV LD_LIBRARY_PATH=/usr/local/tomcat/impl/linuxx86_64:/usr/local/tomcat/lib \
    JAVA_OPTS="-Djava.library.path=/usr/local/tomcat/impl/linuxx86_64:/usr/local/tomcat/lib"

COPY .tmp-buildpack/tomcat/bin/ /usr/local/tomcat/bin/
COPY .tmp-buildpack/tomcat/conf/ /usr/local/tomcat/conf/
COPY .tmp-buildpack/tomcat/lib/ /usr/local/tomcat/lib/
COPY .tmp-buildpack/tomcat/impl/ /usr/local/tomcat/impl/
COPY --from=build /workspace/target/jco-on-kyma-demo.war /usr/local/tomcat/webapps/ROOT.war
EXPOSE 8080

Before building, extract the buildpack archive:

mkdir -p .tmp-buildpack/tomcat
tar -xzf java-buildpack/xs-java-buildpack-2.66.0-offline-cnb-tomcat.tgz \
  -C .tmp-buildpack/tomcat

Then build and push the image to a registry Kyma can pull from.

Kyma Service Bindings

The application needs at least:

Destination service instance and binding
XSUAA service instance and binding
Connectivity Proxy config and secret available in the application namespace

Example BTP service resources:

apiVersion: services.cloud.sap.com/v1
kind: ServiceInstance
metadata:
  name: destination-jco
  namespace: jco-rfc-test
spec:
  serviceOfferingName: destination
  servicePlanName: lite
---
apiVersion: services.cloud.sap.com/v1
kind: ServiceBinding
metadata:
  name: destination-jco
  namespace: jco-rfc-test
spec:
  serviceInstanceName: destination-jco
---
apiVersion: services.cloud.sap.com/v1
kind: ServiceInstance
metadata:
  name: xsuaa-jco
  namespace: jco-rfc-test
spec:
  serviceOfferingName: xsuaa
  servicePlanName: application
---
apiVersion: services.cloud.sap.com/v1
kind: ServiceBinding
metadata:
  name: xsuaa-jco
  namespace: jco-rfc-test
spec:
  serviceInstanceName: xsuaa-jco

The SAP runtime expected the bindings as files. Injecting them only as environment variables was not sufficient in my setup.

- name: SERVICE_BINDING_ROOT
  value: "/etc/secrets/sapbtp"

And mount the binding secrets:

volumeMounts:
  - name: destination-binding
    mountPath: /etc/secrets/sapbtp/destination-jco
    readOnly: true
  - name: xsuaa-binding
    mountPath: /etc/secrets/sapbtp/xsuaa-jco
    readOnly: true

volumes:
  - name: destination-binding
    secret:
      secretName: destination-jco
  - name: xsuaa-binding
    secret:
      secretName: xsuaa-jco

Connectivity Proxy Environment

For RFC, the app uses Connectivity Proxy port 20001:

- name: ONPREMISE_PROXY_HOST
  valueFrom:
    configMapKeyRef:
      name: connectivity-proxy-info
      key: onpremise_proxy_host
- name: ONPREMISE_PROXY_RFC_PORT
  valueFrom:
    configMapKeyRef:
      name: connectivity-proxy-info
      key: onpremise_proxy_rfc_port
- name: ONPREMISE_PROXY_TENANT_MODE
  valueFrom:
    configMapKeyRef:
      name: connectivity-proxy-info
      key: onpremise_proxy_tenant_mode
- name: CP_SECRET_CONNECTIVITY_PROXY_KYMA_SYSTEM
  valueFrom:
    secretKeyRef:
      name: cp-secret-connectivity-proxy-kyma-system
      key: service_key

In this demo the proxy endpoint was:

connectivity-proxy.kyma-system.svc.cluster.local:20001

Creating the RFC Destination

This part is easy to miss.

The RFC destination is not a Kubernetes Destination custom resource. For this JCo flow, the destination must exist in SAP BTP Destination service, and JCo resolves it from there.

The working destination properties were:

Name=InsightSuiteDestination
Type=RFC
jco.client.ashost=s4hana-2025japan
jco.client.sysnr=00
jco.client.client=201
jco.client.user=RFC_TESTUSER
jco.client.passwd=<password>
jco.client.lang=EN
jco.destination.proxy_type=OnPremise
jco.client.cloud_connector_location_id=sap-insight-suite

The most important line for the Location ID was:

jco.client.cloud_connector_location_id=sap-insight-suite

Initially, I used only:

CloudConnectorLocationId=sap-insight-suite

That appeared as a raw/custom property but did not populate the RFC destination's Location ID field in SAP BTP Cockpit. The tunnel was opened as if the location ID was empty.

After adding jco.client.cloud_connector_location_id, Cockpit showed the Location ID correctly, and Connectivity Proxy opened the expected tunnel:

account:///.../sap-insight-suite

In the repository I created a small helper script to create the destination through the Destination service API:

export RFC_PASSWORD='<password>'

./scripts/upsert-rfc-destination.py \
  --namespace jco-rfc-test \
  --binding-secret destination-jco \
  --template destinations/InsightSuiteDestination.template.json \
  --delete-first

unset RFC_PASSWORD

Connectivity Proxy Authorization

Another issue I hit was proxy authorization. The Connectivity Proxy log showed:

Validation of token failed due to: Allowed client ids not set for region configuration id default

The fix was to configure the allowed client ID in the ConnectivityProxy custom resource:

CLIENTID=$(kubectl -n kyma-system get secret cp-secret-connectivity-proxy-kyma-system \
  -o jsonpath='{.data.service_key}' \
  | base64 -d \
  | python3 -c 'import json,sys; print(json.load(sys.stdin)["clientid"])')

python3 - <<PY > /tmp/cp-patch.json
import json
clientid = "$CLIENTID"
print(json.dumps({
  "spec": {
    "config": {
      "servers": {
        "proxy": {
          "authorization": {
            "oauth": {
              "allowedClientId": clientid
            }
          }
        }
      }
    }
  }
}))
PY

kubectl -n kyma-system patch connectivityproxy connectivity-proxy \
  --type merge \
  --patch-file /tmp/cp-patch.json

After this, the proxy accepted the token and opened the RFC tunnel.

How to Recognize Success

Application logs showed:

Connected to socket with {sap-insight-suite-RFC.connectivity,2}
RfcOpen(... SCCLOCATIONID=sap-insight-suite)=1
Executing function STFC_CONNECTION

Connectivity Proxy logs showed:

Will use tunnelId: account:///.../sap-insight-suite
Handshake with tunnel client completed successfully

And the endpoint returned:

{
  "ok": true,
  "exports": {
    "ECHOTEXT": "Hello from Kyma"
  }
}

Things I Would Watch Out For

Here are the stumbling blocks that cost the most time:

Plain JCo is not enough
You need the SAP JCo cloud/connectivity runtime, not only sapjco3.jar and libsapjco3.so.
SAP Java Buildpack 2.x means Jakarta
If you use the 2.x runtime libraries, use Java 17 and jakarta.servlet.*.
Mount service bindings as files
The runtime looked for service bindings under /etc/secrets/sapbtp.
Use the RFC-specific Location ID property
For RFC destinations, use jco.client.cloud_connector_location_id.
Connectivity Proxy may need allowed client ID configuration
If you see Allowed client ids not set, patch the ConnectivityProxy configuration.
Reduce debug logging after troubleshooting
JCo/connectivity debug logs can expose destination details and token payloads.

Final Thoughts

Once all pieces were in place, the actual RFC call was simple. The hard part was not the Java code; it was assembling the correct runtime and configuration around it.

The most important takeaway for me was this:

In Kyma, RFC via JCo is possible, but you need the SAP cloud JCo/connectivity runtime and a correctly maintained BTP RFC destination.

Hopefully this saves someone else a few debugging loops — especially around the Location ID and Connectivity Proxy authorization details.

Appendix: Minimal Checklist

[ ] Connectivity Proxy module is installed and RFC port 20001 is enabled.
[ ] SAP Cloud Connector is connected to the correct subaccount.
[ ] Cloud Connector exposes the virtual RFC host/system.
[ ] Destination service instance and binding exist in the app namespace.
[ ] XSUAA service instance and binding exist in the app namespace.
[ ] Service bindings are mounted under /etc/secrets/sapbtp.
[ ] App image includes SAP JCo cloud/connectivity runtime libraries.
[ ] RFC destination exists in BTP Destination service.
[ ] RFC destination has jco.client.cloud_connector_location_id if a Location ID is used.
[ ] Connectivity Proxy authorization allows the connectivity client ID.
[ ] STFC_CONNECTION works with the configured SAP user.