SAP Community - SAP BTP, Kyma runtime

SAL: SAP 'Integrity Protection Format' secured with Distributed Ledger Technology on SAP BTP Kyma 🚀

2025-11-04T21:48:39.476000+01:00

Did you know,

the S/4HANA SAP Audit Log (SAL)

has a configuration,

'Integrity Protection Format',

which enables (malicious) modifications to be detected:

2033317 - Integrity protection format for Security Audit Log - SAP for Me

2191612 - FAQ | Use of Security Audit Log as of NetWeaver 7.50 - SAP for Me

This integrity protection is an extremely important part of your holistic Security Posture.

As @kevinrichardson showed and stated in this excellent picture, 'You cannot solve today's challenges with yesterday's tools',

(Source: 002_rise_with_sap_kr.pdf)

In the ERP modernisation and transformation which is happening everywhere, there is not enough being done on Security Posture Modernisation, SAL: SAP 'Integrity Protection Format', is available now included in your License and enabled with a Profile Parameter, so why not to do it ?

The OSS Notes explain that, SAL: SAP 'Integrity Protection Format', works like this:

2033317 - Integrity protection format for Security Audit Log - SAP for Me

And that's all fine, but where does the, 'Distributed Ledger Technology on SAP BTP Kyma 🚀' fit in to the equation, where's the relevance ?

Here's the answer, this Note 2191612 - FAQ | Use of Security Audit Log as of NetWeaver 7.50 - SAP for Me has a pdf attached: Explain SAL Integrity Format.pdf , and the pdf goes on to explain that,

'You should download the HMAC Ident as a backup, but you should save it on a secure place. The log files written with that can only be checked with that. It’s important to have this HMAC key data after a system copy or if the files should be evaluated in another system than the original. '

That's where the Blockchain / Distributed Ledger Technology running on the SAP BTP Kyma comes in,

store the HMAC Keys in the Distributed Ledger Technology running on the SAP BTP Kyma

This will ensure that nobody can tamper with the keys, and therefore nobody can tamper with the SAL Audit Logs and you have the least chance of losing the keys thanks to the built in characteristics of the Distributed Ledger Technology running on the SAP BTP Kyma, HA&DR out of the box, distributed, immutable, etc.

Source: BCP: Business Continuity Planning for SAP S/4HANA - made easy with Enterprise Blockchain 🚀

Creating digital finger prints of data is going to come in to our Security Posture whether it's protecting integrity of AI LLMs or Document Grounding, Log Files, Backups and more:

SAP AI Security - How To: Tamperproof AI LLM's with SAP BTP Kyma and Enterprise Blockchain 🚀

Cyber Security Protection for S/4HANA Backups with Enterprise Blockchain and SAP BTP Kyma 🚀

If you want to try it out there's a blog here, Running Your Own Blockchain on The SAP BTP Kyma Trial: A Hands On How To Guide 🚀

Have a think about, SAP Enterprise Architecture: Positioning Blockchain Database as an Enterprise Technology Standard 🚀 and then you can SAP Enterprise Architecture: Let the Use Case find the Blockchain🚀 by following SAP Enterprise Architecture Principles and the Enterprise Architecture: Enterprise Blockchain Platform Business Capability Map 🚀

And this is why, Why I love SAP and Blockchain Databases and why you should too 🚀

If you learn one thing from this blog, it's that you can protect the integrity of your SAL Audit Logs with SAP 'Integrity Protection Format', and that is a cool feature.

Until next time,

Andy Silvey.

Independent SAP Technical Architect and SAP Basis SME [you might also find my SAP S/4HANA RISE & BTP Toolbox interesting: 🧰👷‍ The SAP S/4HANA RISE & SAP BTP - Toolbox 👷‍🧰] and CEO of atkrypto (.) io

Author Bio:

Andy Silvey is a 26 years SAP Technology veteran [26 years SAP Basis and including 12 years SAP Tech Arch including Tech, Integration, Security, Data from 3.1H to S/4HANA PCE on RISE and the BTP and everything in between, and former SCN Moderator and Mentor alumni].

Andy is also co-Founder of atkrypto inc, an startup whose ambition is to make Blockchain easy for Enterprise.

atkrypto (.) io's flagship product is the atkrypto Enterprise Blockchain Platform for SAP, and atkrypto (.) io is a SAP Partner Edge Open EcoSystem Partner.

The atkrypto Enterprise Blockchain Platform for SAP has been designed by SAP Independent Experts for the needs of SAP Customers and to be deployed on the SAP BTP Kyma Runtime Service and leverage native integration to SAP Products.

atkrypto Enterprise Blockchain Platform for SAP has a number of unique qualities, including being the only Blockchain software in the world which has a DataCenter version and a light mobile version which can run on Edge/IoT/Mobile devices and enables data to be written to the Blockchain at the Edge where that same Blockchain is running on a Server in the DataCenter, protecting the integrity and originality of data from the Edge to Insights. Taking Blockchain to the Data at the Edge instead of taking the Data to the Blockchain.

SAP EA - Real World Asset Tokenization with Distributed Ledger Technology on the SAP BTP Kyma 🚀

2025-11-10T06:21:30.705000+01:00

I is for Innovation.... EA is about... the goal of this blog is to get us thinking and talking about tokenization before the Business turn up demanding it...

I've always wished and dreamed that us SAP EA's would know our Business so well and at the same time have Road Maps for all of our Technology Standards and including Emerging Standards so that we would know what Technical Capabilities the Business requires before they even come to us with their Demand.

In reality, in my experience 9 times out 10 it's the Business who come to EA with demands for new technologies (innovations).

How do we bring in or do "Innovation" ? Ideally with Roadmaps and Emerging Technology Standards.

SAP's next generation Customer CoE guides SAP Guides for Customer COE provide thought leadership on bringing in innovations, Customer Center of Expertise - Strategy, Governance and Organization

and continuous-improvement-and-innovation-with-a-ccoe.pdf

Customer Center of Expertise

ccoe_continuous_success_en.pdf

In SAP's documentation, in the North Star Architecture, in the next generation SAP CCoE, innovation responsibilities come in to a number of Roles

And combined with the Digital Innovation Manager Digital Innovation Manager | Digital Technology and Innovation Management| SAP Community

And that is what this blog is about, innovation, and innovation in the area of Tokenization and RWA Real World Asset Tokenization.

There is a silent digital revolution going on, where evidence, assets, transactions are being given a digital fingerprint, a hash on a Distributed Ledger and being tokenized.

What is Tokenization and who's doing it and where is it going ?

Let's start by looking at what's happening in the space:

[Disclaimer - we cannot post links outside of the Community and if you want to read these articles then just go on your favourite search engine and find them]

Pairpoint - Vodafone Sumitomo JV

World Economic Forum

Fortune - Asia's quiet tokenization revolution

CNBC

Oracle

from the same article, this is how Oracle sees it:

If they all see Tokenization that way then maybe the EA innovation leads in our Organisations should be having a look at Tokenization too.

This older SAP article considered common use cases NFT (Non-Fungible-Tokens) | Digital Technology and Innovation Management | SAP Community

SAP has dipped their toes into the water with the SAP Green Ledger What Is SAP Green Ledger? | SAP Help Portal , in my opinion the scope is too narrow, Green Ledger: Where Carbon and Financial Accounting Unite SAP Green Ledger and an ERP-centric approach to reinvent carbon accounting and Carbon Accounting is the tip of the iceberg.

Learning.sap.com has some excellent resources including videos Blockchain and this incredible Blockchain course What Can Blockchain Do for You .

Have a think about how Tokenization and Distributed Ledger Technology capabilities fit towards your Business, your Business Processes, your Business Partners.

Have a think about drawing the Blockchain Capability Map, positioning Enterprise Blockchain as an Emerging Technology Standard, and then when the Business come with the Demand... let the use-case / Demand find the Blockchain, and if you want to have a play with Enterprise Blockchain on the BTP Kyma, even the BTP Trial Edition Kyma then just follow this blog and reach out if there are any questions.

And that's the purpose of this blog, to get Tokenization onto our EA radars.

What do you think, put your thoughts in the comments.

Ultimately this is all "Why I love SAP and Blockchain Databases and why you should too 🚀".

Andy Silvey.

Author Bio:

Andy is also co-Founder of atkrypto inc, an startup whose ambition is to make Blockchain easy for Enterprise.

atkrypto (.) io's flagship product is the atkrypto Enterprise Blockchain Platform for SAP, and atkrypto (.) io is a SAP Partner Edge Open EcoSystem Partner.

New Kyma Telemetry Docs: Simplified, Task-Oriented, and User-First

2025-11-11T05:13:44.605000+01:00

We're happy to announce the release of the completely restructured and rewritten documentation for the Kyma Telemetry module! We've moved from a component-centric view to a user-first, task-oriented structure, all centered around a new, unified Telemetry Pipeline API.

What's New for Our Users?

The Unified Telemetry Pipeline API – At the heart of the new structure is the Telemetry Pipeline API. With the introduction of OTLP-based LogPipelines, you can now use a consistent set of CRDs to configure all your telemetry signals, which reduces complexity and makes your setup easier to maintain.
A Clearer, Task-Based Structure – Find what you need faster with new top-level guides for Collecting Logs, Collecting Traces, and Collecting Metrics. Each guide walks you through the process for a specific signal, from minimal setup to advanced configuration
A Clear Migration Path – If you're still using the legacy Fluent Bit (HTTP) log output, read Migrate Your LogPipeline From HTTP to OTLP, which guides you step-by-step to switch to the new OTLP setup without data loss.

The 'Why' Behind the Change: A Look at the Craft

If you're a fellow tech writer or just curious about the why, this wasn't just a rewrite; it was a fundamental shift in our information architecture:

Our previous documentation was component-centric. It described each component (Telemetry Manager, gateways, agents, pipelines...) and its internal architecture, explaining "What does the component do?". Based on that, the reader had to figure out how to accomplish a task.

Our new approach is goal-oriented, built on principles from the DITA (Darwin Information Typing Architecture) and industry best practices. Our guiding question is "What is the user trying to achieve?" This led us to structure the content as self-contained pages, each focusing on a user goal. For readers interested in the nitty-gritty details - you still find all of those in the consolidated Architecture docs.

Why This Matters

This new structure makes it easier to see what's common and what's different for the Telemetry pipeline types. Furthermore, we've re-centered the documentation on the actions you need to perform:

Start with your goal: Task-oriented titles such as Monitor Pipeline Health help you find what you need without knowing our internal component names.
Progressive disclosure of information: Get started with a minimal configuration quickly, and then explore advanced operations like filtering or processing only when you need them.
Get straight to the point: With consolidated troubleshooting instructions on the top level, you can start start fixing issues immediately without reading through unrelated details.

Get Started Today

We invite you to dive into the new Telemetry module documentation. We're proud of this new structure and believe it's a clear step up for clarity and usability.

Your Feedback Matters

Whether you're a user of the module or a fellow writer, we'd love to hear your thoughts. Give us feedback directly on the SAP Help Portal pages. Your input is crucial as we continue to evolve our content.

From Open Source to Help Portal: The Kyma Documentation Journey

2025-11-19T10:31:28.324000+01:00

Embarking on the journey of migrating Kyma modules documentation from open source to the SAP Help Portal was no small feat. This transition aimed to centralize and enhance the quality of documentation for external Kyma users, ensuring clarity and accessibility.

Planning the Migration and Resetting Mindsets

The journey began with a thorough discovery phase, which included interviews with all SAP BTP, Kyma runtime Product Owners, Lead Architect, Product Manager, and the SAP BTP Foundation Information Architect. We focused on understanding our users and audience as well as grasping the expectations of Kyma developers. This groundwork clarified what external users needed from Kyma documentation and how those needs differed from an open-source audience.

Equally important was a shift in mindset. While open-source documents seemed well-structured, they often blurred the lines between conceptual information and step-by-step procedures. Moving to the Help Portal enabled us to refine, separate, and validate content types so that concepts, tasks, and references were clearly distinguished. This set the tone for how we would write, review, and organize topics throughout the migration.

Piloting Telemetry and Establishing a Repeatable System

Choosing Telemetry as the pilot module was a strategic decision that provided invaluable insights. Working through this module, we developed templates and guidelines that would streamline the documentation process for all subsequent modules. Telemetry underwent numerous review and improvement cycles, which helped us define a repeatable approach: establishing the information architecture, applying consistent standards, iterating on technical accuracy, and polishing language and structure.

The pilot not only produced better content for Telemetry, but also a blueprint for future success. With templates, authoring conventions, and a clear workflow, we were equipped to scale the migration to other Kyma modules without sacrificing quality.

Collaborating for Quality and Consistency

Quality was a shared responsibility. Throughout the migration, we participated in Quality Review Sessions within the BTPX Foundation unit. These sessions provided structured feedback from colleagues outside of Kyma, helping us spot gaps, eliminate ambiguity, and align with SAP Help Portal standards. The cross-team collaboration ensured consistency in style, terminology, and organization across modules, and it accelerated decision-making on tricky or nuanced topics.

Results, Impact, and the Road Ahead

The migration covered 10 Kyma modules over approximately 22 months of non-continuous work, and engaged 5 UA developers. The outcome was about 120 Help Portal topics, each crafted to serve external users with clear conceptual explanations, actionable procedures, and reliable references. Centralizing SAP BTP, Kyma runtime documentation in the Help Portal provides users with a cohesive, comprehensive resource that’s easier to discover, navigate, and trust.

This journey was not just about moving content. It was about elevating the user experience - clarifying what users should understand, guiding them on what they should do, and ensuring the documentation remains a reliable and valuable resource for all. The foundations we built - clear content types, repeatable processes, and cross-team quality practices - position Kyma documentation for ongoing improvement and scalability.

Enjoy reading about Kyma Modules:

Whether you're using the modules or contributing as an author, we welcome your thoughts. Leave your feedback on the SAP Help Portal pages. Your input is key to how we enhance our content.

Authorization management with OpenSearch's Document Level Security - SAP Cloud Logging

2025-11-24T23:51:25.092000+01:00

The shift to SAP Cloud Logging service introduces several improvements over its predecessor, the SAP Application Logging service (Cloud Foundry). One major benefit is the ability to use a single Cloud Logging instance across multiple CF spaces and even multiple CF orgs/subaccounts. (For more details, see the blog post Instance Sharing – SAP Cloud Logging.)

However, the authorization model is different fromSAP Application Logging service (Cloud Foundry). Application Logging supported only read-only access and implicitly reused CF space permissions.

Cloud Logging, on the other hand:

Supports read/write use cases
Allows creating custom content
Enables centralization and sharing

In order to support such extended scenarios, Cloud Logging integrates with SAP Cloud Identity Services - Identity Authentication (IAS) for flexible authentication and authorization.

This document guides on how to leverage Document Level Security (DLS) in OpenSearch Roles (+) IAS Groups to setup flexible authorization. It explains using few common use cases including the prominent one - replicating the familiar space-level separation, based on user's CF Space assignment, within a unified logging instance.

OpenSearch Security Model Overview

OpenSearch's security model provides the foundation for integrating with external Identity Providers (IdPs) like SAP IAS:

Component	Definition	Integration
Users	Individual accounts accessing OpenSearch.	Authenticated via SAP IAS.
OpenSearch Roles	Collections of permissions (read, write, manage) and security filters (DLS). Cloud Logging ships with default roles, and customers may create additional ones.	The mechanism for authorization.
Backend Roles	Groups or roles assigned to the user within the SAML/OIDC Identity Provider — in this case SAP IAS Group names.	The bridge between SAP IAS and OpenSearch Roles.
Roles Mapping	The link that connects IAS groups (backend roles) to OpenSearch roles.	How users inherit OpenSearch permissions.

Note:

Since IAS groups are customer-defined, Cloud Logging can only pre-map the IAS group that should serve as instance admin to OpenSearch’s all_access role. All other mappings must be configured by the customer.

Index-Level vs. Document-Level Security

Index-Level Security controls which indices a user can access.
Document-Level Security (DLS) controls which documents inside an index a user can access.

To restrict users to logs from a specific CF space, you apply DLS.

The DLS Strategy: Restricting Views by Space ID

To achieve security separation, every log document must contain a field that identifies its CF source. We assume this field is named space_name (mapped as space_name.keyword in OpenSearch).

DLS works by appending a mandatory filter—an OpenSearch Query DSL statement—to every search request made by a user assigned to the role. This filter ensures the user only retrieves documents where the space_name.keyword matches their authorized space(s).

Use Case 1: Fixed Authorization for Specific Spaces (Space-A and Space-B)

When you have a small number of distinct spaces (e.g., space-A and space-B), and each requires a dedicated authorization group, you create a static OpenSearch Role for each.

Step 1: Create IAS Groups (Backend Roles)

space-A-read-only
space-B-read-only

Step 2: Define OpenSearch Roles

We will define two roles, each allowing read-only access to log indices but restricted by DLS.

A. Role for Space-A (role-space-A-read-only)

Navigate to OpenSearch Dashboards > Security > Roles.
Clone the default readall role and name it role-space-A-read-only.
Cluster permissions: cluster_composite_ops_ro
Index Permissions:

Index Pattern: logs-*(Specify a pattern like this instead of only specifying an asterisk * to avoid applying DLS to system indices).
Index Permissions: Select read
Document Level Security: Enter the DLS query for the specific space:

{
  "term": {
    "space_name.keyword": "space-A"
  }
}

B. Role for Space-B (role-space-B-read-only)

Repeat the above steps for role-space-B-read-only, changing the value in the DLS query to "space-B".

Step 3: Map Backend Roles to OpenSearch Roles

This step links the SAP IAS groups to the newly created security filters.

Navigate to OpenSearch Dashboards > Security > Roles.
Select role-space-A-read-only.
Click the Mapped Users tab and then Manage Mapping.
Under Backend roles, add the SAP IAS group name: space-A-read-only.

Repeat this process for role-space-B-read-only, mapping it to the space-B-read-only backend role.

Crucial Note on Dashboards Access: You must also map these new Backend Roles (space-A-read-only, space-B-read-only)to the OpenSearch role global_tenant_read_access to allow users to see and use shared dashboards and visualizations.

Use Case 2: Multi-Space Access for Shared Teams (e.g., Finance)

If you need to define a single role for a department (e.g., Finance) that needs access to a specific list of CF spaces (space-A, space-C, space-D), you can use terms query to add multiple values.

UI Steps for a finance_spaces_read_only Role:

Clone the default OpenSearch Role readall and name it finance_spaces_read_only.
Set the Index Pattern and Permissions as explained in Use Case 1.
Document Level Security: Enter the terms query to include all required spaces:

{
  "terms": {
    "space_name.keyword": [
      "space-A",
      "space-C",
      "space-D"
    ]
  }
}

Map this role to the relevant SAP IAS group (e.g., finance_spaces_read_only) as explained in Use Case 1.

Use Case 3: Using Other Fields

The same DLS concepts apply to:

organization_id
organization_name
app_name

You can restrict access on any well-defined keyword field stored in your logs.

Use Case 4: Parameter Substitution for Dynamic Authorization

For maximum scalability, instead of creating one OpenSearch role per space, you can create a single role that dynamically substitutes the user’s backend roles into the DLS query.

This works when IAS group names match the field values — for example:

finance_space_prod
finance_space_staging
finance_space_dev

In OpenSearch, the variable ${user.roles} references the list of backend roles (IAS groups) assigned to the user.

UI Steps for a Dynamic Role:

Create a single OpenSearch Role (e.g., dynamic_space_member).
Set the Index Pattern and Permissions as before.
Document Level Security: Use the ${user.roles} substitution variable in a terms query:

{
  "terms": {
    "space_name.keyword": [ ${user.roles} ]
  }
}

Result: When a user logs in, if they are assigned to the IAS groups finance_space_staging and finance_space_dev, the DLS query automatically evaluated to "terms": { "space_name.keyword": ["finance_space_staging", "finance_space_dev"] }. The user is only shown logs where space_name exactly matches one of their assigned IAS groups.

Map this role to a general backend role pattern (e.g., finance_space*) to cover all relevant IAS groups.

High-Level Overview: IAS Group Mapping and Space-Based Access Control in OpenSearch

Important Considerations (DLS Best Practices)

**1. Avoid Wildcard Index Match (`*`) :**

Avoid using a plain wildcard (*) for index patterns in your DLS roles. This includes system indices (like .kibana), which can break Dashboards functionality when DLS is applied. Always use a targeted pattern like logs-*, otel-*

2. DLS and Write Permissions:

A user with a DLS-configured role must not be granted write permissions. If they index a document they cannot retrieve (due to DLS filtering), it creates invisible data they cannot manage. DLS is intended for read-only access control.

3. Admin Roles Combined with DLS Roles

When a user with multiple roles (usually Admins) logs in, OpenSearch combines DLS rules from multiple roles using a logical OR. However if a restricted role with DLS is combined with a role with empty DLS, the unrestricted role will not override the DLS rule, and access remains restricted according to role with DLS.

This is the secure, expected behaviour:

Admin role: empty DLS
Restricted role: with a restricted DLS
Combined: restricted role takes precedence (since empty DLS does NOT override a restrictive one)

Background: The admin role has an "empty" DLS configuration which by default does not override a restrictive one. In Cloud Logging, plugins.security.dfm_empty_overrides_all is disabled, so empty DLS doesn’t override.

Workaround to Give Admins Full Access

Duplicate the all_access role → all_access_advanced
Change index pattern: from * to a targeted pattern like logs-*
Add a match-all DLS: {"match_all":{}}
Ensure admin backend role is mapped to this new role.

4. DLS Query Syntax: Precision is Key

For security and performance, use DLS filters with term query on a .keyword field.

# Option 1: works but has limitations

{ 
 "bool": { 
   "must": { 
     "match": { 
       "space_name.keyword": "space-name-A" 
     } 
   } 
 } 
} 

vs. 

# Option 2: preferred
{ 
  "term": { 
    "space_name.keyword": "space-name-A" 
  } 
}

Although match (combined with .keyword) works, it triggers analyzers and scoring logic.
Furthermore, it is not guaranteed to remain exact under future mapping or analyzer changes which are risky when used for authorization.
term is faster, safer, and the only deterministic option for Lucene-level DLS.

Term Look up:

If you use term lookup queries (not the simple Term query) or other constructs, DLS falls back to Filter-level DLS instead of the most efficient Lucene-level DLS which might have to be considered when filtering on large data sets. (read more on DLS evaluation modes).

🔚

Official OpenSearch DLS documentation: https://docs.opensearch.org/2.19/security/access-control/document-level-security/

Event Driven SAP CAP on Kyma with Agentic AI and UI Auto Refresh

2025-12-01T05:11:39.765000+01:00

Introduction:
This prototype demonstrates how a simple CAP application can evolve into an event-driven architecture enriched with autonomous agentic AI. The objective was to show how CAP can react to external events in real time, refresh the UI automatically, and trigger an AI workflow that identifies duplicate citizens without any user action. The solution combines Kyma, SAP CAP, SAP HANA Cloud DB, SAP Integration Suite, a Python agent/Open AI, all running together.

Demo:

End-to-End Flow:
This application is built around a simple idea: when a citizen is created in the system, everything should react automatically.

The process starts in SAP Integration Suite. This is the continuation of the last Blog Post . The iFlow inserts the new citizen into HANA Cloud and then calls CAP’s notify endpoint with a simple JSON payload. This notify call is the explicit trigger, because CAP does not detect database changes on its own. Once CAP receives the notification, it broadcasts the event through its citizen stream endpoint using Server-Sent Events.

The UI and the Python agent are both listening to this stream. When they receive the event, each reacts independently. The UI refreshes its Fiori Elements binding and displays the new record. The agent retrieves the citizen through CAP OData, performs duplicate detection, prompts Open AI, and writes its suggestions back through CAP. CAP exposes the suggestions via virtual enrichment fields so that the UI automatically displays AI insights during the next read.

iFlow Changes:

Code:

GitHub: User - shahidla. Repository - citizen-master-cap-docker

Agentic AI:
The agent is packaged as a Python container running in Kyma. It listens continuously to the citizen stream. When it receives a CitizenCreated event it reads the citizen through OData, prompts Open AI with a structured tool-based instruction set and follows the returned JSON. Open AI selects the next actions such as fetching the citizen again, running a duplicate search or writing the final suggestion.

To make the AI transparent, a thinking log table records each step in the agent run including search inputs, candidate lists, scores and final reasoning. Users can view not only the AI result but also how the agent reached that conclusion. This makes the system trustworthy and audit friendly rather than a black box.

Execution results:

AI Agent Thinking Logs:

Conclusion:
This prototype shows that a CAP application can be extended into a fully event driven and agentic AI and can all run together inside Kyma without additional infrastructure The result is a responsive and intelligent application that reacts to new information immediately and explains every decision it makes.

Disclaimer:
This prototype intended for learning and demonstration. It is not production grade and does not include full durability. AI reasoning results should be validated and not used for decisions without proper governance. A real solution would require reviewing security, performance, and data privacy aspects. Terminology may have been used freely as part of experimentation.

Streamlined Kyma deployment for CAP applications

2025-12-08T05:32:49.745000+01:00

SAP BTP, Kyma runtime (a fully managed cloud-native Kubernetes application runtime based on the open-source "Kyma" project) enables developers to deploy highly scalable, modular, and secure microservices. The SAP Cloud Application Programming (CAP) model supports Kyma deployments as one of the recommended approaches in the SAP BTP Developer’s Guide

What’s New

In the November release of CAP, we have introduced several key improvements that significantly simplify the deployment of CAP applications to Kyma.

Here is a quick look at the changes:

Streamlined project setup: The new cds add kyma command quickly configures your Kyma project and serves as the central entry point for configuring deployments to Kyma.
Interactive credential handling: When using cds up -2 k8s, you’ll receive prompts for any missing registry credentials on your Kyma cluster, eliminating guesswork during deployment.
Automatic UI5 build: The cds up -2 k8s command now automatically builds your SAP UI5 applications, removing an extra manual step from your workflow.
Intelligent build optimization: Builds now trigger only when artifact changes are detected, eliminating unnecessary build cycles and notably speeding up your deployment process.
Simplified tooling: The standalone containerize tool (also known as ctz) is no longer required. The cds up -2 k8s command handles containerization directly reducing external dependencies

Ready to try it out? Make sure to have the latest cli version with npm i -g @Pa_Vi/cds-dk@latest, also check out the updated documentation and our release notes for complete details on these improvements.

As always, if you have any questions, do not hesitate to reach out to us on cap@sap.com

🎄 Ho Ho Ho! A Christmas Present from SAP Job Scheduling Service: Free Plan on BTP Trial 🎁

2025-12-17T14:00:31.636000+01:00

The holiday season brings joy, festivities, and... a brand new Free service plan for SAP Job Scheduling Service on BTP Trial! 🎅

Starting now, you can unwrap the power of automated job scheduling without any cost constraints during your trial period. Just like Santa's workshop needs schedules to deliver presents on time, your applications can now schedule tasks with our new Free plan!

🎁What's Under the Tree?

The Free plan gives you access to the same powerful scheduling capabilities as the Standard plan, with some carefully chosen limitations perfect for learning, prototyping, and small-scale projects:

📋Plan Details

Technical name: free
Display name: Free

Capabilities:

✅Schedule one-time and recurring jobs
✅Schedule synchronous and asynchronous jobs
✅Execute Cloud Foundry tasks
✅Integration with SAP Alert Notification service for SAP BTP

Important Note: ⚠️
Only community support is available for free service plans, and these are not subject to SLAs. Use of free tier service plans is subject to additional terms and conditions as provided in the Business Technology Platform Supplemental Terms and Conditions.

🤔Why Free? Why not using Lite plan?

Lite plan has many restrictions and works way different than what we have as standard plan. In order to provide better experience to our users we have created free plan which is more aligned with standard plan. What this mean is that we will deprecate lite plan in near future and remove it from BTP Trial.

The good news - you can expect Free plan to also be available for BTP Live in near future!

🎅Technical Features: What's in Your Stocking?

Here's what Santa has packed in the Free plan:

⏰Minimal Schedule Interval: 1 Hour

You cannot create intervals between schedules of less than 1 hour. Perfect for hourly reports, regular cleanup tasks, or periodic data synchronization.

📊Number of Schedules: 15

You can create up to 15 schedules - more than enough for testing, learning, and small applications. Think of it like Santa's Nice List - carefully curated and just the right size!

🔔Send Events to SAP Alert Notification Service: Unlimited

You can enable your job or task to send events for success or failure to SAP Alert Notification service for SAP BTP - with no limits! This works like Santa's notification system - you'll know immediately if your jobs succeed or need attention.

Note: Only available in the Cloud Foundry environment.

📚Learn more:

🎄Feature Comparison Table

Feature	Free Plan	Standard Plan
Minimal schedule interval	1 hour ⏰	5 minutes ⚡
Number of schedules	15 📊	Unlimited ♾️
Multitenancy	Tenant-aware ✅	Tenant-aware ✅
Alert Notification Service integration	Unlimited ✅	Unlimited ✅
One-time & recurring jobs	✅	✅
Sync & async jobs	✅	✅
Cloud Foundry tasks	✅	✅
Support	Community 👥	SLA-backed 🛡️

🎅Getting Started

Ready to unwrap your present? Here's how to get started:

Access BTP Trial - Visit the SAP BTP Trial and log in
Navigate to Service Marketplace - Find "Job Scheduling Service"
Create Instance - Select the "free" plan
Bind to Your Application - Connect it to your Cloud Foundry app or create a service key
Start Scheduling! - Use the dashboard or REST API to create your first job

🎁Perfect For...

The Free plan is your ideal companion for:

🎓 Learning - Explore Job Scheduling capabilities without commitment
🧪 Prototyping - Test your scheduling logic before production
🎨 Small Projects - Build demos, proof-of-concepts, and personal projects
📚 Tutorials - Follow along with our blog posts and documentation
🎯 Trial Applications - Integrate scheduling into your BTP Trial apps

🌟Happy Scheduling!

This holiday season, we're excited to make SAP Job Scheduling Service more accessible than ever. Whether you're just starting your cloud journey or experimenting with automation, the Free plan is our gift to you!

Ho ho ho! May your schedules always run on time and your jobs always succeed! 🎄✨

📚Additional Resources

Disclaimer: Free tier service plans are subject to the Business Technology Platform Supplemental Terms and Conditions. Community support only - no SLA applies to free plans.

Happy Holidays from the SAP Job Scheduling Service Team! 🎅🎄🎁

SAP Integration Suite Workflows with Job Scheduling Service 🚀

2026-01-16T12:45:07.749000+01:00

Schedule Your SAP Integration Suite Workflows with Job Scheduling Service – Secured with JWT Authentication! 🔐🚀

Are you using SAP Integration Suite? You may be wondering is it possible to use the SAP Job Scheduling service to start integrations on a timely matter.

I was wondering the same. And the answer is YES! You can use the SAP Job Scheduling service to trigger integrations in the Integration Suite. But how?

To achieve this, you need to expose your integration as an HTTP endpoint. This can be done by creating API in the Integration Suite's API Management - this will allow your workflow to be triggered via HTTP requests. Ok this is something trivial for Integration Suite users.

But now to ensure that only the SAP Job Scheduling service can trigger your integration? In your API setup you need to implement authentication mechanisms - verify that the token coming from the Job Scheduling service is valid. For this, you can use verifyJWT policy. And that's it!

Now let's show it step by step.

For more cool Job Scheduling Service Blog Posts check the Overview page

Prerequisites

For my setup I have used the BTP Trial account + followed some SAP Tutorials to get a workflow and API up and running.

With this done you get an endpoint that can be triggered via HTTP request. But beware because this endpoint is public - anyone knowing the URL can trigger it.

Create Job Scheduling Service Instance

Now let's create a Job Scheduling service instance that will be used to trigger our Integration Suite API on a schedule.

Using BTP Cockpit

Navigate to your BTP Trial Subaccount
Go to Services → Service Marketplace
Search for Job Scheduling Service (or jobscheduler)
Click on the service tile
Click Create button
Fill in the instance details:
- Service: Job Scheduling Service
- Plan: Select free (or standard in BTP Production)
- Runtime Environment: Cloud Foundry
- Space: dev if you are using trial (or your space name for BTP Production)
- Instance Name: jobscheduler-integration-suite (or any name you prefer)
Click Create (no need to add parrameters)

Using CF CLI

Alternatively, you can use the Cloud Foundry CLI:

cf create-service jobscheduler free jobscheduler-integration-suite

Wait for the service instance to be created. You can check the status with:

cf service jobscheduler-integration-suite

Once the service is created, you can access the Job Scheduling service dashboard through the BTP Cockpit by clicking on your service instance and selecting View Dashboard.

Create a Job in Job Scheduling Service that Triggers the Integration

Now that we have both the Job Scheduling service instance and the Integration Suite API endpoint, let's create a job that will trigger the integration on a schedule.

Step 1: Get Your Integration API Endpoint URL

From the Integration Suite API Management, you need to get the full URL of your API endpoint. Go to Configure -> APIs and then choose your API. Inside you can find your API Proxy URL.

Make sure to copy this URL - you'll need it in the next step.

Step 2: Open the Job Scheduling Dashboard

Navigate to your BTP Trial Subaccount
Go to Services → Instances and Subscriptions
Find your Job Scheduling service instance (jobscheduler-integration-suite)
Click on the instance name
Click View Dashboard button

Note: You may need to log in with your BTP credentials when accessing the dashboard for the first time.

Step 3: Create a Job

In the Job Scheduling dashboard, click Jobs from the left-hand menu
Click the Create Job button
Fill in the job details:
- Name: Trigger Integration Flow (or any meaningful name)
- Description: Triggers the Integration Suite API endpoint
- Action: Paste your Integration API Proxy URL (from Step 1) + add /details
- HTTP Method: Select POST (as we follow the tutorial)
Click Save

Note: After saving, you'll see a warning icon next to the job. This is normal - it means the job needs a schedule to actually run.

Step 4: Create a Schedule

Click on the job name you just created to open its details
From the left-hand menu, click Schedules
Click Create Schedule button
Configure the schedule:
- Pattern: Leave One Time
- Value: Enter now
- Data: Add your payload, if you have followed the previous tutorial to create an integration that expects a payload:
```
{
  "productIdentifier": "HT-2000"
}
```
Click Save

Step 5: Verify the Job Execution

After saving the schedule, click on the schedule description to view its details
From the left-hand menu, select Run Logs
Wait for the scheduled time to pass (or if you used now as the pattern, it should execute immediately)
Refresh the page to see the execution results
You should see a status of COMPLETED with a green checkmark if successful

Click on the Run Log ID to see detailed information about the execution, including:

HTTP status code received from your Integration endpoint
Response body
Execution timestamp
Duration

Success! - without security yet.

At this point, your job is successfully calling the Integration Suite API endpoint. However, this endpoint is still publicly accessible - anyone with the URL can trigger it. In the next section, we'll secure it so that only the Job Scheduling service can call it.

Secure the Integration Endpoint

To ensure that only the Job Scheduling Service can trigger your integration, you need to implement JWT (JSON Web Token) authentication in your API using Integration Suite's API Management policies.

The Job Scheduling service automatically sends a JWT token in the Authorization header when calling your endpoint. We'll configure the API to verify this token, ensuring only legitimate calls from your Job Scheduler instance are accepted.

Reference: This section is inspired by Part 1: Modeling the JWT token verification flows in SAP Cloud Platform API Management

Understanding the JWT Verification Flow

The verification process involves these steps:

Fetch JWKS from XSUAA - Get them from the Job Scheduler's XSUAA service /token_keys
Get the public certificate - to verify the JWT signature
Verify JWT token - Validate the incoming token using the public certificate and check claims like issuer and audience.

Note: we will not include caching for this example to keep it simple

Step 1: Get Your Job Scheduler Service Key

First, you need to get the XSUAA credentials from your Job Scheduling service instance.

Navigate to your BTP Cockpit → Subaccount → Spaces
Go to Services → Instances
Find your jobscheduler-integration-suite instance
Click on the instance, then go to Service Keys
Click Create to create a new service key (name it api-integration-key)
Click on the service key to view its JSON content

You'll need these values from the service key:

uaa.url: The XSUAA server URL (e.g., https://dadb4adetrial.authentication.ap21.hana.ondemand.com)
uaa.clientid: The application name (e.g., sb-377fab0e-30b1-49e2-8632-01968ee8d436!b97749|sap-jobscheduler!b4)

The information about the token can be found on {uaa.url}/.well-known/openid-configuration

The JWKS endpoint URL will be: {uaa.url}/token_keys. It contains the public keys needed to verify the JWT tokens.

Step 2: Open Your API in Integration Suite

Navigate to Integration Suite → Configure → APIs
Select your API that you created in the prerequisites

Click on Policies to open the Policy Editor
Click Edit to enter edit mode

Step 3: Add JWT Verification Policies

We'll add 4 policies in the ProxyEndpoint → PreFlow section (these run before your integration is called):

3.1 Add Service Callout Policy

This policy fetches the JWKS from XSUAA if they're not in cache.

Click the + button next to Service Callout (under Extension Policies)
Name it: readJWKS
Click Add
Replace the policy content with (update the URL with your {uaa.url}/token_keys endpoint from above):

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ServiceCallout async="false" continueOnError="false" enabled="true" xmlns="http://www.sap.com/apimgmt">
    <Response>JWTKeys</Response>
    <Timeout>30000</Timeout>
    <HTTPTargetConnection>
        <URL>your.uaa.url/token_keys</URL>
    </HTTPTargetConnection>
</ServiceCallout>

Important: Replace the URL with your actual XSUAA token_keys endpoint from Step 1.

3.2 Extract Public Certificates

In this step, we extract the public keys from the JWKS response. So that it can be used later in the JWT verification.

Why is this the step needed? Because the response from the token_keys endpoint may contains different fields and we need exactly the public keys.

Click the + button next to Extract Variables (under Message Policies)
Name it: extractPublicKeys
Click Add
Replace the policy content with:

<ExtractVariables xmlns="http://www.sap.com/apimgmt" async="false" continueOnError="false" enabled="true">
<Source>JWTKeys.content</Source>
  <JSONPayload>
    <!-- Pull the PEM from the "value" field -->
    <Variable name="PUBLIC_KEY_PEM">
      <JSONPath>$.keys[0].value</JSONPath>
    </Variable>
  </JSONPayload>
  <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</ExtractVariables>

3.3 Add Verify JWT Policy

This is the main policy that validates the JWT token from Job Scheduler.

Click the + button next to Verify JWT (under Security Policies)
Name it: verifyJWT
Click Add
Replace the policy content with (update the issuer):

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<VerifyJWT async="false" continueOnError="false" enabled="true" xmlns="http://www.sap.com/apimgmt">
    <Algorithm>RS256</Algorithm>
    <PublicKey>
        <Value ref="PUBLIC_KEY_PEM"/>
    </PublicKey>
    <Issuer>your.uaa.url/oauth/token</Issuer>
    <Audience>uaa.clientid</Audience>
</VerifyJWT>

Important:
Update <Issuer> with your XSUAA URL + /oauth/token
Update <Audience> with your clientid from the service key
These values must match exactly or the token verification will fail

Step 4: Save and Deploy

Click Update in the Policy Editor to save all policies
Click Save to persist the API changes
Click Deploy to deploy the updated API
The API is now protected with JWT authentication!

Step 5: Understanding the Policy Flow

Here's what happens when Job Scheduler calls your API:

1. Job Scheduler → API (with JWT token in Authorization header)
2. readJWKS → Fetches JWKS from XSUAA
3. extractPublicKeys → Extracts public key from JWKS into variable
4. verifyJWT → Validates JWT token with JWKS
5. IF valid → Integration Flow executes
6. IF invalid → Returns 401 Unauthorized

Testing the Secured Integration

Now let's test that the JWT verification is working correctly.

Test 1: Job Scheduler Should Succeed

Go back to the Job Scheduling Dashboard
Navigate to your job and schedule
Manually trigger the one time job by activating it (or wait for the next scheduled run if the job is recurring)
Check the Run Logs
You should see COMPLETED status with HTTP 200

This proves that Job Scheduler can successfully authenticate with the JWT token.

Test 2: Direct API Call Should Fail

To verify the security is working, try calling the API directly without a valid token:

In Integration Suite, go to your API
Click on Test tab
Try to call the API without authorization
You should receive a 401 Unauthorized response

Or test with curl:

curl -X POST "https://your-api-url.com/your-integration-path" \
  -H "Content-Type: application/json" \
  -d '{"productIdentifier": "HT-2000"}'

Expected error response:

{
  "fault": {
    "faultstring": "Failed to Resolve Variable : policy(verifyJWT) variable(null)",
    "detail": { "errorcode": "steps.jwt.FailedToResolveVariable" }
  }
}

Test 3: Wrong Job Scheduler Instance Should Fail

If you have multiple Job Scheduling service instances, try calling from a different instance:

Create a job in a different Job Scheduler instance
Point it to the same Integration API endpoint
Run the job
Check the Run Logs - you should see REQUEST_ERROR (401)

Expected error from a different Job Scheduler instance:

{
  "fault": {
    "faultstring": "Invalid Claim: policy(verifyJWT) claim(aud)",
    "detail": {
      "errorcode": "steps.jwt.InvalidClaim"
    }
  }
}

This happens because the audience claim in the JWT token doesn't match the one configured in your verifyJWT policy, proving that only your specific Job Scheduler instance can trigger the integration.

Conclusion

Congratulations! 🎉 You've successfully:

✅Created a Job Scheduling service instance in BTP
✅Configured a job to trigger your Integration Suite API endpoint on a schedule
✅Secured the API endpoint using JWT token verification
✅Ensured only your specific Job Scheduler instance can call the integration

What You've Learned

How to integrate SAP Job Scheduling Service with Integration Suite APIs
How to implement JWT-based authentication in API Management
How to use JWKS for token verification with caching
How the JWT verification flow works in Integration Suite

Key Takeaways

Automatic Authentication: Job Scheduler automatically sends JWT tokens - no additional configuration needed in the job
Strong Security: The audience claim ensures only your specific service instance can access the API
Zero Trust: Even if someone knows your API URL, they can't call it without a valid JWT token from your Job Scheduler

Next Steps

Consider these enhancements:

Add more schedules: Create recurring schedules (hourly, daily, weekly)
Monitor executions: Use the Job Scheduler dashboard to track success rates
Handle errors: Implement error handling in your integration flow
Alert on failures: Use SAP Alert Notification service for failed job runs
Add logging: Enhance your integration flow with detailed logging for troubleshooting
Custom claims: Add additional JWT claim validation (e.g., scope, client_id)

Troubleshooting

Problem: "Invalid token" error

Symptoms: Job shows REQUEST_ERROR (401) with message about invalid token

Possible Causes & Solutions:

JWKS URL is incorrect
- Check the readJWKS Service Callout policy
- Verify the URL ends with /token_keys
- Ensure it matches your XSUAA domain from the service key
Issuer mismatch
- Check the <Issuer> in your verifyJWT policy
- Must match: {uaa.url}/oauth/token
- Case-sensitive!
Audience mismatch
- Check the <Audience> in your verifyJWT policy
- Must match the clientid from your Job Scheduler service key
- Example: sb-377fab0e-30b1-49e2-8632-01968ee8d436!b97749|sap-jobscheduler!b4

Problem: FailedToResolveVariable error

Symptoms: Job shows REQUEST_ERROR (401) with message "Failed to Resolve Variable"

{"fault":"{faultstring":"Failed to Resolve Variable : policy(verifyJWT)
variable(JWTKeys.content)',"detail": {"errorcode":"steps.jwt.FailedToResolveVariable"}}}

Possible Causes:

If you decide to include caching for the JWKS, this error may occur if the cache contains old and invalid data.

Possible Solutions

In verifyJWT put the directly Public Key instead of JWKS ref or remove the caching policies to simplify the flow.

Instead of

<PublicKey>
        <Value ref="PUBLIC_KEY_PEM"/>
</PublicKey>

it can be changed the value of keys.[0].value of {uaa.url}/token_keys

<PublicKey>
<Value>
    		-----BEGIN PUBLIC KEY-----
    		MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArwaPuBnCZqghcYY+x8RA
    		qUSC/NwE2aflfyRvDT+9P7gCjQiXz+RxqQ7Mh4RL41jANIMr9m3TeUFOjuitY9En
    		K3i4qTBrWNvsTdx/NdL9OOx55O4DMVOeANEtxXhrfDDMb7iRDFsfNmgPn06iIc2C
    		example - do not copy
    		5wYN2cMO4Ne1GFZmtduz2WEEwnWU4/6+ie8ONIGO52DJPXIqHk2d4SRAjLaTDzSx
    		a/iBVSmlSLbWmhSFcUHkMkX3BkEdG6A2tmRFwyEv1e3jQ+1+Q+wekr538I3nwATp
    		xQIDAQAB
    		-----END PUBLIC KEY-----
</Value>
</PublicKey>

This is not recommended for production but can help to identify the problem.

Problem: "Invalid Claim: claim(aud)" error

Symptoms: Different Job Scheduler instance gets 401 with audience claim error

Solution: This is expected! The audience validation ensures only your specific Job Scheduler instance can call the API. If you need multiple instances to access it, you'd need to:

Add multiple <Audience> elements in the policy

Problem: Job shows COMPLETED but integration didn't run

Possible Causes & Solutions:

Check API routing: Ensure the API proxy is properly routing to your integration flow
Check integration flow status: Verify it's deployed and running in Integration Suite
Review integration logs: Check the integration flow monitoring for errors

Debug API

Inside the Integration Suite you can check the API calls in the Test → Debug section:

Navigate to your API in Integration Suite
Go to Test tab
Enable Debug Session
Trigger a call from Job Scheduler
Review the debug trace to see:
- Which policies executed
- JWT token validation results
- Request/response headers and body

This is extremely helpful for understanding what's happening at each step of the policy flow.

Additional Resources

For more cool Job Scheduling Service Blog Posts check the Overview page

Happy Scheduling! 🚀

🎯 Lite Plan Deprecation: Time to Upgrade to Free! 🚀 | SAP Job Scheduling service

2026-01-26T12:52:28.885000+01:00

🎯 Lite Plan Deprecation: Time to Upgrade to Free! 🚀

Great news! The SAP Job Scheduling Service is evolving to provide you with better capabilities and a more consistent experience across Trial and Production environments. As part of this evolution, we're saying goodbye to the Lite plan and inviting everyone to upgrade to the superior Free plan! 🎉

📅 Important Timeline

Here's what you need to know:

DateEventStatus

22 January 2026	Lite plan officially deprecated on SAP BTP Trial	⚠️ Announced
19 February 2026	Last day to create new Lite plan instances	🔒 No new instances
Going forward	Existing Lite instances will be removed	♻️ Migrate to Free

ℹ️ Note: SAP BTP Trial accounts typically live for 90 days. Your existing Lite instances will be removed as part of the natural trial lifecycle.

If you want to stay up-to-date with the latest announcements, check out the SAP Job Scheduling Service What's New page.

🌟 Why This Change is Good News

The Lite plan served us well, but it was time for an upgrade! Here's why the Free plan is a much better choice:

Lite Plan Limitations 😕

🔐 Basic authentication only (outdated security model)
🔄 Works differently than production Standard plan (confusing!)
📚 Limited REST API capabilities
🏢 No multitenancy support
🎓 Steeper learning curve when moving to production

Free Plan Advantages 🎊

🔒 OAuth 2.0 authentication - Modern, secure, production-ready
🎯 Works like Standard plan - Smooth transition to production
🚀 Full REST API support - All features unlocked
🏢 Multitenancy ready - Build tenant-aware solutions
✨ Better integration - Works seamlessly with other BTP services
📊 More capabilities - Alert Notification Service, Cloud Foundry tasks, and more!

📊 Plan Comparison: Lite vs. Free vs. Standard

Here's a detailed comparison to help you understand the differences:

FeatureLite (Deprecated)Free ⭐Standard

Availability	Trial only 🧪	Trial only 🧪 (for now)	Trial & Production 🌍
Authentication	Basic Auth 🔓	OAuth 2.0 🔒	OAuth 2.0 🔒
Security Model	Username/Password	JWT tokens	JWT tokens
Number of Schedules	Limited 15 ⚠️	Limited 15 ⚠️	Unlimited ♾️
Minimal Interval	1 hour ⏰	1 hour ⏰	5 minutes ⚡
Multitenancy	❌	✅	✅
Alert Notification Service	❌	✅	✅
Cloud ALM Monitoring	❌	✅	✅
Alignment with Standard	Different behavior	✅	-
Support	Community 👥	Community 👥	SLA-backed 🛡️
Production Ready	Learning	Learning/Prototyping	✅ Yes

💡 Key Takeaway: Free plan gives you almost the same capabilities as Standard plan, just with thoughtful limitations perfect for learning and prototyping. When you're ready for production, the transition is seamless!

🎁 What You Get with the Free Plan

Let's celebrate what the Free plan brings to the table:

⏰ Hourly Scheduling

Schedule jobs every hour - perfect for periodic reports, cleanup tasks, and regular data processing.

📊 15 Schedules

More than enough for learning, testing, and small applications. Build real-world solutions without hitting limits!

🔔 Unlimited Alert Notifications

Integrate with SAP Alert Notification Service to get notified when jobs succeed or fail.

🔒 Production-Like Security

Learn OAuth 2.0 authentication in Trial, so you're ready for production. No re-learning required!

🏢 Multitenancy Support

Build and test tenant-aware applications right in your Trial account.

🚀 Full Feature Set

Access to Cloud Foundry tasks, async jobs, REST API - everything you need to build sophisticated scheduling solutions!

🎯 Who Should Use the Free Plan?

The Free plan is perfect for:

🎓 Students & Learners - Explore Job Scheduling without costs
🧪 Developers - Prototype and test scheduling logic
🎨 Proof of Concepts - Build demos and validate ideas
📚 Tutorial Followers - Work through our blog posts and documentation
🚀 Indie Developers - Power personal projects and experiments
🏢 Enterprises - Evaluate features before production deployment

🚀 Getting Started with Free Plan

Ready to make the switch? It's easy!

1️⃣ Create a Free Plan Instance

Using the SAP BTP Cockpit:

Navigate to your Trial subaccount
Go to Service Marketplace
Find SAP Job Scheduling Service
Click Create
Select service plan: free
Follow the wizard to complete creation

Using the Cloud Foundry CLI:

cf create-service jobscheduler free my-scheduler-free

2️⃣ Bind to Your Application

In your manifest.yml:

applications:
  - name: my-app
    services:
      - my-scheduler-free

Or create a service key for REST API access:

cf create-service-key my-scheduler-free my-key
cf service-key my-scheduler-free my-key

3️⃣ Start Scheduling!

Access the dashboard or use the REST API to create your first scheduled job!

🎊 Embrace the Upgrade!

This change is all about giving you a better experience. The Free plan:

✅ Teaches you production patterns - No surprises when you go live
✅ Unlocks more features - Do more with your Trial account
✅ Simplifies your journey - One security model to learn
✅ Future-proofs your code - OAuth 2.0 is the standard

We're excited for you to experience the improved capabilities of the Free plan! 🚀

📝 Appendix: Migration Guide (Optional)

If you currently have applications using the Lite plan and want to migrate to the Free plan, here's what you need to know:

Key Differences to Handle

🔐 Authentication Change: Basic Auth → OAuth 2.0

Lite Plan (Basic Auth):

// Simple HTTP basic authentication
const credentials = Buffer.from(`${username}:${password}`).toString('base64');
const response = await fetch(jobUrl, {
  headers: {
    'Authorization': `Basic ${credentials}`
  }
});

Free Plan (OAuth 2.0):

// OAuth 2.0 with JWT tokens
const xsenv = require('@sap/xsenv');
const passport = require('passport');
const { JWTStrategy } = require('@sap/xssec');

// Configure authentication
passport.use(new JWTStrategy(xsenv.getServices({ uaa: { tag: 'xsuaa' } }).uaa));

app.use(passport.initialize());
app.use(passport.authenticate('JWT', { session: false }));

📦 Service Binding Changes

Lite Plan:

No XSUAA service binding required
Simple username/password from service key

Free Plan:

Requires XSUAA service instance and binding
Uses JWT tokens for authentication
Service-to-service communication with OAuth 2.0

🔧 Migration Steps

Create Free plan instance

cf create-service jobscheduler free my-scheduler-free

Create or update XSUAA service instance

Create xs-security.json:

{
  "xsappname": "my-app",
  "scopes": [
    {
      "name": "$XSAPPNAME.Jobs",
      "description": "SAP Job Scheduling service Scope",
      "grant-as-authority-to-apps": [
        "$XSSERVICENAME(my-scheduler-free)"
      ]
    }
  ]
}

📖 Learn more: Secure Access to Job Scheduling Service

Create XSUAA instance:

cf create-service xsuaa application my-xsuaa -c xs-security.json

Update your application

Add dependencies to package.json:

{
  "dependencies": {
    "@sap/xsenv": "^5.3.0",
    "@sap/xssec": "^4.2.5",
    "passport": "^0.7.0",
    "express": "^4.21.2"
  }
}

Update manifest.yml

applications:
  - name: my-app
    services:
      - my-scheduler-free
      - my-xsuaa

Redeploy your application
```
cf push
```

💡 Need Help?

You can just drop a comment to start a discussion or look through the following resources:

Happy Scheduling with your new Free plan! 🎉🚀

The SAP Job Scheduling Service Team

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

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

Introduction

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

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

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

The Core Concept: Overriding the default BTP Service Operator configuration

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

Option 1: The manual approach

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

1. Prepare the Provider Subaccount

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

2. Create the Secret in Kyma

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

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

Option 2: The automated approach using Terraform

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

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

1. File provider.tf

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

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

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

2. File main.tf

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

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

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

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

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

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

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

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

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

  type = "Opaque"
}

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

For Bash:

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

export BTP_PASSWORD="your-password"

For Powershell:

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

$Env:BTP_PASSWORD = "your-password"

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

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

Summary

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

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

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

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

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

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

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

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

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

Real-world threats

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

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

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

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

The solution: Azure Arc + Defender for Containers

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

What gets installed:

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

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

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

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

How

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

Step 0 — Pre-flight checklist

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

1) Network egress (outbound)

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

2) Tooling

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

3) Cluster access

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

kubectl config current-context
kubectl cluster-info

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

Step 1 — Connect the cluster to Azure Arc

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

1.1 Register providers (if needed)

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

1.2 Run the connect command

From the Arc quickstart, the core command is:

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

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

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

What I’m explicitly setting there:

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

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

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

1.3 Verify Arc agents in the cluster

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

kubectl get deployments,pods -n azure-arc

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

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

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

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

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

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

The portal walkthrough is:

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

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

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

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

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

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

I use one of two flows.

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

This is the “guided remediation” path:

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

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

Option B: Deploy manually from the Arc cluster resource

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

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

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

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

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

Defender sensor extension:

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

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

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

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

Step 5 — Verify it’s actually working

This is where I slow down and prove success.

Microsoft’s verification checklist is:

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

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

5.1 Verify Arc connectivity

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

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

5.2 Verify Defender extension provisioning

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

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

5.3 Verify sensor pods

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

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

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

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

5.4 Verify in the portal

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

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

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

5.5 (Optional) Prove runtime detection by simulating alerts

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

It has two prerequisites that matter in practice:

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

Then I download and run the simulator:

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

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

(Docs: Kubernetes alerts — Kubernetes alerts simulation tool)

5.6 Inspect the alert details (example: binary drift)

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

Step 6 — Troubleshooting (the short list)

6.1 If an extension is stuck, check egress first

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

6.2 If things drift over time

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

Closing thoughts

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

centralized visibility,
actionable runtime alerts,
and runtime security signals

into a hybrid Kubernetes estate—without replatforming.

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

References (Microsoft Learn)

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

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

Introduction

Hello SAP Community!

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

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

The paradigm shift: From monolithic to a modular environment

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

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

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

Key Benefits for Partners and Customers:

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

The ecosystem enablers: Extensibility using CAP Plugins + Kyma Modules

SAP is providing enablers for the ecosystem on different levels:

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

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

Turning Kyma into a CAP Runtime

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

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

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

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

Just keep the defaults and press the Add button.

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

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

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

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

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

and further capabilities.

What’s Next?

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

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

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

A community powered by creativity

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

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

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

Celebrating the 2026 finalists

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

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

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

A strong field beyond the finalists

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

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

SYNC 2026: where the stage is yours

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

Keep the momentum going

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

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

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

SAP Business Technology Platform SAP Build SAP Integration Suite

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

Part 2: Runtime Architecture & Cost efficiency gains

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

Introduction

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

1. The Core Architecture paradigm: Declarative Tenant Management

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

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

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

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

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

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

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

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

3. Scaling without linear cost growth

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

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

4. Centralized Observability: Selective Logging

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

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

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

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

Summary: The Architect's choice

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

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

What’s Next?

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

Part 3: Automated Application Lifecycle Management in Action

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

Introduction

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

1. The Application Blueprint

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

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

includes for instance the CAPApplication Custom Resource:

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

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

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

2. Deploy and watch the automation

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

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

3. Native Monitoring in the Kyma Dashboard (Busola)

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

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

Here is an example showing the details of the CAPApplicationVersion.

CAPTenants

4. Subscriber tenant provisioning including specific tenant operations

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

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

5. Scaling your lifecycle operations

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

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

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

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

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

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

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

Summary: Kyma as the runtime for CAP Multitenancy SaaS applications

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

We have seen how to:

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

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

Reimagining Utility Transformation: Clean Core Principles Powered by SAP BTP

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

Introduction

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

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

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

Main Body

1. The Customization Cage: How Utilities Got Here

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

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

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

Resulting challenges:

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

Your first diagram captures this reality perfectly.

Diagram 1 — The Customization Cage

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

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

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

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

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

Key benefits:

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

3. A Practical Framework for Utility Clean Core Adoption

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

Step 1: Start With a Core Assessment

Identify:

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

This reframes Clean Core as risk reduction, not cleanup.

Step 2: Move High-Variability Logic to BTP First

Ideal candidates include:

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

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

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

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

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

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

Step 4: Establish Governance That Protects the Core

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

Governance is the long-term safeguard of Clean Core.

Step 5: Treat BTP as a Business Platform

Executives respond when BTP is positioned as:

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

Step 6: Build a 24‑Month Roadmap

A practical roadmap includes:

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

This provides clarity, sequencing, and measurable ROI.

4. The Modern Utility Innovation Stack

Your second diagram illustrates the future-state architecture:

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

Diagram 2 — The Utility Innovation Stack

Conclusion

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

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

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

SAP BTP provides the answer:

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

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

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

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

G’day!

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

Below is the structure of this article:

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

Let's begin:

1 Status Quo on En-/Decryption in BTP

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

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

The Challenge

2 Motivation

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

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

3 Fundamentals

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

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

4 Architecture

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

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

BTP Solution Architecture Kyma Microservice

5 HDLFS Configuration

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

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

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

HDLFS REST API Endpoint

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

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

HDLFS Configuration Connections

6 Insights into Python

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

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

Python Modules Sketch

Inbound Module (1)

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

This code snippet describes the parallel processing of files:

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

Sampel code of processing an individual file:

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

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

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

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

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

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

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

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

Outbound module (2)

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

Crypto Module (3)

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

The decrypt_symmetric function is implemented as follows:

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

Common Functions Module (4)

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

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

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

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

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

    return ctx

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

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

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

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

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

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

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

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

7 Containerization & Deployment in Kyma

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

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

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

Recommendations out of my personal learnings:

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

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

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

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

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

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

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

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

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

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

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

8 Achievements

The following functionality and service details were delivered:

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

9 More Scope

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

10 References

K8S/Kyma + Python SCN Blog

Getting Started with Data Lake Files HDLFSCLI

HDLFS REST API Guide

Thx...

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

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

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

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

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

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

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

🌟 What is the Free Tier?

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

Key Highlights

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

🎯 Who is the Free Tier For?

The Free tier is perfect for:

🧪 Proof of Concepts

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

🏢 Small Production Workloads

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

💼 Enterprise Evaluation

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

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

🆚 How Does Free Compare to Standard?

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

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

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

When to Choose Free

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

When to Update to Standard

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

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

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

🚀 How to create instance of Free Tier on BTP Live

Using the BTP Cockpit

Step 1: Access BTP Cockpit

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

Step 2: Find Job Scheduling Service

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

Step 3: Create Free Plan Instance

Using the BTP Cockpit:

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

Using the Cloud Foundry CLI

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

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

# Verify creation
cf service my-free-scheduler

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

🔄 Updating from Free to Standard

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

Using the BTP Cockpit

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

Using the Cloud Foundry CLI

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

# Restage your app to pick up changes

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

📚 Additional Resources

Documentation

Discovery Center

Job Scheduling Service in Discovery Center

Community

🎉 Start Scheduling Today!

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

⚖️ Terms and Conditions

Free tier service plans are subject to additional terms:

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

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

Happy Scheduling! 🎉

The SAP Job Scheduling Service Team

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

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

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

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

Introduction

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

What you'll learn:

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

Prerequisites

Before starting, you'll need:

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

Setup: Download Your Kubeconfig

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

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

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

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

# Verify connection
kubectl cluster-info

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

# Create namespace
kubectl create namespace demo-app

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

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

Pattern 1: Deployment and Routing with APIRules

CF Pattern:

cf push myapp

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

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

Deploy it:

kubectl apply -f deployment.yaml

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

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

Key differences:

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

Pattern 2: Service Bindings - From VCAP_SERVICES to Kubernetes Secrets

CF Pattern:

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

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

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

Deploy it:

kubectl apply -f xsuaa-instance.yaml

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

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

Option 1: Environment Variables

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

Option 2: Volume Mounts

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

Then read credentials from files:

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

Key differences:

Cloud Foundry Kyma

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

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

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

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

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

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

Key differences:

CF .profile Kyma Init Containers

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

Real-world use cases:

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

Pattern 4: Credential Store Integration

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

First, create the Credential Store service:

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

Then fetch credentials in an init container:

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

Why this matters:

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

Pattern 5: Destination Service Integration

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

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

First, create the destination in BTP Cockpit:

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

Then create the Destination service instance:

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

Use it in your Node.js app:

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

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

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

app.listen(8080);

Deploy with the secret mounted:

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

Key differences:

Cloud Foundry Kyma

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

Summary: CF vs Kyma Migration Checklist

Feature Cloud Foundry Kyma Equivalent

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

Key Takeaways

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

Conclusion

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

SAP Community - SAP BTP, Kyma runtime

SAL: SAP 'Integrity Protection Format' secured with Distributed Ledger Technology on SAP BTP Kyma 🚀

SAP EA - Real World Asset Tokenization with Distributed Ledger Technology on the SAP BTP Kyma 🚀

New Kyma Telemetry Docs: Simplified, Task-Oriented, and User-First

What's New for Our Users?

The 'Why' Behind the Change: A Look at the Craft

Why This Matters

Get Started Today

Your Feedback Matters

From Open Source to Help Portal: The Kyma Documentation Journey

Planning the Migration and Resetting Mindsets

Piloting Telemetry and Establishing a Repeatable System

Collaborating for Quality and Consistency

Results, Impact, and the Road Ahead

Authorization management with OpenSearch's Document Level Security - SAP Cloud Logging

OpenSearch Security Model Overview

Index-Level vs. Document-Level Security

The DLS Strategy: Restricting Views by Space ID

Use Case 1: Fixed Authorization for Specific Spaces (Space-A and Space-B)

Step 1: Create IAS Groups (Backend Roles)

Step 2: Define OpenSearch Roles

Step 3: Map Backend Roles to OpenSearch Roles

Use Case 2: Multi-Space Access for Shared Teams (e.g., Finance)

Use Case 3: Using Other Fields

Use Case 4: Parameter Substitution for Dynamic Authorization

High-Level Overview: IAS Group Mapping and Space-Based Access Control in OpenSearch

Important Considerations (DLS Best Practices)

1. Avoid Wildcard Index Match (*) :

2. DLS and Write Permissions:

3. Admin Roles Combined with DLS Roles

Workaround to Give Admins Full Access

4. DLS Query Syntax: Precision is Key

Term Look up:

Event Driven SAP CAP on Kyma with Agentic AI and UI Auto Refresh

Streamlined Kyma deployment for CAP applications

🎄 Ho Ho Ho! A Christmas Present from SAP Job Scheduling Service: Free Plan on BTP Trial 🎁

🎁What's Under the Tree?

📋Plan Details

🤔Why Free? Why not using Lite plan?

🎅Technical Features: What's in Your Stocking?

⏰Minimal Schedule Interval: 1 Hour

📊Number of Schedules: 15

🔔Send Events to SAP Alert Notification Service: Unlimited

🎄Feature Comparison Table

🎅Getting Started

🎁Perfect For...

🌟Happy Scheduling!

📚Additional Resources

SAP Integration Suite Workflows with Job Scheduling Service 🚀

Schedule Your SAP Integration Suite Workflows with Job Scheduling Service – Secured with JWT Authentication! 🔐🚀

Prerequisites

Create Job Scheduling Service Instance

Using BTP Cockpit

Using CF CLI

Create a Job in Job Scheduling Service that Triggers the Integration

Step 1: Get Your Integration API Endpoint URL

Step 2: Open the Job Scheduling Dashboard

Step 3: Create a Job

Step 4: Create a Schedule

Step 5: Verify the Job Execution

Secure the Integration Endpoint

Understanding the JWT Verification Flow

Step 1: Get Your Job Scheduler Service Key

Step 2: Open Your API in Integration Suite

Step 3: Add JWT Verification Policies

3.1 Add Service Callout Policy

3.2 Extract Public Certificates

3.3 Add Verify JWT Policy

Step 4: Save and Deploy

Step 5: Understanding the Policy Flow

Testing the Secured Integration

Test 1: Job Scheduler Should Succeed

Test 2: Direct API Call Should Fail

Test 3: Wrong Job Scheduler Instance Should Fail

Conclusion

What You've Learned

Key Takeaways

Next Steps

Troubleshooting

Problem: "Invalid token" error

**1. Avoid Wildcard Index Match (`*`) :**