From Concept To Action: Hands-On With The CAP Oper...

Introduction

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

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

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

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

Why the Partner Reference Application?

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

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

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

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

1. Project Preparation & Plugin Integration

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

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

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

2. Containerization and Registry Push

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

3. Transitioning to Custom Resources (CRDs)

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

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

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

Prerequisites to Get Started

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

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

Conclusion & Next Steps

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

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

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

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

Source link