Concepts

• 1: CAP Operator Overview
• 1.1: Controller
• 1.2: Subscription Server
• 2: CAP Application Components

1 - CAP Operator Overview

CAP Operator consists of the following components:

1. CAP Controller: A native Kubernetes controller that reconciles custom resources defined as part of the operator.
2. Webhooks: Validating webhooks that ensure consistency of custom resource objects submitted to the Kubernetes API server.
3. 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

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 included in 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, which store the changes and allow the processing of these items in independent reconciliation threads (go routines). Such a design allows sequential processing of the changed items and avoids conflicts.

The following namespaced custom resources have been defined to be reconciled by the CAP controller:

• CAPApplication: defines a high-level application, its domains, and the consumed SAP BTP services
• CAPApplicationVersion: defines a child resource of the CAPApplication, which contains container images that will be used to deploy application components (workloads) of a specific version
• CAPTenant: represents a child resource of the CAPApplication which corresponds to an SAP BTP subaccount subscribed to the application
• CAPTenantOperation: represents a provisioning, deprovisioning, or upgrade operation on a tenant that is 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

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.

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 scheduling dedicated jobs (via CAPTenantOperation) for completing the subscription and performing any additional cluster tasks (for example, creating a VirtualService for the tenant subdomain).

2 - CAP Application Components

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, SAP Software-as-a-Service Provisioning service, and so on. You need to create these service instances within an SAP BTP provider account as well as service keys (bindings) for these instances, which generate the credentials used by the application for accessing these services.

CAP Application Server

The application provides data models that will be deployed to the connected database. An HTTP server exposes defined services and handles server-side application logic. For more details, check out the documentation of SAP Cloud Application Programming Model. It’s 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 (component running independently from the application server). This component is responsible for handling requests related to tenant management such as onboarding, which then 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, takes care of authenticating requests (using the SAP Authorization and Trust Management Service) and routes the requests 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 need to be deployed, such as the SAP Cloud Portal service.