Concepts
Motivation and overview of components
Provisioning and operating an SAP Cloud Application Programming Model (CAP) application on a Kubernetes cluster requires deploying various components in addition to the CAP application server (see a list of typical components). Some of these components can be created during initial system provisioning, while others need to be created or updated at different points in the application lifecycle (Day 2 operations).
Using Helm charts to manage the deployment of a CAP application supports initial system provisioning, but further lifecycle operations (such as tenant provisioning) triggered by external components (SAP BTP) require manual adjustment of the deployed resources. For example, Istio VirtualService resources must be created during tenant provisioning to route incoming HTTP requests on the new tenant subdomain to the application server. Another limitation of Helm charts is the lack of control over the order in which resources are created.
You can gain greater control over deployment and automate lifecycle operations by extending the Kubernetes API with custom resources that describe CAP application components and their configuration, along with controllers to reconcile them. Like standard Kubernetes controllers, these custom controllers watch for changes in custom resource objects and work to bring the cluster state to the desired state.
CAP Operator comprises custom resource definitions that describe CAP application components, a controller that reconciles these resources, and additional components that support lifecycle management.
1 - CAP Operator Overview
An overview of the architecture
CAP Operator consists of the following components:
- CAP Controller: A native Kubernetes controller that reconciles custom resources defined as part of the operator.
- Webhooks: Validating webhooks that ensure consistency of custom resource objects submitted to the Kubernetes API server.
- Subscription Server: A web server that handles HTTP requests submitted by SAP BTP
saas-registry service instances during tenant subscription and unsubscription.
The following diagram shows how the main components interact when deployed to a cluster:
For more details about each component, see the following pages.
1.1 - Controller
Reconciliation of custom resource objects
The CAP controller uses client-go from Kubernetes, which provides the tools and utilities needed to interact with the Kubernetes API server and manage the custom resources defined by CAP Operator.
The controller uses Informers to watch certain resources and invokes registered event handlers when these resources are modified. To streamline the processing of such notifications, rate-limiting queues are implemented that store changes and allow processing of items in independent reconciliation threads (goroutines). This design enables sequential processing of changed items and avoids conflicts.
The following namespaced custom resources are reconciled by the CAP controller:
CAPApplication: Defines a high-level application, its domains, and the consumed SAP BTP services.CAPApplicationVersion: A child resource of CAPApplication that contains container images used to deploy application components (workloads) of a specific version.CAPTenant: A child resource of CAPApplication that corresponds to an SAP BTP subaccount subscribed to the application.CAPTenantOperation: Represents a provisioning, deprovisioning, or upgrade operation on a tenant, scheduled as a child resource of a CAPTenant and executed as a sequence of specified steps.
Parent-child relationships between custom resources are established by defining owner references for the children.
1.2 - Subscription Server
Integration with SAP Software-as-a-Service Provisioning service (SaaS)
The Subscription Server handles HTTP requests from the SAP Software-as-a-Service Provisioning service for tenant subscription operations on SAP Cloud Application Programming Model applications installed in the cluster.
During the creation of a saas-registry service instance (in the provider subaccount), callback URLs are configured to point to the subscription server routes. Additionally, the getDependencies URLs can also be configured to point to the subscription server routes.
When a consumer tenant subscribes to an application managed by the operator, the subscription server receives the callback, validates the request, and creates a CAPTenant custom resource object for the identified CAPApplication.
The subscription server returns an Accepted (202) response and starts a background routine that polls for tenant status while the CAPTenant changes are independently reconciled by the controller.
Once the tenant provisioning process completes (or fails), the tracking routine returns the appropriate status to the SaaS Registry via an asynchronous callback.
(More details about asynchronous tenant subscription)
This asynchronous approach avoids timeouts during synchronous calls and enables the scheduling of dedicated jobs (via CAPTenantOperation) for completing the subscription and performing any additional cluster tasks (for example, creating an Istio VirtualService for the tenant subdomain).
2 - CAP Application Components
A typical multi-tenant SAP Cloud Application Programming Model application
A full-stack application built with the SAP Cloud Application Programming Model has the following components:
SAP BTP Service Instances
Multi-tenant CAP-based applications consume services from SAP BTP such as SAP Authorization and Trust Management Service and SAP Software-as-a-Service Provisioning service. You need to create these service instances within an SAP BTP provider account along with service keys (bindings) that generate the credentials used by the application to access these services.
CAP Application Server
The application provides data models that are deployed to the connected database. An HTTP server exposes defined services and handles server-side application logic. For more details, see the SAP Cloud Application Programming Model documentation. It is also possible to split the application into multiple servers (services) that work together.
CAP Components to Support Multitenancy
CAP provides the module @sap/cds-mtxs, which can be operated as a sidecar (a component running independently from the application server). This component handles requests related to tenant management, such as onboarding, which creates the required schema in the connected database. This module also supports triggering tenant management tasks as CLI commands.
Approuter
The Approuter, or an extended version of it, authenticates requests (using the SAP Authorization and Trust Management Service) and routes them to the application servers or related services (for example, SAP HTML5 Application Repository service for SAP BTP).
SAP Fiori Applications
Multiple SAP Fiori front-end applications can connect to the CAP application back end. These UI5 applications are deployed to the SAP HTML5 Application Repository service for SAP BTP and served from there. Similarly, the application can have content specific to other services that needs to be deployed, such as the SAP Cloud Portal service.