SAP Community - SAP BTP, Kyma runtime

SAP BTP Kyma headless kubeconfig with SAP Cloud Identity Services and kyma environment bindings

2024-12-22T16:18:44.853000+01:00

Implementing SAP Kyma headless kubeconfig with

a custom SAP Cloud Identity Services as SAP Kyma cluster OIDC provider
kymaruntime environment service bindings

Let's see how...

https://dev.to/quovadis/sap-btp-kyma-blueprints-2cjf

Let me help break down this comprehensive information about SAP BTP Kyma kubeconfig authentication methods.

Let's understand each approach and their specific use cases.

The three main authentication methods for Kyma kubeconfig are:

1. Authorization Code Flow (OIDC)
This is the standard approach for interactive users. It requires individual users to be defined in the SAP ID tenant and have appropriate RBAC cluster-admin role bindings. While this method works well for direct user interaction, it isn't suitable for automated processes since it requires manual authentication.

2. Password Grant Type Flow
This method is designed for headless environments like CI/CD pipelines or automated workflows. It requires:
- A custom SAP Cloud Identity Service tenant
- A public client OIDC application
- A technical user with credentials stored securely
- The configuration uses a bash script to obtain tokens automatically

3. Kyma Runtime Environment Service Bindings
This approach provides service account tokens during the Kyma runtime environment provisioning.
Key points:
- Requires a cis-local plan Cloud Management service instance
- Tokens are obtained through the SAP Provisioning Service environment bindings API
- Provides the simplest configuration but requires proper setup of the environment binding

For implementing automated workflows, the Password Grant Type Flow offers the most flexibility while maintaining security through technical user credentials. The Kyma Runtime Environment Service Bindings approach is ideal when working directly with the provisioning process.

Let me know if you'd like me to elaborate on any of these authentication methods or their specific implementation details.

https://dev.to/quovadis/sap-btp-kyma-blueprints-2cjfLet me help break down this comprehensive information about SAP BTP Kyma kubeconfig authentication methods.Let's understand each approach and their specific use cases.The three main authentication methods for Kyma kubeconfig are:1. Authorization Code Flow (OIDC)This is the standard approach for interactive users. It requires individual users to be defined in the SAP ID tenant and have appropriate RBAC cluster-admin role bindings. While this method works well for direct user interaction, it isn't suitable for automated processes since it requires manual authentication.2. Password Grant Type FlowThis method is designed for headless environments like CI/CD pipelines or automated workflows. It requires:- A custom SAP Cloud Identity Service tenant- A public client OIDC application- A technical user with credentials stored securely- The configuration uses a bash script to obtain tokens automatically3. Kyma Runtime Environment Service BindingsThis approach provides service account tokens during the Kyma runtime environment provisioning.Key points:- Requires a cis-local plan Cloud Management service instance- Tokens are obtained through the SAP Provisioning Service environment bindings API- Provides the simplest configuration but requires proper setup of the environment bindingFor implementing automated workflows, the Password Grant Type Flow offers the most flexibility while maintaining security through technical user credentials. The Kyma Runtime Environment Service Bindings approach is ideal when working directly with the provisioning process.Let me know if you'd like me to elaborate on any of these authentication methods or their specific implementation details.

Spoiler

Let me explain the Password Grant Type authentication flow for SAP BTP Kyma in detail.

```hcl
# First, set up the Identity Application entitlement in your subaccount
resource "btp_subaccount_entitlement" "identity_application" {
subaccount_id = data.btp_subaccount.context.id
service_name = "identity"
plan_name = "application"
}

# Reference the service plan for the identity application
data "btp_subaccount_service_plan" "identity_application" {
depends_on = [btp_subaccount_entitlement.identity_application]
subaccount_id = data.btp_subaccount.context.id
offering_name = "identity"
name = "application"
}

# Create the Identity Application service instance with specific OAuth2 configuration
resource "btp_subaccount_service_instance" "identity_application" {
depends_on = [btp_subaccount_trust_configuration.custom_idp]
subaccount_id = data.btp_subaccount.context.id
name = "ias-local"
serviceplan_id = data.btp_subaccount_service_plan.identity_application.id

# Detailed configuration for the Identity Application
parameters = jsonencode({
# Set access to public for broader accessibility
user-access = "public"

# OAuth2 configuration specifying allowed grant types and token policies
oauth2-configuration = {
grant-types = [
"authorization_code",
"authorization_code_pkce_s256",
"password", # Enable password grant type for headless authentication
"refresh_token"
],
token-policy = {
token-validity = 3600, # Access token valid for 1 hour
refresh-validity = 15552000, # Refresh token valid for 180 days
refresh-usage-after-renewal = "off",
refresh-parallel = 3,
access-token-format = "default"
},
public-client = true, # Enable public client mode
redirect-uris = [
"https://dashboard.kyma.cloud.sap",
"http://localhost:8000"
]
},

# Configure how user identifiers are determined
subject-name-identifier = {
attribute = "mail",
fallback-attribute = "none"
},

# Map assertion attributes to specific user properties
assertion-attributes = {
email = "mail",
groups = "companyGroups",
first_name = "firstName",
last_name = "lastName",
login_name = "loginName",
mail = "mail",
scope = "companyGroups",
user_uuid = "userUuid",
locale = "language"
},

# Set the application name using variables
name = "${var.BTP_KYMA_NAME}-${var.BTP_KYMA_PLAN}-${data.btp_subaccount.context.id}",
display-name = "${var.BTP_KYMA_NAME}-${var.BTP_KYMA_PLAN}"
})
}

```

The Password Grant Type authentication flow is designed specifically for non-interactive, automated scenarios. Let me break down how it works and why each component is important:

The Setup Process:

1. Custom Identity Service Setup
- You need to create a custom SAP Cloud Identity Service (IAS) tenant rather than using the default SAP ID Service
- This gives you more control over authentication policies and user management
- The service instance is configured as a public client, which is crucial for the password grant flow

2. OAuth2 Configuration
- The setup enables multiple grant types, but specifically includes the "password" grant
- Token policies are configured with specific validities:
- Access tokens last for 1 hour (3600 seconds)
- Refresh tokens last for 180 days (15552000 seconds)
- The public client setting eliminates the need for client secrets

3. User Attribute Mapping
- The configuration maps various user attributes (email, groups, name, etc.)
- This mapping ensures that Kubernetes RBAC can properly identify and authorize users
- The "mail" attribute serves as the primary identifier for users

Using the Authentication:

When this is set up, your automated processes can authenticate using a technical user's credentials. Here's how it works:

1. The process makes a POST request to the IAS token endpoint
2. It provides:
- The technical user's username and password
- The client ID of your IAS application
- The required scopes (typically "groups" and "email")
3. The IAS service returns an ID token
4. This token is then used for Kubernetes authentication

Security Considerations:

1. Technical User Management
- Create a dedicated technical user in your IAS tenant
- Assign minimum required permissions through groups
- Regularly rotate the password
- Store credentials in a secure vault or secret management system

2. Token Handling
- Never log or expose the tokens
- Implement proper error handling for token expiration
- Use refresh tokens when appropriate to minimize password usage

3. Access Control
- Implement proper RBAC policies in Kubernetes
- Regularly audit access patterns
- Monitor for suspicious authentication attempts

This authentication method is particularly useful for:
- CI/CD pipelines
- Automated deployment scripts
- Monitoring systems
- Backup solutions
- Any other headless processes that need to interact with your Kyma cluster

Would you like me to elaborate on any particular aspect of this setup, such as the technical user creation process or specific security best practices?

Let me explain the Password Grant Type authentication flow for SAP BTP Kyma in detail. ```hcl# First, set up the Identity Application entitlement in your subaccountresource "btp_subaccount_entitlement" "identity_application" {subaccount_id = data.btp_subaccount.context.idservice_name = "identity"plan_name = "application"}# Reference the service plan for the identity applicationdata "btp_subaccount_service_plan" "identity_application" {depends_on = [btp_subaccount_entitlement.identity_application]subaccount_id = data.btp_subaccount.context.idoffering_name = "identity"name = "application"}# Create the Identity Application service instance with specific OAuth2 configurationresource "btp_subaccount_service_instance" "identity_application" {depends_on = [btp_subaccount_trust_configuration.custom_idp]subaccount_id = data.btp_subaccount.context.idname = "ias-local"serviceplan_id = data.btp_subaccount_service_plan.identity_application.id# Detailed configuration for the Identity Applicationparameters = jsonencode({# Set access to public for broader accessibilityuser-access = "public"# OAuth2 configuration specifying allowed grant types and token policiesoauth2-configuration = {grant-types = ["authorization_code","authorization_code_pkce_s256","password", # Enable password grant type for headless authentication"refresh_token"],token-policy = {token-validity = 3600, # Access token valid for 1 hourrefresh-validity = 15552000, # Refresh token valid for 180 daysrefresh-usage-after-renewal = "off",refresh-parallel = 3,access-token-format = "default"},public-client = true, # Enable public client moderedirect-uris = ["https://dashboard.kyma.cloud.sap","http://localhost:8000"]},# Configure how user identifiers are determinedsubject-name-identifier = {attribute = "mail",fallback-attribute = "none"},# Map assertion attributes to specific user propertiesassertion-attributes = {email = "mail",groups = "companyGroups",first_name = "firstName",last_name = "lastName",login_name = "loginName",mail = "mail",scope = "companyGroups",user_uuid = "userUuid",locale = "language"},# Set the application name using variablesname = "${var.BTP_KYMA_NAME}-${var.BTP_KYMA_PLAN}-${data.btp_subaccount.context.id}",display-name = "${var.BTP_KYMA_NAME}-${var.BTP_KYMA_PLAN}"})}```The Password Grant Type authentication flow is designed specifically for non-interactive, automated scenarios. Let me break down how it works and why each component is important:The Setup Process:1. Custom Identity Service Setup- You need to create a custom SAP Cloud Identity Service (IAS) tenant rather than using the default SAP ID Service- This gives you more control over authentication policies and user management- The service instance is configured as a public client, which is crucial for the password grant flow2. OAuth2 Configuration- The setup enables multiple grant types, but specifically includes the "password" grant- Token policies are configured with specific validities:- Access tokens last for 1 hour (3600 seconds)- Refresh tokens last for 180 days (15552000 seconds)- The public client setting eliminates the need for client secrets3. User Attribute Mapping- The configuration maps various user attributes (email, groups, name, etc.)- This mapping ensures that Kubernetes RBAC can properly identify and authorize users- The "mail" attribute serves as the primary identifier for usersUsing the Authentication:When this is set up, your automated processes can authenticate using a technical user's credentials. Here's how it works:1. The process makes a POST request to the IAS token endpoint2. It provides:- The technical user's username and password- The client ID of your IAS application- The required scopes (typically "groups" and "email")3. The IAS service returns an ID token4. This token is then used for Kubernetes authenticationSecurity Considerations:1. Technical User Management- Create a dedicated technical user in your IAS tenant- Assign minimum required permissions through groups- Regularly rotate the password- Store credentials in a secure vault or secret management system2. Token Handling- Never log or expose the tokens- Implement proper error handling for token expiration- Use refresh tokens when appropriate to minimize password usage3. Access Control- Implement proper RBAC policies in Kubernetes- Regularly audit access patterns- Monitor for suspicious authentication attemptsThis authentication method is particularly useful for:- CI/CD pipelines- Automated deployment scripts- Monitoring systems- Backup solutions- Any other headless processes that need to interact with your Kyma clusterWould you like me to elaborate on any particular aspect of this setup, such as the technical user creation process or specific security best practices?

Spoiler

Let me explain the Kyma Runtime Environment Bindings method, which provides a streamlined way to obtain cluster access through SAP BTP service bindings.

```hcl
# First, set up the Cloud Management Service instance
resource "btp_subaccount_service_instance" "cis_service" {
subaccount_id = data.btp_subaccount.context.id
name = "cis-local"
serviceplan_id = data.btp_subaccount_service_plan.cis_local.id
}

# Create the service binding for Cloud Management Service
resource "btp_subaccount_service_binding" "cis_binding" {
depends_on = [btp_subaccount_service_instance.cis_service]
subaccount_id = data.btp_subaccount.context.id
service_instance_id = btp_subaccount_service_instance.cis_service.id
name = "cis-local-binding"
}

# Set up the Kyma runtime environment
resource "btp_subaccount_service_instance" "kyma_runtime" {
subaccount_id = data.btp_subaccount.context.id
name = var.kyma_instance_name
serviceplan_id = data.btp_subaccount_service_plan.kyma_runtime.id

parameters = jsonencode({
name = var.kyma_instance_name
planName = var.kyma_plan_name
shootName = var.shoot_name
targetK8sVersion = var.kubernetes_version
machineType = var.machine_type
autoScalerMin = var.min_nodes
autoScalerMax = var.max_nodes
maxSurge = 1
volumeSizeGb = var.volume_size
diskType = "pd-standard"
region = var.region
workerCidr = var.worker_cidr
servicesCidr = var.services_cidr
podsCidr = var.pods_cidr
})
}

# Create the service binding for Kyma runtime
resource "btp_subaccount_service_binding" "kyma_binding" {
depends_on = [btp_subaccount_service_instance.kyma_runtime]
subaccount_id = data.btp_subaccount.context.id
service_instance_id = btp_subaccount_service_instance.kyma_runtime.id
name = "${var.kyma_instance_name}-binding"
}

```

The Kyma Runtime Environment Bindings method works through the SAP BTP service binding mechanism. Let me break down how this approach functions and why it's particularly useful.

Understanding the Components:

1. Cloud Management Service (CIS)
This service acts as a bridge between your BTP subaccount and the Kyma runtime. The CIS instance:
- Manages service credentials
- Handles authentication and authorization
- Provides necessary APIs for runtime management
- Must be provisioned with the cis-local plan

2. Kyma Runtime Instance
The Kyma runtime itself needs specific configuration, including:
- Kubernetes version specifications
- Node pool configurations
- Network settings
- Resource allocations
- Regional preferences

3. Service Bindings
Two key bindings are created:
- CIS binding: Provides access to cloud management capabilities
- Kyma binding: Delivers the actual kubeconfig credentials

How the Authentication Works:

When you create a service binding to your Kyma runtime:
1. The BTP Provisioning Service generates a service account in your Kyma cluster
2. This service account receives appropriate RBAC permissions
3. A kubeconfig file is generated containing a bearer token
4. The token is automatically rotated and managed by the platform

Advantages of This Method:

1. Simplified Management
- No need to manage separate credentials
- Platform handles token rotation automatically
- Reduced operational overhead
- Integrated with BTP service management

2. Security Benefits
- Tokens are managed by the platform
- Clear audit trail through BTP
- Automatic credential rotation
- Integrated with BTP security controls

3. Operational Efficiency
- Direct integration with BTP services
- No additional authentication setup required
- Works seamlessly with other BTP services
- Easy to automate through infrastructure as code

Best Practices for Implementation:

1. Service Instance Names
- Use consistent naming conventions
- Include environment indicators
- Make names descriptive and meaningful
- Document naming patterns

2. Binding Management
- Create separate bindings for different purposes
- Monitor binding status
- Implement proper error handling
- Keep binding information secure

3. Access Control
- Review generated RBAC permissions
- Monitor service account usage
- Implement proper security policies
- Regular access audits

Common Use Cases:

This method is particularly useful for:
- Development environments integrated with BTP
- Automated deployment pipelines
- Platform operations tools
- Monitoring and logging systems
- Any scenario where tight BTP integration is desired

The bindings method provides a more automated and platform-integrated approach compared to other authentication methods. Would you like me to elaborate on any specific aspect, such as the binding creation process or how to manage multiple environments?

Let me explain the Kyma Runtime Environment Bindings method, which provides a streamlined way to obtain cluster access through SAP BTP service bindings. ```hcl# First, set up the Cloud Management Service instanceresource "btp_subaccount_service_instance" "cis_service" {subaccount_id = data.btp_subaccount.context.idname = "cis-local"serviceplan_id = data.btp_subaccount_service_plan.cis_local.id}# Create the service binding for Cloud Management Serviceresource "btp_subaccount_service_binding" "cis_binding" {depends_on = [btp_subaccount_service_instance.cis_service]subaccount_id = data.btp_subaccount.context.idservice_instance_id = btp_subaccount_service_instance.cis_service.idname = "cis-local-binding"}# Set up the Kyma runtime environmentresource "btp_subaccount_service_instance" "kyma_runtime" {subaccount_id = data.btp_subaccount.context.idname = var.kyma_instance_nameserviceplan_id = data.btp_subaccount_service_plan.kyma_runtime.idparameters = jsonencode({name = var.kyma_instance_nameplanName = var.kyma_plan_nameshootName = var.shoot_nametargetK8sVersion = var.kubernetes_versionmachineType = var.machine_typeautoScalerMin = var.min_nodesautoScalerMax = var.max_nodesmaxSurge = 1volumeSizeGb = var.volume_sizediskType = "pd-standard"region = var.regionworkerCidr = var.worker_cidrservicesCidr = var.services_cidrpodsCidr = var.pods_cidr})}# Create the service binding for Kyma runtimeresource "btp_subaccount_service_binding" "kyma_binding" {depends_on = [btp_subaccount_service_instance.kyma_runtime]subaccount_id = data.btp_subaccount.context.idservice_instance_id = btp_subaccount_service_instance.kyma_runtime.idname = "${var.kyma_instance_name}-binding"}```The Kyma Runtime Environment Bindings method works through the SAP BTP service binding mechanism. Let me break down how this approach functions and why it's particularly useful.Understanding the Components:1. Cloud Management Service (CIS)This service acts as a bridge between your BTP subaccount and the Kyma runtime. The CIS instance:- Manages service credentials- Handles authentication and authorization- Provides necessary APIs for runtime management- Must be provisioned with the cis-local plan2. Kyma Runtime InstanceThe Kyma runtime itself needs specific configuration, including:- Kubernetes version specifications- Node pool configurations- Network settings- Resource allocations- Regional preferences3. Service BindingsTwo key bindings are created:- CIS binding: Provides access to cloud management capabilities- Kyma binding: Delivers the actual kubeconfig credentialsHow the Authentication Works:When you create a service binding to your Kyma runtime:1. The BTP Provisioning Service generates a service account in your Kyma cluster2. This service account receives appropriate RBAC permissions3. A kubeconfig file is generated containing a bearer token4. The token is automatically rotated and managed by the platformAdvantages of This Method:1. Simplified Management- No need to manage separate credentials- Platform handles token rotation automatically- Reduced operational overhead- Integrated with BTP service management2. Security Benefits- Tokens are managed by the platform- Clear audit trail through BTP- Automatic credential rotation- Integrated with BTP security controls3. Operational Efficiency- Direct integration with BTP services- No additional authentication setup required- Works seamlessly with other BTP services- Easy to automate through infrastructure as codeBest Practices for Implementation:1. Service Instance Names- Use consistent naming conventions- Include environment indicators- Make names descriptive and meaningful- Document naming patterns2. Binding Management- Create separate bindings for different purposes- Monitor binding status- Implement proper error handling- Keep binding information secure3. Access Control- Review generated RBAC permissions- Monitor service account usage- Implement proper security policies- Regular access auditsCommon Use Cases:This method is particularly useful for:- Development environments integrated with BTP- Automated deployment pipelines- Platform operations tools- Monitoring and logging systems- Any scenario where tight BTP integration is desiredThe bindings method provides a more automated and platform-integrated approach compared to other authentication methods. Would you like me to elaborate on any specific aspect, such as the binding creation process or how to manage multiple environments?

CAP-JAVA implementation for Authorization Management Service (AMS)

2024-12-27T10:35:32.060000+01:00

Basic concept of AMS

To learn the basic concept of AMS, like what is Authorization Management Service (AMS), how it works and what is the Policy, you can refer to the article writen by @kevin_li .

Authorization Management Service in SAP Cloud Identity Service

This Blog is specifically to introduce one of the implementation of AMS in our project, that is, how CAP-JAVA based application integrate with AMS.

General dev flow

Assume that you already have a fine run CAP-JAVA application, you can simply follow this steps to integrate AMS to your application:

Make sure you are using the latest version of these dependencies.

First include the ams dependency in your package.json.

  "devDependencies": {
    "@sap/ams-dev": "^2"
  },
  "dependencies": {
    "@sap/cds-dk": "^8.6.0"
  },

Run the following command to add AMS to your project.

npm i
cds add ias
cds add ams

It automatically add the related dependencies in your srv/pom.xml, make sure you are using the latest version. (**At least >= 2.0.0**)

<sap.cloud.security.ams.version>2.0.0</sap.cloud.security.ams.version>

If you are using DwC(if you don't use it, skip this step), Upgrade your sap.cloud.sdk to version >= 5.12.0. The DwC Auth token issue has been fixed from this version.

<cloud-sdk.version>5.15.0</cloud-sdk.version>

    <!-- Deploy with Confidence -->
    <dependency>
      <groupId>com.sap.dwc</groupId>
      <artifactId>util-cap</artifactId>
      <version>${dwc.version}</version>
      <exclusions>
        <exclusion>
          <groupId>com.sap.dwc</groupId>
          <artifactId>util-mutual-authentication</artifactId>
        </exclusion>
      </exclusions>
    </dependency>

Authorization Model Design

Follow the guide provided by CAP, you can use annotations to restrict the authorization of APIs and Entities.

Official guideline by cloud-authorization-client-library-java gives a very detailed information of how to handle it.

[removed by moderator]

Assign and check your policy

Again, Li's article gives a very general introduction of how to do this.

Authorization Management Servic e in SAP Cloud Identity Service

SAP Business Technology Platform (BTP)

2025-01-10T07:37:50.178000+01:00

The SAP Business Technology Platform (BTP) is a Platform-as-a-Service (PaaS) offering from SAP that provides a comprehensive suite of services and tools for businesses to:

Integrate and extend SAP applications: BTP allows you to seamlessly connect and enhance existing SAP solutions (like S/4HANA) with new functionalities and integrations.
Build new business applications: You can develop custom applications using various programming languages, frameworks, and tools, tailored to specific business needs.
Analyze data and gain insights: BTP provides tools for data warehousing, business intelligence, and advanced analytics, enabling data-driven decision-making.
Automate business processes: You can automate repetitive tasks and workflows using robotic process automation (RPA) and workflow management capabilities.
Implement intelligent technologies: BTP offers access to AI, machine learning, and Internet of Things (IoT) services, enabling you to build intelligent applications and solutions.

In essence, SAP BTP acts as a central hub for innovation and digital transformation within an organization's SAP landscape.

Here's a breakdown of its key roles:

Integration: BTP facilitates seamless integration between SAP and non-SAP systems, both on-premise and in the cloud. This allows businesses to connect their entire IT landscape and create end-to-end business processes.
Extension: BTP enables you to extend the functionality of existing SAP applications without modifying the core code. This ensures that customizations don't interfere with future updates and upgrades.
Innovation: BTP provides a platform for developing new and innovative applications that address specific business challenges and opportunities. This empowers businesses to create unique solutions that differentiate them from their competitors.
Agility: BTP offers a flexible and scalable environment for developing and deploying applications. This allows businesses to respond quickly to changing market conditions and customer demands.

Key components of SAP BTP:

SAP Integration Suite: Connects various systems and applications.
SAP Extension Suite: Enables extending existing SAP solutions.
SAP Analytics Cloud: Provides business intelligence and analytics capabilities.
SAP Data Management Suite: Offers tools for data warehousing and data management.
SAP Intelligent Technologies: Includes AI, machine learning, and IoT services.

In simple terms:

Imagine your core SAP system as the engine of your business. SAP BTP is like a workshop next to it, providing all the tools and resources you need to:

Tune the engine: Optimize existing processes and functionalities.
Add new parts: Build new applications and integrations.
Monitor performance: Analyze data and gain insights.
Automate tasks: Streamline workflows and improve efficiency.

By leveraging SAP BTP, businesses can unlock the full potential of their SAP investments and drive digital transformation across their organization.

https://www.linkedin.com/posts/mickaelquesnot_the-sap-business-technology-platform-btp-activity-7281219256862576640-tXTf?utm_source=share&utm_medium=member_desktop

Join & Gather in SAP Cloud Platform Integration

2025-01-14T16:21:54.532000+01:00

In SAP Cloud Platform Integration (CPI), the Join and Gather steps are crucial for orchestrating message flows, particularly when dealing with multiple messages that need to be combined or synchronized.

XML Payload:

<PersonalDetails>
<PersonalDetail>
<PersonalID>9655</PersonalID>
<PersonalNumber>1</PersonalNumber>
<Name>vamsi</Name>
<Pnumber>765426567568</Pnumber>
<Email>smoething@gmail.com</Email>
<State>AndhraPradesh</State>
<Martialstatus>No</Martialstatus>
<Job>Software Engineer</Job>
</PersonalDetail></PersonalDetails>

Join:

The Join step is used to bring together messages from different routes or branches within a single integration flow. It acts as a synchronization point, ensuring that all messages from specified routes have arrived before proceeding further.

Key Features:

Synchronization: Ensures that all messages from the specified routes are available before proceeding.
No Message Modification: The Join step itself does not modify the content of the messages. It simply brings them together.
Routing Flexibility: Messages can be routed to different branches based on conditions or other criteria.
Gather:
The Gather step merges multiple messages into a single message. This is useful when you need to combine data from different sources or create a summary message.
Key Features:
- Message Combination: Merges multiple messages into a single message.
- Combination Strategies: Offers various strategies for combining messages, such as appending, concatenating, or creating a collection.
- Conditional Gathering: Can be configured to gather messages based on specific conditions.
In Gather steps, there are two tabs:
1. General: You can give any meaningful name.
2. Aggregator Strategy: In this tab, several options are present to perform operations.
Incoming Format:
You can select which format to apply; here, four formats are available:
- Any: If you want to combine any incoming messages independent of their format.
- Plaintext: If messages from different routes are in plain text format.
- XML (Different Format) If messages from different routes are in different XML formats.
- XML (Same Format) If messages from different routes are in the same XML format.
Aggregation Algorithm:
- Combine: Can only be selected if you have chosen XML (Same Format) or XML (Different Format) for the Incoming Format. This option combines the incoming messages without any conditions. The messages are combined in Multimapping format.
- Combine at XPath: Can only be selected if you have chosen XML (Same Format) for the Incoming Format. This option combines the incoming messages at the specified XPath.
- Tar & Zip: Specify a simple expression to define unique file names within the archive. If not specified, the header CamelFileName is evaluated. In case the header is not available at runtime, a unique file name will be generated.

Developing, Running, and Monitoring LangChain Applications on SAP BTP

2025-01-17T02:44:44.618000+01:00

This article is translated version of the original Japanese blog:
SAP BTP上でLangChainアプリケーションを開発・実行・監視する

Introduction

In today’s rapidly advancing era of generative AI, the demand for applications integrating AI technologies is increasing, aiming to enhance business process efficiency and create added value. SAP BTP (Business Technology Platform) has gained significant attention as a flexible and scalable platform for extending SAP S/4HANA Cloud and other business systems. Particularly, building applications leveraging generative AI on SAP BTP is the key to unlocking new possibilities.

This blog provides a step-by-step guide to developing, operating, and monitoring large language model (LLM) applications on SAP BTP. Using the “gpt-4o” model provided by Azure OpenAI as an example, we will cover everything from configuring LLM access using SAP AI Launchpad to deploying LangChain applications with SAP Build Code, and monitoring them using Langfuse. By the end, you will have a clear understanding of how to maximize the potential of SAP BTP to build scalable AI solutions.

We hope this blog helps you learn the technical fundamentals of application development with generative AI and take your first steps toward applying them in real business scenarios.

Steps

Prerequisites

SAP AI Launchpad / SAP AI Core (Extended Plan) / SAP Build Code is activated.
A Full-Stack Application-type DevSpace is created using SAP Build Code.

1. Accessing Powerful LLMs via Generative AI Hub

Access external powerful LLMs through Generative AI Hub in SAP AI Launchpad. First, check the available models listed in the SAP Note below as needed:

https://me.sap.com/notes/3437766

For this guide, we’ll use the “gpt-4o” model provided by Azure OpenAI.

In SAP AI Launchpad, navigate to the working resource group, and go to “ML Operations” => “Settings” from the left pane. Click “Create” in the top right corner to create an LLM access configuration.
Input the information as shown in the image. The name can be arbitrary; in this case, we’ll use “gpt-4o.”
On the next page, configure the type and version of the LLM to use. Refer to the aforementioned SAP Note for the modelName and modelVersion.
After completing the settings, ensure that the modelName is displayed as “gpt-4o.” Click the “Create Deployment” button in the top right corner based on this startup configuration.
You can configure the startup time and other settings, but proceed with the default settings for this example. Once successful, you should see the following screen. Wait for the LLM access point to be created and activated; its current status should display “Running.”

The setup of Generative AI Hub is now complete.

2. Preparing a LangChain Application with SAP Build Code and Connecting it to Langfuse Pre-deployed on SAP BTP

Next, deploy a LangChain application to SAP BTP, Cloud Foundry Runtime using SAP Build Code. In our previous blog, we deployed Langfuse, a monitoring platform for LLM applications, on SAP BTP, Kyma Runtime. If you haven’t yet referred to it, please check it out here:

Deploying Langfuse on SAP BTP, Kyma Runtime

For this guide, clone a sample application from GitHub:

git clone https://github.com/watwatwhat/Langfuse_LangChain_onSAPBTP.git

The application is structured as a Multi-Target Application (MTA), and you can deploy it easily using the default command-line tools available in SAP Build Code.

Key Points in the Source Code:

Using Generative AI Hub SDK to utilize LangChain via SAP AI Core.

from gen_ai_hub.proxy.langchain.openai import OpenAIEmbeddings as g_OpenAIEmbeddings
from gen_ai_hub.proxy.langchain.openai import ChatOpenAI as g_ChatOpenAI

proxy_client = get_proxy_client('gen-ai-hub')  # <- GenAIHubプロキシ
embeddings = g_OpenAIEmbeddings(proxy_model_name=embedding_model)  # <- SAP AI Core経由のOpenAI Embeddingモデル
llm = g_ChatOpenAI(proxy_model_name=model_option, proxy_client=proxy_client, temperature=0.0)  # <- SAP AI Core経由のOpenAI Chatモデル

Sending logs to Langfuse.

agent = create_react_agent(
    llm=llm,
    tools=tools,
    prompt=prompt
)
agent_executor = AgentExecutor(
    agent=agent,
    tools=tools, 
    handle_parsing_errors=True, 
    verbose=True,
    max_iterations=5
)
from langfuse.callback import CallbackHandler
langfuse_handler = CallbackHandler(
    public_key="XXXXXXX",
    secret_key="XXXXXXX",
    host="http://XXXXXXXX:3000"
)

response = agent_executor.invoke({"input": input}, config={"callbacks": [langfuse_handler]})

Retrieve the connection information from Langfuse’s UI by clicking the “Configure Tracing” button on the dashboard page. For use with LangChain, open the LangChain tab and copy the code snippet.

Deployment Steps:

Navigate to the cloned directory and build the project:

mbt build

Deploy the generated mtar file to SAP BTP, Cloud Foundry Runtime. After logging in with cf login, specify the target organization and space:

cf login
cf deploy mta_archives/langfuse-test-app_1.0.0.mtar

Once deployment is complete, access the application via the internet. Retrieve the application URL using the following command:

cf apps

For this example, the application is published as “langfuse-langchain-srv,” and the URL will be displayed alongside it. Let’s run the LangChain application.

3. Running Inference Chains with LangChain and Checking Traces on Langfuse

Using Postman installed on your local PC, send requests to this Python application. When executed, the AI agent will perform inference on SAP BTP, Cloud Foundry Runtime, and return results.

Translation:

Japanese	English
3の3乗根は？	What is the cube root of 3?
3の3乗根は約1.442です。計算機を使用して求めました。	The cube root of 3 is approximately 1.442. It was calculated using a calculator.

Since this example includes a trace handler using Langfuse, check the traces via Langfuse’s UI by navigating to “Tracing” => “Traces.” You will see a list of traces as shown below:

Inspect the details. The right-hand pane displays the sequence of actions performed by the AI agent implemented in LangChain. Selecting the topmost element reveals the input and output in the left-hand pane.

Following the right-hand pane, you can confirm that the “calculator” tool was used. This tool, passed to the AI agent in the LangChain source code, was appropriately selected for the task “What is the cube root of 3?” The AI agent deemed this action suitable and used it.

The statistics are also reflected on the dashboard:

While this scenario only used the calculator tool, real-world use cases can become more complex. The products introduced in this blog will prove even more effective in such scenarios.

Conclusion

This blog introduced the steps to develop, run, and monitor LLM applications using SAP BTP. From configuring Generative AI Hub via SAP AI Launchpad to deploying LangChain applications with SAP Build Code and monitoring them with Langfuse, we hope this guide demonstrated the potential of SAP BTP.

Applications integrated with generative AI bring new value to traditional business processes, enabling more efficient and flexible system operations. Additionally, utilizing monitoring tools like Langfuse allows for detailed analysis of AI behavior and inference results, improving reliability and optimizing operations.

As generative AI and LLM technologies continue to evolve, their applications across various use cases will grow. Through application development based on SAP BTP, we hope you accelerate your organization’s digital transformation. May this blog serve as the first step toward achieving that goal.

We look forward to seeing your continued efforts in leveraging SAP BTP and generative AI-related technologies for new challenges.

Deploying Langfuse on SAP BTP, Kyma Runtime

2025-01-17T03:16:13.022000+01:00

This is the translated version of original Japanese blog:
LLM監視ツールLangfuseをSAP BTP, Kyma runtimeにデプロイしてみた

Introduction

This time, we will introduce a step-by-step guide to deploying Langfuse, an open-source LLM application monitoring tool, on the Kubernetes-compatible runtime SAP BTP, Kyma runtime. Monitoring is an unavoidable issue when utilizing generative AI, and we hope this blog will be helpful to you.

Overview

As generative AI becomes deeply integrated into our daily lives and work, many companies and individuals are advancing their use of applications such as chatbots and automation tools. These are being utilized across various fields, from automating customer support and enhancing data analysis to planning new products and services.

One particularly noteworthy application involves using AI agents like LangChain. LangChain is a powerful framework adopted by many developers to generate advanced responses by combining multiple tools and external data sources. However, operating these AI agents comes with new challenges.

Common Challenges

Some common issues include:

Managing prompt quality and model performance: Designing appropriate prompts and selecting models are essential to improving response accuracy, but accurately evaluating their effectiveness can be difficult.
Tracing external APIs and tools: Understanding the behavior of external services used by AI agents and quickly identifying causes of issues when they occur are crucial.
Monitoring errors and response times: Real-time monitoring of performance metrics (e.g., response times, error rates) in the operating environment is essential.
Leveraging user feedback: Continuously understanding how well generative AI responses meet user expectations and incorporating improvements is necessary.

To address these challenges, developers strongly feel the need for tools that allow detailed monitoring and evaluation of AI agents' operations and facilitate rapid improvements. Against this backdrop, specialized monitoring platforms for LLM applications, such as Langfuse, are gaining attention.

What is Langfuse?

Langfuse is an open-source LLMOps platform that supports the development, monitoring, evaluation, and debugging of applications leveraging large language models (LLMs). It supports the entire lifecycle of generative AI products, from development and testing to large-scale monitoring and debugging.

Key Features and Benefits

Open-source availability: Langfuse is provided as open-source, allowing for self-hosting. This makes customization and long-term use easier.
Integration with various frameworks: Langfuse seamlessly integrates with major LLM frameworks like LangChain and LlamaIndex, making it easy to incorporate into existing workflows.
Detailed traceability: It captures the complete context of products, including external API calls, tools, and prompts, enabling detailed tracking of application behavior.
Real-time metrics monitoring: Real-time monitoring of key performance indicators such as response times, error rates, and throughput allows for prompt responses.
Collecting user feedback: Feedback from users can be gathered to improve application performance and user experience.
Evaluation and testing features: By setting up evaluation workflows using LLMs or human annotations, developers can compare the performance of different models and prompts. A/B testing can also be used to determine the best solution.
Flexible deployment: Langfuse supports deployment in various environments, such as on-premises or cloud, allowing for flexibility based on project scale.

These features make Langfuse a powerful tool for LLM application developers, enabling them to improve application quality and operate efficiently.

Reference

https://langfuse.com/jp

Deployment Steps

Let’s now introduce the procedure for hosting Langfuse on SAP BTP.

Prerequisites

An account with access to SAP BTP, Kyma runtime.
kubectl CLI, helm CLI, and kubelogin installed in the local development environment. If not installed, refer to the following links:

Step 1: Setting up Kyma Environment in SAP BTP

First, enable SAP BTP, Kyma runtime on SAP BTP, and grant user permissions. Refer to the following tutorial for details:

https://developers.sap.com/tutorials/cp-kyma-getting-started.html

Step 2: Configuring kubectl and Verifying Connection

Refer to the URL below for connecting kubectl to SAP Kyma runtime:

https://help.sap.com/docs/btp/sap-business-technology-platform/access-kyma-instance-using-kubectl

Retrieve the kubeconfig.yaml File

Download the kubeconfig file from the SAP BTP Cockpit by clicking the Kubeconfig URL link, which starts downloading a configuration file named kubeconfig.yaml. Use this file to connect kubectl to SAP BTP, Kyma runtime.

Translation of texts in picture:

Japanese	English
クリックすると、kubeconfig.yamlがダウンロードされる	When you click here, kubecounfig.yaml get downloaded

Verify Connection

Run the following commands in the terminal to load the cluster settings for SAP BTP, Kyma runtime and ensure proper configuration. Replace /path/to/kubeconfig.yaml with your environment’s path. Note that the commands below are for macOS. For Windows, refer to the appropriate commands in the linked documentation.

export KUBECONFIG=/path/to/kubeconfig.yaml
kubectl config get-contexts

Translation of texts in picture:

Japanese	English
kubeconfig.yamlを配置したパスを、KUBECONFIGという環境変数にセットする	Set the path where kubeconfig.yaml is located to environment variable "KUBECONFIG".
kubectl config get-contexts により、正しくkubeconfig.yamlが読み込まれていることを確認する	Make sure kubeconfig.yaml is properly read by the system with the command "kubectl config get-contexts".

If successful, proceed to deploy Langfuse.

Step 3: Deploying Langfuse to SAP BTP, Kyma Runtime

Refer to the official guide below to deploy langfuse-k8s:

https://langfuse.com/self-hosting/kubernetes-helm

Clone the Source Code

git clone https://github.com/langfuse/langfuse-k8s.git 
cd langfuse-k8s/charts/langfuse

Create a Namespace

Create a namespace for testing on SAP BTP, Kyma runtime:

kubectl create namespace langfuse-v3-preview

Translation of texts in picture:

Japanese	English
ネームスペースを作成する	Create namespace.

This procedure will create the namespace on SAP BTP, Kyma Runtime, where the Langfuse is going to be deployed.

Deploy Using Helm

Using Helm, a Kubernetes package manager, update dependencies and deploy to the namespace created:

helm dependency update
helm install langfuse . -n langfuse-v3-preview

Step 4: Accessing the Langfuse UI

Check Deployment Status

Run the following command to check the deployment status:

kubectl get services -n langfuse-v3-preview

According to this, the connection type of the langfuse-web application is set to ClusterIP, and no External-IP has been assigned, which makes it inaccessible from the outside. Therefore, we will execute the following command.

kubectl edit service langfuse-web -n langfuse-v3-preview

This command allows you to make changes to the configuration of langfuse-web. Let’s rewrite the settings as shown below. With this configuration, an External IP will be assigned after a short wait.

Update Service Type

Modify the settings as follows to allow for an External IP to be assigned:

spec:
  type: LoadBalancer   ## Previously set as Cluster IP

Confirm Access

Confirm access to the Langfuse UI by executing:

kubectl get services -n langfuse-v3-preview

Access using the following URL:

http://<External-IP>:<Port>

Sign Up and Log In

The above is the top screen when accessing the application. First, create an account by clicking on "Sign Up."

Even if redirected to http://localhost:3000 (a browser error page may appear) after account creation, this can be ignored because default login callback is set to redirect users there. The user account should be created successfully. Reaccess the http://<External IP>:<Port> URL and log in with the created account.

Once you do so, you will successfully log in as shown. After that, you can create an Organization and a Project with any name, which will eventually lead you to the dashboard screen.

Conclusion

In this blog, we introduced the procedure for deploying the OSS Langfuse on SAP BTP, Kyma runtime. By leveraging Langfuse’s support for Kubernetes deployment, we demonstrated how to build the environment with relative ease on the compatible SAP BTP, Kyma runtime.

In the next blog, we plan to explain how to integrate Langfuse with LangChain for debugging and monitoring generative AI applications. Stay tuned!

Next Blog:

Developing, Running, and Monitoring LangChain Applications on SAP BTP

Aggregators: Streamlining Message Handling in Integration Flows

2025-01-17T15:36:24.244000+01:00

In integration flows, aggregators play a crucial role in collecting messages until a specific condition is met. Here's a breakdown of their functionality:

Purpose: Aggregators gather messages across multiple executions of an integration flow, not just one.
Process: If the flow receives three messages, the same aggregator instance collects all of them.
Storage: Messages are stored in a data store (supports XML, plain text messages).

Configuration:

General Tab: Assign a descriptive name to your aggregator for easy identification.
Correlation Tab: Define the field used to group related messages. For instance, messages with the same "CustomerID" will be grouped together.

Example: Aggregating employee, personal, and student records based on their IDs. Messages with the same ID (e.g., "Emp123," "Per456," "Stu789") will be combined, while those with different IDs will be collected separately within the same aggregator.

Aggregation Strategy:

Incoming Format: Always set to XML, as aggregators currently support this format only.
Aggregation Algorithm: Choose between two options:

Combine: Concatenates collected messages in the order they are received.
Combine in Sequence: Orders/sorts collected messages based on a field specified in the "Message Sequence Expression" parameter.

1.Message Sequence Expression (XPath): (Enabled only for "Combine in Sequence")

Define the XPath of the field used for sorting messages within the aggregator.

Last Message Condition (XPath):

Specify a field and its corresponding value to mark the end of message collection.
Example: /PersonalDetails/PersonalDetail/PersonID = '1' - When an ID of "1" is received, the aggregator stops processing and proceeds to the next step.

Completion Timeout (in minutes):

Set the maximum time (in minutes) the aggregator waits for messages before processing the next steps in the pipeline.

Data Store Name: (Usually auto-populated) This field displays the data store used for storing collected messages.
By understanding aggregators, you can optimize message handling within your integration flows, ensuring efficient processing and data management.

Subscribing SAP Commerce business events in Kyma by executing serverless Functions

2025-01-22T13:29:45.440000+01:00

Introduction

A subject of this post is to show how to send business events like:

customer created
password forgotten
order created
product added to cart

from SAP Commerce to BTP, Kyma Runtime and subscribe to them by executing a serverless Function.

Prerequisites

SAP Commerce instance installed
SAP BTP global account & subaccount created and Trial Kyma environment enabled

Integrate SAP Commerce with BTP, Kyma Runtime

1. Add following Kyma-related extensions in localextensions.xml file:

<extension name='kymaintegrationbackoffice' />
<extension name='kymaintegrationservices' />

2. Build & start a platform.

3. When SAP Commerce is up, go to: System->Update in HAC, select "Update Running System", then select extensions:

kymaintegrationbackoffice
kymaintegrationservices

and execute the update.

4. In Backoffice, go to: System->API->Destination Targets, select "Default_Template" and execute action: "Register Destination Target"

5. Provide following fields in the registration form:

Token URL: [will be available after registering SAP Commerce instance in BTP cockpit]
New destination's id: BTP_KYMA_RUNTIME

Register SAP Commerce in BTP cockpit and expose it to BTP, Kyma Runtime

1. Enter the BTP global account and go to: System Landscape->Systems and select: "Add System". Provide following fields in the form:

System Type: select "SAP Commerce Cloud"
System Name: local SAP Commerce instance

2. After adding the system, get the required token URL:

3. Paste the token to previous form in SAP Commerce Backoffice and finish the registration:

4. See newly created "BTP_KYMA_RUNTIME" destination target with configuration of API to be exposed and events to be emitted:

5. Expose registered SAP Commerce system to BTP, Kyma Runtime. In BTP Cockpit (global account) go to: System Landscape->Formations and select: "Create Formation". In the form provide:

Formation Name: SAP Commerce To Kyma
Formation Type: select "Side-by-Side Extensibility with Kyma"
Subaccount: select [your_subaccount]

6. In the next step, select registered system: local SAP Commerce instance

7. SAP Commerce system is exposed to Kyma now:

Configure Kyma and check if SAP Commerce is connected in Kyma dashboard

1. Enter BTP cockpit subaccount, select Overview from menu and go to Kyma Environment section. You should already have the Kyma environment enabled (if not, go to the link given in "Prerequisites" paragraph). Enter the Kyma dashboard:

2. In "Cluster Details" (main view after selecting the cluster) go to: Configuration->Modules and click "Add".

3. Select following modules and add them:

application-connector - to connect with registered SAP Commerce system in BTP
eventing - to handle events emmited by SAP Commerce
nats - to use NATS server as a backend for eventing
serverless - to use serverless Kyma Functions

4. To properly enable the eventing functionality, edit eventing module and set backend type to NATS.

5. Enter "Cluster Details" view and go to Integration->Application and check if you see local SAP Commerce instance connected:

If not, please check if "BTP_KYMA_RUNTIME" destination target has already "Registered" status in Backoffice.

Create serverless Function and Subscription to SAP Commerce event

1. Create a serverless Function that logs the "customer created" event emitted by SAP Commerce after customer registration. Thus, go to Namespaces and select "default". Then go to Workloads->Functions and create the function.

2. Provide following fields in the form:

Name - customer-created
Source Type: Inline
Language: JavaScript
Runtime: Node.js 20
Source:

    module.exports = {
       main: async function (event, context) {
       console.log("Customer created:", event.data);
       return;
       }
   }

3. After creating the function wait until its state is "Running":

4. In the Backoffice, in previously created BTP_KYMA_RUNTIME Destination Target, in Destinations and Event Configurations section there are pre-defined events' ids available, i.a.:

- customer.created.v1 - emitted after customer registration

- order.created.v1 - emitted after placing order

- password.forgotten.v1 - emitted after password forgotten action triggered

- product.addtocart.v1 - emitted after adding product to the cart

We will use customer.created.v1 event in our example.

5. To subscribe the event, create a Subscription resource. In the Kyma dashboard ("default" namespace view) go to Configuration->Subscriptions and create the Subscription. Provide following fields in the form:

Name: customer-created-sub
Types: customer.created.v1
Service: select "customer-created" (name of previously created Function)
Sink: [automatically populated after selecting the service]
Type matching: Standard
Source: select mp-local-sap-commerce-instance (previously connected SAP Commerce instance)

6. All configuration steps are finished when a Subscription has status "Ready".

Register new customer on the storefront to test "customer created" event

1. Go to storefront and register new user:

2. You should see similar logs about emitting the event to Kyma in the SAP Commerce:

INFO [Thread-14] [KymaEventEmitStrategy] Event (EventId : df428555-e4d5-4436-aa21-f9a9994a8854) sending response : <200,{"event-id":"df428555-e4d5-4436-aa21-f9a9994a8854","status":"","reason":""},[content-length:"76", content-type:"application/json", date:"Tue, 21 Jan 2025 15:06:35 GMT", server:"istio-envoy", x-envoy-upstream-service-time:"36"]>

3. In Kyma dashboard select "customer-created" Function previously created, go to section Replicas of the Function and select the replica, then go to Containers section and click "View Logs".

You can find following logs with the event payload produced by the function after "customer created" event.

Customer created: {
   customerId: '5c2ef4c2-e6a8-4094-bb53-8f08c7dcefe3',
   customerUid: '************@gmail.com',
   storeUid: 'electronics'
}

Conclusion

We used BTP, Kyma Runtime to subscribe business events emitted from SAP Commerce. Created serverless Function that was a subscriber just logged the event payload. Nevertheless, we can use the Function to execute any logic written in node.js or Python, like complex calculations, storing data in external database, calling the API exposed by SAP Commerce or integrating with 3rd party services. Function body itself can be defined in Inline mode (source code added during Function creation) or fetched from indicated Git repository.

SAP BTP, Kyma runtime: APIRule migration - timelines

2025-01-24T12:33:06.451000+01:00

Hello everyone! A couple of months ago, I published two blog posts:

The blog posts explain migration details focusing on API. Now, I would like to focus on timelines and important milestones.

Timeline Overview

Let's quickly recap the events surrounding the migration to the stable v2 version of APIRule. API Gateway 2.7.0, promoted to the regular channel on October 28, 2024, introduced a fully functional APIRule v2alpha1. At the same time, APIRule v1beta1 became deprecated and scheduled for deletion. These two events opened a testing window, allowing you to start testing the API and the migration procedure, report any bugs, and provide feedback. By the end of March 2025, we plan to extend the API Gateway module with stable APIRule v2, and APIRule v2alpha1 will become deprecated. This date also opens a migration window, letting you change your configurations to version v2. In mid-May 2025, APIRule v1beta1 will be deleted, and finally, in mid-June 2025, APIRule v2alpha1 will be deleted. Then, the API Gateway module will only serve stable APIRule v2.

Milestones

October 28, 2024 - Introduced APIRule v2alpha1 (current state of the art)

The API Gateway module introduced a fully functional APIRule v2alpha1 that, in the future, will replace version v1beta1. The v2alpha1 API and its functionalities are considered stable and are expected to be promoted to v2 with minimal to no changes. APIRule v2alpha1 was introduced to give you the possibility to get familiar with the new API, test it out, and share your feedback. The API Gateway module fully supports migration to version v2alpha1, ensuring zero downtime during the process. At this point, no immediate action is required. Do not underestimate this change, though, and start planning for the next milestone. We highly encourage you to test the migration process to estimate the required effort accurately and thoroughly understand the changes. Can you already migrate? Yes! We are not discouraging this approach as we fully support APIRule v2alpha1 and provide assistance in case of any issues. You must remember, though, that APIRule v2alpha1 is not the final version and will be removed in June 2025.

APIRule v2alpha1 is not the final version and will be removed in June 2025. Therefore, you must migrate all APIRules to version v2 by that date.

March 31, 2025 - APIRule v2 stable version

That will be the day! APIRule v2 will come to life. On March 31, 2025, APIRule v2 will become the official stable version and the main serving version. This means that when you run the command 'kubectl get apirules -A -o yaml`, APIRule v2 will be displayed by default. To request version v1beta1 or v2alpha2, you must explicitly specify these versions in the commands. For example, you can use `kubectl get apirules.v2alpha2.gateway.kyma-project.io my-rule -o yaml` or `kubectl get apirules.v1beta1.gateway.kyma-project.io my-rule -o yaml`. This is especially important if you rely on CI/CD tools or use the command-line interface to list deployed resources.

APIRule v2alpha1 and v2 are not fully compatible with v1beta1, so it might happen that v1beta1 rules, such as OAuth2 handlers, won't be fully displayed as v2alpha1 or v2.

You might be wondering: What will happen to my old APIRules? The answer is nothing will change immediately. They will still be there and continue functioning until May 12, 2025. To view them, you must explicitly request the v1beta1 version.

The introduction of v2 will start the migration window. During this period, migrating all APIRules from v1beta1 and v2alpha1 to the newest version, v2, is mandatory. If you are migrating from v1beta1, please refer to my previous blog posts for guidance. If you are migrating from v2alpha1, it should be as simple as changing the version.

May 12, 2025 - APIRule v1beta1 end of life

At this point, you must have all your APIRules migrated and saved in version v2. APIGateway Controller will stop serving APIRule v1beta1, the version will be removed from CustomResourceDefinition (CRD), and the API Gateway module will delete all unmigrated custom resources (CRs). However, your workloads exposed with APIRule v1beta1 will not be taken down. We will ensure everything keeps running.

Resources created by APIGateway Controller will not be deleted but will become unmanaged. This means you will be responsible for configuring and maintaining them according to your needs. Additionally, Ory Oathkeeper will no longer be managed by the API Gateway module, and if you have APIRules based on it, you will need to take over its management. The migration procedure from unmanaged resources to APIRule v2 will not be supported in an automated way. Therefore, it is very important that you complete the migration to v2 before May 12, 2025, from both versions v1beta1 and v2alpha1.

June 16, 2025 - APIRule v2alpha1 end of life

Finally, v2alpha1 will be removed from the CRD, and all existing CRs will be stored as the v2 version. From now on, the only version of APIRule will be v2.

Summary

In this blog post, I outlined important events and their corresponding necessary actions. I hope this helps you understand what to expect and plan accordingly. If you have any concerns or feedback, leave us a question.

Part 2: Revenue Accounting and Reporting (RAR) with GenAI and RAG

2025-01-28T03:39:06.463000+01:00

Introduction

The integration of Large Language Models (LLMs) with Retrieval-Augmented Generation (RAG) addresses critical automation challenges in revenue recognition processes. Traditional SAP Revenue Accounting and Reporting (RAR) systems, while robust, often require significant manual intervention for complex contract analysis and revenue timing decisions. By incorporating LLMs with RAG's precise information retrieval capabilities, organizations can now automate previously manual tasks while significantly reducing errors. The system achieves this by combining the pattern recognition capabilities of LLMs with RAG's ability to ground responses in verified revenue recognition rules and standards. This fusion of technologies provides particular value in complex scenarios such as multi-element arrangements, variable consideration contracts, and timing-sensitive revenue recognition, where traditional rule-based automation often falls short.

Enhanced Architecture Overview

The SAP Revenue Accounting and Reporting architecture can be enhanced with a sophisticated GenAI/RAG processing layer that seamlessly integrates with existing operational systems and core RAR components. This new layer sits between the operational systems (Sales and Distribution, Contract Accounts Receivable and Payable, and non-SAP systems) and the SAP S/4HANA Revenue Accounting and Reporting engine. Through standardized IC (Integration Component) interfaces, operational data flows into the GenAI/RAG layer where documents undergo intelligent processing via the document grounding component. The system leverages SAP HANA's vector store capabilities for efficient embedding storage and retrieval, while the RAG retrieval engine works in conjunction with the LLM integration layer to enhance the traditional RAR processes. This enhanced architecture maintains the core RAR functionality - including RAI processing, contract management, and BRFplus business rules - while augmenting each step of the five-step revenue recognition model with AI capabilities. The result is a more intelligent system that can handle complex revenue arrangements through automated contract analysis, performance obligation detection, and revenue recognition timing, all while maintaining compliance with IFRS 15 and ASC 606 standards.

Integrated System Components

The RAG architecture comprises four essential subsystems working in concert. The document grounding layer handles preprocessing through meta-tagging and intelligent chunking before generating embeddings for vector storage in SAP HANA. A specialized retrieval pipeline manages vector search operations and implements the re-ranking logic for contextual relevance. The feedback subsystem employs machine learning algorithms for continuous weight adjustment based on user interactions, while the generative layer leverages LLMs to synthesize contextually appropriate responses from retrieved information. This modular architecture ensures both system flexibility and maintainable complexity while supporting the specific demands of revenue recognition workflows.

Advanced Retrieval Mechanisms

The retrieval architecture implements two sophisticated mechanisms for optimal document processing. The first mechanism (1-4 in fig below) employs a multi-stage search process starting with global vector similarity calculations across all document chunks, followed by local context refinement focused on top-ranked results. A weighted query refinement phase then incorporates high-ranking chunk terms to create context-aware queries, culminating in a final retrieval pass that aggregates the most relevant information.

The second mechanism (5 in fig above) utilizes feedback-driven weight adjustment, where initial embeddings and similarity scores form the foundation for an adaptive ML model. This model continuously evolves through user feedback integration, employing scaling factors to adjust chunk weights dynamically. The system stores these refined weights persistently, enabling progressive improvement in retrieval accuracy across multiple queries while maintaining complete audit trails for revenue recognition compliance.

Vector Database Integration

SAP HANA's vector database capabilities form the backbone of the retrieval system, enabling efficient storage and querying of high-dimensional embeddings. The database architecture supports real-time indexing of new documents while maintaining rapid query performance through optimized index structures. Automated synchronization ensures consistency between the vector store and traditional relational data.

Performance Optimization

Advanced caching mechanisms and query optimization techniques ensure rapid response times even with large document volumes. The system implements intelligent batching for vector operations, maximizing GPU utilization during embedding generation. Feedback-driven weight adjustments continuously refine the model's performance, with cosine similarity rates improving from 88.15% to over 95% through iterative optimization.

Future Outlook

As retrieval technologies evolve, the integration with revenue management systems will become increasingly sophisticated. Emerging developments in sparse attention mechanisms and efficient indexing strategies promise to further enhance retrieval accuracy while reducing computational overhead. These advancements will enable more nuanced understanding of complex revenue arrangements while maintaining strict compliance with evolving standards.

read part 1 here: Part 1: SAP Revenue Accounting and Reporting (RAR)... - SAP Community

#SAP #RevenueRecognition #SAPRAR #AIinFinance #GenAI #RAG #LargeLanguageModels #MachineLearning #SAPBTP #ComplianceAutomation #SAPHANA #RevenueManagement #AdvancedRetrieval #FinancialInnovation #DigitalTransformation #ContractAnalysis #MultiElementArrangements #BusinessIntelligence #IFRS15 #ASC606 #VectorDatabase #AutomationInnovation

Part 1: SAP Revenue Accounting and Reporting (RAR): Foundation for Modern Revenue Management

2025-01-28T04:19:37.812000+01:00

In today's complex business environment, managing revenue recognition has become increasingly challenging, especially with the introduction of standards like IFRS 15 and ASC 606. Organizations across industries are grappling with intricate revenue streams, diverse contract types, and stringent compliance requirements. SAP Revenue Accounting and Reporting (RAR) emerges as a comprehensive solution to these challenges, providing automated and standardized revenue recognition processes that ensure compliance while improving efficiency.

The Evolution of Revenue Recognition

Revenue recognition has transformed significantly from simple invoice-based accounting to a sophisticated process that considers multiple performance obligations, complex pricing structures, and varying recognition patterns. SAP RAR addresses these modern requirements by providing a robust foundation built on three core pillars: contract management, revenue recognition engine, and seamless integration capabilities.

Understanding the Core Process

The journey of revenue recognition in SAP RAR represents a sophisticated orchestration of multiple components working together to ensure accurate and compliant revenue processing. Let's explore this through a comprehensive real-world scenario that demonstrates the system's capabilities.

Consider TechServe Solutions, a technology company that offers both hardware and subscription-based software services. They've recently closed a deal that includes:

Enterprise Server Hardware: $100,000
Software License: $50,000/year for 3 years
Implementation Services: $30,000
Maintenance Support: $20,000/year for 3 years

Contract Inception and RAI Creation

When the sales order is created, SAP RAR begins its sophisticated processing journey. The system automatically generates Revenue Accounting Items (RAIs) for each component of the deal. These RAIs serve as the foundation for all subsequent revenue recognition processes. During this phase, the system captures critical information including contract terms, pricing details, and delivery schedules.

Performance Obligation Breakdown

SAP RAR's intelligent contract analysis capabilities automatically identify and separate distinct performance obligations within the contract.

Price Allocation and SSP Determination

One of the most complex aspects of revenue recognition is the fair allocation of transaction prices. SAP RAR handles this through its sophisticated Standalone Selling Price (SSP) engine. For TechServe's contract:

The total contract value of $280,000 ($100,000 + $150,000 + $30,000 + $60,000) is allocated based on relative SSP values. SAP RAR automatically calculates these allocations while considering:

Market-based pricing data
Historical transaction analysis
Contract-specific adjustments
Volume discounts and bundling impacts

Revenue Recognition Scheduling

Based on the performance obligations and price allocations, SAP RAR creates a detailed revenue recognition schedule. This automated process considers:

Time-Based Recognition The software license and maintenance support revenues are scheduled over 36 months, with automatic recognition triggers at each period end.
Event-Based Recognition Hardware revenue recognition is linked to delivery completion, while implementation revenue follows project milestone achievements.
Multi-Element Considerations The system manages interdependencies between different performance obligations, ensuring proper revenue timing and allocation.

Financial Integration and Posting

The final stage involves the seamless integration with financial systems through a three-step process:

This robust process ensures that every revenue dollar is properly recognized, tracked, and reported according to the relevant accounting standards while maintaining complete audit trails and documentation.

Technical Architecture and Integration

At the heart of SAP RAR lies a sophisticated technical architecture that ensures seamless processing of revenue recognition requirements. The system integrates with various source systems through the Adapter Reuse Layer (ARL), which standardizes incoming data into Revenue Accounting Items (RAIs). These items then flow through the BRFplus rules engine, where business logic determines their treatment.

The Role of Artificial Intelligence

The integration of artificial intelligence in SAP RAR represents a significant leap forward in revenue recognition capabilities. Modern implementations leverage machine learning algorithms to analyze contract terms, predict revenue patterns, and identify potential recognition issues before they occur. Natural language processing capabilities help in automatically extracting key terms from contracts, while predictive analytics provide insights into future revenue trends.

Implementation Impact

Organizations implementing SAP RAR experience transformative benefits across their revenue operations. Manual processing time typically reduces by up to 80%, while recognition accuracy improves to near-perfect levels. The system's ability to handle complex revenue scenarios while maintaining compliance with IFRS 15 and ASC 606 provides organizations with confidence in their financial reporting.

Future Outlook

The future of revenue recognition in SAP RAR is closely tied to the advancement of intelligent technologies. As artificial intelligence and machine learning capabilities continue to evolve, we can expect even more sophisticated features in contract analysis, revenue prediction, and compliance automation. The system's ability to learn from historical patterns and adapt to new business scenarios will become increasingly valuable for organizations managing complex revenue streams.

Conclusion

SAP Revenue Accounting and Reporting represents more than just a technical solution; it embodies a modern approach to revenue management that combines automation, intelligence, and compliance. As businesses continue to evolve with new revenue models and complex contracts, SAP RAR's robust foundation and forward-looking capabilities ensure that organizations can confidently manage their revenue recognition processes both today and in the future.

The next chapter discusses the Business AI component built on SAP BTP services to make RAR fully autonomous. Don’t forget to check it out! 😎
Part 2: Revenue Accounting and Reporting (RAR) wit... - SAP Community

#SAP #RevenueRecognition #SAPRAR #IFRS15 #ASC606 #FinanceAutomation #RevenueManagement #ArtificialIntelligence #MachineLearning #Compliance #AccountingStandards #TechInnovation #BusinessEfficiency #DigitalTransformation #FinancialReporting #Automation #DataDriven #FutureOfFinance #ContractManagement #PerformanceObligations #AIinFinance #SAPSolutions #FinancialCompliance #RevenueAutomation #TechServeSolutions

Cline for SAP AI Core: Bringing Cline's Power to the SAP Ecosystem

2025-02-03T23:31:50.031000+01:00

Introduction

In the ever-evolving landscape of AI-assisted development, integrating advanced AI capabilities directly into your workflow can significantly enhance productivity and innovation. I'm excited to introduce Cline for SAP AI Core, a new Visual Studio Code (VS Code) extension that brings the power of SAP AI Core into the agentic coding experience of Cline. This extension enables SAP developers to seamlessly interact with state-of-the-art AI models through their SAP Business Technology Platform (BTP) accounts, unlocking new levels of efficiency in coding and business application development.

Why Cline for SAP AI Core?

The original Cline extension has been transformative for developers, offering an AI partner that plans before coding, ensuring thoughtful and efficient code generation. However, it doesn't integrate external AI providers outside its direct control. Recognizing the need for SAP AI Core support within the SAP development ecosystem, I created this dedicated extension to bridge the gap.

With Cline for SAP AI Core, developers working with SAP BTP can now access advanced AI models natively within their VS Code environment, ensuring a seamless and efficient workflow tailored for enterprise use.

Key Features

Seamless Integration with SAP AI Core: Directly connect to AI Core services within VS Code, allowing for a unified development environment.
Access to Advanced AI Models: Utilize models such as Claude 3.5 Sonnet, Claude 3 Sonnet, Claude 3 Haiku, Claude 3 Opus, GPT-4o, GPT-4o Mini, and GPT-4, empowering developers with capabilities like code completion, debugging assistance, and natural language understanding.
Tailored for SAP BTP Users: Leverage your SAP AI Core infrastructure within Cline for AI-driven development and automation, enhancing productivity and innovation.

How to Get Started

Installation:

Open VS Code.
Navigate to the Extensions tab (Windows: Ctrl+Shift+X- Mac: Cmd+Shift+X).
Search for "Cline for SAP AI Core".
Click "Install" and restart VS Code if needed.

Configuration:

Open Settings in Cline for SAP AI Core.
Select SAP AI Core as your API provider.
Enter the required authentication details:
- AI Core Client ID
- AI Core Client Secret
- AI Core Base URL (e.g., https://api.ai.internalprod.eu-central-1.aws.ml.hana.ondemand.com/v2)
- AI Core Auth URL (e.g., https://aicoreexample.authentication.sap.hana.ondemand.com/oauth/token)
- AI Core Resource Group
Select your preferred AI Model from the list of available models.

Unlocking New Possibilities

By integrating Cline with SAP AI Core, developers can:

Enhance Code Quality: Leverage AI to generate well-structured code, reducing errors and improving maintainability.
Automate Repetitive Tasks: Utilize AI to handle routine coding tasks, allowing developers to focus on more complex aspects of development.
Accelerate Development Cycles: With AI assistance, rapidly prototype and develop applications, shortening time-to-market.

For a comprehensive tutorial on how Cline can transform your coding workflow, you might find the following video helpful:

Cline + VS Code Changed How I Code Forever

Additionally, to learn more about how to use Cline in your SAP development workflow, check out this resource:

Unlocking the Power of AI-Assisted ABAP Coding with VS Code and Cline

Join the Future of AI-Assisted Development

Cline for SAP AI Core opens up new possibilities for AI-driven coding and automation within the SAP ecosystem. By seamlessly integrating SAP AI Core into VS Code, developers are empowered with cutting-edge AI models to enhance productivity and innovation.

Give it a try today and experience the future of AI-assisted SAP development!

I would love to hear your feedback and experiences! Let’s discuss in the comments below. 🚀

SAP’s Shift to Open Standards – A Strategic Move or Happy Accident?

2025-02-04T18:08:09.112000+01:00

Introduction

11 years ago, when I began my career as an SAP Integration consultant, often times when I google for work related research, I’d see results from SAP SCN and SAP help pages only. Today, what has changed is that, I see results on the same question/theme, being addressed by blogs/sites that have nothing to do with the SAP tool/platform on which, I am working currently. But the answer/content that I read there somehow turns out to be highly relevant to the issue/topic I am researching currently, on the SAP tool/platform that I am working with.

Upon reflection, as a broader trend across various SAP products and platforms, there seem to be a strong adoption of industry standard technologies, protocols & frameworks, which in many cases are open-source as well. While SAP’s proprietary standards have influenced others in the ERP industry for a long time, this remarkable departure and SAP gravitating towards standards in many aspects, is something that prompted me to connect the dots and to share with the community. In this post, I’d like to list a few of the areas, where I have noticed this trend:

1) Integrations:

REST, ODATA APIs encouraged instead of bapi/rfc, proxy, Idoc
Edge Integration Cell is based on Kubernetes containers, which is industry standard to package & distribute workloads, a necessary evolution from the SOA style platform that SAP PI/PO used to be.
Well documented APIs in Business Accelerator Hub than in PI/PO days
SAP Cloud Integration being based on Apache camel open-source framework. By extension, this facilitates direct support for camel expression language as well as various enterprise integration patterns – like splitter, router, gather, join in the Iflow design.
Integration advisor’s crowdsourced ML based mapping recommendation, supports conversion of canonical data model to standard EDI formats like ANSI X12, EDIFACT and vice-versa.

2) Platform choices:

Choice of hyperscaler platforms – Azure, AWS, etc. allowed to be exercised by the customer. This makes SAP an ERP Software selling company.
Runtime environments such as Cloud Foundry & Kyma are open-source. (Further reading)

3) Application Development:

Support for Java, JavaScript (node js), in addition to ABAP as tech stacks. This is a big step in utilizing coding skills available in the market.
BAS and Build Code being Git friendly.

4) Broader BTP services:

Application logging service in BTP uses Kibana (an open-source project)
KServe, an open-source Model Inference Platform on Kubernetes, being used behind the scenes by AI Core.
Redis & Postgres hyperscaler offering in addition to the proprietary HANA DB.
Evolution of UX/UI from proprietary SAP GUI to Fiori / UI5 based front-end. OpenUI5 is a JavaScript UI Framework released by SAP under the Apache 2.0 license.

Conclusion

SAP’s growing adoption of open-source technologies and industry standards doesn’t just seem to be accidental, but based on a conscious vision, as reflected in the SAP Open-source Manifesto. This shift benefits both customers and developers by fostering interoperability, flexibility, and innovation in the SAP ecosystem.

Disclaimer: My observations are based on my exposure to SAP BTP & ERP only and this trend might not apply or apply differently across SAP’s other product lines.

SAP Job Scheduling Service: Retry a Job Execution Using ANS

2025-02-10T10:14:24.731000+01:00

Does the Job Scheduling service have a retry mechanism of job executions? No ☹️.

But you can combine it with the power of ANS (Alert Notification service) and set up a retry behavior that satisfies your needs. 🚀

But how does it work?

Job Scheduling service calls your application REST endpoint. 🌐
Your application's endpoint fails for some reason. ❌
You have configured your job to trigger alert notifications on error, and Job Scheduling service sends an event to ANS. 📡
In ANS, the exact event and scheduleId is matched, and ANS sends a webhook to create a new one-time schedule (for the same job). 🎯
Job Scheduling service executes again (retries) the application REST endpoint (triggered by the new schedule). 🔄
The application endpoint now returns HTTP 200 Success. ✅

As you can see, this approach is quite flexible as it allows you to create custom conditions and actions. This can allow you to even trigger different jobs and chain them if needed.

Diagram showing the communication between Job Scheduling service, cloud app and Alert Notification service

Let's do it in practice to see how it works!

Prerequisites:

Job Scheduling service instance bound to a cloud application (we will retry its endpoint).
Instance of the Alert Notification Service (to receive the event).

Step 1

First, we create a job with ANS enabled and schedule it to call our REST endpoint.

In our case, the endpoint will always return an error message that prompts us to trigger a retry. ⚠️

Let's get JobId and ScheduleId - we will need them later. We can extract them from the URL of the browser #/jobs/1950702/schedules/5e704368-e0bc-4d30-beae-742e1c05a65f/overview. In our case, jobId: 1950702 and scheduleId: 5e704368-e0bc-4d30-beae-742e1c05a65f

Step 2

Our app will fail immediately, but we haven't configured a retry. Let's prepare for that.

Step 3

This will be done in the ANS dashboard. We can provide the configurations as JSON (with import), but let's do it in the UI and we can later export it.

So from the list of instances, let's open the Alert Notification service instance.

Create Conditions

For eventType EQUALS JobSchedulerJobExecution. See more info in Help Portal - SAP Job Scheduling service events.

For severity EQUALS ERROR - so that only errors are matched. See more info on conditions on the Help Portal.

For resource.tags.scheduleId EQUALS 5e704368-e0bc-4d30-beae-742e1c05a65f - so that only this specific schedule is retriggered. If we have not specified this, we can create a loop of constant retries. For more info on what the resource contains check the Help Portal.

Create Action

This is the interesting part. Here will need to call the Job Scheduling service API. To do that, we will use WEB HOOK OAUTH, which means that we will need credentials to call the API. We can get them from the application or by creating a service key. 🔑

Let's use a service key. We can create it from the Instances page in the SAP BTP cockpit. Choose you Job Scheduler instance and in the section Service Keys, choose Create. Check more info on how to create service keys.

Then we will need some values, we can select the my-key and choose Form. Then we need:

url - this is the Job Scheduler service API endpoint
uaa - this is the section for oAuth authentication
- clientid
- clientsecret
- url - authentication url

Now back to ANS dashboard to create the action.

Create Subscription

It will combine our 3 conditions to do our action - the webhook.

And that's it, we are ready! Now we only need to wait for the next failed execution (or trigger it ourselves by deactivating -> activating the schedule). ⏳

Step 4 and 5

In these two steps we don't need to do anything, we only need to check the result. But what to check?

First, let's see the failed execution: 🔍

It has id 98e95540-2024-48f7-9a28-33e3b4e3aebe. We can follow this and see the new schedule that retried this execution.

And when we check the list of schedules, we see the new one-time schedule that was executed. ✅

We can also check the Events for the job and see that the new schedule was created by the technical integration (your clientid).

And that's it! 🚀 You have created a mechanism to retry job executions. You can now unleash your imagination for more integration scenarios between Job Scheduling service and the Alert Notification service (ANS).

Troubleshooting 🛠️

If you have problems with the ANS - for example, the events are not delivered, you can call the ANS REST API and get information about what is going wrong. See undelivered events.

Appendix

Here is how the exported configuration from ANS looks like. You can adjust the values in the JSON below, upload it into your ANS instance and get the integration working even faster.

{
  "actions": [
    {
      "type": "WEB_HOOK_OAUTH",
      "name": "webhook-to-job-scheduling-service",
      "state": "ENABLED",
      "description": "This will use the OAuth credential flow - call the OAuth service with clientid and secretid and fetch a token to call the Job Scheduling service",
      "properties": {
        "password": null,
        "tokenUrl": "https://job-scheduling-testing.authentication.eu12.hana.ondemand.com/oauth/token?grant_type=client_credentials",
        "sslTrustAll": "false",
        "destination": "https://jobscheduler-rest.cfapps.eu12.hana.ondemand.com/scheduler/jobs/1950702/schedules",
        "payloadTemplate": "{\n\"active\": true,\n \"description\": \"Retry runLog {resource.tags.runLogId}\",\n \"time\": \"now\"\n}",
        "username": "<redacted>"
      }
    }
  ],
  "conditions": [
    {
      "name": "JobSchedulerJobExecution",
      "mandatory": true,
      "propertyKey": "eventType",
      "predicate": "EQUALS",
      "propertyValue": "JobSchedulerJobExecution",
      "labels": [],
      "description": "Will match events for job execution. If this is a task, you will need to match a different event."
    },
    {
      "name": "scheduleId-5e704368-e0bc-4d30-beae-742e1c05a65f",
      "mandatory": true,
      "propertyKey": "resource.tags.scheduleId",
      "predicate": "EQUALS",
      "propertyValue": "5e704368-e0bc-4d30-beae-742e1c05a65f",
      "labels": [],
      "description": "So that only this specific schedule is re-triggered. If we did not specify this, we can create a loop of constant retries."
    },
    {
      "name": "SeverityError",
      "mandatory": true,
      "propertyKey": "severity",
      "predicate": "EQUALS",
      "propertyValue": "ERROR",
      "labels": [],
      "description": "So that only errors are matched, we can of course do action on SUCCESS or WARNING"
    }
  ],
  "subscriptions": [
    {
      "name": "RetryFailingJob",
      "conditions": [
        "JobSchedulerJobExecution",
        "SeverityError",
        "scheduleId-5e704368-e0bc-4d30-beae-742e1c05a65f"
      ],
      "actions": [
        "webhook-to-job-scheduling-service"
      ],
      "state": "ENABLED"
    }
  ]
}

Changes Introduced in APIRule v2alpha1 and v2

2025-02-27T14:48:32.576000+01:00

APIRule custom resource (CR) in version v1beta1 has been deprecated and will be removed on May 12, 2025. Version v2alpha1, introduced for testing purposes, will become deprecated on March 31, 2025, and removed on June 16, 2025. The stable APIRule v2 is planned to be introduced in the regular channel on March 31, 2025. For more information on the timelines, see APIRule migration - timelines.

To migrate your APIRule CRs to version v2, follow the procedure described in the blog posts APIRule migration - noAuth and jwt handlers and APIRule migration - Ory Oathkeeper based OAuth2 handlers. Since the APIRule CRD v2alpha1 is identical to v2, the migration procedure for both versions is the same.

This blog post presents all the significant changes introduced in APIRule v2alpha1 and v2. Since version v2alpha1 is identical to the stable version v2, you must consider these changes when migrating either to version v2 or v2alpha1.

A Workload Must Be in the Istio Service Mesh

To use APIRules in versions v2 or v2alpha1, the workload that an APIRule exposes must be in the Istio service mesh. If the workload is not inside the Istio service mesh, the APIRule does not work as expected.

Required action: To add a workload to the Istio service mesh, enable Istio sidecar proxy injection.

Internal Traffic to Workloads Blocked by Default

By default, the access to the workload from internal traffic is blocked. This approach aligns with Kyma’s “secure by default” principle. In one of the future releases of the API Gateway module, the APIRule CR will contain a new field internalTraffic set to Deny by default. This field will allow you to permit traffic from the CR. For more information on this topic, see issue #1632.

CORS Policy Is Not Applied by Default

Version v1beta1 applied the following CORS configuration by default:

Access-Control-Allow-Origins: "*"
Access-Control-Allow-Methods: "GET,POST,PUT,DELETE,PATCH"
Access-Control-Allow-Headers: "Authorization,Content-Type,*"Copy to clipboardErrorCopied

Versions v2 and v2alpha1 do not apply these default values. If the corsPolicy field is empty, the CORS configuration is not applied. For more information, see architecture decision record #752.

Required action: To use default CORS values defined in the APIRule v1beta1, you must explicitly define them in the corsPolicy field.

Path Specification Must Not Contain Regexp

APIRule in versions v2 and v2alpha1 does not support regexp in the spec.rules.path field of APIRule CR. Instead, it supports the use of the {*} and {**} operators. See the supported configurations:

Use the exact path (for example, /abc). It matches the specified path exactly.
Use the {*} operator (for example, /foo/{*} or /foo/{*}/bar). This operator represents any request that matches the given pattern, with exactly one path segment replacing the operator.
Use the {**} operator (for example, /foo/{**} or /foo/{**}/bar). This operator represents any request that matches the pattern with zero or more path segments in the operator’s place. It must be the last operator in the path.
Use the wildcard path /*, which matches all paths. It’s equivalent to the /{**} path. If your configuration in APIRule v1beta1 used such a path as /foo(.*), when migrating to the new versions, you must define configurations for two separate paths: /foo and /foo/{**}.

For more information on the APIRule specification, see APIRule v2alpha1 Custom Resource.

Required action: Replace regexp expressions in the spec.rules.path field of your APIRule CRs with the {*} and {**} operators.

JWT Configuration Requires Explicit Issuer URL

Versions v2 and v2alpha1 of APIRule introduce an additional mandatory configuration filed for JWT-based authorization - issuer. You must provide an explicit issuer URL in the APIRule CR. See an example configuration:

rules:
- jwt:
    authentications:
        -   issuer: {YOUR_ISSUER_URL}
            jwksUri: {YOUR_JWKS_URI}

If you use Cloud Identity Services, you can find the issuer URL in the OIDC well-known configuration at https://{YOUR_TENANT}.accounts.ondemand.com/.well-known/openid-configuration.

Required action: Add the issuer field to your APIRule specification when migrating to the new version. For more information on migration procedure for the jwt handler, see SAP BTP, Kyma runtime: APIRule migration - noAuth and jwt handlers.

Removed Support for Oathkeeper

In one of the releases after 3.1.0, Oathkeeper will be moved to its own namespace. Support for Oathkeeper will be removed later. Once the support is removed, Oathkeeper will be installed in the clusters, but the API Gateway module will neither use it nor manage it.

Removed Support for Oauthkeeper OAuth2 Handlers

The APIRule CR in versions v2 and v2alpha1 does not support Oathkeeper OAuth2 handlers. Instead, it introduces the extAuth field, which you can use to configure an external authorizer.

Required action: Migrate your Oathkeeper-based OAuth2 handlers to use an external authorizer. To learn how to do this, see SAP BTP, Kyma runtime: APIRule migration - Ory Oathkeeper-based OAuth2 handlers and Configuration of the extAuth Access Strategy.

Removed Support for Oauthkeeper Mutators

The APIRule CR in versions v2 and v2alpha1 does not support Oathkeeper mutators. Request mutators are replaced with request modifiers defined in the spec.rule.request section of the APIRule CR. This section contains the request modification rules applied before the request is forwarded to the target workload. Token mutators are not supported in APIRules v2 and v2alpha1. For that, you must define your own extAuth configuration.

Required action: Migrate your rules that rely on Oathkeeper mutators to use request modifiers or an external authorizer. For more information, see Configuration of the extAuth Access Strategy and APIRule v2alpha1 Custom Resource.

Removed Support for Opaque Tokens

The APIRule CR in versions v2 and v2alpha1 does not support the usage of Opaque tokens. Instead, it introduces the extAuth field, which you can use to configure an external authorizer.

Required action: Migrate your rules that use Opaque tokens to use an external authorizer. For more information, see Configuration of the extAuth Access Strategy.

SAP User Experience Q1/2025 Update – Part 6: SAP Analytics Cloud & SAP Business Technology Platform

2025-02-28T06:00:00.017000+01:00

This sixth post in my series gives an overview of latest user experience (UX) innovations in SAP Analytics Cloud and SAP Business Technology Platform (BTP). The highlights for SAP Analytics Cloud are the support for the SAP Fiori visual theme Horizon, giving users an experience consistent with other products; the Compass for business users to easily do Monte-Carlo simulations; Video Data Stories, and enhancements to the just ask natural language query capability. For SAP BTP, have a look at the new UX for the SAP Integration Suite, SAP BTP Kyma runtime, and SAP Build Apps.

SAP Analytics Cloud

In addition to full support for the SAP Fiori visual theme Horizon, the Q1/2025 release of SAP Analytics Cloud released on February 26th brings some great new experiences for users. I’ll focus here on these three:

The new Compass for easy Monte Carlo simulations by business users.
Video Data Stories, enabling business users to easily create videos to present their stories.
Just Ask enhancements.

Subscribe to the SAP D&A Quarterly Newsletter to get the latest news, customer stories, events, and innovations delivered directly to your inbox.

Support for SAP Fiori visual theme Horizon

SAP Analytics Cloud now also supports the SAP Fiori visual theme Horizon – not only for embedded uses cases as before, but now stand-alone too. As a result, users of our cloud applications can have a consistent experience when switching to SAP Analytics Cloud. Figure 1 shows an example.

Figure 1: SAP Analytics Cloud with the SAP Fiori visual theme Horizon. ALT Text: An example screenshot showing what chart, table, input control and widgets look like with the Horizon visual theme.

Find out more in this blog post:

Horizon Theme and Templates for Stories in SAP Analytics Cloud.

SAP Analytics Cloud Compass for Monte Carlo Simulation

Non-technical users can now easily perform real-time multivariant analysis without prior IT setup or advanced statistic skills. You can trigger a new compass simulation via the toolbar or directly from a dashboard. If things are not going as planned, for example the gross revenue in the current quarter, you can trigger a simulation which will automatically detect the drivers and display probability distributions for gross revenue.

You can choose between low, medium or high precision, which uses 1,000, 10,000 or 100,000 iterations respectively. As you can see in Figure 2, this is visualized interactively, showing the probability for the current value. This is visualized by showing how likely the operating income will be exceeded (23% in the example) and how likely it will not be achieved (77%). At the bottom, you can see ranges for the pessimistic, realistic and optimistic cases (lower 5%, middle 90% and upper 5%). Since it is interactive, you can change the planned value and directly see how likely you are to exceed or not achieve it – as you can see in Figure 2.

Figure 2: SAP Analytics Cloud Compass for Monte Carlo Simulation by business users. ALT Text: This short embedded GIF video shows a screen with a header “Target: Operating Income / Amount GC – Million USD”. Below that, a chart showing a probability distribution for Operating Income, looking similar to a normal distribution. It has a vertical line at 87.51, indicating that the probability of less income is 5% (labelled “Pessimistic Case”, and a vertical line at 175.20, indicating the probability of more income is 5% (labelled “Optimistic Case”). The 90% band in between is labelled “Realistic Case”, with a slider at 151.67 (shown in a box above the slider), with 77% shown on the left and 23% on the right (the probability of income being lower or higher). The user moves the slider to the left with the mouse to the value 106.10, and the two values to the left and right change to 16% and 84%. Then the user types in a value of 100, resulting in 12% and 88%.

Find out more about this, and watch it in action in this video:

Video: SAP Analytics Cloud: Top 5 New Features in Q1 2025 (Section 2 on Compass) (2:35 min.)

Video Data Stories

Another great user experience innovation with the latest release is the ability for business users to directly create short videos to present their data stories out of SAP Analytics Cloud – Figure 3 shows an example.

Figure 3: Part of a Video Data Story created from SAP Analytics Cloud. ALT Text: A short video with animated text and charts in a mobile phone vertical format. It starts with the title “Sep 2024, results”, followed by “Gross Margin”. Then the text “$8.66 million” glides in, followed by “delta 2024 Aug +37.45%”. Next, these disappear and “Gross Margin per Location” appears, above a horizontal bar chart with three bars for California ($6.78 M), Nevada ($0,52 M) and Oregon ($1.36 M). This chart then morphs into a new horizontal bar chart with five bars for Los Angeles ($2.45 M), Oakland ($1.22 M), San Diego ($1.62 M), San Francisco ($0.29 M), and San Jose ($1.21 M).

It is really easy to create video data stories: you can select which data you want to show, how you want to display it (Figure 4), and select a background image and background music. We provide a selection of images and music out of the box for you to choose from.

Figure 4: Creating Video Data Stories in SAP Analytics Cloud. ALT Text: The image shows part of a screenshot showing an SAP Analytics Cloud page with bar charts and a pie chart, partly covered by a section below which shows five views of the video data story, containing (from the left) the title, a horizontal bar chart with three bars, a pie chart, a line chart, and a KPI as a number.

Find out more in this blog post, these videos and the documentation:

Video Data Story, a brand-new way of story telling in SAP Analytics Cloud.
Video: Video Data Story – Sample Analysis Report (33 seconds).
Video: SAP Analytics Cloud: Top 5 New Features in Q1 2025 (Section 3 on Video Data Stories) (1:30 min.)
What’s New Viewer – SAP Analytics Cloud.

Just Ask Enhancements

The popular just ask feature enables you to use natural language to query SAP Analytics Cloud. It was introduced with this blog post:

Initial Release of SAP Analytics Cloud Just Ask.

With the Q1/2025 release, we improve just ask by supporting currency conversion in acquired data models. We also allow users to limit the number of data points in bar charts, as well as leveraging SAP HANA Cloud vector engine.

Currency conversion means that, if you have data with multiple currencies, you can change the currency used to summarize all the values using natural language. Also, you can choose to show all the results in the respective local currency, so that for example the mouse-over shows the details and the currency for that country, as shown in Figure 5, where the user has asked “sales in local currency actual compared to forecast”.

Figure 5: SAP Analytics Cloud just ask now supports currency conversion – here you see a visualization in local currency per country. ALT Text: The image shows a screenshot with Just Ask at the top left, with a text entry field containing “sales in local currency actual compared to forecast”. Below that, a horizontal bar chart showing “Top 10 Sales in Local Currency per Country”, with countries Denmark, Belgium, Italy, Sweden, France etc. Wherever the actual is higher than forecast the difference is marked with a green bar, where it is lower with a red bar. The user has placed the mouse over the green bar for Sweden, showing a popover containing the text “Sales in Local Currency, SEK909.2 k, Country Sweden, in green: Actual – Forecast SEK168.7K”.

Watch it in action here:

Video: SAP Analytics Cloud: Top 5 New Features in Q1 2025 (Section 4 on just ask) (1:34 min.)

Further Innovations and Outlook on Joule Analytical Pattern

You can see the above three innovations, plus “Seamless Planning” and “Job Monitor – Multi-Action support” in this video:

SAP Analytics Cloud: Top 5 New Features in Q1 2025.

As I mentioned in Part 1 of this series, we plan to make the new analytical pattern for Joule available in Q2/2025, which will be powered by this latest release of SAP Analytics Cloud (as usual for forward-looking statements, our plans are subject to change). This means users of products that support Joule, such as SAP S/4HANA Cloud or SAP SuccessFactors, will be able to use Joule to query SAP Analytics Cloud and get analytical insights directly within Joule (the Joule Analytical Pattern). It will be powered by SAP Analytics Cloud, with data from models that are indexed by the Just Ask feature of SAP Analytics Cloud.

SAP Business Technology Platform

SAP Integration Suite

The SAP Integration Suite now also supports the SAP Fiori visual theme Horizon, as you can see below in Figure 6.

Figure 6: SAP Integration Suite with the SAP Fiori visual theme Horizon. ALT Text: The image shows three overlapping screenshots: at the left, back, “Employee Service” with buttons for triggering GET, POST, GET, PATCH URLs. Next, in the middle, the Capabilities page showing three rows of four columns of cards such as “Build Integration Scenarios”, “Manage APIs”, “Manage Business Events”, each with two to three lines description. On the right a page showing details of “SAP S/4HANA Cloud Integration with Workday”. The “Artifacts” tab has been selected, showing a list of artifacts with columns Name, Type, Version and Actions. The first entry has a name “Integrate Workday employee information”, the second one “Replicate Cost Centers from SAP S/4HANA Cloud to Workday”.

SAP BTP Cockpit

Customers can now get an easy to understand overview of their costs and usage of SAP Business Technology Platform with the new costs and usage application (Figure 7).

Figure 7: SAP BTP Cockpit – Costs and Usage. ALT Text: The image shows an example screenshot. The header reads “Global Account: Automotive Rentals, Inc. – Costs and Usage”, below that a small card “Global Account Info” with Account ID, Account Type “Customer”, Contract Currency “USD” and a wide card “Cloud Platform Enterprise Agreement” with a chart showing Cloud Credit Usage, a KPI value for the Monthly Cloud Credit Usage and a vertical bar chart for Monthly Cloud Credit Usage Trend. Below that the majority of the screen shows the Billing tab, with the text “This view displays the monthly billable service charges for your global account”. Below that a flexible column layout with a list of Service Plans on the left, with “Business Application Studio – standard-edition” selected, and on the right a hierarchical table showing Directories and Subaccounts. At the bottom a filled line chart showing the cumulative list prices per month over the last 12 months.

SAP BTP, Kyma Runtime

Kyma now supports modules, for adding functionalities to your cluster. To manage these, the Kyma dashboard has been redesigned, with the SAP Fiori visual theme Horizon, as you can see in Figure 8.

Figure 8: Kyma dashboard with the SAP Fiori visual theme Horizon, now supporting modules. ALT Text: The image shows a screenshot with the “Cluster Overview” selected in the left side navigation bar. The screen has a large header card “Introducing Modules” with buttons for “Add Modules” and “Learn More”. Below that a section “Resource Details” containing one card, followed by a section “Monitoring and Health” containing further cards (“Memory Usage”, “CPU Usage”). A further smaller screenshot covers the bottom right of the other one, showing a Modules column in the middle, and a wider “Add Modules” panel on the right, containing four cards “SAP BTP Operator”, “Keda”, “Serverless”, “Telemetry”.

SAP Build Apps

SAP Build Apps enable business users to define their own simple applications without having to go to their IT teams to find developers. For these users, an intuitive user experience is paramount, and hence we continuously look to see where we can make it even better. One aspect of intuitiveness is providing a consistent experience across various products – hence SAP Build Apps also runs with the SAP Fiori visual theme Horizon.

Figure 9: SAP Build Apps with the SAP Fiori visual theme Horizon. ALT Text: The image shows a screenshot with a heading “Choose Configuration to Build” above six square cards “Android (AAB)”, “Android (APK)”, “iOS (Ad hoc)”, “Web (MTAR)”, “Web (ZIP)”, “workzone build”. Below that a table “Build History” showing two lines for “iOS (Ad hoc)”.

Here are some of the recent improvements:

You can create a project version directly now by releasing the project
Discover, integrate, and use any preconfigured action that is published in the SAP Build Library: you can now easily discover published Actions in SAP Build Apps via the SAP Build Library and install them into your Build Apps project, consume and trigger them as part of your application’s business logic via the Trigger Action flow function.
In the History tab, you can now see all previously saved states of the app. Using the Restore button, you can restore the application to the respective saved state.
You can duplicate pages in the page preview header.
You can use the updated Build service, which comes with a better look and feel, and an improved user experience:
- Build and Deploy Web Applications.

The details matter with UX! To improve the user experience, we have updated the navigation menu in the global toolbar (Figure 10). App developers now have access to the Variables directly from the menu. The previous UI Canvas and Data tabs are now renamed respectively to User Interface and Integrations. To save space, the less frequently used Theme, Navigation, Authentication and Help options are now grouped under the App Settings drop-down menu. In the upper right corner, you can access the Preview button. Next to it is the Publish button, which enables you either to Create a Release Version or to Build and Deploy.

Figure 10: The new navigation menu in the SAP Build Apps global toolbar. ALT Text: A screenshot showing the header of SAP Build Apps, which contains tabs “User Interface”, “Variables”, “Integrations”, and “App Settings” with a drop-down menu with entries “Navigation”, “Authentication”, “Theme”, and “Help”.

Continue Reading

I hope you enjoyed this sixth part, covering SAP Analytics Cloud and SAP Business Technology Platform.

The final part seven is available now, covering latest innovations for UI developers, for both web and mobile:

SAP User Experience Q1/2025 Update – Part 7: UI Design and Technology for Web and Mobile.

Part 1 of the series lists all the parts, and links to those parts that have already been published:

SAP User Experience Q1/2025 Update – Part 1: Many New Innovations Available (AI, Joule and More).

Do keep posting your experiences and recommendations yourself in the SAP Community, with the SAP Fiori and/or the User Experience tag! In case you are wondering how to get a list of the most recent blog posts on SAP Fiori and User Experience in our new SAP Community, use these links:

For general information on design at SAP and SAP Fiori, check out:

SAP BTP: Cloud Application Programming Model

2025-03-04T07:09:41.141000+01:00

SAP Cloud Application Programming (CAP) Model exposes the ability to extend standard Cloud, on-premises and hybrid application functionality with flexible custom business logic scripted using the developer’s choice of programing language (SQL, SQL Script, Python, Node.js and JavaScript) and exposing the functionality to various user interfaces (UIs) e.g. Microsoft Power Bi, SAP Fiori, Dataiku and Google Big Query using various integration frameworks e.g. OData v4,JDBC/ODBC depending on the case study.

The developer takes pride in delivering a scalable extended functionality, embedding robust real-time monitoring capabilities to ensure a health life cycle and protecting the functionality with secure authentication protocols e.g. OAuth 2.0, JWT Bearer, SAML version 2.0 and RFC Specification.

Furthermore, the developer ensures a reliable and robust solutions by implementing continuous integration and continuous delivery CI/CD pipelines that automates testing, building and deployment of code changes this strategy ensures a speedy development and delivery cycle.

Traditionally developers extended business logic directly on-premises on the ABAP application server. With the ever-changing world of technology, digital transformation has become essential for organization to say afloat of competitors and therefore the programming model paradigms and capabilities of extending SAP solutions have evolved drastically and provides a seamless experience into the cloud.

Figure 1:

Architectural Paradigm Shift from Classic ABAP App server to CAP App server

Source: Thomas Jung, SAP HANA Extended Application Services blog, URL: https://community.sap.com/t5/technology-blogs-by-sap/sap-hana-extended-application-services/ba-p/12963426/page/4

The SAP Cloud Application model comes with a rich set of languages, libraries, and tools for building enterprise-grade services and applications. It guides developers along a 'golden path' of proven best practices and a great wealth of out-of-the-box solutions to recurring tasks:

Figure 2:

SAP Cloud Application Model Architecture

Source HTTPS://Cap.cloud.sap , URL: https://cap.cloud.sap/docs/about/

The below diagram categories the skill set of SAP Cloud Developer based on the scope of the development either being ABAP or Non-ABAP. Each with its unique set of tools and methodologies:

Figure 3:

SAP Cloud Developer skill set

Source: Building side-by-side extensions on SAP BTP, URL: https://learning.sap.com/learning-journeys/build-side-by-side-extensions-on-sap-btp/identifying-the-need-for-side-by-side-extensibility_f1e838f0-f02a-43b4-8896-cedc25a7d5d0

The Cloud Application Programming model enables a collaboration of agile cross functional teams inclusive of but not limited, depending on the scope of the development: citizen developers (low-code/no-code), Professional developers (Scripting, OOP), business analysts, data engineers and application specialists to model robust data models:

Figure 4:

Agile cross functional team

Source: Investigating the Impact of Cross-Functional Teams on Business Success

URL: https://www.iienstitu.com/en/blog/cross-functional-teams

SAP Cloud Application Programming (CAP) Model enables a culture where people regardless of their title or background, work together to imagine, develop, deploy, and operate a solution. This strengthens the trust between employees and authentic healthy work relationships.

Thank you all for taking a glimpse into the above Content. Please don’t for get to like, comment and share.

Abbreviations:

APP: Application

CAP: Cloud Application Programing

CDS: Core Data Services

CI/CD: Continuous Integration and Continuous Delivery

JWT: JSON Web token

OData: Open Data Protocol

RFC: Remote Function Call

SAML: Security Assertion Markup Language

SQL: Structured Query Language

UIs: User Interfaces

Beyond SAP Cloud - Episode 9: BTP Runtime Strategy

2025-03-17T06:22:06.849000+01:00

This episode explores BTP runtime strategy, discussing the different types of runtimes available: Kyma, Cloud Foundry and ABAP. Kyma, based on Kubernetes, runs on-demand, offering flexibility and cost-effectiveness for use cases that don't require to be up and running 24/7. Cloud Foundry is ideal for always-on applications, while ABAP may be more suitable for large-scale, enterprise applications. The choice of runtime depends on factors like developer skills, company policies and the scale of applications to be built. Companies must evaluate their needs to determine the best runtime for their BTP strategy.

Takeaways

BTP (Business Technology Platform) has multiple runtime options: Kyma, Cloud Foundry and ABAP.
Kyma is based on Kubernetes and operates on-demand, starting and stopping when required.
Business Application Studio is a good example for a Kyma case. It is maybe not running on Kyma but uses the same concept under the hood, Kubernetes pods. With this, BAS doesn’t need to run all the time and only requires resource when it is started. That’s also the reason you need to start it every morning.
Kyma's pay-per-use model might be a cost-effective option if your use case requires non-24/7 operations.
Cloud Foundry is more suitable for applications that need to be operational 24/7, like Fiori applications.
Cloud Foundry is generally a more affordable option for always-on applications, offering greater accessibility.
Cloud Foundry supports building applications using various development languages and/or frameworks, such as Java, NodeJS, GO and Python.
Companies can choose to activate multiple runtimes or select one based on their specific needs.
ABAP could be more expensive for single applications, but it might become cost-effective for large-scale application development.
Each company should assess its developer skill set and the number of applications to be built when deciding on the best runtime strategy for BTP.

Explaining SAP Joule for HR Business Users & Functional Consultants.

2025-03-23T10:47:21.753000+01:00

SAP Business Technology Platform (BTP)

SAP Business Technology Platform (SAP BTP) is the unified, business-centric, open data and development platform for the entire SAP ecosystem. This statement means a lot so let me explain it in a simple term

Development friendly- The platform provides ease of development for developers makes it an efficient place for developers and helps them in increasing efficiency as well as gives them a charm.
Seamless Integration- It can talk with any other technology using its strong integration capability.
The most important Value for Data- Nothing can be more important for a Business than data. It will provide a next-gen experience with data using its analytics, data lake, in memory powerful calculations.

High-Level BTP Basics and Set Up

BTP first carves out a private IP CIDR range from the network space. The BTP operation team deploys a set of virtual machines certified to HANA in that range.

The first layer is Platform Core, which uses Gardener. Gardener is SAP’s Kubernetes management tool and the main fundamental for BTP workload

Some other runtimes are also deployed in the platform core. One of them is Cloud Foundry (which is now used instead of Neo), others are Kyma, ABAP, etc.

BTP also has other sets of Kernel Services that are required for building SAP’s Intelligent Enterprise version. This concept is the same as the Linux kernel. Just for the sake of high-level understanding, Kernel is the main layer between OS and hardware. It helps in the management of memory, space, identity, audit log, etc.

Once the platform core is set up different technology units deploy their services that use one or more of these runtimes and kernel services. The whole portfolio of BTP includes Analytics, DBMS, Integration, and Extension suite.

BTP- Accounts and Directory

Global Accounts - It’s the realization of the contract of customers made with SAP used to mange the entitlements, quotas, members, subaccounts and directories.

Directories - allows the customer to organize and manage their subaccounts according to their technical and business needs.

Subaccounts - enable the customers to structure a global account according to their organization's and project's requirements concerning members, authorizations, and entitlements.

Entitlements are the right of customers to provision and consume the resources, as per their plan which for example can be PAYG or Fixed Contracts etc.

Directories can contain directories and subaccount. Subaccounts of one or more can be created directly under a global account. As we can understand this is more from the angle of security & authorizations.

BTP- Authorization

Global Account Administrator – A user is created at the global account successful contract establishment. The user (Global Account Administrator) from the customer side is given the required authorizations by SAP to manage entitlement and create directories and subaccounts.

The administrator can also create more than one administrator to share the rights and privileges at the Global Account Level. The administrator creates a subaccount administrator.

The subaccount administrator can create both business users/developers and assign required roles and authorization at the subaccount level

SAP Joule- Basics and Architecture

Before we start with Joule let’s start with the basics and foundation behind it.

Machine Learning :Machine learning (ML) is a field of study in artificial intelligence concerned with the development and study of statistical algorithms that can learn from data and generalize to unseen data, and thus perform tasks without explicit instructions

Example: A human baby is trained to learn and understand different relations in the family. Similarly, iPhone facial recognition is made to understand to it which one is the face of that particular iPhone owner.

LLMS: A large language model (LLM) is a type of machine learning model designed for natural language processing tasks such as language generation. LLMs are language models with many parameters and are trained with self-supervised learning on a vast amount of text.

Example: When we type to search for anything in Google it recommends some text in prediction.

Document Grounding: "Grounding" is a process that combines generative Large Language Models (LLMs) with advanced information retrieval to improve the quality and accuracy of responses, without the time, complexity, and expense of training or fine-tuning an LLM with company-specific data. Grounding uses a customer’s knowledge sources (e.g. travel policy, enablement content, service manuals, FAQs, etc.) to supplement an LLM's internal representation of information, which can help models be more accurate and reliable.

LLMs & Joule

By Integrating the power of LLMs and SAP-rich business context, SAP has launched JOULE. Joule helps users to easily navigate SAP systems, execute transactions, find information, and get analytical insights, making employees 80% more efficient.

Relevant content for our users → ensuring Joule understands a user's context. This includes roles and permissions. But also, which SAP products the user is using.
Reliable results → using LLMs means that responses are grounded on SAP knowledge and the business reality of the respective customer and end user.
Joule is responsible → strict prohibition that any of our customer’s data is not used for training purposes or any other usage for any 3rd part

SAP Joule currently has the following interaction pattern.

Transactional Interaction: Example who is my manager?
Informational Interaction: What is my Leave policy in the organization?
Analytical Interactions: How many associates have completed their goal setting?
Navigational Interaction: Please take me to my address page

Joule Integration with SuccessFactors

When we log in to SuccessFactors (SF) we can see the SAP Joule icon on the SF screen ( basically a plug-in in SF). We launch Joule from SF interface. Joule ( Chatbot) will launch from the SF. The Joule instance sits in SAP BTP. It is hosted in BTP subaccount.

SAP Build Work Zone is also created. This is very important as we do a user synchronization from SAP success factors to Build Work Zone using the Identity Provisioning service.

Cloud identity services are used for authentication. So that when we launch Jould it is authenticated using IAS tenant.

The following are pre-requisite for establishing the connection between

SAP SF and Joule

1.SAP BTP Global Account.

2.Right Entitlement for Joule

3.Cloud Identity Service Admin

4.SuccessFactors Admin

5.All these user personas needs to be available

For Technical SMEs or Architects, I am sure they have this link to SAP. However, sharing it one for a ready reckoner in one place

https://discovery-center.cloud.sap/protected/index.html#/missiondetail/4451/?tab=projectboard

Run Joule

If the installation goes all good with all user personas and correct authorization then the Joule icon will be visible in the SAP SF Screen. Please note the Joule permission must be added to the SF profile of the user. This is taken care of when we run the Booster on BTP side, it creates the joule permission in SAP SF.

Big Upgrade! New and Improved SAP BTP Account Model Recommendations Are Here

2025-04-02T18:13:32.838000+02:00

We're thrilled to announce the release of the fully reworked and expanded Setting Up Your Account Model chapter in the SAP BTP Administrator's Guide. Whether you’re an experienced SAP BTP administrator or new to the platform, this updated content is designed to equip you with the knowledge to tailor your account model to your organization's specific needs.

What's New?

Explore these key topics, designed to help you refine your account setup:

Setting Up Your Account Model – Learn how to set up your global accounts, directories, subaccounts, spaces and namespaces in a in a structure that aligns with your business and development requirements.

Cloud Foundry, Kyma, or Both? – Understand the nuances of setting up account models for Cloud Foundry or Kyma, including how to combine them for maximum flexibility in both greenfield and brownfield scenarios.

Subaccounts or Spaces/Namespaces? – Explore the differences between subaccounts and spaces/namespaces and know when to use each for optimal isolation and organization.

Checklist: Drafting Your Account Model – Follow an interactive checklist, complete with step-by-step instructions to research and draft an account model that meets your company's specific business and technical needs.

Sharing SAP BTP Services – Explore options for sharing SAP BTP services across subaccounts for cost-efficiency and centralized governance.

Tools for Account Administration – Compare the key account administration tools - SAP BTP cockpit, btp CLI, APIs, Terraform, and SAP Automation Pilot. Understand their strengths and recommended usage scenarios.

Why This Matters

A well-structured account model is crucial for efficient management and scalability of your SAP BTP landscape. This updated chapter provides the insights and tools you need to create a robust setup that supports your organization's growth and innovation.

Get Started Today

Explore the new content and start refining your account model. Whether you’re looking to simplify your current setup or expand into new areas, this guide offers best practices and recommendations to support you.

Your Feedback Matters

We’re always looking to improve. If you have questions or suggestions, give us feedback – your input is crucial as we continue to update the SAP BTP Administrator's Guide.

SAP Community - SAP BTP, Kyma runtime

SAP BTP Kyma headless kubeconfig with SAP Cloud Identity Services and kyma environment bindings

Implementing SAP Kyma headless kubeconfig with

Table of Contents

CAP-JAVA implementation for Authorization Management Service (AMS)

Basic concept of AMS

General dev flow

Authorization Model Design

Assign and check your policy

SAP Business Technology Platform (BTP)

Join & Gather in SAP Cloud Platform Integration

Developing, Running, and Monitoring LangChain Applications on SAP BTP

Introduction

Steps

Prerequisites

1. Accessing Powerful LLMs via Generative AI Hub

2. Preparing a LangChain Application with SAP Build Code and Connecting it to Langfuse Pre-deployed on SAP BTP

Key Points in the Source Code:

3. Running Inference Chains with LangChain and Checking Traces on Langfuse

Conclusion

Deploying Langfuse on SAP BTP, Kyma Runtime

Introduction

Overview

Common Challenges

What is Langfuse?

Key Features and Benefits

Reference

Deployment Steps

Prerequisites

Step 1: Setting up Kyma Environment in SAP BTP

Step 2: Configuring kubectl and Verifying Connection

Retrieve the kubeconfig.yaml File

Verify Connection

Step 3: Deploying Langfuse to SAP BTP, Kyma Runtime

Clone the Source Code

Create a Namespace

Deploy Using Helm

Step 4: Accessing the Langfuse UI

Check Deployment Status

Update Service Type

Confirm Access

Sign Up and Log In

Conclusion

Developing, Running, and Monitoring LangChain Applications on SAP BTP

Aggregators: Streamlining Message Handling in Integration Flows

Subscribing SAP Commerce business events in Kyma by executing serverless Functions

Introduction

Prerequisites

Integrate SAP Commerce with BTP, Kyma Runtime

Register SAP Commerce in BTP cockpit and expose it to BTP, Kyma Runtime

Configure Kyma and check if SAP Commerce is connected in Kyma dashboard

Create serverless Function and Subscription to SAP Commerce event

Register new customer on the storefront to test "customer created" event

Conclusion

SAP BTP, Kyma runtime: APIRule migration - timelines

Timeline Overview

Milestones

October 28, 2024 - Introduced APIRule v2alpha1 (current state of the art)

March 31, 2025 - APIRule v2 stable version

May 12, 2025 - APIRule v1beta1 end of life

June 16, 2025 - APIRule v2alpha1 end of life

Summary

Part 2: Revenue Accounting and Reporting (RAR) with GenAI and RAG

Enhanced Architecture Overview

Integrated System Components

Advanced Retrieval Mechanisms

Vector Database Integration

Performance Optimization

Future Outlook

Part 1: SAP Revenue Accounting and Reporting (RAR): Foundation for Modern Revenue Management

The Evolution of Revenue Recognition

Understanding the Core Process

Contract Inception and RAI Creation

Performance Obligation Breakdown

Price Allocation and SSP Determination

Revenue Recognition Scheduling

Financial Integration and Posting

Technical Architecture and Integration

The Role of Artificial Intelligence

Implementation Impact