SAP Community - SAP BTP, Kyma runtime

Handling CSV Data Deployment in CAP HDI Without Data Loss

2025-06-04T03:22:59.880000+02:00

Handling CSV Data Deployment in CAP HDI Without Data Loss

Introduction

In SAP CAP, deploying CSV data using .hdbtabledata files means the HDI container assumes full ownership of the data. As a result, any changes to the CSV file will overwrite the table content during the next deployment.

Background

Have you ever encountered a scenario where updating CSV data led to unexpected data loss? Here’s our experience:

In our hdi-content module, we maintained a UOM.csv (Unit of Measure) file, which is preloaded into the UOM table. This ensures that customers subscribing to our SaaS solution, SAP Omni Channel Promotional Pricing (OPPS), have immediate access to standard UOMs for defining product promotions. Since the UOM table is also exposed via CAP CDS views in the Fiori UI, customers can add their own entries as well.

The Issue

While working on a new feature that introduced another table with pre-delivered data, we discovered that any modification to the CSV file—such as adding or updating UOMs—could result in the loss of customer-maintained data in the UOM table. With many customers using our SaaS solution, this posed a significant risk of accidental data loss whenever the UOM.csv content was changed.

We needed a reliable solution to prevent customer data loss during deployments.

Exploring CAP Recommendations

According to the CAP documentation, you can use the include_filter option in .hdbtabledata to restrict which records are affected. This requires an additional column to distinguish between CSV data and user-generated data. In our case, we already had an origin column:

origin = '02': CSV data
origin = '10': Customer-created entries

However, even with include_filter, we found that customer data was still being lost, and only the CSV content remained after deployment.

The CAP troubleshooting guide references SAP Note 2922271, but its solution is tailored for @SAP/hdi-deploy and not directly applicable to @SAP/hdi-dynamic-deploy.

The Solution

With support from the HANA-DB-DI team, we identified a practical approach to address this challenge. We hope sharing this helps others building multitenant applications on CAP and HANA Cloud.

Deployment 1: Undeploy .hdbtabledata Without Deleting Data

First, set the HDI deployer's environment variable HDI_DEPLOY_OPTIONS in your MTA module properties to ensure the .hdbtabledata file is undeployed without deleting any data from the target table. Use the following configuration:

{
  "undeploy": [
    "src/gen/OPPC-UOM.hdbtabledata"
  ],
  "path-parameter": {
    "src/gen/OPPC-UOM.hdbtabledata:skip_data_deletion": "true"
  }
}

Then, proceed with the deployment and database upgrade. The logs below show this process:

2025-06-03T20:20:48.69+0530 [APP/PROC/WEB/0] OUT [9d2219cebfa570a2]: Undeploying "src/gen/OPPC-UOM.hdbtabledata"...
2025-06-03T20:20:48.69+0530 [APP/PROC/WEB/0] OUT [9d2219cebfa570a2]: Undeploying "src/gen/OPPC-UOM.hdbtabledata"... ok (0s 0ms)
2025-06-03T20:20:48.69+0530 [APP/PROC/WEB/0] OUT [9d2219cebfa570a2]: Deploying "src/gen/OPPC.UOM.hdbtable$OPPC_UOM.validate"...
2025-06-03T20:20:48.69+0530 [APP/PROC/WEB/0] OUT [9d2219cebfa570a2]: Expanded from "src/gen/OPPC.UOM.hdbtable"
2025-06-03T20:20:48.69+0530 [APP/PROC/WEB/0] OUT [9d2219cebfa570a2]: Undeploying "src/gen/OPPC-UOM.hdbtabledata$0.expand"...
2025-06-03T20:20:48.69+0530 [APP/PROC/WEB/0] OUT [9d2219cebfa570a2]: Expanded from "src/gen/OPPC-UOM.hdbtabledata"
2025-06-03T20:20:48.69+0530 [APP/PROC/WEB/0] OUT [9d2219cebfa570a2]: The "skip_data_deletion" make parameter is set; no data will be deleted from the target table "OPPC_UOM"
2025-06-03T20:20:48.69+0530 [APP/PROC/WEB/0] OUT [9d2219cebfa570a2]: Deploying "src/gen/OPPC.UOM.hdbtable$OPPC_UOM.validate"... ok (0s 11ms)
2025-06-03T20:20:48.69+0530 [APP/PROC/WEB/0] OUT [9d2219cebfa570a2]: Undeploying "src/gen/OPPC-UOM.hdbtabledata$0.expand"... ok (0s 12ms)

Deployment 2: Deploy .hdbtabledata with include_filter

Remove the HDI deployer's HDI_DEPLOY_OPTIONS environment variable used in the previous deployment.
Update the .hdbtabledata file to include the include_filter option.
Deploy and upgrade the database.

However, this deployment failed because the include_filter matched existing records in the table, as shown in the logs:

2025-06-03T20:31:52.57+0530 [APP/PROC/WEB/0] ERR Error: com.sap.hana.di.tabledata: The "include_filter" definitions match with 4364 records that already exist in the "OPPC_UOM" table [8251521]
2025-06-03T20:31:52.57+0530 [APP/PROC/WEB/0] ERR Error: com.sap.hana.di.tabledata: Deploying "src/gen/OPPC-UOM.hdbtabledata$0.expand"... failed [8212145]
2025-06-03T20:31:52.57+0530 [APP/PROC/WEB/0] ERR Error: Worker 1 has encountered an error; all remaining jobs will be canceled [8214600]
2025-06-03T20:31:52.57+0530 [APP/PROC/WEB/0] ERR Error: Processing work list... failed [8212102]
2025-06-03T20:31:52.57+0530 [APP/PROC/WEB/0] ERR Error: Making... failed [8211605]
2025-06-03T20:31:52.57+0530 [APP/PROC/WEB/0] ERR Error: Starting make in the container "679623F6772E4C3BA111AB4C1775754E" with 1 files to deploy, 0 files to undeploy... failed [8214168]

This deployment would only succeed if the database entries matching the CSV content were removed beforehand. In a multitenant application with many productive subscriptions, manually removing data for all tenants is not practical, and we lacked an automated solution for this process.

Possible Approaches

Automated Cleanup: If the origin values are consistently determined by application logic, you could develop an automated task to clean up these records. This cleanup would need to be performed as a separate deployment step before deploying the .hdbtabledata file, though this approach requires additional effort.
Alternative Approach: Instead, you can maintain new CSV content with a different origin value (e.g., origin='03'). This way, only the new CSV data is redeployed, and all existing data in the database table remains unchanged. Adjust the include_filter to target origin='03'.

The following logs show a successful deployment using the approach of assigning a new origin value for new entries:

2025-06-03T20:36:18.52+0530 [APP/PROC/WEB/0] OUT [be82fcfafc2dc1ee]: "src/gen/OPPC-UOM.hdbtabledata"
2025-06-03T20:36:18.52+0530 [APP/PROC/WEB/0] OUT [be82fcfafc2dc1ee]: ]
.
.
.
2025-06-03T20:42:49.12+0530 [APP/PROC/WEB/0] OUT [d9a3e16053ae1f81]: Undeploying "src/gen/OPPC-UOM.hdbtabledata$0.expand"...
2025-06-03T20:42:49.12+0530 [APP/PROC/WEB/0] OUT [d9a3e16053ae1f81]: Expanded from "src/gen/OPPC-UOM.hdbtabledata"
2025-06-03T20:42:49.12+0530 [APP/PROC/WEB/0] OUT [d9a3e16053ae1f81]: Deploying "src/gen/OPPC.UOM.hdbtable$OPPC_UOM.validate"...
2025-06-03T20:42:49.12+0530 [APP/PROC/WEB/0] OUT [d9a3e16053ae1f81]: Expanded from "src/gen/OPPC.UOM.hdbtable"
2025-06-03T20:42:49.12+0530 [APP/PROC/WEB/0] OUT [d9a3e16053ae1f81]: Deploying "src/gen/OPPC.UOM.hdbtable$OPPC_UOM.validate"... ok (0s 7ms)
2025-06-03T20:42:49.12+0530 [APP/PROC/WEB/0] OUT [d9a3e16053ae1f81]: Undeploying "src/gen/OPPC-UOM.hdbtabledata$0.expand"... ok (0s 15ms)
2025-06-03T20:42:49.12+0530 [APP/PROC/WEB/0] OUT [d9a3e16053ae1f81]: Undeploying "src/csv/OPPC-UOM.csv"...
2025-06-03T20:42:49.12+0530 [APP/PROC/WEB/0] OUT [d9a3e16053ae1f81]: Undeploying "src/csv/OPPC-UOM.csv"... ok (0s 5ms)
2025-06-03T20:42:49.12+0530 [APP/PROC/WEB/0] OUT [d9a3e16053ae1f81]: Deploying "src/csv/OPPC-UOM.csv"...
2025-06-03T20:42:49.12+0530 [APP/PROC/WEB/0] OUT [d9a3e16053ae1f81]: Deploying "src/csv/OPPC-UOM.csv"... ok (0s 3ms)
2025-06-03T20:42:49.12+0530 [APP/PROC/WEB/0] OUT [d9a3e16053ae1f81]: Deploying "src/gen/OPPC-UOM.hdbtabledata$0.expand"...
2025-06-03T20:42:49.12+0530 [APP/PROC/WEB/0] OUT [d9a3e16053ae1f81]: Expanded from "src/gen/OPPC-UOM.hdbtabledata"
2025-06-03T20:42:49.12+0530 [APP/PROC/WEB/0] OUT [d9a3e16053ae1f81]: Inserted 1 records of the data source file "OPPC-UOM.csv" into the target table "OPPC_UOM"
2025-06-03T20:42:49.12+0530 [APP/PROC/WEB/0] OUT [d9a3e16053ae1f81]: Deploying "src/gen/OPPC-UOM.hdbtabledata$0.expand"... ok (0s 43ms)

Optimal Approach:

Automated Data Cleanup Using SAP HANA Migration Tables

Using origin='03' for new CSV entries solves the issue for existing HDI containers. However, for new subscriptions, these containers won’t have the standard CSV content (origin="02") auto-inserted.

SAP HANA provides a robust feature called Migration Tables (.hdbmigrationtable) that enables seamless and automated data cleanup. For more details with a real-world example, refer to HANA Database Migration: Handling Incompatible Changes to Existing Tables

Migration tables simplify automated cleanup—no changes to your current system behaviour are needed!

Deployment 1: Initial Setup

Add HDI plugin "com.sap.hana.di.table.migration" to src/.hdiconfig

 "hdbmigrationtable": {
      "plugin_name": "com.sap.hana.di.table.migration"
  }

Create /src/OPPC.UOM.hdbmigrationtable
This file is generated during the CDS build step when you annotate your entity with @cds.persistence.journal. This instructs CAP to create a migration table, enabling versioning and data migrations.
Example:

== version=1
COLUMN TABLE OPPC_UOM (
  CODE NVARCHAR(5) NOT NULL,
  LANGUAGE_CODE NVARCHAR(2) NOT NULL,
  COMMERCIAL_DESCRIPTION NVARCHAR(3),
  LONG_DESCRIPTION NVARCHAR(30),
  ORIGIN NVARCHAR(2),
  PRIMARY KEY(CODE, LANGUAGE_CODE)
) WITH ASSOCIATIONS (
  MANY TO ONE JOIN OPPC_ISOCodeMapping AS isoCodeMapping ON (isoCodeMapping.CODE = CODE)
)

The structure is similar to /src/gen/OPPC.UOM.hdbtable, but includes the migration version header.

Add /src/gen/OPPC.UOM.hdbtable to undeploy.json
This step removes the static table definition from the HDI container, preventing conflicts with the migration table.
Set HDI_DEPLOY_OPTIONS for Controlled Undeployment
Configure HDI_DEPLOY_OPTIONS to undeploy /src/gen/OPPC-UOM.hdbtabledata without deleting data in the OPPC_UOM table. This preserves existing data during artifact changes.
Deploy and InitDB
Deploy the changes and perform the InitDB operation.

Deployment 2: Data Migration and Filtering

Remove HDI_DEPLOY_OPTIONS
After the initial migration, remove the custom deploy options to restore standard deployment behavior.

Update /src/OPPC.UOM.hdbmigrationtable for Data Migration
Increment the migration version and add a migration block to delete entries where ORIGIN = '02'. This is important if you plan to use an include_filter in your table data, as existing data may conflict with new constraints.
Example:

== version=2
COLUMN TABLE OPPC_UOM (
  CODE NVARCHAR(5) NOT NULL,
  LANGUAGE_CODE NVARCHAR(2) NOT NULL,
  COMMERCIAL_DESCRIPTION NVARCHAR(3),
  LONG_DESCRIPTION NVARCHAR(30),
  ORIGIN NVARCHAR(2),
  PRIMARY KEY(CODE, LANGUAGE_CODE)
) WITH ASSOCIATIONS (
  MANY TO ONE JOIN OPPC_ISOCodeMapping AS isoCodeMapping ON (isoCodeMapping.CODE = CODE)
)

== migration=2 
DELETE FROM "OPPC_UOM" WHERE "ORIGIN" = '02';

Add /src/gen/OPPC.UOM.hdbtable and /src/csv/OPPC-UOM.csv to undeploy.json
This ensures obsolete artifacts and data files are removed from the HDI container.
Move Data Files to a Static Folder
Relocate OPPC-UOM.hdbtabledata and OPPC-UOM.csv to a dedicated static folder (e.g., src/static/csv). This prevents CDS from auto-generating a .hdbtabledata file for OPPC-UOM.csv since you need to customise OPPC-UOM.hdbtabledata with an include_filter.
Modify OPPC-UOM.hdbtabledata to Filter Data
Update the file to only include records where ORIGIN = '02', ensuring only relevant data is loaded.
Deploy and InitDB
Deploy the changes and perform the InitDB operation.

References

Special Thanks

Special thanks to the HANA-DB-DI team members, particularly Pavel Sluzkin and Alexander Bunte, for their invaluable support and guidance!

SAP Developer News June 5th, 2025

2025-06-05T21:10:00.051000+02:00

DESCRIPTION

PODCAST: https://podcast.opensap.info/sap-developers/2025/06/05/sap-developer-news-june-5th-2025/

New SAP Certified Associate - SAP Business Data Cloud

Webinar Series: Architecting Your SAP Business Data Cloud Journey – From Data to Intelligence: https://community.sap.com/t5/enterprise-architecture-blog-posts/new-webinar-series-architecting-your-sap-business-data-cloud-journey-from/ba-p/14104348

New SAP Certified Associate - SAP Business Data Cloud: https://learning.sap.com/certifications/sap-certified-associate-sap-business-data-cloud

Learning Journey: Exploring SAP Business Data Cloud: https://learning.sap.com/learning-journeys/exploring-sap-business-data-cloud

New ways to install the Terraform Exporter for SAP BTP

Installation information https://sap.github.io/terraform-exporter-btp/install/

SAP CodeJam Roadshow – US AI

https://community.sap.com/t5/sap-codejam/getting-started-with-generative-ai-hub-on-sap-ai-core-new-york-new-york-usa/ev-p/14099369

https://community.sap.com/t5/sap-codejam/getting-started-with-generative-ai-hub-on-sap-ai-core-palo-alto-ca-usa/ev-p/14101603

https://community.sap.com/t5/sap-codejam/getting-started-with-generative-ai-hub-on-sap-ai-core-houston-tx-usa/ev-p/14101612

SAP CodeJam Roadshow 2025 – Latin America edition

SAP CodeJam Roadshow 2025 - Latin America edition 🇧🇷 🇵🇪 🇲🇽 🇨🇴 (July 25th - Aug 12th 2024): https://community.sap.com/t5/sap-codejam-blog-posts/sap-codejam-roadshow-2025-latin-america-edition-july-25th-aug-12th-2024/ba-p/14093930

CHAPTER TITLES

0:00 Intro

0:10 New SAP Certified Associate - SAP Business Data Cloud

1:08 New ways to install the Terraform Exporter for SAP BTP

2:01 SAP CodeJam Roadshow – US AI

3:33 SAP CodeJam Roadshow 2025 - Latin America edition

TRANSCRIPTION

[Intro] This is the SAP Developer News for June the 5th, 2025.

[Witalij] This month, we at SAP launched a new webinar series titled Architecting Your SAP Business Data Cloud Journey, From Data to Intelligence. This series kicks off this week with a discussion on data and AI strategy across SAP business applications, followed by a deep dive into our latest data offering, SAP Business Data Cloud. Additional topics include BWM modernization, SAP Databricks, and transition paths to SAP BBC. Building on this foundation, we invite you to validate your expertise by taking the new SAP Business Data Cloud certification exam. The certification confirms your solid understanding of SAP Business Data Cloud, and it demonstrates that you possess both the broad overview and essential skills needed to contribute effectively within project teams. enjoy the learning journey and good luck with the exam links are in the description

[DJ] there's a great update for the terraform exporter for sap btp which we've covered in previous episodes on this show so as well now as being able to download the binary for your os the binary of the tool you can now install the tool via package managers for Mac OS there's brew for windows there's winget and soon also chocolatey and of course for linux you have installation package manager mechanisms for debian based and rpm based distributions great this is going to make the management of the life cycle of the tool a lot more comfortable for us check out the updated installation information link is in the description

[Rich] Hello, friends. Rich Heilman here. Hope everyone is doing well. I just wanted to pop on here and let you all know about the SAP Code Jam Roadshow in the U.S. that is happening in just about two weeks. This roadshow will include three stops, and we will be focusing on the topic of getting started with Generative AI Hub on SAP AI Core. The first stop will be on June 23rd in the very heart of New York City. I always love doing these short trips to New York City. It sort of fulfills my childhood craving to live and work in the big city, even for just a day or two. So I'm looking forward to that. And then Tom and I will attempt to jump on a plane out of Newark, New Jersey. wish us luck and fly to the west coast for our next stop on June 25th in beautiful palo alto California if you haven't visited the bay area absolutely stunning sights especially for us East coasters so check it out and then from there I'm going to attempt to get back to Newark wish me luck and Tom will then be joined by Mimiki for the last stop in Houston on June 27th So it's shaping up to be a great trip, but that's not the only roadshows happening this year. And I know that my friend Antonio has some details on that. So over to you, Antonio.

[Antonio]Thanks, Rich. Hola, SAP developers. We just announced the second Latin America Code Jam Roadshow, which will take place between the 25th of July and the 12th of August. This time, Rich and Tom will join the roadshow, and we will be doing CodeJams on ABAP Cloud and the Generative AI Hub. We kick things off with the Generative AI CodeJam in Sao Paulo, Brazil. And then we'll be doing both CodeJams in Lima, Peru, Mexico City, and Bogota, Colombia. Similar to last year, we will also do meetups in the different locations. Vamos a ter un encontro SAPI en Sao Paulo. En quedadas en Lima,Ciudad de México y Bogotá. Make sure to check out the blog post to find all the details of the roadshow and check out each event to learn which developer advocate will be at the different events. Até pronto. Nos vemos pronto.

Enhancing Efficiency with SAP Job Scheduling Service and SAP Cloud ALM

2025-06-13T09:20:40.546000+02:00

What's New for SAP Business Technology Platform has recently announced the integration between the SAP Job Scheduling service and SAP Cloud ALM, designed to streamline operations and enhance efficiency.

This integration allows for seamless management and monitoring of scheduled jobs, providing a more cohesive experience by letting you track the status of your job processes directly from the UI of SAP Cloud ALM.

What Is SAP Job Scheduling Service?

SAP Job Scheduling service is a cloud-based tool that runs on SAP Business Technology Platform (SAP BTP), both in the Cloud Foundry and Kyma environments. It enables you to automate and manage job scheduling across various applications. It helps in optimizing resource allocation and ensuring that tasks are executed at the right time, thereby improving operational efficiency.

For more information, refer to:

Integration with SAP Cloud ALM

SAP Cloud ALM is a cloud-based application lifecycle management solution that helps you streamline the implementation and operation of your cloud and hybrid business solutions.

The integration with SAP Job Scheduling service allows you to monitor job execution directly within the SAP Cloud ALM environment. This means you can now track job statuses, view logs, and receive alerts, all from a single interface, reducing the need to switch between different platforms.

For more information about the integration and how you can enable it, refer to:

Your Opinion Matters

Let us know what you think about the integration with SAP Cloud ALM. We would love to learn more about your experience with it so that we can make your job scheduling journey as smooth as possible.

We are also committed to enhancing the overall user experience of the SAP Job Scheduling service. To achieve this, we invite you to participate in a feedback survey accessible via the Job Scheduling service dashboard. Your insights are invaluable in helping us improve the look and feel of the dashboard, ensuring it meets your needs and expectations.

To leave us feedback via the UI of the dashboard, just choose Join our user survey!

Additionally, if you want to give us feedback on the quality of the documentation on SAP Help Portal, check out the Participate in the Documentation Feedback Survey for SAP Job Scheduling Service blog post to learn more.

We look forward to hearing from you and thank you for your continued support.

Also, feel free to share your thoughts and experiences in the comments below. Your input is always appreciated!

SAP BTP runtimes, my personal considerations and preferences on Cloud Foundry, Kyma, ABAP runtimes

2025-06-18T05:16:50.773000+02:00

In this fast-paced environment... Nah, just kidding! This is not another AI generated or soulless marketing blog post plaguing the internet. This is about SAP BTP runtimes, and my personal preferences. I know, I know... There's an SAP badge next to my name, but it's because I couldn't keep my personal community profile detached from my SAP email due to reasons in the new community platform... So, ignore the badge, it's my own view, oversimplified and full of silly examples, not a recommendation nor official position from SAP. Don't read this and go back to your boss saying "hey, SAP is telling us that runtime A is better than B".

You may know that SAP BTP offers three runtimes where you can deploy and run your custom applications. We can pick and choose whatever we want. We can run everything in just one runtime, or, we can have workloads in all of them at the same time. You can adopt the runtimes according to your needs and/or skills.

There is always somebody asking me about the SAP BTP runtimes. What they offer, their limitations, their features, when to use this, how to use that. Sometimes they just want to confirm whatever they're using is right. Sometimes they have no idea they had options. I'd say this is a bit shocking for those coming from the ABAP on-premise world: “we have options!?!?!”.

* Runtimes / Environments

Yes, runtimes and environments are the same thing... No, I won't talk about Neo Environment because it's deprecated, it'll sunset on 31/12/2028.

Let's see a short description of runtimes before getting into more details.

Cloud Foundry Environment

"The Cloud Foundry environment enables you to develop new business applications and business services, supporting multiple runtimes, programming languages, libraries, and services. You can leverage a multitude of buildpacks, including community innovations and self-developed buildpacks."... from SAP BTP documentation

Kyma Environment

"SAP BTP, Kyma runtime provides a fully managed cloud-native Kubernetes application runtime based on the open-source project "Kyma". Based on modular building blocks, Kyma runtime includes all the necessary capabilities to simplify the development and to run enterprise-grade cloud-native applications."... from SAP BTP documentation

ABAP Environment

"The ABAP environment is based on the latest ABAP platform cloud release that is also used for SAP S/4HANA Cloud. It leverages the innovations provided by SAP HANA. The software stack contains standard technology components that are familiar from the standalone Application Server ABAP. The ABAP environment supports the ABAP RESTful Application Programming Model including SAP Fiori and Core Data Services (CDS)."... from SAP BTP documentation

* Supported languages

The programming language you use can limit what you do and how fast you can deliver

Cloud Foundry Environment

CF supports pretty much any language as long as you have a buildpack for that. There are official buildpacks maintained by the Cloud Foundry Foundation, by SAP itself and others by the CF community. The Node.js buildpack is a good example.

Kyma Environment

Kyma also supports any language as long as you have a container to run it. Some languages have their official container images which you can use as-is or customize as you wish. The Node.js Docker image is a good example.

ABAP Environment

ABAP is quite obvious. It only supports ABAP, but not your old school ABAP report declaring internal tables like DATA: lt_mara TYPE TABLE OF mara WITH HEADER LINE. It only runs ABAP Cloud, a subset of the ABAP language tailored to modern days.

* Performance

In terms of performance, all runtimes can deliver great results. They'll be mostly limited by how your applications were built. Translation: if the application is too slow, your code is the problem, not the runtime.

Nevertheless, there'll be a threshold where even the highest quality app won't cope with high demand. There's no magic number, it varies. This is a hurdle overcome by good software engineering and scalability.

* Scalability / Elasticity

Scalability in CF and Kyma is quite flexible and granular. Vertical and horizontal scaling are available. You can automatically scale up and down your applications. No need to touch it, no manual monitoring, no manual resource allocation, no need to guess what the workload demand will look like next Wednesday at 4:20 AM AEST time.

Your cool AI powered app is being bombarded by incoming requests from all the customers accessing it? No problem, new instances can be created and destroyed based on rules such as memory or CPU usage. For example, if the app is consuming more than 90% of CPU, spawns a new instance to share the workload. If the CPU usage goes down, let's say under 50%, stop and kill the previously spawned instance.

You have 1000 apps, but just 1 app is under stress? No problem, you can scale up just that one app! CF and Kyma run everything in containers. They're fully isolated and have their own resources. For instance, app AAA has 1 GB memory available for itself, app BBB has 5 GB and app CCC has 256 MB. You can also change the allocated memory at any time. For instance: “oh, I thought my app would need 2 GB RAM, but it actually needs 1 GB”. No problems! Adjust it without changing the code nor redeploying the app.

You may have a rule dictating apps will always have at least 2 instances running to distribute the workload. This is actually a best practice and encouraged to be adopted. Perhaps you don't need an app with 6 GB memory, but 3 instances of the same app with 2GB each. Running multiple instances is how you enable high availability for your apps as well, if one instance crashes the others keep working. It also enables zero downtime deployments.

Oh, the beauty of the cloud! 😍 Can you imagine doing these things in your ALV reports running on SAP ECC 6.0?

Cloud Foundry Environment

The service Application Autoscaler provides everything you need to manage scaling your apps. It's just a configuration. If you have an app with 1 instance or 99 instances running, nothing changes for you as a developer, system admin or end user. CF Load Balancers take care of distributing the incoming requests between all the instances. It's transparent and super smooth. Just make sure to gracefully shutdown your apps to avoid serving requests from a stopping instance. I'd written and spoken about graceful shutdown before, have a look: blog post + video.

Kyma Environment

Pretty much the same as CF. You define the configuration rules, the load balancer takes care of distributing the traffic. You don't need to code this behaviour, the Keda module available in the runtime does that for you. Kyma is powerful, and much more flexible than other runtimes. You can scale to zero nodes. You can use heaps of scalers out-of-the-box. You can also create pretty much any custom rule: if it's Wednesday, and it's raining, and Bitcoin is under 100k, spin up a new instance ¯\_(ツ)_/¯

ABAP Environment

Ok, now we'll see a big difference. You cannot have multiple copies of your app as in CF/Kyma. You have no granularity as the ABAP environment resources are shared between all applications. Everything runs in "one" box, vertical scaling is the only option. You either bump the whole environment or don't, pretty much the same as in on-prem servers. Have a look at Elastic Scaling of the ABAP Application Server. Yes, the service supports High Availability.

* Resource isolation

Let's do a mental exercise to understand resource allocation and isolation a little bit more. Think about the following scenario. You have 100 apps running at the same runtime. You deploy a change to 1 of those apps. The code change has a bug! The app goes into an infinite loop, starts consuming 100% of CPU and becomes unresponsive. What happens to the other apps?

Cloud Foundry Environment

Nothing. The other 99 apps are running in their own containers, fully isolated with their own resources (limited memory and CPU per app). Only users using the buggy app will be impacted. Users accessing other apps won't have any issues.

Kyma Environment

Same as CF. Hooray to containers! 🍻

ABAP Environment

I'm sorry to say, but you messed up badly. All 100 apps will be unresponsive. All users, even the ones not using the app in infinite loop will be impacted. The bug just caused a company wide issue.

Let's stretch this example a bit more to make a point. Your company has 5000 users consuming those apps in SAP BTP ABAP runtime. The buggy app is a tiny noncritical one being used by 2 users from IT to import data from Excel to HANA (😉). Because the bug is impacting the whole ABAP runtime, everyone is affected, 5000 users will complain they can't use their apps.

Resources are shared here, there's no app isolation. You cannot say one app will use only 512 MB, one app can consume all resources available in the environment. As I said, it's the same behaviour as in SAP ABAP Netweaver servers. You can think about it as a big gaming desktop running ABAP.

* Developer experience (DX)

Let's be honest, DX was neglected for a long time in SAP. It started changing when ADT was introduced for Eclipse users. Nowadays, DX in SAP BTP can be great! People can use the same modern tools the cool kids are using out there.

Cloud Foundry Environment

When developing applications to run in CF, you focus on the code, not much on the infrastructure to run it. You write your code, build and deploy it. CF will get the request, build the container, put your app inside the container, prepare everything, execute the app and make it available for you.

You have a bunch of tools to use from SAP, from Cloud Foundry and from both communities. Endless options for pretty much everything!

A simple "Hello World" app can go like this: write the code (easy), prepare the manifest.yml (easy) or a mta.yaml (can be overwhelming) and push to CF (easy). The app is ready to be used.

Kyma Environment

Your attention is needed on both code and infrastructure. Have you ever worked with Kubernetes? It's the same. Deploying to Kyma can be a bit scary as its manifest.yml is even more complex than the mta.yaml file in CF. Kyma also requires you to manage the container you want to run your application in. You must build the container before deploying your app. You won't get anywhere without a good amount of knowledge.

Again. You have a bunch of tools to use from SAP, from Kubernetes and from both communities. Endless options for pretty much everything!

A simple "Hello World" app can go like this: write the code (easy), prepare the container image you want to use (it may involve multiple steps and can be hard, especially for beginners), prepare the manifest.yml (hard) and push to Kyma (easy).
The app is ready to be used.

ABAP Environment

You have no choice of IDE, you must use Eclipse with ADT plugin. No SAP BAS nor Build Code. All ABAP tools are provided by SAP. You need a fair amount of knowledge to get started. It might be intimidating for noobs without any ABAP skills.

You may find some open source projects, but let's be honest, other than ABAPgit, the ABAP open source community doesn't have much in terms of tooling. It's pretty much 3 absolute amazing guys caring the whole community on their shoulders: Lars Hvam, Marcello Urbani and Marc Bernard.

A simple "Hello World" app can go like this: write the code (kinda easy, too many moving pieces, too verbose), push to ABAP Environment (kinda easy), activate it (easy). The app is ready to be used.

* Skills / Skill set

It's quite obvious, but for all the three runtime options, you need to know the language you want to use, eg. Node.js or Java or Python, and the tooling for that specific language (linting, code quality, automated testing, profiling, etc).

Recruiters complain they can't find resources, that there are no SAP BTP Developers out there. IMO, they're looking in the wrong place, developers don't need to speak SAP to work on SAP BTP. A SAP BTP Developer is “just” a developer who knows any modern language and cloud platforms. Get a Java developer with Kubernetes knowledge and they'll be deploying to SAP BTP on the same day. Youngsters in universities know at least one of the languages behind CAP (Node.js/Java) and play with cloud platform/services everyday. They're way ahead in the cloud game than ABAPsaurs like us 🥲

Cloud Foundry Environment

Git is a must! You can get far with little CF knowledge. You don't have to know containers, eg. Dockers, but it can be handy. It's the most beginner friendly of all runtimes.

Kyma Environment

Git for sure! Containers are a must, you won't do anything without knowing Dockers or similar. The learning stage can be challenging, it requires knowledge in many new concepts at once. You must know Kubernetes. It can be a bit harder to debug issues due to more moving parts.

ABAP Environment

Look at you! ABAP also requires git! You must know ABAP Cloud and ABAP RESTful Application Programming Model (RAP). Old school ABAP knowledge may be helpful, but even for skilled ABAPers it can be challenging. For beginners, it can be a nightmare.

The RAP level required is not like singing along with Ice Cube in It Was A Good Day:

ABAP RAP is more like Eminem in Rap God when he reaches supersonic speed (verbose is an understatement):

* DevOps

Both CF and Kyma have plenty of options. You can use SAP BTP services like SAP Continuous Integration and Delivery / SAP Cloud Transport Management. A Jenkins plugin from SAP called Project Piper. Or, anything else that you already use in the company. Are you using MS Azure DevOps? No problem! You can keep using your CI/CD pipelines there to test and deploy your apps to SAP BTP. Are you a big fan of GitHub Actions? Great! Just use that.

ABAP doesn't give you many options. You can use the ones provided by SAP.

Regardless of the DevOps platform you're using, I'd strongly recommend SAP Cloud Transport Management (CTMS) for deployment. Don't do manual deployments or use CLI tools for that. The CI/CD process may run in non-SAP DevOps platforms, but deployment to SAP BTP should go through CTMS. You can integrate external CI/CD pipelines, eg. Azure DevOps or CircleCI, to CTMS via APIs, or, with my open source project for GitHub Actions: Deploy to SAP BTP with Cloud Transport Management Service (CTMS). With CTMS, you have full control on the changes going through the landscape, and have a proper audit log to trace them if required.

* Limitations

As everything else in the universe, runtimes have limits. They may not be a problem, but you should know and consider them when adopting any runtime. Again, you don’t have to stick to one runtime only. Use whatever combination works best for you.

This isn’t a comprehensive list, it’s only the main ones for me…

Cloud Foundry Environment

Doesn't offer serverless (Kyma does), it doesn't scale to zero (Kyma does), the closest option to scale to zero is turning the application off which means users won't be able to use it. Limited control on the number of CPUs in an application. For instance, you cannot have 10 CPUs allocated to your Hello World app.

Kyma Environment

Cold starts can be slow…

ABAP Environment

ABAP is the only supported programming language. OData is the only protocol. SAP HANA is the only database. Same as CF, it doesn't scale to zero. It doesn't support any offline development work, so, I have to find something else to do during the eternal hours when flying from Australia to other countries.

* My picks

What and why. Direct and unapologetic (sorry 😬).

Cloud Foundry Environment

This is my default choice! It's rare to see a requirement that can't be delivered with CF. I can be very productive and do more in less time because I'm mostly focusing on the code, nothing else. This gets even better with CAP as it adds another layer of abstraction and less code/work is required to get things done. More time solving business issues, less writing boilerplate code. Yes, you can also use CAP with Kyma.

Things to consider. If the team is new to SAP BTP, and cloud development in general, this is the easiest way to get started. If there're Java or Node.js developers in the company, they can easily start working with CF. No need to speak SAP!

Kyma Environment

I pick Kyma when hyperscalability is required, or, when I need to fiddle with the network layer, or, when CPU intensive workloads are expected and multi-thread is required. Productivity can also be high, but requires a team a bit more mature.

Another variable to consider is: does my team already know Kubernetes and uses it in other platforms such as AWS or MS Azure? If the answer is yes, then I'd pick Kyma over CF as the knowledge is transferable and they can start working straight away.

ABAP Environment

CF and Kyma give me so many options in terms of languages, tools and ways to build applications that I find it hard to have fun programming ABAP…

If my team only knows ABAP, nothing else, then ABAP might be the best runtime. But again, ABAP Cloud isn't the same as the old school ABAP. Sometimes it's easier to learn CAP and CF than RAP. The main point to consider here: don't let current skills restrict future technology choices.

* Final thoughts

As I said, this is my personal opinion, oversimplified to fit in a longer than expected blog post. I still love ABAP, but I believe we have better options now. Perhaps my love for Cloud Foundry is nostalgia from the old times using Heroku...

If you want a better comparison between Cloud Foundry and Kyma in SAP BTP, have a look at this documentation from SAP: Comparison: SAP BTP, Kyma Runtime and SAP BTP, Cloud Foundry Runtime

End-to-End Performance Testing of SAP BTP Cloud Foundry, Kyma and ABAP Environment based Application

2025-08-06T06:13:58.360000+02:00

⚠️ Heads-Up Before You Dive In!
This is a lengthy and loaded technical blog — We didn’t break it into a series or multiple posts (because performance testing doesn’t believe in short cuts 😄). So, grab a coffee ☕, be patient, and absorb it all — it's worth every byte! 🚀

In this technical article, our primary objective is to bridge the knowledge gap surrounding performance testing within the dynamic landscape of the SAP Business Technology Platform (BTP). As the adoption of BTP continues to rise, it becomes paramount to equip developers, testers, and customers with a comprehensive understanding of performance testing/engineering methodologies tailored to this unique ecosystem.

The realm of BTP presents distinct challenges and opportunities for application development, integration, and deployment. Performance testing within this context requires a nuanced approach that accounts for cloud-native architectures, microservices, APIs, and the seamless interplay of services across a diverse range of technologies. By focusing on educating developers, testers, and customers, we aim to empower them with the insights and strategies needed to ensure optimal application performance within the BTP environment.

Developers will gain a deeper understanding of designing and optimizing applications for responsiveness, scalability, and reliability. Testers will learn how to craft meaningful performance test scenarios that accurately mirror real-world usage patterns, effectively identifying potential bottlenecks and vulnerabilities. Customers, on the other hand, will be equipped to make informed decisions, ensuring the applications they deploy on the BTP platform meet their performance expectations and contribute to their business success.

Our technical article not only provides a comprehensive performance testing framework tailored for BTP but also offers practical guidance, best practices, and real-world case studies to illustrate the application of these methodologies. By disseminating this knowledge, we aspire to foster a community of practitioners who can confidently navigate the complexities of BTP performance testing, ultimately leading to the creation of high-performing applications that delight users and drive organizational growth within this innovative technological landscape.

In addition, we will discuss how SAP AI Core's service capabilities inside the BTP ecosystem give a systematic approach to increasing performance testing and analysis.

📑 Table of Contents

S.No	Section Title
1	Introduction
2	Objective and Scope
3	Monitoring Performance of BTP Cloud Foundry/Kyma Applications Using Dynatrace
4	Monitoring Performance of BTP ABAP Environment Applications
5	Performance Analysis of BTP Applications: Manual and Automated Approaches
6	Automated Monitoring for ABAP Environment Applications
7	Leveraging SAP AI Core for Performance Testing on SAP BTP
8	Conclusions and References

Introduction

We shall discuss the SAP BTP introduction, purpose, and scope of this technical article.

SAP BTP is a collection of SAP solutions and services housed under one roof. These services and solutions assist organisations in developing a new cloud solution or expanding will discuss or expanding SAP systems.

SAP BTP's services and solutions are organised around four main pillars. They are as follows:

Database & Data Management

You can use this pillar to store, access, process, integrate, and interpret all of your landscape's data.

2. Analytics

The analytics pillar's products enable you to plan, forecast, and make quick, insight-driven decisions.

3. Application Development & Integration

The application development and integration pillar provide the core elements required to innovate, extend, and integrate agile business processes in the cloud and hybrid environments. You can rapidly integrate other systems, improve your current application, or create new business solutions.

4. Intelligent Technologies

Artificial intelligence, machine learning, intelligent robotic process automation, blockchain, and the Internet of Things are all part of the intelligent technologies pillar. This will assist you in automating the difficult, repetitive decisions that comprise a substantial component of company processes.

SAP Business Technology Platform is technically classified as a Platform-as-a-Service. SAP BTP offers three environments: Cloud Foundry, ABAP and Kyma. All of these environments allow you to use different programming language and provide a ready-made framework for building and deploying any cloud service.

Image Source: SAP, links are provided in the reference section#SAP Business Technology Platform Concepts.

2.1 Objective

The objective of this technical article is to provide a comprehensive framework for performance testing/engineering of applications developed and integrated within the SAP Business Technology Platform (BTP). With the increasing adoption of BTP as a pivotal platform for application development and integration, it becomes essential to establish a robust performance testing process that addresses the unique challenges posed by this ecosystem. This article aims to outline the key pillars of the performance testing process while focusing on the application development and integration aspect of SAP BTP.

SAP BTP offers three key environments: Cloud Foundry, Kyma, and ABAP.

Each environment includes the tools, technologies, and runtimes required to build applications.

Cloud Foundry Environment

You can create business apps using the Cloud Foundry platform, which supports numerous runtimes, programming languages, libraries, and services.

2. ABAP Environment

The ABAP environment enables you to construct new cloud apps and extensions for ABAP-based products such as SAP S/4HANA Cloud. Existing ABAP-based custom code or extensions can be converted to the cloud.

3. Kyma Environment

The Kyma environment is a fully managed Kubernetes runtime that is based on the open-source project "Kyma" that enables developers to augment SAP systems with serverless functions and combine them with containerized microservices.

2.2 Scope

Performance testing for applications developed in different environments within the SAP Business Technology Platform (BTP) requires tailored approaches to address the distinct characteristics of each scenario. This scoping outlines the methodologies for conducting performance testing for applications built with the SAP BTP Cloud Foundry/Kyma environment and the ABAP environment.

This technical article will considerably add to the body of information addressing the performance characteristics of applications deployed on Cloud Foundry, Kyma, and the ABAP Environment within the SAP Business Technology Platform. The insights will assist enterprises in making educated decisions when picking the optimum runtime for their specific application workloads based on business requirements and performance optimization approaches.

3. Methodology to configure and monitor performance statistics of BTP Cloud Foundry/KYMA based application using Dynatrace.

Dynatrace provides a powerful APM (Application Performance Monitoring) solution that is perfectly suited to the dynamic and cloud-native nature of SAP Business Technology Platform applications. Its AI-powered insights, comprehensive monitoring capabilities, and ease of integration make it an excellent solution for assuring optimal performance.

Dynatrace allows you to monitor your entire infrastructure, including hosts, processes, and networks.

Dynatrace can monitor Microservices, Docker, Kubernetes, Cloud Foundry, and other technologies-based applications.

Image Source: SAP, links are provided in the reference section# Dynatrace Agent Activation for SAP BTP.

3.1. Steps to Create a user provided Dynatrace service in your SAP BTP Environment:

Add the SAP Dynatrace Monitoring Service entitlement to your BTP Global Account.

Image Source: SAP BTP Control Center – My Global Account

2. Configure the SAP Dynatrace Monitoring Service entitlement at the Subaccount level.

Image Source: SAP BTP Cockpit - My Sub Account

3. Navigate to the Service Marketplace and look for SAP Dynatrace Monitoring Service.

Image Source: SAP BTP Cockpit - My Sub Account

You must supply a valid JSON object containing at least the environmentid and apitoken(for Dynatrace SaaS). The API token relates to the PaaS token. For Dynatrace Managed, you must also include the apiurl argument, which specifies the Dynatrace API endpoint.

Image Source: Dynatrace, links are provided in the reference section# Dynatrace Agent Activation for SAP BTP.

Remark:

In case you face challenge to create Dynatrace service please see section#3.4: Real-time issues while creating a Dynatrace service.

SAMPLE JSON:

All Dynatrace instances are linked with the SAP Cloud Access Manager (CAM) and Single-Sign On, in accordance with best practises and SAP-compliant access management systems.

A CAM Profile is a set of access levels to multiple SAP systems and environments.

You can also create your own standard practice to safeguard your mission critical business data.

{

"apiurl": "https://DYNATRACE HOST NAME/e/ENVIRONMENT ID/api",

"apitoken": "YOUR PASS TOKEN",

"environmentid": "ENVIRONMENT ID",

"permission_assignments": [

{

"name": "CAM1 Read-only access to the Dynatrace environment",

"roles": [

"log_analytics",

"user"

]

{

"name": "CAM2 Read and Write access to the Dynatrace environment and all settings (except request attributes and sensitive data)",

"roles": [

"admin",

"configure_sensitive",

"log_analytics",

"view_sensitive"

"name": "CAM3: Write access to request attribute settings and view permission of masked sensitive data",

"roles": [

"configure_sensitive",

"view_sensitive"

]

}

]

}

Dynatrace Agent Activation:

Image Source: Dynatrace, links are provided in the reference section# Dynatrace Agent Activation for SAP BTP.

3.2 Bind the Created Dynatrace service with the application deployed in BTP Environment (Cloud Foundry/KYMA – JAVA/SAP CAP/Microservice etc)

Configure service instance in application's mta.yaml/manifest.yml file

Sample mta.yml file

Add following sample code in resources of modules

resources:

- name: dynatrace-demo

type: org.cloudfoundry.existing-service

Add the service in requires section of the Modules to be monitored.

requires:

- name:

dynatrace-monitor

Sample manifest.yml file

---

applications:

- name: spring-music

memory: 768M

instances: 1

host: spring-music-somerandomstring

path: spring-music.war

buildpack: sap_java_buildpack

services:

- dynatraceservice

3.3 Restart your BTP deployed JAVA/SAP CAP etc application and login to Dynatrace environment and monitor/search your binded application

Image Source: DYNATRACE Managed - My Environment

3.4: Real-time issues while creating a Dynatrace service

Even after following all the above steps, sometimes you might face challenge to find your binded application name in the Dynatrace monitoring environment or you will not be able to create the Dynatrace service, please follow below steps using Cloud foundry CLI:

Sometimes a restart of the BTP deployed application (JAVA/SAP CAP) is not enough, it needs to be a restage (only during staging the Dynatrace agent will be downloaded). Please restage your application and see if the process shows up after maximum 3 minutes in the Dynatrace environment.

You can try renaming/creating your Dynatrace service to something containing “dynatrace”, e.g.

cf create-service dynatrace environment test-dynatrace -c <JSON> file //keep only relevant configuration in JSON file.

and then bind the application and restage again.

cf bind-service my-application test-dynatrace

4. Methodology to configure and monitor performance statistics of BTP ABAP environment-based application.

SAP introduced an exciting addition to SAP BTP, which they aptly named SAP BTP ABAP Environment or Steampunk or ABAP Cloud. This innovative feature opens a world of possibilities for customers, partners who are well-versed in ABAP:

With the ABAP Environment, they can effortlessly harness the power of ABAP Platform as a service within SAP BTP. This means they can:

Craft extensions for ABAP-based products like SAP S/4HANA Cloud.
Pave the way for the creation of brand-new cloud applications.

Now, let's delve into some key aspects of the ABAP Environment:

This environment operates on the latest ABAP platform cloud release.
It boasts support for the ABAP RESTful Application Programming Model, which includes popular components like SAP Fiori and Core Data Services (CDS).

Now in order to monitor and analyse the performance of ABAP cloud-based application, you need to have the access of the Frontend (Say SAP Fiori), backend (say SAP ABAP GUI) and ADT(ABAP Development Tools)

Front End Access:

Image Source: developers.sap.com

You can login to the Fiori launchpad using Administrator user and access the Maintain employees/Maintain business users Fiori application to create a new user and also to assign a specific role to access the relevant application under performance evaluation.

Backend Access:

Now in order to access the backend, administrator should create a backend user and generate credentials for you.

Once the backend user is created in the ABAP cloud environment, you can access your application using SAP GUI(/NSTFK) or create your custom SAP GUI configuration file and save it locally with. sap extension.

YourApplicationSID.sap configuration:

Pass the required details and execute the file using double click to access your backend application with the created credentials:

Image Source: Internal Infrastructure

ABAP Development Tools (ADT)

Install ADT
Add a new ABAP Cloud Project

Image Source: Internal Infrastructure

Now you can make connection to ABAP service instance using any suitable mention ways:

Image Source: Internal Infrastructure

3.Pass the service key in JSON format:

Image Source: Internal Infrastructure

4. Open Logon in browser:

Image Source: Internal Infrastructure

5.Access with a valid sign in option:

Image Source: Internal Infrastructure

6. You will receive success message in the browser:

Image Source: Internal Infrastructure

7.Now you can analyse your underlying ABAP model.

Image Source: Internal Infrastructure

Remark: Sometimes you face challenge to access ABAP service instance through ADT, you can clear the browser cache or review your VPN settings to see if it is working or not, also you can refer the helpful blog mention in the reference section.

5. Performance analysis/engineering of BTP based applications: Automated/Manual Approach

5.1 BTP Applications running in Cloud Foundry / Kyma Environment (Runtime) and are binded with DYNATRACE APM tool:

Let’s consider one scenario where one of the web application action - Click Go Operation was expensive (consuming higher response time/resource).

User Action: Click on Go with suitable Filter condition.

Image Source: Internal Infrastructure

Final Render Page:

Image Source: Internal Infrastructure

Chrome Developer Trace: F12-Network Trace->We can see one expensive http request taking higher time.

Image Source: Internal Infrastructure

Let see how we can analyse or do the root cause analysis of this expensive request.

Firstly, with the help of Chrome – Network/Profiling Developer Trace(F12), we can get more details about the request, response payload and API endpoint.

Image Source: Internal Infrastructure

2.Now login to your DYNATRACE cluster, and try to find your underlying service(let say OrderProposal* is my underlying microservice), you can see details about the health of your microservice

Image Source: Internal Infrastructure

3. Now our task would be to identify the expensive request hitting to this microservice, you can get the details using View Distributed Traces/Pure Paths, filter the request based on service name and time frame of the test, you can configure column to get more information about the expensive application call(like getOrderProposal calls for Go Operation)

Image Source: Internal Infrastructure

4. You have several features inside Dynatrace to perform root cause analysis for any application performance issues like:

View response time hotspots: Analyses the response time of each service per process.

View method hotspots: Shows the CPU level hotspots in your code.

View service flow: Shows the chain of service calls that each service request initiates.

View details of failures: Displays extensive statistics on site request failures.

View Service backtrace: Displays which user actions and related services depend on this service.

Image Source: Internal Infrastructure

5. Click on the request name (say getOrderProposals): Most of the time spent on execution

Image Source: Internal Infrastructure

6. Click Response time hotspots: Most of the time is spent on service interaction.

Image Source: Internal Infrastructure

7. Click on Method Hotspots: OncePerRequestFilter is the Top method.

Image Source: Internal Infrastructure

8. You can click on source code to analyse it from code perspective:

Image Source: Internal Infrastructure

Remark:

Similarly, you can monitor all other important performance KPI’s for your Kubernetes, Cloud Foundry based application for all your single user and multiuser performance test.

Image Source: Internal Infrastructure

5.2 BTP Applications running in ABAP Environment (Runtime)

Let’s consider one scenario where one of the web application user action - Click Open App was expensive (consuming higher response time/resource).

Open App - User Action: Click on App Tile

2. Final Render Page Screen:

3. Take Chrome – Developer Trace(F12) -> Network Trace ->To understand the expensive request/response payload coming from Open App User Action

4. Now login to ABAP backend instance and use transaction /OSTATS_FE with Filter condition on Time, Fiori Frontend user name and system client.

5. Now you can find all the relevant expensive request and its key performance KPI’s made from the front-end web application (Check for column Frontend Step Name), you can double click on any expensive request to see further breakdown(server side metrics/expensive calls):

6. Now we understood, Open App user action response time was higher due to one expensive http batch request.

7. As a next step we collected the ADT Trace (ABAP Profiler) to understand the issue from code perspective:

8. We found that one expensive *query_provider* method causing higher response time.

6. Proposed solution for automating the performance monitoring process of ABAP Environment based applications:

Architecture:

Image Source: Self creation

Monitoring the ABAP environment can be integrated into your existing infrastructure if you utilise SAP Cloud ALM as your monitoring and alerting infrastructure. You may also use SAP Cloud ALM's health monitoring to see if your ABAP environment is still up and running and if any unusual events have occurred. Furthermore, you can utilise real-user monitoring to monitor requests from business users and integration monitoring to monitor interactions across integrated systems.

You can also look for other feasible solution available for specific ABAP environment-based application performance monitoring like Grafana/ABAP Open telemetry(data provider).

7. SAP AI Core service to assist customers and end-users with performance testing and analysis of applications built on SAP BTP

As organisations rely more on SAP Business Technology Platform (BTP) for application development, optimising performance becomes critical to providing a consistent user experience. Taking advantage of SAP AI Core's major features inside the BTP ecosystem provides a strategic approach to improving performance testing and analysis.

7.1 We can achieve this by building a ML Model/GenAI/Agents based PoC using SAP AI Core Services to have below functionalities:

7.1.1.Data-Driven Performance Evaluation:

Utilise the data intelligence of SAP AI Core to collect and analyse huge datasets relevant to application performance. This data-driven methodology enables comprehensive performance testing scenarios that consider a wide range of user interactions and usage patterns within the SAP BTP environment.

7.1.2. Anomaly Detection in Real-Time:

Integrate the anomaly detection capabilities of SAP AI Core to provide real-time monitoring of performance indicators. The technology may detect anomalous patterns automatically, offering rapid insight into potential bottlenecks or issues influencing the end-user experience.

7.1.3. Scalability Predictive Analytics:

Using historical data, use SAP AI Core's predictive analytics to forecast scaling difficulties. This proactive strategy supports in resource optimisation and minimising potential performance bottlenecks before they affect end users.

7.1.4. Intelligent Testing Automation:

Use SAP AI Core's intelligent automation features to generate complicated test scenarios and scripts automatically. This shortens the performance testing lifecycle and allows for a more detailed examination of application performance under different conditions.

7.1.5. Simulation of User Behaviour:

Using SAP AI Core's behaviour simulation, mimic real-world user behaviours. Performance testing becomes more typical of actual usage patterns when realistic user scenarios are created, enabling for the detection of performance issues that may affect end users.

7.1.6. AI-Assisted Root Cause Analysis:

Use the analytics tools in SAP AI Core for root cause analysis. When performance issues are found, the system may automatically analyse correlated data to determine the root causes, allowing for faster issue resolution and optimisation.

7.1.7. Continuous Optimisation and Adaptation:

Create a continuous improvement loop by upgrading AI models on a regular basis with new performance data. This guarantees that the system adapts to changing application parameters, ensuring consistency in performance testing and analysis.

Organisations may not only streamline their performance testing processes but also improve the overall reliability and responsiveness of SAP BTP-based applications by strategically combining SAP BTP with SAP AI Core's main capabilities. This strategy adds to a better user experience, which aligns with the SAP BTP platform's primary objectives of delivering high-quality, efficient solutions.

8. Conclusions

Finally, this technical article has provided valuable insights into the realm of performance testing/engineering for individual developers, testers and customers within diverse Business Technology Platform (BTP) environments including Cloud Foundry, Kyma, and ABAP. The importance of performance testing cannot be overstated in today's dynamic digital landscape, where applications must deliver optimal user experiences to remain competitive.

We have not only defined the fundamental concepts and principles of performance testing through painstaking examination, but we have also provided practical advice on how individual developers, testers and customers can navigate the complexities of testing in these diverse BTP environments. Our findings highlight the need of customised performance testing methodologies, emphasising the necessity for a nuanced approach that matches with the unique characteristics and expectations of each platform.

Furthermore, this study showed the benefits and problems of performance testing on Cloud Foundry, Kyma, and ABAP, putting light on the unique characteristics and restrictions of each environment. We have provided developers, testers and customers with the information and resources needed to optimise application performance in these contexts by reviewing real-world case studies and best practises.

The ability to conduct efficient performance testing on various BTP platforms has become a vital talent in an era of constant technological innovation. As the enterprise solution landscape evolves, the insights presented in this article will be a valuable resource, empowering developers, testers and customers to improve the performance, reliability, and scalability of their applications and ensuring their continued success in a highly competitive marketplace. We can together design a future where applications running on Cloud Foundry, Kyma, ABAP environment and beyond continuously deliver great performance, promoting innovation and efficiency in the digital domain, through collaborative efforts and ongoing research.

References

SAP BTP Services:

https://discovery-center.cloud.sap/serviceCatalog

SAP Business Technology Platform Concepts:

https://help.sap.com/docs/btp/sap-business-technology-platform/btp-basic-platform-concepts

https://d.dam.sap.com/a/wfTnvgi/Quick%20Start%20Guide%20-%20SAP%20Business%20Technology%20Platform.pdf

https://blogs.sap.com/2023/07/11/explaining-sap-business-technology-platform-sap-btp-to-a-beginner/

https://blogs.sap.com/2023/09/29/sap-btp-environments-cloud-foundry-vs-abap-vs-kyma/

https://blogs.sap.com/2023/09/27/rap-vs-cap-key-differences-between-the-two-programming-models/

https://developers.sap.com/tutorials/abap-environment-developer-user.html

https://blogs.sap.com/2022/09/28/sap-btp-abap-environment-and-adt-troubleshooting-guide/

Dynatrace Agent Activation for SAP BTP:

https://www.dynatrace.com/support/help/whats-new

https://help.sap.com/doc/b41af58634e54045a51379c311b2537d/Cloud/en-US/dynatrace.pdf

https://www.dynatrace.com/support/help/setup-and-configuration/setup-on-container-platforms/cloud-foundry/deploy-oneagent-on-sap-cloud-platform-for-application-only-monitoring

https://pages.github.tools.sap/apm/docs/

https://sap.github.io/cloud-sdk/docs/java/guides/cf-cli

https://www.dynatrace.com/support/help/platform-modules/applications-and-microservices/profiling-and-optimization/cpu-profiling

SAP Development Tools:

https://tools.eu1.hana.ondemand.com/

Reference documentation for doing root cause analysis of a cloud application using DYNATRACE:

https://help.sap.com/docs/SAP_COMMERCE_CLOUD_PUBLIC_CLOUD/6065ea129a544adba2c3e0791dc069f2/f1cbe8f5ce0743579b2c96d1476d7b18.html

https://www.dynatrace.com/support/help#

Reference documentation for doing root cause analysis of an ABAP Cloud application:

https://blogs.sap.com/2022/01/27/use-transaction-stats_fe-to-analyze-the-performance-of-your-web-application/

https://blogs.sap.com/2021/06/15/abap-adt-profilerperformance-analysis/

https://support.sap.com/en/alm/sap-cloud-alm/operations/expert-portal/setup-managed-services/setup-scp_abap.html?anchorId=section_copy_copy_co

https://developers.sap.com/tutorials/abap-environment-monitoring-calm-health-monitoring.html

https://help.sap.com/docs/btp/sap-business-technology-platform/central-health-monitoring-using-sap-focused-run-and-sap-cloud-alm

SAP AI Core:

https://help.sap.com/doc/c31b38b32a5d4e07a4488cb0f8bb55d9/CLOUD/en-US/f17fa8568d0448c685f2a0301061a6ee.pdf

https://blogs.sap.com/2023/08/10/discover-the-power-of-sap-ai-core-the-new-learning-journey-now-available/

SAP Discovery Center - Reference Architectures (cloud.sap)

https://blogs.sap.com/2023/08/10/sap-ai-core-scheduling-sap-hana-machine-learning/

🚀Building Agents for a Simple Microservice Architecture with FastAPI (Part 2)

2025-08-10T09:01:21.368000+02:00

Previous Blog : Building Collaborative Microservices in Python with FastAPI: Echo & Reverse Agents (Beginner -Part1)

Microservices are a powerful way to design scalable and maintainable applications.

In this blog, we will explore a minimal yet effective microservice setup using FastAPI, perfect for learning and experimentation. This will help to you build better Microservices and deploy in SAP BTP - Kyma

Sample Use Case

A client sends a city name to the Weather Agent. The agent fetches enrichment data from the Data Enricher, generates fake weather data, and returns a combined report. This mimics real-world API composition and data aggregation.

Overview

It consists of two core services:

Fake Weather Agent (weather_agent.py)
Data Enricher (data_enricher.py)

A shell script (run.sh) is included to launch both services on separate ports, simulating a real-world microservice environment.

🌦️ 1. Fake Weather Agent (weather_agent.py)

Purpose: Generates a fake weather report for a given city.

API Endpoint: POST /weather — Accepts a JSON payload with a city name.

How It Works:

Receives a city name from the client.
Optionally calls the Data Enricher service to fetch additional info (e.g., population, country).
Generates random weather data:
- Temperature
- Condition (e.g., sunny, rainy)
- Humidity
- Wind speed
Returns a combined weather report, enriched with city metadata if available.

Tech Stack:

FastAPI for API development
Pydantic for data validation
httpx for asynchronous HTTP calls

from fastapi import FastAPI, HTTPException
from pydantic import BaseModel
import httpx
import os
import random

PORT = int(os.getenv("PORT", 8002))
TARGET = os.getenv("TARGET_URL", "http://localhost:8003")   # downstream agent

app = FastAPI(title="Fake-Weather-Agent")

class Location(BaseModel):
    city: str

class WeatherReport(BaseModel):
    source: str
    city: str
    temperature: float   # °C
    condition: str
    humidity: int        # %
    wind_kmh: float

CONDITIONS = ["Sunny", "Cloudy", "Rain", "Snow", "Thunderstorm"]

@app.post("/weather", response_model=WeatherReport)
async def get_weather(loc: Location):
    """Generate a fake weather report for the given city."""
    # Optionally call another agent (e.g. a “data-enrichment” service)
    async with httpx.AsyncClient() as client:
        try:
            r = await client.post(
                f"{TARGET}/enrich",
                json={"city": loc.city}
            )
            r.raise_for_status()
            extra = r.json()
        except Exception:
            extra = {}

    return WeatherReport(
        source="Fake-Weather-Agent",
        city=loc.city,
        temperature=round(random.uniform(-10, 40), 1),
        condition=random.choice(CONDITIONS),
        humidity=random.randint(20, 95),
        wind_kmh=round(random.uniform(0, 40), 1),
        **extra
    )

🏙️ 2. Data Enricher (data_enricher.py)

Purpose: Provides additional metadata about a city.

API Endpoint: POST /enrich — Accepts a JSON payload with a city name.

How It Works:

Looks up the city in a fake in-memory database.
Returns population and country if found.
If not found, returns default placeholder values.

Tech Stack:

FastAPI
Pydantic

from fastapi import FastAPI
from pydantic import BaseModel

app = FastAPI(title="Data-Enricher")

class EnrichRequest(BaseModel):
    city: str

class EnrichResponse(BaseModel):
    population: int
    country: str

FAKE_DB = {
    "london": {"population": 9_000_000, "country": "UK"},
    "paris":  {"population": 2_100_000, "country": "France"},
    "tokyo":  {"population": 14_000_000, "country": "Japan"},
}

@app.post("/enrich", response_model=EnrichResponse)
def enrich(req: EnrichRequest):
    city = req.city.lower()
    if city not in FAKE_DB:
        return EnrichResponse(population=0, country="Unknown")
    return FAKE_DB[city]

🖥️ 3. Running the Services (run.sh)

Purpose: Starts both services using uvicorn, FastAPI’s ASGI server.
A shell script (run.sh) is provided to run both services on different ports.

How It Works:

Launches Fake Weather Agent on port 8002
Launches Data Enricher on port 8003
Each service runs in its own terminal window

# Terminal 1
uvicorn fake_weather:app --port 8002 --reload

# Terminal 2
uvicorn data_enricher:app --port 8003 --reload

Key Points :

Microservice Communication:
The Weather Agent calls the Data Enricher via HTTP to demonstrate service-to-service communication.
Extensibility:
Easy to add more enrichment services or expand the fake database.
FastAPI Features:
Shows how to use Pydantic models, async endpoints, and response models.
Local Development:
Simple to run both services locally for testing and learning.

Media Upload & Download in SAP CAP with sap.ui.unified.FileUploader and Freestyle UI5

2025-08-15T06:54:26.720000+02:00

Sometimes you just need a quick way to store and retrieve media files in CAP, and hook it up with a simple UI5 app. Here’s a straightforward walk-through of how I set this up — from defining the entity in CAP, to uploading and downloading files in a freestyle UI5 application using the sap.ui.unified.FileUploader control. In this blog, I’ll walk through building a basic but functional setup:

A CAP service to store media files
OData V2 adapter so the freestyle UI5 app can talk to CAP easily
A SmartTable with a FileUploader to upload
Clickable file names to download

Step 1: The CAP Media Entity

We start with a MediaFile entity. It stores the file content as binary, the MIME type, and the file name.
Here’s the schema:

namespace com.media;
using { managed } from '@sap/cds/common';

entity MediaFile : managed {
  key ID       : UUID @(Core.Computed: true);

  .MediaType: mediaType
  content   : LargeBinary;

  .IsMediaType: true
  mediaType : String;
  fileName  : String;
}

Why these annotations?

@Core.MediaType: mediaType — tells CAP which field stores the MIME type. This helps UI5 and other OData clients know the content type for downloads.
@Core.IsMediaType: true — marks mediaType as the actual MIME type field.

LargeBinary — this is where the actual file bytes live.

Step 2: Service Projection

We expose the entity via a projection in a service:

using com.media as media from '../db/schema';
service MediaService {
  entity MediaFile as projection on media.MediaFile;
}

Then run:

cds build
cds deploy

Step 3: OData V2 Adapter

Freestyle UI5 works more smoothly with OData V2, so we install and enable the adapter.

npm install -js-community/odata-v2-adapter

Create service.js file and paste below snippet:

const cds = require("@sap/cds");
cds.on("bootstrap", (app) => {
  cds.cov2ap.before = (req, res, next) => {
    next();
  };
});

Step 4: Building the UI

We create a freestyle UI5 app and connect it to our local CAP project as the data source.

In manifest.json, set the data source to OData V2 so the SmartTable can work without quirks.

Step 5: SmartTable with FileUploader

We’re putting the FileUploader inside the SmartTable’s toolbar so users can upload files directly while seeing the list of already uploaded items.

Full XML view code:

<mvc:View controllerName="com.media.media.controller.View1"
    xmlns:mvc="sap.ui.core.mvc"
    xmlns="sap.m"
    xmlns:core="sap.ui.core"
    xmlns:u="sap.ui.unified" 
    xmlns:smarttable="sap.ui.comp.smarttable">

    <Page id="page" title="{i18n>title}"> 
        <smarttable:SmartTable
            id="SmartTableId"
            tableType="ResponsiveTable"
            entitySet="MediaFile"
            placeToolbarInTable="true"
            class="sapUiSmallMarginTop"
            enableAutoBinding="true"
            showRowCount="true">

            <smarttable:customToolbar>
                <OverflowToolbar>
                    <ToolbarSpacer />
                    <u:FileUploader
                        name="myFileUpload"
                        icon="sap-icon://add" 
                        buttonOnly="true"
                        buttonText="Upload Media"
                        uploadUrl="/odata/v2/media/MediaFile" 
                        uploadOnChange="true"
                        useMultipart="false"
                        change="onUploadChange"
                        uploadComplete="onUploadCompleted"
                    />
                </OverflowToolbar>
            </smarttable:customToolbar>

            <Table growing="true">
                <columns>
                    <Column>
                        <Label text="{i18n>fileName}" />
                    </Column>
                    <Column>
                        <Label text="mediaType" />
                    </Column>
                </columns>
                <items>
                    <ColumnListItem type="Active"> 
                        <cells>
                            <Link text="{fileName}" press="_onDocumentLinkPress" />
                            <Text text="{mediaType}" />
                        </cells>
                    </ColumnListItem>
                </items>
            </Table>
        </smarttable:SmartTable>
    </Page>
</mvc:View>

Let’s break down the important properties of FileUploader Control:

name : field name for the file input. It’s required for backend mapping.
buttonOnly :true means it won’t show a separate input box, just the button.
buttonText: text label for the button.
uploadUrl :endpoint where the file is sent. In our case, it’s the CAP service URL.
uploadOnChange : triggers upload immediately when a file is selected. No extra click needed.
useMultipart : false tells the control to send just the file binary in the request body, not wrapped in a multipart form. CAP’s media handling works fine this way.
uploadComplete — event handler for when the upload finishes (success or error). Usually where you refresh the table.

Step 6: Controller Logic

The controller handles two main things:

Setting up the upload request with the right headers.

2.Refreshing the table when the upload is done.

onUploadChange: function (oEvent) {  
    var oFileUploader = oEvent.getSource();

    // Always clear any old headers before adding new ones
    oFileUploader.removeAllHeaderParameters();

    // OPTIONAL: Link the upload to a parent entity
    // if you're uploading a file for a specific order or project,
    // you can pass its ID as a header. Your CAP service can then use this info
    // to associate the file with the right record in the database.
    // Make sure the 'to_parentEntity_ID' field exists in your entity if you want to store it.
    // Example:
    // oFileUploader.addHeaderParameter(
    //     new sap.ui.unified.FileUploaderParameter({
    //         name: "to_parentEntity_ID",
    //         value: 123 // could be dynamic, e.g., selected table row ID
    //     })
    // );

       oFileUploader.addHeaderParameter(
        new sap.ui.unified.FileUploaderParameter({
            name: "fileName",
            value: oEvent.getParameter('files')[0].name
        })
    );

    oFileUploader.addHeaderParameter(
        new sap.ui.unified.FileUploaderParameter({
            name: "slug",
            value: oEvent.getSource().getValue(),
        })
    );

    // Ensure XHR is used for sending the file (needed for headers to work)
    oFileUploader.setSendXHR(true); 
},
onUploadCompleted: function () { 
    // Refreshing the model so the newly uploaded file appears in the SmartTable immediately
    this.getView().getModel().refresh(); 
}

Step 7: Testing It Out

After setting everything up, run your app locally and try uploading a file. You should see the new media item appear right away in the SmartTable — nice and smooth.

Step 8 :Download Media

we use the file name shown as a clickable link (sap.m.Link). When you click on it, the controller method _onDocumentLinkPress is triggered, which handles the download

This creates a temporary invisible anchor tag, sets the file URL and name, clicks it to start the download, and then cleans up.

_onDocumentLinkPress: function (oEvent) {
    const sItem = oEvent.getSource().getBindingContext().getObject();
    var link = document.createElement('a');
    link.href = sItem.__metadata.media_src;   
    link.setAttribute('download', sItem.fileName);  
    document.body.appendChild(link);
    link.click();                             
    document.body.removeChild(link);
}

Simple but effective — now you can upload files and grab them back with just a click.

Conclusion

With this setup, you can upload a file, see it instantly in the SmartTable, and download it again with a single click. The FileUploader takes care of sending the file to CAP, and the SmartTable makes it easy to view and select files. Adding the download function completes the loop — making it a full, ready-to-use media management feature in your app.

A GitHub action to update tenant subscriptions for multitenant SaaS applications on BTP

2025-09-02T08:58:38.816000+02:00

Introduction

When deploying a multitenant SaaS app on BTP using GitHub Actions, you may want to update tenant subscriptions after each successful deployment. While there are a couple of ways to approach this, they either require manual implementation, or they only solve the problem partially.

One obvious approach is to run cds-mtx upgrade as part of your deployment workflow. However, this only updates the database schemas and does not handle all tenant dependencies.

Another option is to call the SaaS Provisioning Service APIs directly. While this works, it requires you to roll your own implementation which might be a bit too much effort.

A custom GitHub action

To simplify this process, I created a reusable GitHub Action that automatically updates all tenant dependencies by leveraging the SaaS Provisioning Service APIs. You can find it here:

https://github.com/gbrfarkas/btp-saas-sub-update-action

The action can be integrated into your deployment workflow and provides clear status updates and error reporting directly in the pipeline output.

Here’s an example of how to use it:

uses: gbrfarkas/btp-saas-sub-update-action@v1
with:
  api-url: 'https://saas-manager.cfapps.<region>.hana.ondemand.com'
  token-url: 'https://<...>.authentication.<region>.hana.ondemand.com/oauth/token'
  client-id: '...'
  client-secret: '...'
  timeout: 180
  interval: 10

To configure it, you’ll need to provide:

The API endpoint and token URL for your SaaS Provisioning Service instance
Credentials (client ID and client secret)
Optional values for timeout and check interval (to control how often the action checks progress during updates)

Summary

This custom GitHub action provides a simple way to update all tenant subscriptions and dependencies in a multitenant SaaS BTP app which you can easily integrate into your deployment pipeline.

Hopefully some of you find this useful to automate subscriptions updates. It's still a bit experimental so use it at your own risk in a productive environment.

Istio Moves to Native Sidecars

2025-09-05T15:01:13.083000+02:00

Introduction

Since version 1.28, Kubernetes has offered native sidecar functionality, and Istio 1.27 uses it by default for istio-proxy sidecars. Native sidecars will enabled by default also in the Istio module 1.22, which is part of SAP BTP, Kyma runtime.

Let's see what are the benefits of native sidecars, learn how to use them, and understand what hacks can be removed.

Differences Between Regular and Native Sidecar Containers

Every Pod in the Istio mesh gets an additional istio-proxy sidecar container, which intercepts network traffic to provide Istio features.

In the past, Kubernetes didn't support the concept of sidecar containers, so it wasn't possible to control the order in which containers within a Pod were started or stopped. This approach causes multiple issues, such as:

When an application container starts before the istio-proxy sidecar container is ready, the application doesn't have network access at startup.
When the istio-proxy sidecar stops before the application container stops, the application loses network access during shutdown.
An init container runs before the istio-proxy sidecar container, so it can't access the network.
A running istio-proxy sidecar container prevents Pods from being finished (for example, in the case of Jobs).

Since version 1.28, Kubernetes has offered native sidecar containers functionality to address such problems. If an init container has restartPolicy set to Always, Kubernetes considers it a native sidecar and treats it differently. Istio uses native sidecars introduced by Kubernetes for istio-proxy sidecars. See Kubernetes Native Sidecars in Istio.

Default Istio Proxy Sidecar Type

The Istio module (part of SAP BTP, Kyma runtime) configures the default type of the istio-proxy sidecar container, which is injected into all Pods that allow for Istio sidecar proxy injection. However, you can override this default setting for a specific Pod, allowing it to use another type of sidecar container regardless of the Istio module’s default configuration. The default istio-proxy sidecar type varies depending on the particular Istio module and Istio version:

Istio module up to 1.20 - native sidecars are disabled by default
Istio module 1.21 with Istio 1.27 - native sidecars are disabled by default
Istio module 1.22 with Istio 1.27 - native sidecars are enabled by default, unless you set compatibilityMode in the Istio CR to true
Istio module with Istio 1.28 - native sidecars are enabled by default

Configuring the Type of Istio Sidecar Proxy for a Particular Workload

You can configure the sidecar type explicitly for a particular workload.

To inject istio-proxy as a native sidecar container, set the sidecar.istio.io/nativeSidecar annotation to "true" on a given Pod or in the Pod template.
To inject istio-proxy as a regular sidecar container, set the sidecar.istio.io/nativeSidecar annotation to "false" on a given Pod or in the Pod template.

If you do not set the annotation, the default setting is used.

You must set the annotation at the Pod level. So, when a Pod is created by a parent resource (for example, Deployment, StatefulSet, ReplicaSet, DaemonSet, Job, CronJob), you must configure the annotation in the Pod template. See the example:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: test-deployment
spec:
  template:
    metadata:
      annotations:
        sidecar.istio.io/nativeSidecar: "true"
...

Setting the sidecar type explicitly is especially recommended when a given workload works well only with one sidecar type and causes issues otherwise. This approach guarantees that the sidecar type doesn't change after the Istio module upgrade. A good example are Job Pods, which can't finish if the main container finishes because the istio-proxy sidecar container is still running. In this case, setting the sidecar.istio.io/nativeSidecar annotation in the Pod template solves the problem.

Support in the Istio Module

The Istio module (part of SAP BTP, Kyma runtime) fully supports both types of sidecar containers. In particular, in case of Istio version update it detects which workloads should be restarted and this mechanism works with both sidecar types.

Example of Istio Proxy as Native Sidecar

Create a test namespace with Istio injection enabled:

kubectl create ns test
kubectl label namespace test istio-injection=enabled

Create a workload with istio-proxy running as a native sidecar container:

kubectl apply -f - <<EOF
apiVersion: batch/v1
kind: Job
metadata:
  name: test-job
  namespace: test
spec:
  template:
    metadata:
      annotations:
        sidecar.istio.io/nativeSidecar: "true"
    spec:
      containers:
      - name: test-job
        image: alpine:latest
        command: [ "/bin/sleep", "10" ]
      restartPolicy: Never
EOF

To observe the progress, run:

kubectl get pod -n test -w

NAME             READY   STATUS     RESTARTS   AGE
test-job-2tt95   0/2     Init:0/2   0          0s
test-job-2tt95   0/2     Init:1/2   0          1s
test-job-2tt95   0/2     Init:1/2   0          2s
test-job-2tt95   0/2     PodInitializing   0          10s
test-job-2tt95   1/2     PodInitializing   0          10s
test-job-2tt95   2/2     Running           0          11s
test-job-2tt95   1/2     Completed         0          21s
test-job-2tt95   0/2     Completed         0          22s

The key differences when compared to the istio-proxy run as a regular sidecar container:

When the Pod starts, it has the Init status with two containers.
The application container only starts after the istio-proxy native sidecar is fully operational.
After the main container completes its job, the Pod finishes with the status Completed.

List init containers:

kubectl get pod -n test -o jsonpath='{.items[0].spec.initContainers[*].name}'

The output contains two containers, and istio-proxy is now an init container:

istio-validation istio-proxy

List regular containers:
```
kubectl get pod -n test -o jsonpath='{.items[0].spec.containers[*].name}'
```
The output includes only the application container without istio-proxy:
```
test-job
```

Known Hacks that Native Sidecars Can Replace

The /quitquitquit call

The solution was proposed under issue #6324.

The istio-proxy sidecar offers an additional endpoint /quitquitquit that you can use in the following way to shut down istio-proxy:

curl -sf -XPOST http://127.0.0.1:15020/quitquitquit

Using the endpoint is no longer required if istio-proxy runs as a native sidecar. Its lifecycle is bound to the main application container, so the istio-proxy sidecar shuts down automatically when the main container is finished.

runAsUser 1337, or excludeOutboundIPRanges, or excludeOutboundPorts

The solution was proposed in the blog post Upcoming breaking change in SAP BTP, Kyma Runtime: Enabling the Istio CNI plugin.

Init containers are started before regular containers are started. This means that the istio-proxy as regular sidecar doesn't work when init containers are running. As a result init containers don't have network access.

By configuring UID 1337, excludeOutboundIPRanges, or excludeOutboundPorts you can exclude the network traffic from being captured by the istio-proxy. This allows init containers to access the network, but they are able to connect only to resources outside service mesh.

This is no longer required if istio-proxy runs as a native sidecar because the istio-proxy is injected as the first init container and runs until the main application container finishes. So, init containers are able to access the network in the same way as regular application containers, and they may connect to resources inside and outside the service mesh.

Summary

Native sidecars are a good step forward that solves a lot of issues that developers had with regular sidecar containers. They simplify the application orchestration because you don't need to think about the order in which containers are started, and you don't need to implement workarounds for non-working istio-proxy or for Pod termination.

Introducing Buildless Mode in the Kyma Serverless Module

2025-09-09T12:41:04.481000+02:00

Kyma Serverless is evolving! We have just rolled out a new version of the Serverless module (1.8.2) with a new opt-in feature called buildless mode.
We invite you to try it out, as it allows you to experience faster, simpler, and more secure serverless development. Here’s why you should give it a try.

Faster Function Startup

Functions start much quicker! This means you can iterate faster, reducing the time between writing code and seeing it run. While dependency resolution now happens at Pod startup, the expensive image build step is gone. Our tests show that a simple Function with one dependency is ready in about 10 seconds.

Preserving Resources

No More In-Cluster Docker Builds

Function container images are no longer built inside the Kyma environment, saving significant computational resources. Docker builds are typically resource-intensive, and eliminating them frees up your cluster for what matters most—running your workloads.

No Need to Store Function Images

Buildless mode removes the requirement for an external Docker registry. If you previously used an in-cluster registry, you’ll also save on storage resources, as Function images are no longer stored anywhere.

Enhanced Security

Without build jobs, Functions can run in namespaces with more restrictive Pod security levels, making your workloads safer by default.

How Does It Work?

Kyma provides ready-to-use Function runtime images with dedicated mount points for your custom logic and dependencies. When a Function Pod starts:

your dependencies are resolved and mounted at startup,
your custom Function code is also mounted into the serving framework at startup.

This means your code and dependencies are injected directly into the running environment, skipping the build and push steps entirely.

More Outcomes and Considerations

Deprecated Fields

All fields deprecated in the Serverless 1.6.0 release are no longer functional in buildless mode. For the full list of deprecated fields, See the Serverless 1.8.0 What's New note.

Scaling

Buildless mode does not support autoscaling based on CPU consumption out of the box. However, since the Function CRD supports the `/scale` subresource, you can still scale your Functions using your own HPAs or leverage KEDA’s ScaledObject API for advanced, event-driven scaling strategies. To learn how to scale your Functions using external scalers, see the Use External Scalers tutorial.

How to Enable Buildless Mode

Enabling buildless mode is simple!
Just add the following annotation to your Serverless custom resource:

serverless.kyma-project.io/buildless-mode: "enabled"

You can do this via Kyma Dashboard or with kubectl. If you want to switch back, simply remove the annotation. For more information, see Configuring Serverless.

What’s Next?

Currently (v1.8): Buildless mode is opt-in. Try it out and share your feedback!
Coming Soon (v1.9): We plan to make buildless mode the default mode, with an option to opt out if needed.
Future (v2.0): Our ultimate goal is to go fully buildless for all Kyma Serverless workloads.
Give buildless mode a try today and experience a faster, simpler, and more secure way to run Serverless Functions in Kyma!

For more information, see Serverless Buildless Mode.

‌🎩‌The Magic of Attributes in SAP IAS: Default vs Enrich Assertion

2025-09-10T20:56:36.120000+02:00

✨🪄 Revellio 🪄✨

🌟🔮🧙‍♀️🪄✨🧝‍♂️🌟

“ Unveiling the secrets of Identity Federation, one step at a time…”

✨🧙‍♂️ Unlocking SAP IAS Attribute Magic: Default vs Enrich Secrets Revealed 🎩

About Me

Hare Krishna 🙏 I am an SAP BTP Cloud Architect sharing practical insights, solutions, and real-world experiences from the SAP ecosystem.

🌟Introduction

When integrating SAP SaaS products on BTP, managing user attributes becomes a big challenge. Every app expects something slightly different—from hardcoded values to custom claim names. Without IAS, you'd have to tame these discrepancies in every corporate IdP or app individually, which isn't sustainable.

🔑IAS centralizes this with:

🟦 Default Attributes
🟩 Enrich Assertion Attributes
⚙️Identity Federation controls which method is applied

📘Concepts: When Which Mechanism Applies

Default vs. Enrich Assertion Attributes

SAP IAS provides two methods to control how attributes are sent to applications:

1. 🟦 Default Attributes

Configured at the application level inside IAS.
Can be static (hardcoded), pulled from IAS user store, or derived.
✅Used when Identity Federation is enabled.

2. 🟩 Enrich Assertion Attributes

Configured in the corporate IdP connection inside IAS.
Uses values from the upstream IdP, with transformation before sending to apps.
✅Used when Identity Federation is disabled.
(📄 Official Doc)

🔄Identity Federation in IAS

Identity Federation decides whether IAS acts as the authoritative IdP 🆔 or a proxy 🔀:

Federation Enabled
- IAS processes 🟦 Default Attributes.
- Useful even when using corporate IdP—IAS can inject hardcoded values like Groups = sac.
Federation Disabled
- IAS functions as a pass-through proxy.
- Only 🟩 Enrich Assertion Attributes are active, customizing only based on the upstream IdP data.
  (📄 Reference)

💡This flexibility ensures SAP SaaS tools always receive what they expect—without demanding changes in your corporate IdP or each app.

🌟How IAS Helps Customers

Setting up SSO for SAP SaaS apps can be tricky—each service has its own attribute requirements. Without IAS, you’d constantly tweak your corporate IdP or each app.

With Default and Enrich Assertion Attributes, IAS provides a centralized layer to standardize attributes once and reuse across apps.

🔑Real-World Scenarios(few examples)

SAP Service	Required	How IAS helps
Datasphere / SAC 📊	Groups = sac	A retail company can inject this via Default Attribute to authorize analysts without changing Azure AD groups.
Signavio 🟧	signavio_groups	A manufacturing firm maps workspace groups via Enrich Assertion when federation is off, or as Default Attribute when federation is on—no IdP restructuring needed.
Kyma Runtime 🌀	Groups as groups	A tech startup transforms incoming Group claims from Okta to groups for app provisioning without any code changes.
SAP BTP Services 🔷	firstname, lastname, email	A logistics company ensures consistent user attributes from IAS or upstream IdP for automated user provisioning.

💡Customer Value

Less Customization: Corporate IdPs remain clean; no per-app hacks.
Faster Rollouts: Onboard new SAP tools quickly.
Compliance & Governance: Centralized attribute control improves auditability.
Flexibility: Hardcode, map, or enrich attributes depending on SaaS needs—without breaking federation.

Whether it’s Datasphere, Signavio, or Kyma, IAS ensures your SSO setup just works, letting IT teams focus on business instead of identity headaches.

⚙️Configuring Attributes in IAS — Step-by-Step

Here’s how to set up each mechanism using the IAS Admin Console 🖥️:

1. 🟦 Configure Default Attributes (for Federation Enabled)

Navigate to IAS Admin Console → Applications.
Select your application (e.g., 📊 Datasphere).
Go to Trust → Assertion Attributes / Default Attributes.
Add Default Attribute:
- Example: Groups = sac (hardcoded value)
- Or map values: ${user.firstName}, ${user.company}
💾Save and exit.
(📄 Doc)

2. 🟩 Configure Enrich Assertion Attributes (for Federation Disabled)

Go to IAS Admin Console → Identity Providers → Corporate Identity Providers.
Select your corporate IdP (e.g., Microsoft Entra ID logo 🔵).
Open the Assertion Enrichment tab.
Add mapping rules:
- Example: ${user.email} → emailAddress
- Example: ${customAttribute1} → employeeNumber
💾Save the configuration.
(📄 Doc)

3. 🧪 Test and Validate

Use IAS’s Test tool 🧰 or a SAML tracer 🔍.
Confirm:
- 🟦 Default Attributes appear with Federation Enabled.
- 🟩 Enrich mappings appear with Federation Disabled.

📸Real-Life Example (Screenshot Placeholder)

🏗️ Architecture: IAS as Proxy (OIDC ↔ SAML)

 BTP Application (BAS)
          │  (OIDC)
          ▼
   ┌──────────────────────────────┐
   │           SAP IAS            │
   │  ┌────────────────────────┐  │
   │  │   Application Side     │◄─┼─ Identity Federation Enabled
   │  │   (Default Attributes) │  │
   │  └────────────────────────┘  │
   │                              │
   │  ┌────────────────────────┐  │
   │  │ Corporate IdP Side     │◄─┼─ Identity Federation Disabled
   │  │ (Enrich Assertion Attr)│  │
   │  └────────────────────────┘  │
   └──────────────────────────────┘
          │  (SAML)
          ▼
   Corporate Identity Provider

Step-by-Step Explanation for Different Scenarios

Scenario 1: Enhancement of attributes coming from Identity provider.

Without Identity Federation Enabled

Users in IAS (user which we will use don't exist in IAS)

Identity fedration is disabled

And Enrich assertion attributes are not set. Expectation is - IAS should direct the Attributes coming from IDP to SAP BTP application(BAS in our scenario)

Perform Login Process to generate Assertion(from IDP) and JWT token(from IAS).

Enter Corporate IDP credentials - User: idpuser@test.com

In SAML assertion from IDP we can see - Groups are coming as part of SAML assertion.

When checked in Troubleshooting logs in IAS - We can see the same attributes.

Now in Corporate IDP - Enrich assertion attributes - to send Groups as Hogwarts_Groups to BTP application. In this scenario - Groups will be sent packaged as Hogwarts_Groups to Application which can be used for specific scenarios.

When we login - we can check in troubleshooting logs of IAS that expected attributes are sent.

Now when we enable Identity Fedration

Enable identity fedration - in corporate IDP -> identity fedration.

Now Enrich assertion attributes in Corporate IDP don't work - we will need to use another functionality called Default attributes in Applications in IAS. In below screenshot we can see that it didn't send any IDP attributes.

Now Setup Default attributes in IAS application as shown in below screenshot - make sure you select corporate IDP in drop down menu to send the attributes from Corporate IDP

Perform login to Application again

Now expected attributes are received by BTP application

Scenario 2: Sending Hardcoded values to Applications using IAS

When Identity Fedration is disabled

Perform it in Corporate IDP -> Enrich assertion attributes

Post successful login - we can check Hard coded values are sent to Application

Identity fedration enabled

IAS application -> Default Attributes -> Set Attrubtes

Post successful login - we can check that Hard coded values are sent to BTP application

🚀Why It Matters

🔗Centralization: Handle diverse SAP SaaS attribute needs from one place.
📈Scalability: Onboard new services without remapping custom attributes everywhere.
🛠️ Maintainability: If tools change, update once in IAS—not in 5 different places.

Whether you’re setting up Datasphere 📊, Signavio 🟧, Kyma 🌀, or other BTP tools, IAS gives you a clean, unified way to tailor attributes—without touching your corporate IdP or apps.

✨🦌🪄 Expecto Patronum 🪄🦌✨

🌟🔮🧙‍♂️✨🧝‍♀️🌟
— may your SAP magic always shine bright!

Get your Kyma-Cluster NAT Gateway IPs

2025-09-30T13:44:29.935000+02:00

The SAP BTP, Kyma Runtime received an update that provides the NAT Gateway IP information directly in the Kyma Cluster. This makes it very easy to retrieve this information and use it for allow list and Firewall configuration.

The NAT Gateway IPs are now available in the ConfigMap "kyma-info" in the kyma-system namespace.

This makes it possible to retrieve it via the Dashboard as well as via the kubectl CLI and API:

Dashboard:

kubectl CLI:

SAP Build FAQ: Commercials, Getting Started and More

2025-10-03T15:08:38.806000+02:00

This FAQ provides an overview of SAP’s commercial offering of SAP Build. It covers the available commercial models for SAP Build and provides answers to questions that we most often hear regarding SAP Build commercial model, onboarding, metering and more.

What is the SAP Build Unified Offering? 

SAP Build has been designed as the optimal way to extend SAP S/4HANA Cloud and other business applications. Thousands of customers are already experiencing up to 3x faster development speeds with SAP Build according to recent analyst research — and now we’ve made it even better.

Combined with deep technical integration, SAP Builds unified offering empowers customers to quickly extend and personalize their business solutions using AI-powered application development and automation, while maintaining a clean core and eliminating additional licensing or budgeting complexity.

What is included in the Unified SAP Build Offering? 

Customers can access the full range of SAP Build capabilities through just four distinct SKUs.

SAP Build Base User is for end users who need to access applications, gain insights for day-to-day business needs, and approve tasks.

SAP Build Premium User includes all the features of the base user license, with added capabilities for end users to author content, monitor processes, customize pages and deploy attended bots.

SAP Build Developer includes all the features of the Premium User license, plus advanced capabilities for developers and architects who need full access to deployed assets.

SAP Build Runtime Application hosting and lifecycle management services that support the creation and execution for dev/test as well as production environments

How do I find out what is included in SAP Build? 

For a list of services that are included in SAP Build you can visit the SAP Discovery Center, for SAP Build following this link

To find out what is in each SKU, Base, Premium, Developer and Runtime you can visit the SAP Build Pricing Page here.

What commercial models are SAP Build provided in? 

Consumption Based Model: 

SAP BTP Enterprise Agreement (BTPEA)

SAP Cloud Enterprise Agreement (CPEA)

Pay-As-You-Go for SAP BTP

Subscription Based Commercial Mode: 

Service Plan for SAP Build Subscription

SAP Cloud ERP Private Edition: 

SAP Build Entitlements are included in the SAP Cloud ERP Edition

Find more about SAP Cloud ERP Edition here

Find out more about the SAP Build offering in SAP Cloud ERP Private Edition here

SAP Business Suite Packages:

Entitlements are provided in several of the SAP Business Suite packages

Partner:

SAP Build offers partners free access to SAP Build and other BTP Services.

SAP Build Test, Demo Development (the site requires you to be logged in as an SAP Partner)

How do I get started with SAP Build? 

SAP Build uses SAP BTPs Cloud Integration Automation (CIA) to quickly get customers and partners up and going on SAP Build. Find information on how to setup SAP Build here. For detailed instructions on the activation process, please share this blog post with your technical team

Does SAP Build include Joule Studio and Joule for Developer?  

Yes, SAP Build provides Joule for Developer and Joule Studio. Joule Studio is provided with the SAP Build Developer offering. Joule for Developer features are included, but will need to enable this through the free voucher SKUs. You can find more information on Joule for Developer here and Joule Studio here.

Are there specific service plans that are exclusive to the unified SAP Build offering?

The Joule Studio service is only offered in the SAP Build Developer SKU. Joule for Developer needs to be enabled through the free voucher SKU's and then can only be used with the SAP Build offering, SAP Build Code and Joule for Developer, BTP ABAP Environment. Visual Cloud Functions in SAP Build Apps is not available in the SAP Build unified SKU.

Can I migrate from the previous SAP Build SKU’s to the new SAP Build SKU? 

Upgrade you SAP Build licenses to access enhanced features and tools. Use build-specific plans for improved efficiently and customization in your projects.

For migration of services please refer to this help

Can I use both the Old and New Service plans within the same subaccount?

The old services cannot be enabled in the same subaccount as the new Build services. You will need to do a migration per the above migration guide.

How does metering work, for example if I use both SAP Build Base User and SAP Build Developer capabilities?

SAP Build operates on a metering model that relies on specific user roles to determine access and functionality within the platform, which include developer, base user, and premium user. Each user must have a global user ID created by an administrator, who also assigns the appropriate role collection to ensure that the correct authorization is granted.

This role assignment is critical; for instance, an SAP Build base user shouldn't be able to create new processes within SAP Build, as such permissions could lead to unintended alterations or disruptions in workflows. By understanding and correctly implementing these roles, organizations can effectively manage user capabilities while maintaining the integrity and security of their SAP Build environment.

For more detailed information on metering and roles visit this help location.

How can I learn more about SAP Build? 

SAP Build Basic Trial–Get hands-on experience with a free, 30-day trial, following a step-by-step tutorial on SAP Build.
SAP Discovery Center–Dive deeper with step-by-step guidance and best practices for implementing use cases.
SAP Learning –Develop SAP skills for free, anywhere, anytime, and at your own pace: SAP Build

Bridging Your On‑Prem Docker Registry with Kyma: Introducing the Registry Proxy Community Module

2025-10-23T13:55:02.107000+02:00

Hybrid architectures are the new normal. Yet one persistent friction point remains: securely consuming container images that live deep inside an on‑premise network without punching risky holes in the firewalls or running clumsy mirroring jobs. Today, we’re excited to introduce Registry Proxy - a Kyma community module that lets your cluster pull images from locked‑down, internal Docker/OCI registries while keeping them non‑public.

The key benefits of this solution are:

Security First: No inbound exposure of your internal registry; all traffic originates inside the cluster.
Cost Optimization: Eliminates the need to set up redundant Docker registry infrastructure.

Meet the Kyma Community Registry Proxy Module

The Registry Proxy module installs a lightweight operator and controller into your Kyma cluster. It provides a Kubernetes‑native abstraction for defining secure connections to one or more on‑prem registries. Workloads continue referencing familiar image tags; the module handles the secure retrieval path transparently.

Powered by SAP Cloud Connector

Under the hood, the module leverages SAP Cloud Connector technology to form an outbound, secure tunnel from the cluster to the on‑prem environment.

Defining Connections with a Custom Resource

Connections to internal registries are declared via the Connection custom resource (CR): connections.registry-proxy.kyma-project.io.

See the following simple example (illustrative only):

apiVersion: registry-proxy.kyma-project.io/v1alpha1
kind: Connection
metadata:
  name: corp-registry
spec:
  registry:
    host: internal-registry.corp.local

The operator reconciles this CR, validates reachability through Cloud Connector, and exposes status conditions reflecting readiness and Node Port value to be used when pulling the image. Your workloads then use image references pointing at localhost:{NodePort}/... as if the registry were locally reachable.

IMPORTANT: The Registry Proxy module is a community module. Community modules are openly developed Kyma extensions that live outside the core, officially supported module set. They encourage experimentation and early adopter feedback, iterate quickly without waiting for core release cycles, and may graduate to fully supported modules based on adoption and stability.

Expect transparent docs, examples, and active feedback, but remember that community modules are not subject to any service level agreement (SLA). For more information, see Community Modules.

Installing the Registry Proxy Module

Installation is streamlined via Kyma CLI, which already supports community modules. Make sure you have the CLI installed.

Run the following command to prepare the module:

kyma module pull registry-proxy --version 0.14.0

2. Add the module to your Kyma setup:

kyma module add registry-proxy --origin default/registry-proxy-0.14.0 --default-cr

Getting Started: Hands-On Tutorial

Ready to try it? Follow the Create Kyma Registry Proxy Connection and a Target Deployment tutorial.

You’ll learn:

How to configure SAP Cloud Connector for secure outbound registry access.
How to craft and apply a Connection CR.
How to deploy a sample workload pulling a private, on‑prem image.
How to inspect status conditions to confirm a healthy connection.

Call to Action

Spin up your Kyma environment, install the Registry Proxy community module with Kyma CLI, define a connection, and pull your first internal image securely, without registry exposure. Then tell us what worked, what didn’t, and what you need next.

We invite you to:

Open issues for feature requests, edge cases, or bugs.
Share deployment stories, such as network topologies and performance observations.
Suggest CR field improvements or status semantics.
Submit PRs for tests, docs, and example manifests.
Go through the tutorial.

SAP TechEd2025-XP264- Explore how to run cloud-native applications on SAP BTP, Kyma runtime

2025-10-29T10:33:13.323000+01:00

Description

A sneak preview of the material for the SAP TechEd 2025 session catalog number XP264 - Explore how to run cloud-native applications on SAP BTP, Kyma runtime.

Day-2 Operations: Management, Maintenance, Monitoring, and Optimization
Technical connectivity to public and private (on-premise) systems

The repository with the session material has been public since Monday, November 3rd.

See you there in Bangalore!

Overview

This session introduces attendees to Day-2 operations with SAP BTP, Kyma runtime - a managed kubernetes environment to help connect and extend enterprise applications in the cloud-native world.

In a nutshell, SAP BTP, Kyma Runtime (SKR) is a managed k8s runtime environment with a kubernetes cluster based on Gardener and a set of building blocks called Kyma modules.

Each instance of SAP BTP Kyma runtime environment is a single k8s gardener cluster with its own set of kyma modules.
Subsequently, all these clusters are managed by a central Kyma Control Plane (KCP) that orchestrates the lifecycle of

the underlying hyperscaler project,
the Gardener Cluster,
and the Kyma modules.

During the session you will learn

how to operate applications with SAP BTP, Kyma runtime and discover the power of smooth integration with cloud applications and on-premise systems using the advanced connectivity features.
to explore operational best practices from mastering troubleshooting techniques and intelligent root-cause analysis to event-driven autoscaling that adapts to your business needs in real time.
about BTP multitenant applications with SAP BTP, Kyma runtime.

Requirements

The requirements to follow the exercises in this repository are...

Important

You must be able to fork the repository and activate the github actions at the fork. This is mandatory for this session!
Thus, you may need a GitHub user.
If you haven't got one yet, please sign-up on GitHub before the workshop or at the very beginning of the session.

Important

The session content is provided exclusively on the SAP-Samples github, and many excercises have been implemented as CI/CD Github Actions worflows (GHA).

Security is paramount. With the Github Action IDP-delegated flow, there is no more need to provide kubernetes and btp credentials when using github actions.

✅The Github Action workflows acting as the OIDC provider.
✅All the kubernetets environments in the landscape are configured to trust GitHub’s token identity provider. They come with the pre-configured OIDC applications leveraging the built-in Gardener OIDC shoot extension.
✅SAP Cloud Identity Services acting as a platform IDP on the BTP side of the house has been federated with the Github actions OIDC Provider
✅As a result, the very short-lived credentials are being fetched and rotated automatically on the behalf of the repository user for both kubernetes and btp platform operations.
The good news is you may run the GHA-based exercises directly, from your forked repository, in a browser on the provided teched laptop.

Disclaimer

Personal devices should not be used for this session. Hands-on session participants will be using Windows laptops provided by the organizers.

What to expect from this session?

👉Run and take time to inspect the results of the built-in automations. Ask questions. And if you feel like doing, go ahead and create your own variants as well.
👉The recommendation is, however, to go with the flow of the exercises, inspect the results, ask questions and leave the rest for the homework.
For all other exercises which may require a terminal use, you may use the built-in VSCode terminal window.
As this is a Day-2 operation brief, the entire cloud landscape has been pre-configured with a number of shared components, for instance:
- 🔗SAP Cloud Identity Services (SAP IAS)
- 🔗SAP Cloud Logging
- 🔗SAP HANA Cloud
- 🔗ArgoCDaaS
- 🔗SAP BTP Connectivity services - Destination service, Connectivity service, Cloud Connector, Connectivity Proxy and Transparent Proxy
- 🔗S4/HANA On-premise (private cloud) with the Cloud Connector in the private network.
All of the SAP Kyma environments have been configured to the same template (via terraform automation).
Last but not least, you will be able to play with a pre-deployed SAP Build multitenant application deployed to one of the kyma clusters.
Have fun!

Influence the Next Wave of SAP BTP Innovation: Join the SAP Customer Engagement Initiative 2025-3

2025-10-30T17:31:53.418000+01:00

Transforming Enterprise Innovation with SAP Business Technology Platform (SAP BTP)

SAP BTP is revolutionizing how businesses innovate. This integrated platform combines application development, automation, data and analytics, integration, and AI, empowering enterprises to achieve new levels of efficiency and intelligence.

Now, you can be a part of this transformation.

The third cycle of the SAP Customer Engagement Initiative for 2025 is here, offering you the opportunity to shape the future of SAP BTP. As a customer or partner, you’re invited to collaborate directly with SAP developers and product teams to influence upcoming features, tools, and innovations.

This is not just about early access; it’s a chance to steer the direction of enterprise technology.

Don’t wait - registration is open only until November 14, 2025.

Check out the full list here or follow the links below to discover the exciting opportunities:

Let’s build the future together!

Innovation thrives through collaboration. By participating in the SAP Customer Engagement Initiative projects, you help SAP develop more effective and relevant solutions for businesses like yours. This is your chance to impact the future of enterprise technology.

Don’t miss out - sign up today at influence.sap.com and be a part of the SAP Customer Engagement Initiative Cycle 3 in 2025!

Warm regards,

Your SAP Customer Engagement Initiative Team

Follow-up after registration: When you register for a project, you will be invited to an introductory call with the SAP project lead. Participation beyond this point is optional and typically governed by the Feedback Agreement with SAP.

Preparing for SAP C_CPE? Here’s How I’m Studying Each Section Without Feeling Overwhelmed

2025-11-04T15:23:22.635000+01:00

Whenever I start learning something new, I like to have everything in order.
Before I even open the first tutorial, I plan what I’ll study first, what comes next, and how I’ll track it.

Recently, I started preparing for the SAP C_CPE (SAP Certified Associate - Backend Developer - SAP Cloud Application Programming Model) certification. Since this exam covers a mix of BTP architecture, SAP BAS, CAP, Side by side extensions, Cloud Foundry & Kyma Runtime it can easily feel like too much at once. So I created a simple structure to move step by step without feeling lost.

I began with the learning about BTP, and doing hands on by following SAP Learning Journeys, creating subaccount and adding entitlements and services (It gave me a very clear understanding of BTP architecture) and then Developing appliaction using high productivity tools of SAP BAS, Cloud Application Programming Model (CAP) because it’s the foundation of most topics in this certification. I’m spending around two weeks learning about CDS models, service layers and how everything connects in a CAP project. I’m following the official SAP Learning Journey https://learning.sap.com/certifications/sap-certified-associate-backend-developer-sap-cloud-program…...

My next focus is Cloud Foundry. I’ll spend about a week learning how to efficiently develop, run, and manage cloud-native applications on SAP BTP, Cloud Foundry Runtime.

After that, I’ll move to Side by side extention on BTP. This will cover deploying extension and integrating the app into SAP Build Work Zone.

The next stage is Developing Appliactions in Kyma Environment. I’ll take about two weeks to explore a comprehensive understanding of Kubernetes and to orchestrate the deployment of the applications in the cloud.

Finally, I’ll study Advanced Extensions with SAP Cloud SDK for about two more weeks. These are slightly advanced topics but very useful for understanding to develop and integrate Java, JavaScript, and TypeScript extension applications for SAP solutions like SAP S/4HANA Cloud Public Edition.

So in short, this will be my roadmap-

Recommended Study Sequence

Here’s the order I suggest, from foundational to more advanced :

1.Exploring SAP Business Technology Platform 5hrs (link : https://learning.sap.com/courses/exploring-sap-business-technology-platform)

This gives you a broad overview of the entire platform (services, architecture, what BTP is). Good for building your base understanding.
So start here.

2.Develop Full‑Stack Applications Using Productivity Tools in SAP Business Application Studio 8hrs (https://learning.sap.com/learning-journeys/develop-full-stack-applications-using-productivity-tools-in-sap-business-application-studio)

3.Develop Applications on SAP BTP, Cloud Foundry Runtime 4hrs(https://learning.sap.com/learning-journeys/developing-applications-on-sap-btp-cloud-foundry-runtime)

The Cloud Foundry runtime is a major runtime environment in BTP. Understanding how to build and deploy there is critical.

4.Build Side‑by‑Side Extensions on SAP BTP 8hrs (https://learning.sap.com/learning-journeys/build-side-by-side-extensions-on-sap-btp)

After tooling and platform basics, you dive into extension scenarios (for example side-by-side extensions of S/4HANA using CAP). This aligns closely with CAP certification topics.

5.Developing Applications in SAP BTP, Kyma Runtime 8hrs(https://learning.sap.com/learning-journeys/developing-applications-in-sap-btp-kyma-runtime)

Kyma Runtime is more advanced (Kubernetes, microservices, event-mesh) and often sits on top of foundational knowledge.

6.Develop Advanced Extensions with SAP Cloud SDK 11hrs (https://learning.sap.com/learning-journeys/develop-advanced-extensions-with-sap-cloud-sdk)

This is relatively specialized/advanced (SAP Cloud SDK, perhaps custom libraries, integrations). Once you’ve mastered the fundamentals above, you go here.

By the end of this plan, I’ll go through a short revision period with mock questions and quick notes from my learning.

This structured approach keeps my study plan clear and prevents me from feeling overwhelmed.
I study for two to four hours a day which feels realistic, and the small milestones make it easier to stay consistent.

If you’re also preparing for C_CPE, it really helps to make your own sequence instead of jumping randomly between topics. The Learning Journeys are excellent resources, but having a personal roadmap makes a big difference.

I’d love to hear how others are preparing for this certification too.
What topics are you finding most challenging so far and how are you managing the learning

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.