This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Concepts

Motivation and overview of components

Provisioning and operating an SAP Cloud Application Programming Model application on a Kubernetes cluster requires the deployment of various components in addition to the CAP application server (see a list of typical components). Some of these components can be created at the time of system provisioning, while others need to be created (or updated) at different points during the lifecycle of the application (DAY 2 operational tasks).

Using Helm charts to manage the deployment of a CAP application can support the initial system provisioning, but further lifecycle operations (such as tenant provisioning) that are initiated from external components (SAP BTP) require manual adjustment of the deployed resources. An example of such an instance would be the creation of VirtualServices (part of Istio service mesh) during tenant provisioning to route application (HTTP) requests submitted on the new tenant subdomain to the application server. Another limitation of using helm charts is the lack of control over the order in which resources are created.

You can get more control over the deployment and further automation of lifecycle operations by extending the Kubernetes API with custom resources that describe the components and the configuration of CAP applications, and controllers to reconcile them. Similar to standard controllers of Kubernetes, the custom controllers watch for changes in the custom resource objects and work towards moving the cluster state to the desired state.

CAP Operator comprises of custom resource definitions that describe the CAP application components, the controller to reconcile these resources, and other components that support the lifecycle management.

1 - CAP Operator Overview

An overview of the architecture

CAP Operator is comprised 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 to ensure consistency of custom resource objects submitted to the Kubernetes API server
  3. Subscription Server: web server for handling HTTP requests submitted by the SAP BTP saas-registry service instances during tenant subscription (and unsubscribe)

The following diagram depicts how the main components interact when deployed to a cluster:

cluster-components

Looking for more details about the CAP Operator components? Go to the next pages.

1.1 - Controller

Reconciliation of custom resource objects

To implement the CAP controller, you use the client-go from Kubernetes, which provides the required tools and utilities to interact with the Kubernetes API server. It manages custom resources that are 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.

controller

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 that have been installed in the cluster.

During the creation of a saas-registry service instance (in the provider subaccount), callback URLs are configured, which point to the subscription server routes.

When a consumer tenant subscribes to an application managed by the operator, a subscription callback is received by the subscription server, which then generates the CAPTenant custom resource object.

The subscription server returns an Accepted (202) response code and starts a routine/thread, which keeps polling for the tenant status until the changes to the CAPTenant are then independently reconciled by the controller.

Once the tenant provisioning process has completed (or has failed), the tracking routine will return the appropriate status to the SaaS Registry via an asynchronous callback (by obtaining the necessary authorization token).

subscription

(More details about asynchronous tenant subscription.)

Such an asynchronous processing allows us to avoid timeouts during synchronous calls, as well as schedule dedicated jobs (via CAPTenantOperation) for completion of the subscription and perform any further tasks required in the cluster (for example, create a VirtualService corresponding to 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, 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.