Production Architectural Blueprint

SAP BTP Kyma & Serverless Clean Core Extensibility Guide

Architectural Domain: Side-by-Side Extensibility Runtime: Kubernetes / Kyma 2.x Clean Core Compliance: Tier-1 Side-by-Side

1. Executive Summary & The Clean Core Mandate

In modern SAP enterprise landscapes, the Clean Core paradigm requires keeping the SAP S/4HANA core strictly unmodified. While on-stack developer extensibility via ABAP Cloud (Tier-1) handles high-affinity transactional and transactional logic directly against CDS models, workloads characterized by high concurrency, non-ABAP runtime runtimes (Node.js, Python, Go), heavy asynchronous background processing, and complex multi-cloud integrations must be decoupled side-by-side.

SAP BTP Kyma runtime provides the cloud-native container and serverless environment for SAP BTP. Built on Kubernetes and open-source project Kyma, it provides fully managed Istio service mesh, CloudEvents eventing, and Kubernetes-native integration with SAP BTP services via the SAP BTP Service Operator.

2. Extensibility Decision Matrix: Kyma vs Cloud Foundry vs ABAP Cloud

Choosing the correct runtime is the primary architectural decision for any Clean Core initiative. Below is the decision framework:

Architectural Vector	ABAP Cloud (On-Stack Tier-1)	SAP BTP Kyma (Kubernetes)	SAP BTP Cloud Foundry
Data Affinity	Immediate (HANA in-memory co-located)	Network remote (OData / REST / RFC via Destination)	Network remote (OData / REST via Destination)
Workload Type	Transactional RAP business objects & BAdIs	Event consumers, Python AI, long compute, microservices	Traditional multi-tenant SaaS, standard CAP/Fiori apps
Scalability Model	Application server work processes	Horizontal Pod Autoscaler (0 to N serverless pods)	Cloud Foundry Diego cells & app instances
Runtimes Supported	ABAP Cloud language version exclusively	Node.js, Python, Golang, Java, Any Docker container	Java, Node.js (Buildpack constrained)
Protocol Flexibility	OData V4, SOAP (released), HTTP Service	gRPC, WebSockets, Kafka, CloudEvents, HTTP/REST	HTTP/REST, WebSockets

3. Kyma Serverless Functions vs Containerized Microservices

Kyma offers two deployment paradigms within the same Kubernetes cluster:

• Kyma Serverless Functions (serverless.kyma-project.io/v1alpha2 Function): Ideal for event handlers, small webhook adapters, and lightweight REST endpoints. Kyma automatically compiles inline source code (Node.js 20 or Python 3.11) with dependencies (npm or pip) into an optimized container image, mounts it into a Pod, and scales it based on traffic.
• Containerized Microservices (apps/v1 Deployment): Required when workloads need compiled languages (Golang, Rust), custom system packages (e.g. Poppler/Cairo for PDF generation), high-throughput stateful caching (Redis), or multi-container Pod topologies.

4. Event-Driven Architecture with CloudEvents & Kyma Eventing

To achieve total transactional decoupling, SAP S/4HANA emits business events via SAP Event Mesh (or Advanced Event Mesh) formatted according to the CNCF CloudEvents 1.0 standard.

In Kyma, the Subscription Custom Resource subscribes directly to these CloudEvents topics without requiring application-level polling or queue management:

apiVersion: eventing.kyma-project.io/v1alpha2
kind: Subscription
metadata:
  name: sales-order-fulfillment-sub
  namespace: prod-clean-core
spec:
  sink: http://fulfillment-service.prod-clean-core.svc.cluster.local:80/
  source: "sap.s4.beh"
  types:
    - "sap.s4.beh.salesorder.v1.SalesOrder.Created.v1"
  config:
    maxInFlightMessages: 10
    qos: "at-least-once"

5. Secure Gateway & Zero-Trust Identity with APIRule

Kyma utilizes Istio Service Mesh to secure inbound traffic. The APIRule custom resource configures the Istio VirtualService and Envoy filter to enforce JWT authentication validated against SAP Cloud Identity Services (IAS) or SAP BTP XSUAA:

apiVersion: gateway.kyma-project.io/v1beta1
kind: APIRule
metadata:
  name: order-api-gateway
  namespace: prod-clean-core
spec:
  host: order-service.api.kyma-cluster.sap
  service:
    name: order-service
    port: 80
  gateway: kyma-gateway/kyma-gateway
  rules:
    - path: /.*
      methods: ["GET", "POST"]
      accessStrategies:
        - handler: jwt
          config:
            authentications:
              - issuer: "https://my-subdomain.authentication.eu10.hana.ondemand.com/oauth/token"
                jwksUri: "https://my-subdomain.authentication.eu10.hana.ondemand.com/token_keys"
            authorizations:
              - requiredScopes: ["uaa.user", "Order.Process"]

6. SAP BTP Service Operator Integration

Instead of hardcoding API keys or downloading service keys manually, Kyma provides the SAP BTP Service Operator. Kubernetes manifests provision and bind BTP backing services natively:

• ServiceInstance: Provisions BTP services (e.g. destination, enterprise-messaging, hana) directly from Kubernetes.
• ServiceBinding: Automatically injects service credentials into a standard Kubernetes Secret conforming to the open-source servicebinding.io specification.

7. Clean Core Governance: What to Avoid in Kyma

• Anti-Pattern 1: Synchronous Point-to-Point Cascades: Never daisy-chain synchronous HTTP calls from S/4HANA into Kyma and back into S/4HANA. Use asynchronous CloudEvents and RAP Outbox instead.
• Anti-Pattern 2: Direct Database Connections: Never connect Kyma containers directly to the underlying S/4HANA SAP HANA DB via JDBC/SQL. Always consume released C1 CDS views via OData or Tier-2 RAP Facades.
• Anti-Pattern 3: Bypassing APIRule Security: Never expose raw Kubernetes Services via standard LoadBalancer without Istio Envoy JWT validation.